On Wed, Jan 8, 2025 at 11:26 AM Csókás Bence <csokas.bence@xxxxxxxxx> wrote: > > 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`: > 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. >
