[Deepin-Kernel-SIG] [linux 6.18.y] [FROMLIST] hwmon: raspberrypi: Add voltage input support

[Avenger-285714]

Extend the raspberrypi-hwmon driver to expose firmware-provided voltage measurements through the hwmon subsystem.

The driver now exports the following voltage inputs:

• in0_input (core)
• in1_input (sdram_c)
• in2_input (sdram_i)
• in3_input (sdram_p)

Voltage values returned by firmware are converted from microvolts to millivolts as expected by the hwmon subsystem.

Update the documentation related to it.

The existing undervoltage sticky alarm handling is preserved and associated with the first voltage channel.

Tested in -

• Raspberry Pi 3b+ (Linux raspberrypi 6.12.75+rpt-rpi-v8 V23 k510 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux)

Reviewed-by: Florian Fainelli florian.fainelli@broadcom.com
Link: https://lore.kernel.org/r/20260517080445.103962-3-chakrabortyshubham66@gmail.com
[groeck: Added missing empty line after declaration]

Summary by Sourcery

Extend the Raspberry Pi hwmon driver to expose firmware-provided voltage channels as standard hwmon inputs with labels while preserving undervoltage alarm reporting.

New Features:

• Export core and SDRAM voltage measurements via hwmon in0–in3 input channels with descriptive labels.

Enhancements:

• Detect and expose only those voltage input channels that are reported as supported by the firmware.
• Update driver metadata, including authorship information, to reflect the new voltage sensor support.

Documentation:

• Update the raspberrypi-hwmon documentation to describe the newly exposed voltage input channels.

[sourcery-ai]

Reviewer's Guide

Extends the raspberrypi-hwmon driver to expose Raspberry Pi firmware voltage channels via the hwmon "in" interface, with per-channel visibility, labels, and preservation of the existing undervoltage alarm, plus matching documentation updates.

Sequence diagram for Raspberry Pi hwmon voltage read path

sequenceDiagram
    participant hwmon_core
    participant rpi_hwmon_driver
    participant rpi_firmware

    hwmon_core->>rpi_hwmon_driver: rpi_read(hwmon_in, hwmon_in_input, channel, val)
    alt channel 0..3
        rpi_hwmon_driver->>rpi_hwmon_driver: rpi_firmware_get_voltage(data, volt_id, val)
        rpi_hwmon_driver->>rpi_firmware: rpi_firmware_property(fw, RPI_FIRMWARE_GET_VOLTAGE, packet, sizeof(packet))
        rpi_firmware-->>rpi_hwmon_driver: packet.value (microvolts)
        rpi_hwmon_driver->>rpi_hwmon_driver: le32_to_cpu(packet.value) / 1000
        rpi_hwmon_driver-->>hwmon_core: val (millivolts)
    else channel 0, hwmon_in_lcrit_alarm
        hwmon_core->>rpi_hwmon_driver: rpi_read(hwmon_in, hwmon_in_lcrit_alarm, 0, val)
        rpi_hwmon_driver->>rpi_hwmon_driver: data->last_throttled & UNDERVOLTAGE_STICKY_BIT
        rpi_hwmon_driver-->>hwmon_core: val (alarm bit)
    end

Loading

File-Level Changes

Change	Details	Files
Add firmware-backed voltage input channels (core and SDRAM rails) to the raspberrypi-hwmon driver and wire them into the hwmon in* API.	Introduce rpi_firmware_get_voltage() helper to fetch and convert firmware voltage values from microvolts to millivolts Extend rpi_read() to handle hwmon_in_input and hwmon_in_lcrit_alarm per channel, mapping channels 0–3 to the appropriate firmware voltage IDs and limiting the undervoltage alarm to channel 0 Add rpi_read_string() and a static label table for voltage channel names to support hwmon_in_label	drivers/hwmon/raspberrypi-hwmon.c
Make voltage channel visibility dynamic based on firmware support and adjust hwmon registration accordingly.	Add valid_inputs bitmask to rpi_hwmon_data and populate it in rpi_hwmon_probe() by probing each firmware voltage ID, only marking channels present when voltage queries succeed Replace fixed .visible permission with rpi_is_visible() to expose hwmon_in_input and hwmon_in_label only for valid channels, and limit hwmon_in_lcrit_alarm visibility to channel 0 Expand HWMON_CHANNEL_INFO(in, ...) to declare four input channels with input, label, and lcrit_alarm capabilities as appropriate	drivers/hwmon/raspberrypi-hwmon.c
Update metadata and documentation to reflect the new voltage sensor functionality.	Add the new author to the driver source and update the MODULE_AUTHOR list Update the Raspberry Pi hwmon documentation to describe the new voltage input channels and their semantics	drivers/hwmon/raspberrypi-hwmon.c Documentation/hwmon/raspberrypi-hwmon.rst

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from avenger-285714. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sourcery-ai]

Hey - I've left some high level feedback:

• The probe path repeats the same rpi_firmware_get_voltage() pattern for each voltage ID; consider iterating over an array of {id, bit} pairs to set valid_inputs in a loop for better readability and easier future extension.
• rpi_is_visible() always exposes the in0_lcrit_alarm attribute regardless of whether the core voltage channel was successfully marked valid in probe; consider tying visibility of the alarm to valid_inputs (or always marking channel 0 valid) so the interface is consistent when core voltage is unavailable.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The probe path repeats the same rpi_firmware_get_voltage() pattern for each voltage ID; consider iterating over an array of {id, bit} pairs to set valid_inputs in a loop for better readability and easier future extension.
- rpi_is_visible() always exposes the in0_lcrit_alarm attribute regardless of whether the core voltage channel was successfully marked valid in probe; consider tying visibility of the alarm to valid_inputs (or always marking channel 0 valid) so the interface is consistent when core voltage is unavailable.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[Copilot]

Pull request overview

Extends the raspberrypi-hwmon driver to expose firmware-reported voltage rails via the hwmon in*_input and in*_label interfaces, while keeping the existing undervoltage sticky alarm as in0_lcrit_alarm.

Changes:

• Add voltage reading support (core + SDRAM rails) and expose them as in0..in3 hwmon channels with labels.
• Add per-channel visibility logic to only create sysfs nodes for firmware-supported voltage IDs.
• Update Documentation/hwmon/raspberrypi-hwmon.rst to describe the new sysfs entries.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
drivers/hwmon/raspberrypi-hwmon.c	Adds voltage channels/labels, firmware voltage property reads, and dynamic visibility gating.
Documentation/hwmon/raspberrypi-hwmon.rst	Documents the new in*_input / in*_label attributes and conditional exposure behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.