[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200826183044.4g6jvfrgkhpxki3k@skbuf>
Date: Wed, 26 Aug 2020 21:30:44 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: Kuldip Dwivedi <kuldip.dwivedi@...esoftware.com>,
Qiang Zhao <qiang.zhao@....com>, linux-spi@...r.kernel.org,
linux-kernel@...r.kernel.org,
Pankaj Bansal <pankaj.bansal@....com>,
Varun Sethi <V.Sethi@....com>,
Tanveer Alam <tanveer.alam@...esoftware.com>
Subject: Re: [PATCH] spi: spi-fsl-dspi: Add ACPI support
On Wed, Aug 26, 2020 at 06:02:05PM +0100, Mark Brown wrote:
> On Wed, Aug 26, 2020 at 07:09:50PM +0300, Vladimir Oltean wrote:
>
> > I don't even know if NXP0005 is made up or if it's written down
> > somewhere in the PNP ID registry. NXP0006 seems to be assigned to the
>
> Well, any ID is made up to some extent. I am concerned about the
> allocation of IDs too, it needs to be coordinated with NXP since it's
> being allocated from their namespace, but unfortunately in general
> there's no sensible way to go from a chip/feature name to an ACPI name
> due to ACPI's specification mechanism. There's also not any kind of
> central list of IDs.
>
> > In the ACPI spec there's also a _HRV (Hardware Revision) object, which
> > comes as a simple DWORD. We could use acpi_evaluate_integer() to read
> > that, and use it as index into the array of fsl_dspi_devtype_data, if
> > we declare that as ABI within the driver (and new SoCs would be added
> > only at the end of the enum). Then we could use the NXP0005 _HID for
> > everything DSPI.
>
> That's not something that it's particularly idiomatic to actually use in
> ACPI and you end up with the same namespacing problem assigning IDs so
> I'm not sure it makes life any better.
So what's the idiomatic thing to do in this case, allocate the first
free PNP ID now for DSPI controller on LS2085A, then another one for
DSPI on LX2160A later, etc etc?
Thanks,
-Vladimir
Powered by blists - more mailing lists