diff mbox series

[4/7] gpiolib: of: add a quirk for reset line for Marvell NFC controller

Message ID 20221011-gpiolib-quirks-v1-4-e01d9d3e7b29@gmail.com (mailing list archive)
State New, archived
Headers show
Series gpiolib: more quirks to handle legacy names | expand

Commit Message

Dmitry Torokhov Oct. 11, 2022, 10:19 p.m. UTC
The controller is using non-standard "reset-n-io" name for its reset
gpio property, whereas gpiod API expects "<name>-gpios". Add a quirk
so that gpiod API will still work on unmodified DTSes.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/gpio/gpiolib-of.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

Comments

Daniel Thompson Oct. 12, 2022, 10:29 a.m. UTC | #1
On Tue, Oct 11, 2022 at 03:19:32PM -0700, Dmitry Torokhov wrote:
> The controller is using non-standard "reset-n-io" name for its reset
> gpio property, whereas gpiod API expects "<name>-gpios". Add a quirk
> so that gpiod API will still work on unmodified DTSes.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

How/when has/will the DT bindings documentation for this hardware be
updated to describe the new bindings?

Delivering the quirks ahead of driver updates is great for avoiding
merge conflicts but it also conceals the rename from reviewers so
risks neglecting to update the bindings.

Other than that:
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>


Daniel.

