Add support for ADP5055

[actorreno]

PR Description

• This adds driver support and device tree bindings for ADP5055 triple buck regulator.
• Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/adp5055.pdf
• Tested on RPI4 on the eval board: https://www.analog.com/media/en/technical-documentation/user-guides/adp5055-evalz-ug-1930.pdf

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 tested the changes on the relevant hardware
• I have updated the documentation outside this repo accordingly (if there is the case)

[nunojsa]

Please, fix first the valid CI errors you have...

[actorreno]

It seems the checks returns some errors I couldn't capture when locally running commit check scripts like "./scripts/checkpatch <driver_file>"

I have fixed them except 1 last error which I am confused about since the error is not related to my files.
Screenshot below.

Edit: was fixed by rebasing to latest main

[kister-jimenez]

ADP5055 is PMBUS compatible, should this be under hwmon/pmbus?

[actorreno]

The datasheet did say "pmbus compatible" but it didn't have any pmbus commands the other typical pmbus dataseet contain
it also doesn't have an eeprom for the usual "pages" I see in other pmbus codes.

some colleagues agreed with me that it was just an i2c interface and decided it is better off in the regulator subsystem

[nunojsa]

ADP5055 is PMBUS compatible, should this be under hwmon/pmbus?

Hmm, I do think this is a pertinent question... Looking at the description:

"The ADP5055 is a power management unit that combines three high performance buck regulators with a PMBus interface..."

So this looks like a typical power management device that fits in HWMON/PMBUs. Note that the pmbus subsystem also has an interface with the regulator subsystem and it will also check what standard PMbus registers are supported by the device. On top of that, you can pretty much bypass the standard registers and control the device as you want. Example, I see the VIDx_LOW/HIGH registers that could fit in the standard HWMON ABI and you totally support it even not using standard pmbus commands. There's also power good and overcurrent stuff that could very likely be made to work.

All the above to say that pmbus might be doable and allows you to better support this device (meaning, more features). You can also internally reach the apps engineer for this part and try to understand the actual PMBUS commands supported. Looking at the datasheet, I can see STATUS_CML to be supported.

[nunojsa]

I'm still not convinced on the location of the driver but i'm already doing some comments on the DT bindings

[nunojsa]

This looks custom implementation of a subset of the ON_OFF_CONFIG command. Moreover, DT maintainers do not like much of properties like this where you just give the register code. You should have a string property and do the mapping in the driver (for register values). On top of that, you should likely control 3 gpios that should be mandatory for options 0 and 3.

[nunojsa]

no need for the 0/1 description. Should encode the state in the property name. Simply adi,ocp-blanking and if the property is enabled, then it's pretty clear we're enabling the feature.

[nunojsa]

You have a lot properties for the channels so I think it might be a good idea to create channel child nodes and have the properties per channel instead of this.