| 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 |
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
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!
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.
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.
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 --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" },
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(+)