On Fri, Jan 22, 2021 at 6:12 PM Andy Shevchenko
[off-list ref] wrote:

On Fri, Jan 22, 2021 at 05:40:41PM +0100, Rafael J. Wysocki wrote:

quoted

On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
[off-list ref] wrote:

quoted

Using fwnode_get_id(), get the reg property value for DT node
or get the _ADR object value for ACPI node.

So I'm not really sure if this is going to be generically useful.

First of all, the meaning of the _ADR return value is specific to a
given bus type (e.g. the PCI encoding of it is different from the I2C
encoding of it) and it just happens to be matching the definition of
the "reg" property for this particular binding.

quoted

IOW, not everyone may expect the "reg" property and the _ADR return
value to have the same encoding and belong to the same set of values,

I have counted three or even four attempts to open code exact this scenario
in the past couple of years. And I have no idea where to put a common base for
them so they will not duplicate this in each case.

In that case it makes sense to have it in the core, but calling the
_ADR return value an "id" generically is a stretch to put it lightly.

It may be better to call the function something like
fwnode_get_local_bus_id() end explain in the kerneldoc comment that
the return value provides a way to distinguish the given device from
the other devices on the same bus segment.

Otherwise it may cause people to expect that the "reg" property and
_ADR are generally equivalent, which is not the case AFAICS.

At least the kerneldoc should say something like "use only if it is
known for a fact that the _ADR return value can be treated as a
fallback replacement for the "reg" property that is missing in the
given use case".

quoted

so maybe put this function somewhere closer to the code that's going
to use it, because it seems to be kind of specific to this particular
use case?