[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240716-stuck-saggy-0638f8f0af4e@wendy>
Date: Tue, 16 Jul 2024 10:09:09 +0100
From: Conor Dooley <conor.dooley@...rochip.com>
To: Szőke Benjamin <egyszeregy@...email.hu>
CC: Mark Brown <broonie@...nel.org>, <linux-spi@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH] spi: spidev: add "generic-spidev" for compatible string
On Tue, Jul 16, 2024 at 09:41:08AM +0200, Szőke Benjamin wrote:
> 2024. 07. 15. 16:10 keltezéssel, Mark Brown írta:
> > On Sun, Jul 14, 2024 at 10:23:03PM +0200, egyszeregy@...email.hu wrote:
> > > From: Benjamin Szőke <egyszeregy@...email.hu>
> > >
> > > Spidev is a not an ASIC, IC or Sensor specific driver.
> > > It is better to use a simple and generic compatible
> > > string instead of many dummy vendor/product names
> > > which are all just fake.
> >
> > > Signed-off-by: Benjamin Szőke <egyszeregy@...email.hu>
> > > ---
> > > drivers/spi/spidev.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > No, as previously and repeatedly discussed the DT describes the
> > hardware, not the software that happens to be used to control that
> > hardware.
> >
> > You also need to document any new bindings.
>
> If DT describes the hardware, yes this is why need a generic compatible
> string for SPIdev driver. SPIdev driver is a typical driver for boards which
> have just header pin for SPI connection and it is not defined what IC/Sensor
> will be connected on it later.
What is preventing you using, for example, overlays to describe what
devices are being connected to your board?
> In normally if a developer start to use an IC/Sensor which has not yet any
> driver in Linux he/she should start to make it in a regular way and not
> hardcoding these fake compatible strings inside spidev.c and use it for
> longterm.
As I understand it the process would be:
- document the actual device you have
- add that compatible to spidev.c
- work on a driver in userspace
- drop the compatible from spidev.c and create a specific driver
The hardware at all points in time remains identical, and so the
description of it does not change depending on what driver the OS
happens to use.
Of course a developer could just develop a specific driver for the
hardware from the beginning, and not ever add its compatible to the
spidev driver.
> By the way, please send some reference link about the rules what you say for
> DT
For instance checkpatch will complain about your change:
WARNING: DT compatible string "generic-spidev" appears un-documented -- check ./Documentation/devicetree/bindings/
#35: FILE: drivers/spi/spidev.c:732:
+ { .compatible = "generic-spidev", .data = &spidev_of_check },
> and please send the link for SPIdev binding documents, i can not find it,
> but you point on it all the time.
There is no binding for "spidev" because it is not a real device. The
devices currently bound to by the driver should be documented in various
locations.
> devicetree@...r.kernel.org
> Please start a normal discussion about it with devicetree maintainers who
> can decided it real what need in this driver code for compatible strings.
I do not understand what you are saying here. Are you telling Mark to
have a conversation with the devicetree maintainers?
> I
> do not think it is a good idea to append these list for +100 fake devices in
> the future because you say this is the rules for it.
What do you mean "+100 fake devices"? Surely the things being appended
to this list would be real devices that do not have a driver right now?
You keep talking about lots of fake compatibles, but actually
"generic-spidev" is the fake, and the specific compatibles for
different sensors etc are the real ones!
A wee bit confused,
Conor.
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists