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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux