[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200826170205.GL4965@sirena.org.uk>
Date: Wed, 26 Aug 2020 18:02:05 +0100
From: Mark Brown <broonie@...nel.org>
To: Vladimir Oltean <olteanv@...il.com>
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 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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists