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: <b03307f7-93f6-4680-9241-cf28b5456fd0@sirena.org.uk>
Date: Mon, 19 Jan 2026 19:01:38 +0000
From: Mark Brown <broonie@...nel.org>
To: Michal Simek <michal.simek@....com>
Cc: Abdurrahman Hussain <abdurrahman@...thop.ai>,
	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 07:52:35PM +0100, Michal Simek wrote:
> On 1/19/26 19:38, Mark Brown wrote:

> > This was specifically targetted at some embedded x86 systems where there
> > was a goal to reuse device tree bindings for things that just can't be
> > expressed well in ACPI.  _DSD is generally considered tasteless for more
> > server style systems, AIUI the general approach preferred by ACPI
> > forward OSs is to use some combination of DMI quirking and registering
> > with a per-device ID (like the per generation fake PCI IDs that Intel
> > uses for all IPs on their SoCs).  Just blindly accepting _DSD can end up
> > with something that's not used because it's not what the ecosystem
> > wants.

> Is it a better way to use auxiliary bus as was recommended by Greg in past
> on drivers/misc/keba/cp500.c review?
> https://lore.kernel.org/linux-i2c/2024060203-impeding-curing-e6cd@gregkh/

The driver there appears to be doing runtime enumeration based on some
EEPROMs on the system and creating platform devices based on what it
finds there so it's a bit of a different thing, the aux bus suggestion
is about what the code that does with the data it got from the EEPROM.
This patch is for something described directly by firmware so there's no
way we'd create an aux device, that's purely in kernel.

I have no idea what the hardware this series targets is (other than that
it's using a FPGA) or if there's even a motivation for the change other
than code inspection.

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