linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Conor Dooley <conor.dooley@microchip.com>
To: "Szőke Benjamin" <egyszeregy@freemail.hu>
Cc: Mark Brown <broonie@kernel.org>, <linux-spi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>
Subject: Re: [PATCH] spi: spidev: add "generic-spidev" for compatible string
Date: Tue, 16 Jul 2024 10:09:09 +0100	[thread overview]
Message-ID: <20240716-stuck-saggy-0638f8f0af4e@wendy> (raw)
In-Reply-To: <8d18306c-8d36-4e59-bc1f-0fc83dd40ca4@freemail.hu>

[-- Attachment #1: Type: text/plain, Size: 3450 bytes --]

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@freemail.hu wrote:
> > > From: Benjamin Szőke <egyszeregy@freemail.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@freemail.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@vger.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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2024-07-16  9:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-14 20:23 [PATCH] spi: spidev: add "generic-spidev" for compatible string egyszeregy
2024-07-15 14:10 ` Mark Brown
2024-07-16  7:41   ` Szőke Benjamin
2024-07-16  9:09     ` Conor Dooley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240716-stuck-saggy-0638f8f0af4e@wendy \
    --to=conor.dooley@microchip.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=egyszeregy@freemail.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).