[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0izwiuD+gRmbw=i=DojDMwqOevDQwXArcmq4WyPVrEDfQ@mail.gmail.com>
Date: Fri, 22 Jan 2021 19:11:56 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Calvin Johnson <calvin.johnson@....nxp.com>,
Grant Likely <grant.likely@....com>,
Jeremy Linton <jeremy.linton@....com>,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Russell King - ARM Linux admin <linux@...linux.org.uk>,
Cristi Sovaiala <cristian.sovaiala@....com>,
Florin Laurentiu Chiculita <florinlaurentiu.chiculita@....com>,
Ioana Ciornei <ioana.ciornei@....com>,
Madalin Bucur <madalin.bucur@....nxp.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Marcin Wojtas <mw@...ihalf.com>,
Pieter Jansen Van Vuuren <pieter.jansenvv@...boosystems.io>,
Jon <jon@...id-run.com>, Saravana Kannan <saravanak@...gle.com>,
Randy Dunlap <rdunlap@...radead.org>,
"linux.cj" <linux.cj@...il.com>,
Diana Madalina Craciun <diana.craciun@....com>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
Laurentiu Tudor <laurentiu.tudor@....com>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>
Subject: Re: [net-next PATCH v4 09/15] device property: Introduce fwnode_get_id()
On Fri, Jan 22, 2021 at 6:12 PM Andy Shevchenko
<andy.shevchenko@...il.com> 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@....nxp.com> 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?
Powered by blists - more mailing lists