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

["Csókás Bence" <csokas.bence@prolan.hu>]

Hi all,

On 2025. 01. 06. 21:16, Bartosz Golaszewski wrote:
> On Mon, Jan 6, 2025 at 10:19 AM Geert Uytterhoeven <geert@linux-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