mbox series

[GIT,PULL] gpio: updates for v5.11-rc1

Message ID 20201209095248.22408-1-brgl@bgdev.pl
State New
Headers show
Series [GIT,PULL] gpio: updates for v5.11-rc1 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/gpio-updates-for-v5.11

Message

Bartosz Golaszewski Dec. 9, 2020, 9:52 a.m. UTC
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Linus,

These are the patches I collected over this release cycle. Nothing all
too exciting - mainly just updates to drivers and refactoring of the
core code. Please pull.

Bartosz

The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:

  Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/gpio-updates-for-v5.11

for you to fetch changes up to b5252196d08abd82f3b21532354f71a40dd2801d:

  gpio: put virtual gpio device into their own submenu (2020-12-08 10:13:51 +0100)

----------------------------------------------------------------
gpio updates for v5.11-rc1

- several refactoring patches of the core gpiolib code
- add support for NXP PCAL9554B/C to gpio-pca953x
- allow probing mockup devices from device tree
- refactoring and improvements to gpio-rcar
- improvements to locking in gpio-tegra
- code shrink in gpiolib devres
- get the irq offset from device tree in gpio-sifive
- major refactoring of gpio-exar
- convert gpio-mvebu pwm access to regmap
- create a new submenu for virtual GPIO drivers
- fix clang fall-through warnings treewide
- minor driver refactoring and tweaks sprinkled all over

----------------------------------------------------------------
Alexandru Ardelean (1):
      gpio: xra1403: remove unneeded spi_set_drvdata()

Andy Shevchenko (4):
      gpiolib: Extract gpiod_not_found() helper
      gpiolib: of: Use named item for enum gpiod_flags variable
      gpiolib: Unify expectations about ->request() returned value
      gpiolib: split error path in gpiod_request_commit()

Bartosz Golaszewski (8):
      gpiolib: devres: shrink devm_gpiochip_add_data_with_key()
      gpio: exar: add a newline after the copyright notice
      gpio: exar: include idr.h
      gpio: exar: switch to a simpler IDA interface
      gpio: exar: use a helper variable for &pdev->dev
      gpio: exar: unduplicate address and offset computation
      gpio: exar: switch to using regmap
      gpio: exar: use devm action for freeing the IDA and drop remove()

Baruch Siach (2):
      gpio: mvebu: update Armada XP per-CPU comment
      gpio: mvebu: switch pwm duration registers to regmap

Damien Le Moal (1):
      gpio: dwapb: Remove unnecessary error message

Dmitry Osipenko (2):
      gpio: tegra: Add lockdep class
      gpio: tegra: Use raw_spinlock

Enrico Weigelt, metux IT consult (1):
      gpio: put virtual gpio device into their own submenu

Geert Uytterhoeven (4):
      gpio: rcar: Cache gpiochip_get_data() return value
      gpio: rcar: Align register offsets
      gpio: rcar: Rework hardware features handling
      gpio: rcar: Implement gpio_chip.get_multiple()

Greentime Hu (1):
      gpio: sifive: To get gpio irq offset from device tree data

Grygorii Strashko (2):
      gpio: omap: handle deferred probe with dev_err_probe() for gpiochip_add_data()
      gpiolib: do not print err message for EPROBE_DEFER

Gustavo A. R. Silva (2):
      gpiolib: acpi: Fix fall-through warnings for Clang
      gpio: ath79: Fix fall-through warning for Clang

Kent Gibson (2):
      gpiolib: cdev: document that line eflags are shared
      gpiolib: cdev: add GPIO_V2_LINE_FLAG_EDGE_BOTH and use it in edge_irq_thread()

Mike Looijmans (1):
      dt-bindings: gpio: pca953x: Add support for the NXP PCAL9554B/C

Vincent Whitchurch (1):
      gpio: mockup: Allow probing from device tree

 .../devicetree/bindings/gpio/gpio-pca95xx.yaml     |   1 +
 drivers/gpio/Kconfig                               |   5 +
 drivers/gpio/gpio-ath79.c                          |   1 +
 drivers/gpio/gpio-dwapb.c                          |   7 +-
 drivers/gpio/gpio-exar.c                           | 155 ++++++++++-----------
 drivers/gpio/gpio-mockup.c                         |  11 +-
 drivers/gpio/gpio-mvebu.c                          |  71 +++++-----
 drivers/gpio/gpio-omap.c                           |   7 +-
 drivers/gpio/gpio-rcar.c                           |  87 ++++++++----
 drivers/gpio/gpio-sifive.c                         |  14 +-
 drivers/gpio/gpio-tegra.c                          |  22 ++-
 drivers/gpio/gpio-xra1403.c                        |  10 +-
 drivers/gpio/gpiolib-acpi.c                        |   1 +
 drivers/gpio/gpiolib-cdev.c                        |  33 +++--
 drivers/gpio/gpiolib-devres.c                      |  27 +---
 drivers/gpio/gpiolib-of.c                          |  14 +-
 drivers/gpio/gpiolib-sysfs.c                       |   2 +-
 drivers/gpio/gpiolib.c                             |  39 +++---
 drivers/gpio/gpiolib.h                             |   2 +
 19 files changed, 280 insertions(+), 229 deletions(-)

