Message-ID: <6e06696e-09a4-46e0-98fa-252690b888e0@sirena.org.uk>
Date: Mon, 19 Jan 2026 23:20:56 +0000
From: Mark Brown <broonie@...nel.org>
To: Abdurrahman Hussain <abdurrahman@...thop.ai>
Cc: Michal Simek <michal.simek@....com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, linux-spi@...r.kernel.org,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

On Mon, Jan 19, 2026 at 12:30:43PM -0800, Abdurrahman Hussain wrote:

To repeat what I previously said:

| Please fix your mail client to word wrap within paragraphs at something
| substantially less than 80 columns.  Doing this makes your messages much
| easier to read and reply to.

> > On Jan 19, 2026, at 11:56 AM, Mark Brown <broonie@...nel.org> wrote:
> > On Mon, Jan 19, 2026 at 08:17:46PM +0100, Michal Simek wrote:
> >> On 1/19/26 20:01, Mark Brown wrote:
> >>> On Mon, Jan 19, 2026 at 07:52:35PM +0100, Michal Simek wrote:

> > None of this looks like something intended to add ACPI bindings,
> > it's not clear to me how we'd even get the device instantiated on a
> > normal ACPI system.  There's no ACPI IDs defined (and there aren't any
> > existing ones), just a conversion of the property parsing code.

> These "random" cleanups make the spi-xilinx.c driver work on non-DT platforms.
> Which is what the cover letter says.

The cover letter just says:

| Transition the driver to use the generic device property API.

| Additionally, make interrupts optional to allow the driver to fall back
| to its existing polling mode on systems where interrupts are either missing
| or broken.

which doesn't mention any motivation for this, it's just a statement of
what the patches do.  It's very unclear why this is a series TBH, the
interrupts changes have no visible relationship to the device properties
conversion and should have been submitted separately.

> We are trying NOT to introduce new ACPI IDS, or fork the existing drivers.
> But rather, to re-use the existing drivers as much as possible by relying on the
> special DT namespace link "PRP0001":

What is the goal in avoiding using native ACPI bindings?  PRP0001 is a
workaround for cases where you have things that ACPI has never dreamed
of and can't abstract well but which have already been handled by DT,
it is not something we're aiming.  The hardware you have described
seems like fairly normal server style hardware and like it should fit
well with normal ACPI.  Adding ACPI IDs to existing drivers is pretty
common and standard, I'd class that as reuse.

As far as I can see from the example you posted the devices are all
fairly standard and just need IDs assigning to work naturally with ACPI.
There's possibly an argument for using PRP0001 for the flash given that
it's not especially idiomatic to have OS visible flash on ACPI systems,
usually flash would only be visible to UEFI, but equally the description
would trivial and systems wouldn't have to use it.

> > You should use whatever firmware interface is sensible for the platform,
> > if that's x86 that's always ACPI.  For other architectures there's a
> > split with servers using ACPI and more embedded platforms using DT.

> Which is exactly what we are doing - using ACPI on x86 to describe the hardware.

There is the bit where there's a PCI bus in the way and you don't use
ACPI particularly idiomatically...  I can see the dodging out on the PCI
bus description, but the way the devices behind the PCI bus are
described seems confusing.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists