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: <d5909def-1ce8-409e-a5cd-2405da89e5e2@lunn.ch>
Date: Tue, 20 Jan 2026 21:41:27 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Abdurrahman Hussain <abdurrahman@...thop.ai>
Cc: Mark Brown <broonie@...nel.org>, 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.

> We could, but we don’t own the Xilinx IP blocks. Are we not justified in using PRP0001
> hack until the driver owner adds the HIDs? Wasn’t PRP0001 created as an escape hatch for
> these kind of scenarios?

I suspect your wording is wrong here. You probably have a license for
the Xilinx IP blocks, you are using in your synthesising for use in
your FPGA.

That i think you are trying to say is that you don't own the software
driver for the Xilinx IP blocks? But that should not matter. The Linux
community Maintains these drivers, and can make modifications to them.
You as part of this community can propose a patch which adds the
needed IDs to the driver.

The "escape hatch" is generally used when there is a mature DT
binding, but nothing for ACPI. Linux has a mature and complex set of
DT bindings around network device sub-components, where Linux drivers
all the sub-components. ACPI has nothing in this area, because network
devices used in the ACPI world tend to use firmware, not Linux to
drive the hardware. In such a case, using the escape hatch makes
sense. However, I2C, SPI, etc all have well established ACPI bindings
and are part of the basic ACPI standard. It makes no sense to use the
"escape hatch" hatch for such devices. Please follow the ACPI
standard.

       Andrew