Comments

Linus Walleij Dec. 9, 2020, 10:07 a.m. UTC | #1
Hi Bartosz,

On Wed, Dec 9, 2020 at 10:52 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> These are the patches I collected over this release cycle. Nothing all
> too exciting - mainly just updates to drivers and refactoring of the
> core code. Please pull.

Nice!

But I get a merge conflict in gpiolib-acpi.c! Since I said Andy should
be maintaining that file it makes me a bit nervous.

It looks like this:

index 6cc5f91bfe2e,23fa9df8241d..000000000000
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@@ -586,6 -526,40 +586,43 @@@ static bool acpi_get_driver_gpio_data(s
        return false;
  }

++<<<<<<< HEAD
++=======
+ static enum gpiod_flags
+ acpi_gpio_to_gpiod_flags(const struct acpi_resource_gpio *agpio)
+ {
+       switch (agpio->io_restriction) {
+       case ACPI_IO_RESTRICT_INPUT:
+               return GPIOD_IN;
+       case ACPI_IO_RESTRICT_OUTPUT:
+               /*
+                * ACPI GPIO resources don't contain an initial value for the
+                * GPIO. Therefore we deduce that value from the pull field
+                * instead. If the pin is pulled up we assume default to be
+                * high, if it is pulled down we assume default to be low,
+                * otherwise we leave pin untouched.
+                */
+               switch (agpio->pin_config) {
+               case ACPI_PIN_CONFIG_PULLUP:
+                       return GPIOD_OUT_HIGH;
+               case ACPI_PIN_CONFIG_PULLDOWN:
+                       return GPIOD_OUT_LOW;
+               default:
+                       break;
+               }
+               break;
+       default:
+               break;
+       }
+
+       /*
+        * Assume that the BIOS has configured the direction and pull
+        * accordingly.
+        */
+       return GPIOD_ASIS;
+ }
+
++>>>>>>> 1542ec5eaddb45b4fe625de3d95ee4e94226514d
  static int
  __acpi_gpio_update_gpiod_flags(enum gpiod_flags *flags, enum
gpiod_flags update)
  {

I don't exactly know what do do here ... any advice?

Yours,
Linus Walleij
Bartosz Golaszewski Dec. 9, 2020, 10:12 a.m. UTC | #2
On Wed, Dec 9, 2020 at 11:07 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Hi Bartosz,
>
> On Wed, Dec 9, 2020 at 10:52 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > These are the patches I collected over this release cycle. Nothing all
> > too exciting - mainly just updates to drivers and refactoring of the
> > core code. Please pull.
>
> Nice!
>
> But I get a merge conflict in gpiolib-acpi.c! Since I said Andy should
> be maintaining that file it makes me a bit nervous.
>
> It looks like this:
>
> index 6cc5f91bfe2e,23fa9df8241d..000000000000
> --- a/drivers/gpio/gpiolib-acpi.c
> +++ b/drivers/gpio/gpiolib-acpi.c
> @@@ -586,6 -526,40 +586,43 @@@ static bool acpi_get_driver_gpio_data(s
>         return false;
>   }

Strange, I didn't see any conflicts in next...

>
> ++<<<<<<< HEAD
> ++=======
> + static enum gpiod_flags
> + acpi_gpio_to_gpiod_flags(const struct acpi_resource_gpio *agpio)
> + {
> +       switch (agpio->io_restriction) {
> +       case ACPI_IO_RESTRICT_INPUT:
> +               return GPIOD_IN;
> +       case ACPI_IO_RESTRICT_OUTPUT:
> +               /*
> +                * ACPI GPIO resources don't contain an initial value for the
> +                * GPIO. Therefore we deduce that value from the pull field
> +                * instead. If the pin is pulled up we assume default to be
> +                * high, if it is pulled down we assume default to be low,
> +                * otherwise we leave pin untouched.
> +                */
> +               switch (agpio->pin_config) {
> +               case ACPI_PIN_CONFIG_PULLUP:
> +                       return GPIOD_OUT_HIGH;
> +               case ACPI_PIN_CONFIG_PULLDOWN:
> +                       return GPIOD_OUT_LOW;
> +               default:
> +                       break;
> +               }
> +               break;

This break is the only thing I have in my tree. Andy told me to take
that patch with his ack. It seems you don't have this function in your
tree - was it moved at some point?

Bartosz

> +       default:
> +               break;
> +       }
> +
> +       /*
> +        * Assume that the BIOS has configured the direction and pull
> +        * accordingly.
> +        */
> +       return GPIOD_ASIS;
> + }
> +
> ++>>>>>>> 1542ec5eaddb45b4fe625de3d95ee4e94226514d
>   static int
>   __acpi_gpio_update_gpiod_flags(enum gpiod_flags *flags, enum
> gpiod_flags update)
>   {
>
> I don't exactly know what do do here ... any advice?
>
> Yours,
> Linus Walleij
Linus Walleij Dec. 9, 2020, 10:20 a.m. UTC | #3
On Wed, Dec 9, 2020 at 11:13 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Wed, Dec 9, 2020 at 11:07 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Wed, Dec 9, 2020 at 10:52 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > > These are the patches I collected over this release cycle. Nothing all
> > > too exciting - mainly just updates to drivers and refactoring of the
> > > core code. Please pull.
> >
> > Nice!
> >
> > But I get a merge conflict in gpiolib-acpi.c! Since I said Andy should
> > be maintaining that file it makes me a bit nervous.
> >
> > It looks like this:
> >
> > index 6cc5f91bfe2e,23fa9df8241d..000000000000
> > --- a/drivers/gpio/gpiolib-acpi.c
> > +++ b/drivers/gpio/gpiolib-acpi.c
> > @@@ -586,6 -526,40 +586,43 @@@ static bool acpi_get_driver_gpio_data(s
> >         return false;
> >   }
>
> Strange, I didn't see any conflicts in next...
>
> >
> > ++<<<<<<< HEAD
> > ++=======
> > + static enum gpiod_flags
> > + acpi_gpio_to_gpiod_flags(const struct acpi_resource_gpio *agpio)
> > + {
> > +       switch (agpio->io_restriction) {
> > +       case ACPI_IO_RESTRICT_INPUT:
> > +               return GPIOD_IN;
> > +       case ACPI_IO_RESTRICT_OUTPUT:
> > +               /*
> > +                * ACPI GPIO resources don't contain an initial value for the
> > +                * GPIO. Therefore we deduce that value from the pull field
> > +                * instead. If the pin is pulled up we assume default to be
> > +                * high, if it is pulled down we assume default to be low,
> > +                * otherwise we leave pin untouched.
> > +                */
> > +               switch (agpio->pin_config) {
> > +               case ACPI_PIN_CONFIG_PULLUP:
> > +                       return GPIOD_OUT_HIGH;
> > +               case ACPI_PIN_CONFIG_PULLDOWN:
> > +                       return GPIOD_OUT_LOW;
> > +               default:
> > +                       break;
> > +               }
> > +               break;
>
> This break is the only thing I have in my tree. Andy told me to take
> that patch with his ack. It seems you don't have this function in your
> tree - was it moved at some point?

Hm yeah I have a bunch of ACPI things I pulled from Andy in my tree.

I can try just -3 I guess. I assume the function shall be there.

Yours,
Linus Walleij
Andy Shevchenko Dec. 9, 2020, 10:33 a.m. UTC | #4
On Wed, Dec 9, 2020 at 12:22 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 9, 2020 at 11:13 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > On Wed, Dec 9, 2020 at 11:07 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Wed, Dec 9, 2020 at 10:52 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >
> > > > These are the patches I collected over this release cycle. Nothing all
> > > > too exciting - mainly just updates to drivers and refactoring of the
> > > > core code. Please pull.
> > >
> > > Nice!
> > >
> > > But I get a merge conflict in gpiolib-acpi.c! Since I said Andy should
> > > be maintaining that file it makes me a bit nervous.

Linus, no problem. This conflict can be easily resolved.
Do you want me to publish a test branch with an example of resolution?
Andy Shevchenko Dec. 9, 2020, 10:39 a.m. UTC | #5
On Wed, Dec 9, 2020 at 12:33 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Wed, Dec 9, 2020 at 12:22 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Wed, Dec 9, 2020 at 11:13 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > On Wed, Dec 9, 2020 at 11:07 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > > On Wed, Dec 9, 2020 at 10:52 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > >
> > > > > These are the patches I collected over this release cycle. Nothing all
> > > > > too exciting - mainly just updates to drivers and refactoring of the
> > > > > core code. Please pull.
> > > >
> > > > Nice!
> > > >
> > > > But I get a merge conflict in gpiolib-acpi.c! Since I said Andy should
> > > > be maintaining that file it makes me a bit nervous.
>
> Linus, no problem. This conflict can be easily resolved.
> Do you want me to publish a test branch with an example of resolution?

Here you are:
https://gitlab.com/andy-shev/next/-/tree/test-gpio-brgl-merge

Manually I did the following:
- removed the conflicting hunk entirely
- added 'break;' to the existing function in 'case
ACPI_IO_RESTRICT_OUTPUT:' case
Linus Walleij Dec. 9, 2020, 2:39 p.m. UTC | #6
On Wed, Dec 9, 2020 at 11:39 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:

> Manually I did the following:
> - removed the conflicting hunk entirely
> - added 'break;' to the existing function in 'case
> ACPI_IO_RESTRICT_OUTPUT:' case

OK I did the same and merged in Bartosz branch exactly like that,
let's hope it works!

Yours,
Linus Walleij
Andy Shevchenko Dec. 9, 2020, 4:03 p.m. UTC | #7
On Wed, Dec 9, 2020 at 4:39 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Dec 9, 2020 at 11:39 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>
> > Manually I did the following:
> > - removed the conflicting hunk entirely
> > - added 'break;' to the existing function in 'case
> > ACPI_IO_RESTRICT_OUTPUT:' case
>
> OK I did the same and merged in Bartosz branch exactly like that,
> let's hope it works!

I just have checked your devel branch and it looks okay to me, thanks!