On 2/15/24 03:48, Conor Dooley wrote:
On Wed, Feb 14, 2024 at 05:17:04PM -0800, Guenter Roeck wrote:
On 2/14/24 11:55, Conor Dooley wrote:
[ ... ]
Why "vout0" if there's only one output? Is it called that in the
documentation? I had a quick check but only saw it called "vout".
Are there other related devices that would have multiple regulators
that might end up sharing the binding?
Primarily because that is what the PMBus core generates for the driver
because no one including me was aware that this is unacceptable
for single-output drivers.
Is it unacceptable? If you're implying that I am saying it is, that's
not what I was doing here - I'm just wondering why it was chosen.
Numbering when there's only one seems odd, so I was just looking for the
rationale.
Given the tendency of corporate speak (aka "this was a good attempt" for
a complete screwup), and since this did come up before, I did interpret
it along that line. My apologies if that was not the idea.
I'm not gonna go and decree that "vout0" is unacceptable, if it was
called that in documentation that I had missed or was convention, I was
just gonna say "okay, that sounds reasonable to me".
"convention" only if lack of awareness how regulators are supposed to be named
is a convention.
Still, I really don't know how to resolve this for existing PMBus drivers
which do register "vout0" even if there is only a single output regulator.
I had a quick look at that series, none of the devices that I checked
out there seem to have documented regulators at all. Some of the devices
were only documented in trivial-devices.yaml. Relying on the naming of
undocumented child nodes is a bug in those drivers & I guess nobody cares
about dtbs_check complaints for those platforms. The example that was
linked in the other thread doesn't even use a valid compatible :(
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed/aspeed-bmc-delta-ahe50dc.dts?id=8d3dea210042f54b952b481838c1e7dfc4ec751d#n21
I guess it uses the i2c device ids to probe on that platform, or have
I missed something there?
I think that is correct. If I recall correctly, the I2C subsystem no longer
searches for compatible drivers by only looking at the device id in the
compatible node, so I guess one has to list "lm25066" instead of "ti,lm25066"
as compatible to get a match in the i2c subsystem. That is of course
completely wrong.
Guenter
