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

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

[J. Neuschäfer via B4 Relay]

This patchset adds a compatible string for another part, and clarifies
the role of the latch clock pin on 74x164-compatible shift registers.

Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
---
Changes in v2:
- Remove patches 2 and 4 (latch GPIO support) in favor of a new patch 3,
  which explains that the latch GPIO acts as a chip select
- Add missing spi_device_id entry in the driver
- Add Linus Walleij's R-b tags
- Link to v1: https://lore.kernel.org/r/20241213-gpio74-v1-0-fa2c089caf41@posteo.net

---
J. Neuschäfer (3):
      dt-bindings: gpio: fairchild,74hc595: Add On Semi MC74HC595A compat
      gpio: 74x164: Add On Semi MC74HC595A compat
      dt-bindings: gpio: fairchild,74hc595: Document chip select vs. latch clock

 .../devicetree/bindings/gpio/fairchild,74hc595.yaml    | 18 ++++++++++++++++++
 drivers/gpio/gpio-74x164.c                             |  2 ++
 2 files changed, 20 insertions(+)
---
base-commit: 4bbf9020becbfd8fc2c3da790855b7042fad455b
change-id: 20241213-gpio74-66ea33da446d

Best regards,
-- 
J. Neuschäfer <j.ne@posteo.net>

[PATCH v2 1/3] dt-bindings: gpio: fairchild,74hc595: Add On Semi MC74HC595A compat

[J. Neuschäfer via B4 Relay]

From: "J. Neuschäfer" <j.ne@posteo.net>

The On Semi MC74HC595A/MC74HCT595A is another part that is compatible with
the Fairchild MM74HC595. This patch adds it to the DT binding.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
---

v2:
- Add Linus Walleij's R-b
---
 Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
index e8bc9f018edb1253d700945f006e19598efb299a..629cf9b2ab8e4a63fbe17f56792a46d2066d40c3 100644
--- a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
+++ b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
@@ -14,6 +14,7 @@ properties:
     enum:
       - fairchild,74hc595
       - nxp,74lvc594
+      - onnn,74hc595a
 
   reg:
     maxItems: 1

-- 
2.45.2

Re: [PATCH v2 1/3] dt-bindings: gpio: fairchild,74hc595: Add On Semi MC74HC595A compat

[Rob Herring]

On Tue, Dec 24, 2024 at 09:02:10AM +0100, J. Neuschäfer wrote:
> The On Semi MC74HC595A/MC74HCT595A is another part that is compatible with
> the Fairchild MM74HC595. This patch adds it to the DT binding.

To make the binding match what you say here, what you really should have 
is:

compatible = "onnn,74hc595a", "fairchild,74hc595";

And then no driver change is needed (until you have some difference you 
want to handle).

> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
> ---
> 
> v2:
> - Add Linus Walleij's R-b
> ---
>  Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
> index e8bc9f018edb1253d700945f006e19598efb299a..629cf9b2ab8e4a63fbe17f56792a46d2066d40c3 100644
> --- a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
> +++ b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
> @@ -14,6 +14,7 @@ properties:
>      enum:
>        - fairchild,74hc595
>        - nxp,74lvc594
> +      - onnn,74hc595a
>  
>    reg:
>      maxItems: 1
> 
> -- 
> 2.45.2
> 

[PATCH v2 2/3] gpio: 74x164: Add On Semi MC74HC595A compat

[J. Neuschäfer via B4 Relay]

From: "J. Neuschäfer" <j.ne@posteo.net>

The On Semi MC74HC595A/MC74HCT595A is another part that is compatible
with the Fairchild MM74HC595. This patch adds it to the driver.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
---

v2:
- Add Linus Walleij's R-b
- Add missing spi_device_id entry, required by the SPI core
---
 drivers/gpio/gpio-74x164.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-74x164.c b/drivers/gpio/gpio-74x164.c
index fca6cd2eb1ddacb3c330111343ebecf9b7c9234d..2ce00e90ea5650673420d7852999d13c298c2db6 100644
--- a/drivers/gpio/gpio-74x164.c
+++ b/drivers/gpio/gpio-74x164.c
@@ -165,6 +165,7 @@ static void gen_74x164_remove(struct spi_device *spi)
 
 static const struct spi_device_id gen_74x164_spi_ids[] = {
 	{ .name = "74hc595" },
+	{ .name = "74hc595a" },
 	{ .name = "74lvc594" },
 	{},
 };
@@ -173,6 +174,7 @@ MODULE_DEVICE_TABLE(spi, gen_74x164_spi_ids);
 static const struct of_device_id gen_74x164_dt_ids[] = {
 	{ .compatible = "fairchild,74hc595" },
 	{ .compatible = "nxp,74lvc594" },
+	{ .compatible = "onnn,74hc595a" },
 	{},
 };
 MODULE_DEVICE_TABLE(of, gen_74x164_dt_ids);

-- 
2.45.2

[PATCH v2 3/3] dt-bindings: gpio: fairchild,74hc595: Document chip select vs. latch clock

[J. Neuschäfer via B4 Relay]

From: "J. Neuschäfer" <j.ne@posteo.net>

From looking at the data sheets, it is not obvious that CS# and latch
clock can be treated at the same, but doing so works fine and saves the
hassle of (1) trying to specify a SPI device without CS, and (2) adding
another property to drive the latch clock[1].

[1]: https://lore.kernel.org/lkml/20241213-gpio74-v1-2-fa2c089caf41@posteo.net/

Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
---

