| Message ID | 20220721093422.2173982-1-marcus.folkesson@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] gpio: gpio-74x164: add support for CDx4HC4094 | expand |
Hello Marcus, Am Thu, Jul 21, 2022 at 11:34:21AM +0200 schrieb Marcus Folkesson: > 74hc4094 and 75hc4094 works similar to 74x164 but has an additional ^^ That 75 is probably a typo, isn't it? Greets Alex > storage latch associated with each stage for strobing data from the > serial input to parallell buffer tri-state output. > > Add support for an optional strobe pin. > > Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> > --- > drivers/gpio/gpio-74x164.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/drivers/gpio/gpio-74x164.c b/drivers/gpio/gpio-74x164.c > index e00c33310517..4a1c4de358e4 100644 > --- a/drivers/gpio/gpio-74x164.c > +++ b/drivers/gpio/gpio-74x164.c > @@ -21,6 +21,7 @@ struct gen_74x164_chip { > struct gpio_chip gpio_chip; > struct mutex lock; > struct gpio_desc *gpiod_oe; > + struct gpio_desc *gpiod_strobe; > u32 registers; > /* > * Since the registers are chained, every byte sent will make > @@ -66,6 +67,10 @@ static void gen_74x164_set_value(struct gpio_chip *gc, > chip->buffer[bank] &= ~(1 << pin); > > __gen_74x164_write_config(chip); > + > + /* Latch data to output pins*/ > + gpiod_set_value_cansleep(chip->gpiod_strobe, 1); > + gpiod_set_value_cansleep(chip->gpiod_strobe, 0); > mutex_unlock(&chip->lock); > } > > @@ -87,6 +92,10 @@ static void gen_74x164_set_multiple(struct gpio_chip *gc, unsigned long *mask, > chip->buffer[bank] |= bitmask; > } > __gen_74x164_write_config(chip); > + > + /* Latch data to output pins*/ > + gpiod_set_value_cansleep(chip->gpiod_strobe, 1); > + gpiod_set_value_cansleep(chip->gpiod_strobe, 0); > mutex_unlock(&chip->lock); > } > > @@ -129,6 +138,12 @@ static int gen_74x164_probe(struct spi_device *spi) > > gpiod_set_value_cansleep(chip->gpiod_oe, 1); > > + chip->gpiod_strobe = devm_gpiod_get_optional(&spi->dev, "strobe", > + GPIOD_OUT_LOW); > + if (IS_ERR(chip->gpiod_strobe)) > + return PTR_ERR(chip->gpiod_strobe); > + > + > spi_set_drvdata(spi, chip); > > chip->gpio_chip.label = spi->modalias; > @@ -153,6 +168,10 @@ static int gen_74x164_probe(struct spi_device *spi) > goto exit_destroy; > } > > + /* Latch data to output pins*/ > + gpiod_set_value_cansleep(chip->gpiod_strobe, 1); > + gpiod_set_value_cansleep(chip->gpiod_strobe, 0); > + > ret = gpiochip_add_data(&chip->gpio_chip, chip); > if (!ret) > return 0; > @@ -182,6 +201,8 @@ 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 = "ti,cd54hc4094" }, > + { .compatible = "ti,cd74hc4094" }, > {}, > }; > MODULE_DEVICE_TABLE(of, gen_74x164_dt_ids); > -- > 2.36.1 >
On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson <marcus.folkesson@gmail.com> wrote: > > 74hc4094 and 75hc4094 works similar to 74x164 but has an additional > storage latch associated with each stage for strobing data from the > serial input to parallell buffer tri-state output. parallel > Add support for an optional strobe pin. Sorry for my absence of understanding, but why? SPI has MOSI, CLK, CS, where the last one is exactly for that. No?
On Mon, Jul 25, 2022 at 11:32 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson > <marcus.folkesson@gmail.com> wrote: > > > > 74hc4094 and 75hc4094 works similar to 74x164 but has an additional > > storage latch associated with each stage for strobing data from the > > serial input to parallell buffer tri-state output. > > parallel > > > Add support for an optional strobe pin. > > Sorry for my absence of understanding, but why? > SPI has MOSI, CLK, CS, where the last one is exactly for that. No? I have a 595 register which also has a latch. What I expect to see in this series is just a compatible string addition (but again, why even that is needed?).
On Mon, Jul 25, 2022 at 11:32:16AM +0200, Andy Shevchenko wrote: > On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson > <marcus.folkesson@gmail.com> wrote: > > > > 74hc4094 and 75hc4094 works similar to 74x164 but has an additional > > storage latch associated with each stage for strobing data from the > > serial input to parallell buffer tri-state output. > > parallel > > > Add support for an optional strobe pin. > > Sorry for my absence of understanding, but why? > SPI has MOSI, CLK, CS, where the last one is exactly for that. No? You're right, I didn't think of that CS could be used for this. The additional compatible strings is then superfluous, so I will skip those. > > > -- > With Best Regards, > Andy Shevchenko Best regards Marcus Folkesson
On Mon, Jul 25, 2022 at 11:32 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson > <marcus.folkesson@gmail.com> wrote: > > > > 74hc4094 and 75hc4094 works similar to 74x164 but has an additional > > storage latch associated with each stage for strobing data from the > > serial input to parallell buffer tri-state output. > > parallel > > > Add support for an optional strobe pin. > > Sorry for my absence of understanding, but why? > SPI has MOSI, CLK, CS, where the last one is exactly for that. No? Forgive me if I misunderstand, but if you use CS that way, the way that the SPI framework works is to assert CS then transfer a few chunks over SPI (MOSI/CLK) then de-assert CS. If CS is used for strobe, it is constantly asserted during transfer and the sequence will be latched out immediately as you write the SPI transfers and the data is clocked through the register, making the whole train of zeroes and ones flash across the output pins before they stabilize after the SPI transfer is finished. If you first do the SPI transfer, then strobe after finished, this will not happen. Then it should be a separate pin, so this doesn't happen, right? Yours, Linus Walleij
On Mon, Jul 25, 2022 at 3:54 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Mon, Jul 25, 2022 at 11:32 AM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson > > <marcus.folkesson@gmail.com> wrote: > > > > > > 74hc4094 and 75hc4094 works similar to 74x164 but has an additional > > > storage latch associated with each stage for strobing data from the > > > serial input to parallell buffer tri-state output. > > > > parallel > > > > > Add support for an optional strobe pin. > > > > Sorry for my absence of understanding, but why? > > SPI has MOSI, CLK, CS, where the last one is exactly for that. No? > > Forgive me if I misunderstand, but if you use CS that > way, the way that the SPI framework works is to assert > CS then transfer a few chunks over SPI (MOSI/CLK) > then de-assert CS. > > If CS is used for strobe, it is constantly asserted > during transfer and the sequence will be latched > out immediately as you write the SPI transfers and > the data is clocked through the register, making the > whole train of zeroes and ones flash across the > output pins before they stabilize after the SPI > transfer is finished. > > If you first do the SPI transfer, then strobe after > finished, this will not happen. > > Then it should be a separate pin, so this doesn't > happen, right? > > Yours, > Linus Walleij
On Mon, Jul 25, 2022 at 3:54 PM Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Jul 25, 2022 at 11:32 AM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson > > <marcus.folkesson@gmail.com> wrote: ... > > Sorry for my absence of understanding, but why? > > SPI has MOSI, CLK, CS, where the last one is exactly for that. No? > > Forgive me if I misunderstand, but if you use CS that > way, the way that the SPI framework works is to assert > CS then transfer a few chunks over SPI (MOSI/CLK) > then de-assert CS. No, CS here is used exactly for what it is designed for ("tell that this message is *for me*"). Yes, hardware implementation here is a latch register. Because otherwise ALL messages are "for me" which is wrong. Is it wrong interpretation of the hardware and SPI? > If CS is used for strobe, it is constantly asserted > during transfer and the sequence will be latched > out immediately as you write the SPI transfers and > the data is clocked through the register, making the > whole train of zeroes and ones flash across the > output pins before they stabilize after the SPI > transfer is finished. I'm not sure I understand the stabilization issue here. It's how SPI normally works and we have a lot of delays here and there related to the phase of the CS in comparison to clock and data. We have a lot of time to stabilize the outputs of the shift register before latching it. Did I miss anything? > If you first do the SPI transfer, then strobe after > finished, this will not happen. I have hardware, I have tested it and I understand what you mean by "stabilizing", but finishing transfer _is_ CS toggling for _this_ chip. No? > Then it should be a separate pin, so this doesn't > happen, right? I think no, you don't need it. I.o.w. either I'm missing something very interesting about both this kind of chips and SPI basics (shame on me in this case) or...?
On Mon, Jul 25, 2022 at 10:49 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Mon, Jul 25, 2022 at 3:54 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Mon, Jul 25, 2022 at 11:32 AM Andy Shevchenko > > <andy.shevchenko@gmail.com> wrote: > > > On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson > > > <marcus.folkesson@gmail.com> wrote: > > ... > > > > Sorry for my absence of understanding, but why? > > > SPI has MOSI, CLK, CS, where the last one is exactly for that. No? > > > > Forgive me if I misunderstand, but if you use CS that > > way, the way that the SPI framework works is to assert > > CS then transfer a few chunks over SPI (MOSI/CLK) > > then de-assert CS. > > No, CS here is used exactly for what it is designed for ("tell that > this message is *for me*"). Yes, hardware implementation here is a > latch register. Because otherwise ALL messages are "for me" which is > wrong. Is it wrong interpretation of the hardware and SPI? I was under the impression that the shift register has no idea if the message is "for me", and that there can only be one shift register on the bus if using ordinary SPI to control it. I look at this data sheet: https://www.farnell.com/datasheets/2030250.pdf IIUC what you say is CS == STR? > > If CS is used for strobe, it is constantly asserted > > during transfer and the sequence will be latched > > out immediately as you write the SPI transfers and > > the data is clocked through the register, making the > > whole train of zeroes and ones flash across the > > output pins before they stabilize after the SPI > > transfer is finished. > > I'm not sure I understand the stabilization issue here. It's how SPI > normally works and we have a lot of delays here and there related to > the phase of the CS in comparison to clock and data. We have a lot of > time to stabilize the outputs of the shift register before latching > it. Did I miss anything? STR (strobe) is latching out the data, and how is that happening when you connect it to CS? CS is asserted throughout the whole transaction... STR is supposed to be used like in the patch: to be toggled after the transfer is complete. CS does not behave like this at all. > > If you first do the SPI transfer, then strobe after > > finished, this will not happen. > > I have hardware, I have tested it and I understand what you mean by > "stabilizing", but finishing transfer _is_ CS toggling for _this_ > chip. No? Well it will work, because all values come out, however *during* the transfer, not *after* the transfer as intended with the STR signal. > > Then it should be a separate pin, so this doesn't > > happen, right? > > I think no, you don't need it. I.o.w. either I'm missing something > very interesting about both this kind of chips and SPI basics (shame > on me in this case) or...? SPI will assert CS, then make the transfer i.e. toggle the clock a few times with new data on MOSI each clock cycle, then de-assert CS. STR is supposed to be toggled after all this happened to latch out the data to the outputs, just like the patch does. What happens if STR is connected to CS is that you will see the shift register contents change on the output. It will be fast so it will look fine if it is e.g. a LED. But if it is something more sensitive, there will be chaos. At least how I see it ...? Yours, Linus Walleij
On Tue, Jul 26, 2022 at 12:22 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Mon, Jul 25, 2022 at 10:49 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Mon, Jul 25, 2022 at 3:54 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > > On Mon, Jul 25, 2022 at 11:32 AM Andy Shevchenko > > > <andy.shevchenko@gmail.com> wrote: > > > > On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson > > > > <marcus.folkesson@gmail.com> wrote: > > > > ... > > > > > > Sorry for my absence of understanding, but why? > > > > SPI has MOSI, CLK, CS, where the last one is exactly for that. No? > > > > > > Forgive me if I misunderstand, but if you use CS that > > > way, the way that the SPI framework works is to assert > > > CS then transfer a few chunks over SPI (MOSI/CLK) > > > then de-assert CS. > > > > No, CS here is used exactly for what it is designed for ("tell that > > this message is *for me*"). Yes, hardware implementation here is a > > latch register. Because otherwise ALL messages are "for me" which is > > wrong. Is it wrong interpretation of the hardware and SPI? > > I was under the impression that the shift register has no idea > if the message is "for me", and that there can only be one shift register > on the bus if using ordinary SPI to control it. Yes and no. Yes, the shift register in this HW is always 'for all'. No, there are as many shift registers as you have chip selects on the same bus. > I look at this data sheet: > https://www.farnell.com/datasheets/2030250.pdf > > IIUC what you say is CS == STR? Yes. > > > If CS is used for strobe, it is constantly asserted > > > during transfer and the sequence will be latched > > > out immediately as you write the SPI transfers and > > > the data is clocked through the register, making the > > > whole train of zeroes and ones flash across the > > > output pins before they stabilize after the SPI > > > transfer is finished. > > > > I'm not sure I understand the stabilization issue here. It's how SPI > > normally works and we have a lot of delays here and there related to > > the phase of the CS in comparison to clock and data. We have a lot of > > time to stabilize the outputs of the shift register before latching > > it. Did I miss anything? > > STR (strobe) is latching out the data, and how is that happening > when you connect it to CS? CS is asserted throughout the whole > transaction... Is it a problem? I consider it exactly what it's designed for, it tells the chip: "hey, there is something for you". > STR is supposed to be used like in the patch: to be toggled after > the transfer is complete. CS does not behave like this at all. How is CS different in this sense? Just longer? Who cares that it starts early and latches exactly at the time it must latch the data. > > > If you first do the SPI transfer, then strobe after > > > finished, this will not happen. > > > > I have hardware, I have tested it and I understand what you mean by > > "stabilizing", but finishing transfer _is_ CS toggling for _this_ > > chip. No? > > Well it will work, because all values come out, however *during* > the transfer, not *after* the transfer as intended with the > STR signal. No. I think you missed one little but crucial detail. The strobe is edge, not level, while you consider CS as a level signal (only). > > > Then it should be a separate pin, so this doesn't > > > happen, right? > > > > I think no, you don't need it. I.o.w. either I'm missing something > > very interesting about both this kind of chips and SPI basics (shame > > on me in this case) or...? > > SPI will assert CS, then make the transfer i.e. toggle the clock > a few times with new data on MOSI each clock cycle, then > de-assert CS. Right. > STR is supposed to be toggled after all this happened to latch > out the data to the outputs, just like the patch does. So... > What happens if STR is connected to CS is that you will see > the shift register contents change on the output. It will be > fast so it will look fine if it is e.g. a LED. But if it is something > more sensitive, there will be chaos. See Figure 7 and Table 9 in the datasheet you linked to. When STR is low, the data is not changed. Maybe it's not clear in this datasheet, I found somewhere in a more clear table. > At least how I see it ...? If what you are saying is true, the hardware is totally broken and I wouldn't use it. I.o.w. if the strobe passes all data when it's at low level and latches at low-to-high, it's broken by definition in my point of view.
On Tue, Jul 26, 2022 at 8:54 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Tue, Jul 26, 2022 at 12:22 AM Linus Walleij <linus.walleij@linaro.org> wrote: ... > See Figure 7 and Table 9 in the datasheet you linked to. When STR is Table 9 --> Figure 9 > low, the data is not changed. Maybe it's not clear in this datasheet, > I found somewhere > in a more clear table. If you have hardware and an oscilloscope you may test it. We will know for sure :-)
On Tue, Jul 26, 2022 at 9:00 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Tue, Jul 26, 2022 at 8:54 AM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Tue, Jul 26, 2022 at 12:22 AM Linus Walleij <linus.walleij@linaro.org> wrote: ... > > See Figure 7 and Table 9 in the datasheet you linked to. When STR is > > Table 9 --> Figure 9 > > > low, the data is not changed. Maybe it's not clear in this datasheet, > > I found somewhere > > in a more clear table. Ah, Table 3 shows that. > If you have hardware and an oscilloscope you may test it. We will know > for sure :-)
On Tue, Jul 26, 2022 at 8:55 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Tue, Jul 26, 2022 at 12:22 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > Well it will work, because all values come out, however *during* > > the transfer, not *after* the transfer as intended with the > > STR signal. > > No. I think you missed one little but crucial detail. The strobe is > edge, not level, while you consider CS as a level signal (only). Aha! Then it works :) > See Figure 7 and Table 9 in the datasheet you linked to. When STR is > low, the data is not changed. Maybe it's not clear in this datasheet, > I found somewhere > in a more clear table. > > > At least how I see it ...? > > If what you are saying is true, the hardware is totally broken and I > wouldn't use it. I.o.w. if the strobe passes all data when it's at low > level and latches at low-to-high, it's broken by definition in my > point of view. I have seen strobes that are level-active in my life, but if you say this one isn't then all is fine! Yours, Linus Walleij
On Tue, Jul 26, 2022 at 9:23 AM Linus Walleij <linus.walleij@linaro.org> wrote: > On Tue, Jul 26, 2022 at 8:55 AM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Tue, Jul 26, 2022 at 12:22 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > > > Well it will work, because all values come out, however *during* > > > the transfer, not *after* the transfer as intended with the > > > STR signal. > > > > No. I think you missed one little but crucial detail. The strobe is > > edge, not level, while you consider CS as a level signal (only). > > Aha! Then it works :) > > > See Figure 7 and Table 9 in the datasheet you linked to. When STR is > > low, the data is not changed. Maybe it's not clear in this datasheet, > > I found somewhere > > in a more clear table. > > > > > At least how I see it ...? > > > > If what you are saying is true, the hardware is totally broken and I > > wouldn't use it. I.o.w. if the strobe passes all data when it's at low > > level and latches at low-to-high, it's broken by definition in my > > point of view. > > I have seen strobes that are level-active in my life, but if you > say this one isn't then all is fine! It's rather my common sense, because we have a clock here to shift a register. It's kinda obvious *to me* that when we have a latch, that latch shouldn't pass data on a level. Yes, there are buffers with level strobe, but it's different. So, as I said, the oscilloscope can finish our discussion one way or the other, but I believe it will be my way ;) I will very (badly) surprised if it becomes your way. It will ruin my beliefs in humanity. Not less.
On Tue, Jul 26, 2022 at 9:31 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > It's rather my common sense, because we have a clock here to shift a > register. It's kinda obvious *to me* that when we have a latch, that > latch shouldn't pass data on a level. Yes, there are buffers with > level strobe, but it's different. So, as I said, the oscilloscope can > finish our discussion one way or the other, but I believe it will be > my way ;) I will very (badly) surprised if it becomes your way. It > will ruin my beliefs in humanity. Not less. I think you are right Andy, I trust your judgement better than my own here for sure! Yours, Linus Walleij
On Tue, Jul 26, 2022 at 10:28 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Tue, Jul 26, 2022 at 9:31 AM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > > It's rather my common sense, because we have a clock here to shift a > > register. It's kinda obvious *to me* that when we have a latch, that > > latch shouldn't pass data on a level. Yes, there are buffers with > > level strobe, but it's different. So, as I said, the oscilloscope can > > finish our discussion one way or the other, but I believe it will be > > my way ;) I will very (badly) surprised if it becomes your way. It > > will ruin my beliefs in humanity. Not less. > > I think you are right Andy, I trust your judgement better than my own > here for sure! The true science when we put any statement in doubt and then go step-by-step to prove it again. If this will be done successfully the statement is correct. That said, thank you to put this in doubt, it's appreciated!
diff --git a/drivers/gpio/gpio-74x164.c b/drivers/gpio/gpio-74x164.c index e00c33310517..4a1c4de358e4 100644 --- a/drivers/gpio/gpio-74x164.c +++ b/drivers/gpio/gpio-74x164.c @@ -21,6 +21,7 @@ struct gen_74x164_chip { struct gpio_chip gpio_chip; struct mutex lock; struct gpio_desc *gpiod_oe; + struct gpio_desc *gpiod_strobe; u32 registers; /* * Since the registers are chained, every byte sent will make @@ -66,6 +67,10 @@ static void gen_74x164_set_value(struct gpio_chip *gc, chip->buffer[bank] &= ~(1 << pin); __gen_74x164_write_config(chip); + + /* Latch data to output pins*/ + gpiod_set_value_cansleep(chip->gpiod_strobe, 1); + gpiod_set_value_cansleep(chip->gpiod_strobe, 0); mutex_unlock(&chip->lock); } @@ -87,6 +92,10 @@ static void gen_74x164_set_multiple(struct gpio_chip *gc, unsigned long *mask, chip->buffer[bank] |= bitmask; } __gen_74x164_write_config(chip); + + /* Latch data to output pins*/ + gpiod_set_value_cansleep(chip->gpiod_strobe, 1); + gpiod_set_value_cansleep(chip->gpiod_strobe, 0); mutex_unlock(&chip->lock); } @@ -129,6 +138,12 @@ static int gen_74x164_probe(struct spi_device *spi) gpiod_set_value_cansleep(chip->gpiod_oe, 1); + chip->gpiod_strobe = devm_gpiod_get_optional(&spi->dev, "strobe", + GPIOD_OUT_LOW); + if (IS_ERR(chip->gpiod_strobe)) + return PTR_ERR(chip->gpiod_strobe); + + spi_set_drvdata(spi, chip); chip->gpio_chip.label = spi->modalias; @@ -153,6 +168,10 @@ static int gen_74x164_probe(struct spi_device *spi) goto exit_destroy; } + /* Latch data to output pins*/ + gpiod_set_value_cansleep(chip->gpiod_strobe, 1); + gpiod_set_value_cansleep(chip->gpiod_strobe, 0); + ret = gpiochip_add_data(&chip->gpio_chip, chip); if (!ret) return 0; @@ -182,6 +201,8 @@ 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 = "ti,cd54hc4094" }, + { .compatible = "ti,cd74hc4094" }, {}, }; MODULE_DEVICE_TABLE(of, gen_74x164_dt_ids);
74hc4094 and 75hc4094 works similar to 74x164 but has an additional storage latch associated with each stage for strobing data from the serial input to parallell buffer tri-state output. Add support for an optional strobe pin. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> --- drivers/gpio/gpio-74x164.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)