On Fri, Jan 22, 2021 at 6:12 PM Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > On Fri, Jan 22, 2021 at 05:40:41PM +0100, Rafael J. Wysocki wrote: > > On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson > > <calvin.johnson@xxxxxxxxxxx> wrote: > > > > > > 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. > > > 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". > > 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?
