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: <192e97dd-698a-4434-bd32-c1181ec85ba3@prolan.hu>
Date: Wed, 8 Jan 2025 11:26:05 +0100
From: Csókás Bence <csokas.bence@...lan.hu>
To: Bartosz Golaszewski <brgl@...ev.pl>, Geert Uytterhoeven
	<geert@...ux-m68k.org>
CC: 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>, 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

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`:

* 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.

Bence