Skip to content

hwmon: (pmbus/max20830): add enable-gpio property, VOUT feedback resistor properties, and add support for max20830c/max20840c - #3357

Open
actorreno wants to merge 7 commits into
mirror_ci/groeck/linux-staging/hwmon-nextfrom
dev/max20830c
Open

hwmon: (pmbus/max20830): add enable-gpio property, VOUT feedback resistor properties, and add support for max20830c/max20840c#3357
actorreno wants to merge 7 commits into
mirror_ci/groeck/linux-staging/hwmon-nextfrom
dev/max20830c

Conversation

@actorreno

@actorreno actorreno commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

PR Description

Adds a missing entry for enable pin in the driver.

Adds entries for VOUT feedback resistor properties. VOUT telemetry is now based on the
scaling provided by two feedback resistors where VOUT = VREF*(1+Rfb1/Rfb2)

This PR adds support for the Analog Devices MAX20830C and MAX20840C
step-down DC-DC switching regulator with PMBus interface.

This PR is based on top of this: #3183

PR Type

  • Bug fix (a change that fixes an issue)
  • New feature (a change that adds new functionality)
  • Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

  • I have conducted a self-review of my own code changes
  • I have compiled my changes, including the documentation
  • I have tested the changes on the relevant hardware
  • I have updated the documentation outside this repo accordingly
  • I have provided links for the relevant upstream lore

@actorreno
actorreno marked this pull request as ready for review June 5, 2026 06:27
@actorreno
actorreno force-pushed the dev/max20830c branch 2 times, most recently from 71e6378 to ed1b60e Compare June 8, 2026 03:03
@actorreno actorreno changed the title hwmon: (pmbus/max20830): add support for max20830c and max20840c hwmon: (pmbus/max20830): add enable-gpio property and add support for max20830c/max20840c Jun 8, 2026
enum:
- adi,max20830
- adi,max20830c
- adi,max20840c

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can the new devices somehow fallback to the adi,max20830 so that we can use fallback compatible? If not, you might be asked to justify it and typically DT maintainers want that in the commit message.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yes, they're so similar that falling back wouldn't change behavior

Comment thread drivers/hwmon/pmbus/max20830.c Outdated
{"max20830"},
{"max20830", max20830},
{"max20830c", max20830c},
{"max20840c", max20840c},

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is something common in pmbus but I would try it as in IIO? per device struct with a const char * identifier.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ill try it out, i think it could reduce a lot of the code complexity

Comment thread drivers/hwmon/pmbus/max20830.c Outdated
/* MAX20840C variant detected */
} else if (!strncmp(buf, "MAX20830", 8)) {
/* MAX20830 variant detected */
} else {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then no need for the above. Just one comparison

Comment thread drivers/hwmon/pmbus/max20830.c Outdated
*/
ret = i2c_smbus_read_i2c_block_data(client, PMBUS_IC_DEVICE_ID,
MAX20830_IC_DEVICE_ID_LENGTH + 1,
MAX20830_IC_DEVICE_ID_MAX_LENGTH + 1,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this actually work for the devices that only have MAX20830_IC_DEVICE_ID_MIN_LENGTH? Anyways, with a per chip struct this becomes again trivial to just use the amount of bytes any device is really needs to be read.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just to answer so far yes, the i2c read here just returns FF beyond what the chip replies,
but yeah if edited as suggested above, this should be trivial

@actorreno
actorreno force-pushed the dev/max20830c branch 3 times, most recently from 9b8e2eb to d4a9363 Compare June 9, 2026 06:11
@actorreno

actorreno commented Jun 9, 2026

Copy link
Copy Markdown
Contributor Author

v2:

dts:

  • added fallback for adi,max20830

.c:

  • followed iio style device matching
  • added an id_length in chip info struct despite having equal values, in prep for future devices with different lengths

Note:
CI checks having issues at the time, no space left

@actorreno
actorreno force-pushed the dev/max20830c branch 2 times, most recently from f84f0b6 to 5ee4759 Compare June 9, 2026 06:19
@actorreno
actorreno requested a review from nunojsa June 9, 2026 06:23
Base automatically changed from dev_max20830 to main June 11, 2026 08:21
@nunojsa

nunojsa commented Jun 19, 2026

Copy link
Copy Markdown
Collaborator

I guess this is to upstream? If so, please change base branch to a sensible mirror/

patch ci

Signed-off-by: CSE CI <cse-ci-notifications@analog.com>
@actorreno
actorreno changed the base branch from main to mirror_ci/groeck/linux-staging/hwmon-next June 22, 2026 01:24
@gastmaier
gastmaier force-pushed the mirror_ci/groeck/linux-staging/hwmon-next branch 2 times, most recently from 8c1a5f8 to bd112c8 Compare June 30, 2026 00:01
Adding a missing entry for the MAX20830 EN (enable) pin.

Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Add support for the GPIO controlled EN pin. The EN pin is asserted high
for device to operate.

Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
…erties

Add adi,vout-rfb1-ohms and adi,vout-rfb2-ohms properties to support
external voltage divider configuration for VOUT sensing. When the
desired output voltage is higher than VREF, a resistor divider (RFB1
and RFB2) is required to reach the intended value.

The properties use a dependency constraint to ensure both resistors
are specified together, or neither. This prevents misconfiguration
where only one resistor value is provided.

Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Implement support for external voltage divider scaling using the
adi,vout-rfb1-ohms and adi,vout-rfb2-ohms device tree properties.

When the desired output voltage exceeds VREF, a resistor divider
(RFB1 and RFB2) is used to scale down the feedback voltage. The
driver reads these resistor values from device tree and applies
the scaling formula: VOUT_actual = VOUT_measured × (1 + RFB1/RFB2)

The properties are optional. If not specified, the driver assumes
no voltage divider is present and reports the raw VOUT reading.

Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
…port

Add compatible strings for variants of MAX20830 which are MAX20830C
and MAX20840C. These devices have the same register functionality with
MAX20830 but with a longer IC_DEVICE_ID.

Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Add support for MAX20830C and MAX20840 step-down DC-DC switching
regulator with PMBus interface. MAX20830C is a different packaging
for MAX20830, and MAX20840C supports 40A regulation compared to
MAX20830 that is only 30A.

Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
@gastmaier
gastmaier force-pushed the mirror_ci/groeck/linux-staging/hwmon-next branch 7 times, most recently from b8ab74e to b9080e0 Compare July 7, 2026 00:12
@gastmaier
gastmaier force-pushed the mirror_ci/groeck/linux-staging/hwmon-next branch 6 times, most recently from 4e21503 to 97e15ef Compare July 14, 2026 00:02
@gastmaier
gastmaier force-pushed the mirror_ci/groeck/linux-staging/hwmon-next branch 8 times, most recently from 8411d1b to a17a53a Compare July 22, 2026 00:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants