The newly appeared gpio-delay module enables external signal delay lines
that may be connected to the GPIOs. But at the same time it copies the
GPIO forwarder functionality. Besides that the approach does not scale.
If we would have another external component, we would need yet another
driver. That's why I think, and seems others support me, better to
enable such a functionality inside GPIO aggregator driver.

Patch 1 is a cleanup that may be applied independently on the decision
about the rest.

Please, test and comment! Alexander, I would appreciate your tag.

In v3:
- added new patch 3 to prevent device removal from sysfs
- switched to feature in driver data instead of "compatible" (Geert)
- applied tags (Geert, Linus)
- left DT bindings untouched, can be amended later on

In v2:
- split as a series
- covered CONFIG_OF_GPIO=n case
- removed the gpio-delay
- moved gpio-delay Kconfig help to the comment in the code
- left udelay() call untouched as recommended by documentation

Andy Shevchenko (5):
  gpio: aggregator: Remove CONFIG_OF and of_match_ptr() protections
  gpio: aggregator: Support delay for setting up individual GPIOs
  gpio: aggregator: Prevent collisions between DT and user device IDs
  gpio: aggregator: Set up a parser of delay line parameters
  gpio: delay: Remove duplicative functionality

 drivers/gpio/Kconfig           |   9 --
 drivers/gpio/Makefile          |   1 -
 drivers/gpio/gpio-aggregator.c | 113 +++++++++++++++++++++--
 drivers/gpio/gpio-delay.c      | 164 ---------------------------------
 4 files changed, 106 insertions(+), 181 deletions(-)
 delete mode 100644 drivers/gpio/gpio-delay.c

-- 
2.40.0.1.gaa8946217a0b

On Thu, Jun 15, 2023 at 3:51 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> The newly appeared gpio-delay module enables external signal delay lines
> that may be connected to the GPIOs. But at the same time it copies the
> GPIO forwarder functionality. Besides that the approach does not scale.
> If we would have another external component, we would need yet another
> driver. That's why I think, and seems others support me, better to
> enable such a functionality inside GPIO aggregator driver.
>
> Patch 1 is a cleanup that may be applied independently on the decision
> about the rest.
>
> Please, test and comment! Alexander, I would appreciate your tag.
>
> In v3:
> - added new patch 3 to prevent device removal from sysfs
> - switched to feature in driver data instead of "compatible" (Geert)
> - applied tags (Geert, Linus)
> - left DT bindings untouched, can be amended later on
>
> In v2:
> - split as a series
> - covered CONFIG_OF_GPIO=n case
> - removed the gpio-delay
> - moved gpio-delay Kconfig help to the comment in the code
> - left udelay() call untouched as recommended by documentation
>
> Andy Shevchenko (5):
>   gpio: aggregator: Remove CONFIG_OF and of_match_ptr() protections
>   gpio: aggregator: Support delay for setting up individual GPIOs
>   gpio: aggregator: Prevent collisions between DT and user device IDs
>   gpio: aggregator: Set up a parser of delay line parameters
>   gpio: delay: Remove duplicative functionality
>
>  drivers/gpio/Kconfig           |   9 --
>  drivers/gpio/Makefile          |   1 -
>  drivers/gpio/gpio-aggregator.c | 113 +++++++++++++++++++++--
>  drivers/gpio/gpio-delay.c      | 164 ---------------------------------
>  4 files changed, 106 insertions(+), 181 deletions(-)
>  delete mode 100644 drivers/gpio/gpio-delay.c
>
> --
> 2.40.0.1.gaa8946217a0b
>

Applied patches 1, 2, 4 and 5. Thanks!

Bart

Hi Andy,

Am Donnerstag, 15. Juni 2023, 15:20:18 CEST schrieb Andy Shevchenko:
> The newly appeared gpio-delay module enables external signal delay lines
> that may be connected to the GPIOs. But at the same time it copies the
> GPIO forwarder functionality. Besides that the approach does not scale.
> If we would have another external component, we would need yet another
> driver. That's why I think, and seems others support me, better to
> enable such a functionality inside GPIO aggregator driver.
> 
> Patch 1 is a cleanup that may be applied independently on the decision
> about the rest.
> 
> Please, test and comment! Alexander, I would appreciate your tag.

This works on my platform:
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>

> In v3:
> - added new patch 3 to prevent device removal from sysfs
> - switched to feature in driver data instead of "compatible" (Geert)
> - applied tags (Geert, Linus)
> - left DT bindings untouched, can be amended later on
> 
> In v2:
> - split as a series
> - covered CONFIG_OF_GPIO=n case
> - removed the gpio-delay
> - moved gpio-delay Kconfig help to the comment in the code
> - left udelay() call untouched as recommended by documentation
> 
> Andy Shevchenko (5):
>   gpio: aggregator: Remove CONFIG_OF and of_match_ptr() protections
>   gpio: aggregator: Support delay for setting up individual GPIOs
>   gpio: aggregator: Prevent collisions between DT and user device IDs
>   gpio: aggregator: Set up a parser of delay line parameters
>   gpio: delay: Remove duplicative functionality
> 
>  drivers/gpio/Kconfig           |   9 --
>  drivers/gpio/Makefile          |   1 -
>  drivers/gpio/gpio-aggregator.c | 113 +++++++++++++++++++++--
>  drivers/gpio/gpio-delay.c      | 164 ---------------------------------
>  4 files changed, 106 insertions(+), 181 deletions(-)
>  delete mode 100644 drivers/gpio/gpio-delay.c


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

On Fri, Jun 16, 2023 at 11:01:17AM +0200, Alexander Stein wrote:
> Am Donnerstag, 15. Juni 2023, 15:20:18 CEST schrieb Andy Shevchenko:
> > The newly appeared gpio-delay module enables external signal delay lines
> > that may be connected to the GPIOs. But at the same time it copies the
> > GPIO forwarder functionality. Besides that the approach does not scale.
> > If we would have another external component, we would need yet another
> > driver. That's why I think, and seems others support me, better to
> > enable such a functionality inside GPIO aggregator driver.
> > 
> > Patch 1 is a cleanup that may be applied independently on the decision
> > about the rest.
> > 
> > Please, test and comment! Alexander, I would appreciate your tag.
> 
> This works on my platform:
> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>

Thank you!

-- 
With Best Regards,
Andy Shevchenko