linux-kernel - Re: [PATCH v1] riscv: dts: starfive: remove non-existant spi device from jh7110-common.dtsi

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: <CAJM55Z_QFfKOVLhKTwZCHFRC--b7QPn7_Y_Dz9ffTBGNNDcuoQ@mail.gmail.com>
Date: Fri, 26 Jul 2024 08:59:51 -0400
From: Emil Renner Berthing <emil.renner.berthing@...onical.com>
To: Conor Dooley <conor@...nel.org>, 
	Emil Renner Berthing <emil.renner.berthing@...onical.com>
Cc: Conor Dooley <conor.dooley@...rochip.com>, linux-riscv@...ts.infradead.org, 
	Emil Renner Berthing <kernel@...il.dk>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, 
	William Qiu <william.qiu@...rfivetech.com>, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] riscv: dts: starfive: remove non-existant spi device
 from jh7110-common.dtsi

Conor Dooley wrote:
> On Fri, Jul 26, 2024 at 08:29:39AM -0400, Emil Renner Berthing wrote:
> > Conor Dooley wrote:
> > > There is no rohm,dh2228fv on any of supported JH7110 boards - in fact
> > > the dh2228fv almost certainly does not exist as it is not a valid Rohm
> > > part number. Likely a typo by Maxime when adding the device originally,
> > > and should have been bh2228fv, but these boards do not have a bh2228fv
> > > either! Remove it from jh7110-common.dtsi - pretending to have a device
> > > so that the spidev driver will be bound by Linux is not acceptable.
> >
> > This patch is correct, but as you mention the fake device was most likely added
> > in order to use spidev from userspace with random devices added on the exposed
> > pins. In case someone actually makes use of this wouldn't this be a regression?
> > What is the right way to support this?
>
> Unfortunately, there's no "right way" that's supported for for this
> particular case. If people want to use spidev for their device, they
> should either document it in the bindings, add the compatible to the
> spidev driver and use an overlay to add the device to the dts or they
> can r bind the spidev driver to the device from userspace.
>
> The other thing, which doesn't exist yet, is a connector binding. The
> folks are Beagle are currently working on creating a connector binding
> for the Mikrobus connector - but that's rather far from complete at the
> moment.
>

I see. Thanks for the explanation. At least now there is this thread
any potential users might find.

Reviewed-by: Emil Renner Berthing <emil.renner.berthing@...onical.com>