> ---
>  drivers/gpio/gpiolib-of.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 576f2f0c3432..7d4193fe36e5 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -383,6 +383,16 @@ static struct gpio_desc *of_find_gpio_rename(struct device_node *np,
>  #if IS_ENABLED(CONFIG_MFD_ARIZONA)
>  		{ "wlf,reset",	NULL,		NULL },
>  #endif
> +
> +#if IS_ENABLED(CONFIG_NFC_MRVL_I2C)
> +		{ "reset",	"reset-n-io",	"marvell,nfc-i2c" },
> +#endif
> +#if IS_ENABLED(CONFIG_NFC_MRVL_SPI)
> +		{ "reset",	"reset-n-io",	"marvell,nfc-spi" },
> +#endif
> +#if IS_ENABLED(CONFIG_NFC_MRVL_UART)
> +		{ "reset",	"reset-n-io",	"marvell,nfc-uart" },
> +#endif
>  #if !IS_ENABLED(CONFIG_PCI_LANTIQ)
>  		/* MIPS Lantiq PCI */
>  		{ "reset",	"gpios-reset",	"lantiq,pci-xway" },
>
> --
> b4 0.11.0-dev-5166b
Dmitry Torokhov Oct. 12, 2022, 6:45 p.m. UTC | #2
On Wed, Oct 12, 2022 at 11:29:02AM +0100, Daniel Thompson wrote:
> On Tue, Oct 11, 2022 at 03:19:32PM -0700, Dmitry Torokhov wrote:
> > The controller is using non-standard "reset-n-io" name for its reset
> > gpio property, whereas gpiod API expects "<name>-gpios". Add a quirk
> > so that gpiod API will still work on unmodified DTSes.
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> How/when has/will the DT bindings documentation for this hardware be
> updated to describe the new bindings?
> 
> Delivering the quirks ahead of driver updates is great for avoiding
> merge conflicts but it also conceals the rename from reviewers so
> risks neglecting to update the bindings.

I was planning on sending binding updates once driver patches land.

> 
> Other than that:
> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>

Thank you for your reviews!
Daniel Thompson Oct. 12, 2022, 6:50 p.m. UTC | #3
On Wed, Oct 12, 2022 at 11:45:02AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 12, 2022 at 11:29:02AM +0100, Daniel Thompson wrote:
> > On Tue, Oct 11, 2022 at 03:19:32PM -0700, Dmitry Torokhov wrote:
> > > The controller is using non-standard "reset-n-io" name for its reset
> > > gpio property, whereas gpiod API expects "<name>-gpios". Add a quirk
> > > so that gpiod API will still work on unmodified DTSes.
> > >
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >
> > How/when has/will the DT bindings documentation for this hardware be
> > updated to describe the new bindings?
> >
> > Delivering the quirks ahead of driver updates is great for avoiding
> > merge conflicts but it also conceals the rename from reviewers so
> > risks neglecting to update the bindings.
>
> I was planning on sending binding updates once driver patches land.

I'd have a (weak) preference for them being shared in the same patchset.
Maintainers can either ack or the changes can land seperately but
having them in the same patchset helps avoid having to quibble or check!


Daniel.
Dmitry Torokhov Oct. 12, 2022, 6:55 p.m. UTC | #4
On Wed, Oct 12, 2022 at 07:50:49PM +0100, Daniel Thompson wrote:
> On Wed, Oct 12, 2022 at 11:45:02AM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 12, 2022 at 11:29:02AM +0100, Daniel Thompson wrote:
> > > On Tue, Oct 11, 2022 at 03:19:32PM -0700, Dmitry Torokhov wrote:
> > > > The controller is using non-standard "reset-n-io" name for its reset
> > > > gpio property, whereas gpiod API expects "<name>-gpios". Add a quirk
> > > > so that gpiod API will still work on unmodified DTSes.
> > > >
> > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > >
> > > How/when has/will the DT bindings documentation for this hardware be
> > > updated to describe the new bindings?
> > >
> > > Delivering the quirks ahead of driver updates is great for avoiding
> > > merge conflicts but it also conceals the rename from reviewers so
> > > risks neglecting to update the bindings.
> >
> > I was planning on sending binding updates once driver patches land.
> 
> I'd have a (weak) preference for them being shared in the same patchset.
> Maintainers can either ack or the changes can land seperately but
> having them in the same patchset helps avoid having to quibble or check!

OK, so how about once we agree and land this patchset to gpiolib I can
blast driver patches + binding patches together?

Thanks.
Daniel Thompson Oct. 13, 2022, 1 p.m. UTC | #5
On Wed, Oct 12, 2022 at 11:55:36AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 12, 2022 at 07:50:49PM +0100, Daniel Thompson wrote:
> > On Wed, Oct 12, 2022 at 11:45:02AM -0700, Dmitry Torokhov wrote:
> > > On Wed, Oct 12, 2022 at 11:29:02AM +0100, Daniel Thompson wrote:
> > > > On Tue, Oct 11, 2022 at 03:19:32PM -0700, Dmitry Torokhov wrote:
> > > > > The controller is using non-standard "reset-n-io" name for its reset
> > > > > gpio property, whereas gpiod API expects "<name>-gpios". Add a quirk
> > > > > so that gpiod API will still work on unmodified DTSes.
> > > > >
> > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > >
> > > > How/when has/will the DT bindings documentation for this hardware be
> > > > updated to describe the new bindings?
> > > >
> > > > Delivering the quirks ahead of driver updates is great for avoiding
> > > > merge conflicts but it also conceals the rename from reviewers so
> > > > risks neglecting to update the bindings.
> > >
> > > I was planning on sending binding updates once driver patches land.
> >
> > I'd have a (weak) preference for them being shared in the same patchset.
> > Maintainers can either ack or the changes can land seperately but
> > having them in the same patchset helps avoid having to quibble or check!
>
> OK, so how about once we agree and land this patchset to gpiolib I can
> blast driver patches + binding patches together?

That's good for me!


Daniel.
diff mbox series

Patch

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 576f2f0c3432..7d4193fe36e5 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -383,6 +383,16 @@  static struct gpio_desc *of_find_gpio_rename(struct device_node *np,
 #if IS_ENABLED(CONFIG_MFD_ARIZONA)
 		{ "wlf,reset",	NULL,		NULL },
 #endif
+
+#if IS_ENABLED(CONFIG_NFC_MRVL_I2C)
+		{ "reset",	"reset-n-io",	"marvell,nfc-i2c" },
+#endif
+#if IS_ENABLED(CONFIG_NFC_MRVL_SPI)
+		{ "reset",	"reset-n-io",	"marvell,nfc-spi" },
+#endif
+#if IS_ENABLED(CONFIG_NFC_MRVL_UART)
+		{ "reset",	"reset-n-io",	"marvell,nfc-uart" },
+#endif
 #if !IS_ENABLED(CONFIG_PCI_LANTIQ)
 		/* MIPS Lantiq PCI */
 		{ "reset",	"gpios-reset",	"lantiq,pci-xway" },