linux-kernel - Re: [PATCH v2 0/3] gpio: 74HC595 / 74x164 shift register improvements

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: <CAMRc=MewCR=W=_0RKFZR0gW2mvkMD-pKBWpXCeqOY4j8CXBSXw@mail.gmail.com>
Date: Wed, 8 Jan 2025 13:08:37 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Csókás Bence <csokas.bence@...lan.hu>, 
	J. Neuschäfer <j.ne@...teo.net>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, 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>, Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, 
	linux-gpio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>, 
	linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] gpio: 74HC595 / 74x164 shift register improvements

On Wed, Jan 8, 2025 at 11:26 AM Csókás Bence <csokas.bence@...lan.hu> wrote:
>
> Hi all,
>
> On 2025. 01. 06. 21:16, Bartosz Golaszewski wrote:
> > On Mon, Jan 6, 2025 at 10:19 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> >> Do we really need to document and add driver support for all variants?
> >> I can easily come up with a list of tens or perhaps even hundreds
> >> of xx74yy595z parts that are all compatible, as far as software is
> >> concerned.  As SPI was invented by Motorola, the original part is
> >> probably named MC74595 or MC74LS595 (yes, ON Semiconductor bought the
> >> logic division of Motorola).
>
> I second this, no point of having a new compatible which is a guaranteed
> 1:1 equivalent of an already existing one. Especially true if the only
> change was that a different company bought the IP. By the same logic, I
> could start to sumbit patches to change all `fsl,` compatible-s to
> `nxp,`; `atmel,`, `maxim,`, `smsc,` etc. to `microchip,`; `ralink,` to
> `mediatek,` and so on. There would be no end.
>
> >> Perhaps we need a separate vendor prefix for the 74xx-series[1]?
>
> I don't think that is the case. Rather, we should document that the
> existing binding/compatible should be used for all such simple cases (it
> is called _compatible_ for a reason, after all, and not
> `exact-part-number`).
>
> >> The xx-prefix and z-suffix don't matter; the yy-infix for semiconductor
> >> technology rarely matters (there are a few exceptions, though, mostly
> >> pinout, which doesn't matter for software).
> >>
> >
> > I missed the fact that Rob actually responded to patch 1/3 with a
> > similar suggestion (fallback, instead of a full compatible).
> >
> > I can drop this series from my queue if it needs more rework.
>
> I think you can keep 3/3 (the one commenting the use of `latch` as CS).
> The rest can be replaced by another commit commenting on what it means
> to be `fairchild,74hc595`:
>

J. Neuschäfer: do you want to send a follow-up for this?

Bart

> * tri-state output
> * 8-bit output
> * OE pin (or latch or whatever it happens to be called in their chosen
> manufacturer's datasheet)
> * SRCLR does not seem to be used by the driver, so we can probably skip
> that...
>
> And telling people NOT to add a new compatible if their part satisfies
> these.
>