v2:
- new patch
---
 .../devicetree/bindings/gpio/fairchild,74hc595.yaml     | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
index 629cf9b2ab8e4a63fbe17f56792a46d2066d40c3..a209c5b4f6e01ae9a376148b229273db7fdf0aa0 100644
--- a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
+++ b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
@@ -6,6 +6,23 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 
 title: Generic 8-bit shift register
 
+description: |
+  NOTE: These chips nominally don't have a chip select pin. They do however
+  have a rising-edge triggered latch clock (or storage register clock) pin,
+  which behaves like an active-low chip select.
+
+  After the bits are shifted into the shift register, CS# is driven high, which
+  the 74HC595 sees as a rising edge on the latch clock that results in a
+  transfer of the bits from the shift register to the storage register and thus
+  to the output pins.
+                      _   _       _   _
+  shift clock    ____| |_| |_..._| |_| |_________
+
+  latch clock                           * trigger
+                 ___                     ________
+  chip select#      |___________________|
+
+
 maintainers:
   - Maxime Ripard <mripard@kernel.org>
 

-- 
2.45.2

Re: [PATCH v2 3/3] dt-bindings: gpio: fairchild,74hc595: Document chip select vs. latch clock

[Linus Walleij]

On Tue, Dec 24, 2024 at 9:02 AM J. Neuschäfer via B4 Relay
<devnull+j.ne.posteo.net@kernel.org> wrote:

> From: "J. Neuschäfer" <j.ne@posteo.net>
>
> From looking at the data sheets, it is not obvious that CS# and latch
> clock can be treated at the same, but doing so works fine and saves the
> hassle of (1) trying to specify a SPI device without CS, and (2) adding
> another property to drive the latch clock[1].
>
> [1]: https://lore.kernel.org/lkml/20241213-gpio74-v1-2-fa2c089caf41@posteo.net/
>
> Signed-off-by: J. Neuschäfer <j.ne@posteo.net>

Fair enough!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH v2 3/3] dt-bindings: gpio: fairchild,74hc595: Document chip select vs. latch clock

[Rob Herring (Arm)]

On Tue, 24 Dec 2024 09:02:12 +0100, J. Neuschäfer wrote:
> 
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

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

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>


On Tue, 24 Dec 2024 09:02:09 +0100, J. Neuschäfer wrote:
> This patchset adds a compatible string for another part, and clarifies
> the role of the latch clock pin on 74x164-compatible shift registers.
> 
> 

Applied, thanks!

[1/3] dt-bindings: gpio: fairchild,74hc595: Add On Semi MC74HC595A compat
      commit: 0ba6cec7acbb666d28998780683deb83a3e677e3
[2/3] gpio: 74x164: Add On Semi MC74HC595A compat
      commit: b1468db9d865deb5271c9a20d05201b1c0636895
[3/3] dt-bindings: gpio: fairchild,74hc595: Document chip select vs. latch clock
      commit: b97263d14cd6400ab54f2675792b26e966e41168

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

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

[Geert Uytterhoeven]

Hi Bartosz,

CC spi

On Fri, Jan 3, 2025 at 9:33 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> On Tue, 24 Dec 2024 09:02:09 +0100, J. Neuschäfer wrote:
> > This patchset adds a compatible string for another part, and clarifies
> > the role of the latch clock pin on 74x164-compatible shift registers.
>
> Applied, thanks!
>
> [1/3] dt-bindings: gpio: fairchild,74hc595: Add On Semi MC74HC595A compat
>       commit: 0ba6cec7acbb666d28998780683deb83a3e677e3
> [2/3] gpio: 74x164: Add On Semi MC74HC595A compat
>       commit: b1468db9d865deb5271c9a20d05201b1c0636895

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

Perhaps we need a separate vendor prefix for the 74xx-series[1]?
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).

Thanks!

[1] https://en.wikipedia.org/wiki/List_of_7400-series_integrated_circuits

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Bartosz Golaszewski]

On Mon, Jan 6, 2025 at 10:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Bartosz,
>
> CC spi
>
> On Fri, Jan 3, 2025 at 9:33 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > On Tue, 24 Dec 2024 09:02:09 +0100, J. Neuschäfer wrote:
> > > This patchset adds a compatible string for another part, and clarifies
> > > the role of the latch clock pin on 74x164-compatible shift registers.
> >
> > Applied, thanks!
> >
> > [1/3] dt-bindings: gpio: fairchild,74hc595: Add On Semi MC74HC595A compat
> >       commit: 0ba6cec7acbb666d28998780683deb83a3e677e3
> > [2/3] gpio: 74x164: Add On Semi MC74HC595A compat
> >       commit: b1468db9d865deb5271c9a20d05201b1c0636895
>
> 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).
>
> Perhaps we need a separate vendor prefix for the 74xx-series[1]?
> 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.

Bartosz

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

[Csókás Bence]

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

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

[Bartosz Golaszewski]

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

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

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

[J. Neuschäfer]

On Wed, Jan 08, 2025 at 01:08:37PM +0100, Bartosz Golaszewski wrote:
> On Wed, Jan 8, 2025 at 11:26 AM Csókás Bence <csokas.bence@prolan.hu> wrote:
> >
> > Hi all,

Hi,


> >
> > 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`:
> >
> 
> J. Neuschäfer: do you want to send a follow-up for this?

I'm fine with this outcome, but I'd prefer not to prepare this proposed
patch (for reasons of time management on my end, mostly).  So if anyone
else would take it up, I'd greatly appreciate that.


Best regards,
 jn