[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMuHMdVrQms38kXjr4df3kJfcoNFm3oEm2Zr0XNuucZwg_VbxA@mail.gmail.com>
Date: Sun, 12 Jan 2025 10:57:48 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Csókás Bence <csokas.bence@...lan.hu>,
Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Maxime Ripard <mripard@...nel.org>, J . Neuschäfer <j.ne@...teo.net>,
linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH 0/2] gpio: 74x164: use a compatible fallback and don't
extend the driver
Hi Krzysztof,
On Sat, Jan 11, 2025 at 12:00 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> On 10/01/2025 15:14, Bartosz Golaszewski wrote:
> >> At24 EEPROMs differ from '595 shift registers in that they provide an
> >> API with multiple commands, and some commands or parameter bits may
> >> differ among different implementations (but usually these differences
> >> are called quirks).
> >>
> >> All '595 (I'm deliberately writing it like that) shift registers
> >> should be 100% compatible, modulo some electrical specifications
> >> (voltage levels, maximum speed, power consumption, ...).
> >>
> >> Interestingly, the driver is called gpio-74x164.c, while no '164
> >> compatible value is present. Most important difference is that the
> >> '164 lacks the output latch, which is used as chip-select with SPI[1].
> >>
> >>>> I'm especially against introducing a new, vendor-specific (On Semi, in
> >>>> this case) name; if we really want to introduce a new compatible, at
> >>>> least make it as generic as possible, i.e. `generic,74x595`, or even
> >>>> `generic,spi-shift-register-output`.
> >>>
> >>> If anything, that would have to be the fallback that the driver knows.
> >>> The first string in the compatible property has to have an actual
> >>> vendor (I think, I'll let DT maintainers correct me).
> >>
> >> For the inverse operation (parallel in, serial out), there's just
> >> "pisosr-gpio".
> >
> > Ok, I admit I don't know the correct next step. I'll wait for
> > Krzysztof, Rob or Conor to chime in (on the subject of representing
> > reality - the actual manufacturer - in DTS) and then possibly just
> > remove patches 1-2 from my tree.
>
> Well, folks, I don't know the exact device, so maybe there is no point
> in a new compatible if there is a claim all devices have same interface
> and documenting all of them would result in 1000 redundant
> compatibles... but OTOH, that's what we still do with jedec,spi and
> at24, so if we can add specific compatibles for these, we can do same
> also here.
Except that we don't for jedec,spi, unfortunately[1].
At24 and jedec,spi use a complex programming API, with lots of room
for deviation and extension. '595 is a pure hardware part[2]: it is
just a shift register (driven by SPI clock and MOSI) with a latch
(driven by deasserting SPI chip select), without room for deviation.
Anything that behaves differently is not a jelly-bean '595 part.
[1] "[PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for
more MT25QU parts'
https://lore.kernel.org/all/363186079b4269891073f620e3e2353cf7d2559a.1669988238.git.geert+renesas@glider.be
[2] Ignoring the rumor that all Microchip I/O expanders are actually
pre-programmed PIC microcontrollers ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists