linux-kernel - Re: [PATCH v3 3/3] spi: xilinx: use device property accessors.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c3fc04a4-4b09-4c6a-a0f1-e5aa92a22976@sirena.org.uk>
Date: Tue, 20 Jan 2026 18:45:54 +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>, Andrew Lunn <andrew@...n.ch>,
	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 04:20:06PM -0800, Abdurrahman Hussain wrote:

To repeat once again:

| 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 3:20 PM, Mark Brown <broonie@...nel.org> wrote:

> >> 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.

> I did not intentionally avoid introducing new ACPI _HIDs, but at the same time
> don’t understand the need to, especially when PRP0001 workaround works and
> it works well. We don’t own the spi-xilinx driver and neither do we own the i2c-xiic.
> These are standard Xilinx IP platform drivers that could be made usable on ACPI platforms
> by just switching to device_property APIs. Which is what these series is trying to do.

It's just not idiomatic ACPI, indeed some other OSs actively reject the
idea of binding to PRP0001 described devices.  In general we don't want
to encourage people needlessly creating unusual hardware descriptions,
that provides better future proofing so we're less likely to have to
work around our own past decisions and avoids causing hassle for other
OS vendors with having to deal with Linux special firmware descriptions.

> > 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 mention “idiomatic” a lot. Are you implying the SPI NOR-flash devices should
> not be exposed to user-space? Then why does the spi-nor driver even exist?

Flashes are widely used on non-ACPI systems where exposing them to the
OS is a perfectly normal and standard thing to do.  Usually on a system
with ACPI NOR flashes would be purely for the firmware to store itself
and it's data, storage exposed to the OS would be at least eMMC or
something.  ACPI has a very strong idea of what the systems it is used
with should look like.

> We have a SPI device that needs to be accessible from users-space in order to
> “flash" various FPGAs. How do you suggest we do that?

You should probably register the device, it's just a question of if it's
weird enough that it does actually fit with PRP0001 or if it's something
with general enough application in ACPI systems that a HID should be
allocated.

> Also, there are hundreds of drivers in the DT namespace that are missing the ACPI IDs today.
> Do you suggest adding ACPI IDs to every driver just so it’s more “idiomatic” to use?

To drivers that are used on ACPI systems, yes.  Many devices wouldn't be
used on ACPI systems, or would be expected to be exposed differently
(for example, hidden behind AML).

> I am just trying to get this 2-line small change merged so we can start using the standard spi-xilinx driver today. I am not trying to boil the ocean.

I mean, adding a HID wouldn't take substantially more code.

> > 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.

> What exactly about this usage is not idiomatic? Our PCI device description in ACPI looks like
> this (GPP5 is the PCIe bridge under which the FPGA is located):

The use of PRP0001.

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