linux-kernel - Re: [PATCH 0/2] gpio: 74x164: use a compatible fallback and don't extend the driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMRc=Meqnr9wMu5kUNEbisBJntZf6KuQp_QspOnDPyqqX9VM3w@mail.gmail.com>
Date: Mon, 13 Jan 2025 09:22:05 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, 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

On Sun, Jan 12, 2025 at 10:58 AM Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
>
> 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 ;-)

It's late into the cycle and as it's not clear whether we really need
the new compatible or not, I removed the two patches from my queue.
Let's revisit it in the next release.

Bartosz