[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1GOTtYIeOFmrmm7@sirena.org.uk>
Date: Thu, 20 Oct 2022 19:07:10 +0100
From: Mark Brown <broonie@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-spi@...r.kernel.org,
linux-kernel@...r.kernel.org, Daniel Mack <daniel@...que.org>,
Haojian Zhuang <haojian.zhuang@...il.com>,
Robert Jarzmik <robert.jarzmik@...e.fr>
Subject: Re: [PATCH v1 3/6] spi: pxa2xx: Remove no more needed PCI ID table
On Thu, Oct 20, 2022 at 08:55:02PM +0300, Andy Shevchenko wrote:
> On Thu, Oct 20, 2022 at 06:45:19PM +0100, Mark Brown wrote:
> > Not sure I quite get what you're proposing here but I *think* so,
> > assuming you mean checking the values if the property is present (and
> > error out if the property isn't there at all and you're instantiating
> > via a MFD rather than direct PCI/DT binding I guess)?
> When we instantiate via MFD, we (semi-)manually create resources for each of
> the children. These resources may or may not have a dedicated names. Those
> names can be given _only_ inside the source code in the kernel, so it means
> it is _explicit_ telling, that we are know where the device in question comes
> from.
> if (resource_with_name_present()) {
> ret = device_property_...
> Like you said, checking property only when we have resource present _by name_
> and bail out if there is none.
Remember that device_property backs onto fwnode so properties can come
from _DSD properties too since fwnode will query any source of
properties (and further remember that things will be going through
multiple trees so even with stuff purely in the kernel things could get
out of sync). I think the code would have to also check that it was a
MFD child at least, you couldn't get _DSD on a child node so that should
be fine.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists