[GIT PULL] gpio: updates for v5.15

[GIT PULL] gpio: updates for v5.15

[Bartosz Golaszewski]

Hi Linus,

Here's the pull-request for this cycle from the GPIO subsystem. We mostly
have various improvements and refactoring all over the place but also some
interesting new features - like the virtio GPIO driver that allows guest VMs
to use host's GPIOs. We also have a new/old GPIO driver for rockchip - this
one has been split out of the pinctrl driver, hence the pull from the
pinctrl tree you can see in my branch. Another merge in the tree is from Andy
for the intel drivers. Details are in the signed tag.

Please pull!
Bartosz

The following changes since commit e73f0f0ee7541171d89f2e2491130c7771ba58d3:

  Linux 5.14-rc1 (2021-07-11 15:07:40 -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.15

for you to fetch changes up to 889a1b3f35db6ba5ba6a0c23a3a55594570b6a17:

  gpio: mpc8xxx: Use 'devm_gpiochip_add_data()' to simplify the code and avoid a leak (2021-08-31 12:10:24 +0200)

----------------------------------------------------------------
gpio updates for v5.15

- new driver: gpio-virtio allowing a guest VM running linux to access
  GPIO lines provided by the host
- split the GPIO driver out of the rockchip pin control driver
- add support for a new model to gpio-aspeed-sgpio, refactor the driver
  and use generic device property interfaces, improve property sanitization
- add ACPI support to gpio-tegra186
- improve the code setting the line names to support multiple GPIO banks
  per device
- constify a bunch of OF functions in the core GPIO code and make the
  declaration for one of the core OF functions we use consistent within its
  header
- use software nodes in intel_quark_i2c_gpio
- add support for the gpio-line-names property in gpio-mt7621
- use the standard GPIO function for setting the GPIO names in gpio-brcmstb
- fix a bunch of leaks and other bugs in gpio-mpc8xxx
- use generic pm callbacks in gpio-ml-ioh
- improve resource management and PM handling in gpio-mlxbf2
- modernize and improve the gpio-dwapb driver
- coding style improvements in gpio-rcar
- documentation fixes and improvements
- update the MAINTAINERS entry for gpio-zynq
- minor tweaks in several drivers

----------------------------------------------------------------
Akhil R (1):
      gpio: tegra186: Add ACPI support

Alexandru Ardelean (1):
      gpio: viperboard: remove platform_set_drvdata() call in probe

Andy Shevchenko (9):
      gpiolib: Deduplicate forward declaration in the consumer.h header
      gpio: dwapb: Unify ACPI enumeration checks in get_irq() and configure_irqs()
      gpio: dwapb: Read GPIO base from gpio-base property
      mfd: intel_quark_i2c_gpio: Convert GPIO to use software nodes
      gpio: dwapb: Get rid of legacy platform data
      gpio: mlxbf2: Convert to device PM ops
      gpio: mlxbf2: Drop wrong use of ACPI_PTR()
      gpio: mlxbf2: Use devm_platform_ioremap_resource()
      gpio: mlxbf2: Use DEFINE_RES_MEM_NAMED() helper macro

Bartosz Golaszewski (2):
      Merge tag 'intel-gpio-v5.15-1' of gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-next
      Merge branch 'ib-rockchip' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl into gpio/for-next

Christophe JAILLET (3):
      gpio: mpc8xxx: Fix a resources leak in the error handling path of 'mpc8xxx_probe()'
      gpio: mpc8xxx: Fix a potential double iounmap call in 'mpc8xxx_probe()'
      gpio: mpc8xxx: Use 'devm_gpiochip_add_data()' to simplify the code and avoid a leak

Geert Uytterhoeven (1):
      gpio: rcar: Always use local variable dev in gpio_rcar_probe()

Hannu Hartikainen (1):
      docs: gpio: explain GPIOD_OUT_* values and toggling active low

Jianqun Xu (9):
      pinctrl/rockchip: always enable clock for gpio controller
      pinctrl/rockchip: separate struct rockchip_pin_bank to a head file
      pinctrl/rockchip: add pinctrl device to gpio bank struct
      dt-bindings: gpio: change items restriction of clock for rockchip,gpio-bank
      gpio/rockchip: add driver for rockchip gpio
      gpio/rockchip: use struct rockchip_gpio_regs for gpio controller
      gpio/rockchip: support next version gpio controller
      gpio/rockchip: drop irq_gc_lock/irq_gc_unlock for irq set type
      pinctrl/rockchip: drop the gpio related codes

Krzysztof Kozlowski (3):
      of: unify of_count_phandle_with_args() arguments with !CONFIG_OF
      gpiolib: constify passed device_node pointer
      gpiolib: of: constify few local device_node variables

Linus Walleij (1):
      gpio: max730x: Use the right include

Lukas Bulwahn (1):
      gpio: remove the obsolete MX35 3DS BOARD MC9S08DZ60 GPIO functions

Mauro Carvalho Chehab (1):
      MAINTAINERS: update gpio-zynq.yaml reference

Sergio Paracuellos (3):
      gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip banks per device
      gpio: mt7621: support gpio-line-names property
      gpio: brcmstb: remove custom 'brcmstb_gpio_set_names'

Steven Lee (5):
      gpio: gpio-aspeed-sgpio: Add AST2600 sgpio support
      gpio: gpio-aspeed-sgpio: Add set_config function
      gpio: gpio-aspeed-sgpio: Move irq_chip to aspeed-sgpio struct
      gpio: gpio-aspeed-sgpio: Use generic device property APIs
      gpio: gpio-aspeed-sgpio: Return error if ngpios is not multiple of 8.

Vaibhav Gupta (1):
      gpio: ml-ioh: Convert to dev_pm_ops

Vincent Pelletier (1):
      Documentation: gpio: driver.rst: Remove gpiochip_irqchip_add mention

Viresh Kumar (3):
      gpio: Add virtio-gpio driver
      gpio: virtio: Fix sparse warnings
      gpio: virtio: Add missing mailings lists in MAINTAINERS entry

 .../bindings/gpio/rockchip,gpio-bank.yaml          |   5 +-
 Documentation/driver-api/gpio/consumer.rst         |  10 +-
 Documentation/driver-api/gpio/driver.rst           |  11 +-
 MAINTAINERS                                        |  11 +-
 drivers/gpio/Kconfig                               |  23 +-
 drivers/gpio/Makefile                              |   3 +-
 drivers/gpio/gpio-aspeed-sgpio.c                   | 178 ++--
 drivers/gpio/gpio-brcmstb.c                        |  45 +-
 drivers/gpio/gpio-dwapb.c                          |  56 +-
 drivers/gpio/gpio-mc9s08dz60.c                     | 112 ---
 drivers/gpio/gpio-ml-ioh.c                         |  49 +-
 drivers/gpio/gpio-mlxbf2.c                         |  43 +-
 drivers/gpio/gpio-mpc8xxx.c                        |  13 +-
 drivers/gpio/gpio-mt7621.c                         |   1 +
 drivers/gpio/gpio-rcar.c                           |   4 +-
 drivers/gpio/gpio-rockchip.c                       | 771 +++++++++++++++++
 drivers/gpio/gpio-tegra186.c                       |  30 +-
 drivers/gpio/gpio-viperboard.c                     |  14 +-
 drivers/gpio/gpio-virtio.c                         | 374 +++++++++
 drivers/gpio/gpiolib-devres.c                      |   2 +-
 drivers/gpio/gpiolib-of.c                          |  16 +-
 drivers/gpio/gpiolib.c                             |  32 +-
 drivers/mfd/intel_quark_i2c_gpio.c                 |  71 +-
 drivers/pinctrl/pinctrl-rockchip.c                 | 909 +--------------------
 drivers/pinctrl/pinctrl-rockchip.h                 | 287 +++++++
 include/linux/gpio/consumer.h                      |  14 +-
 include/linux/gpio/driver.h                        |   4 +
 include/linux/of.h                                 |   2 +-
 include/linux/of_gpio.h                            |  15 +-
 include/linux/platform_data/gpio-dwapb.h           |  25 -
 include/linux/spi/max7301.h                        |   2 +-
 include/uapi/linux/virtio_gpio.h                   |  47 ++
 include/uapi/linux/virtio_ids.h                    |   1 +
 33 files changed, 1841 insertions(+), 1339 deletions(-)
 delete mode 100644 drivers/gpio/gpio-mc9s08dz60.c
 create mode 100644 drivers/gpio/gpio-rockchip.c
 create mode 100644 drivers/gpio/gpio-virtio.c
 create mode 100644 drivers/pinctrl/pinctrl-rockchip.h
 delete mode 100644 include/linux/platform_data/gpio-dwapb.h
 create mode 100644 include/uapi/linux/virtio_gpio.h

Re: [GIT PULL] gpio: updates for v5.15

[Linus Torvalds]

On Tue, Sep 7, 2021 at 1:36 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
>  We also have a new/old GPIO driver for rockchip - this
> one has been split out of the pinctrl driver, hence the pull from the
> pinctrl tree you can see in my branch. Another merge in the tree is from Andy
> for the intel drivers.

I appreciate the heads-up, but just *look* at those merges.

The intel GPIO merge at least talks about what it does, and looks
sane. I'm not convinced that automated shortlogs are great, but
whatever. The merge isn't bad.

The rockchip one?

All I can say is "WTF?"

This is the complete and full commit message:

    Merge branch 'ib-rockchip' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
into gpio/for-next

what part of that screams "that's an acceptable commit message" to you?

If the reason for that merge was that you want to have the current
state so that you can split it up, then SAY SO, for chrissake!

Not that useless commit message.

Why do I have to tell this to people SEVERAL TIMES EVERY SINGLE MERGE WINDOW?

Merge commits need explanations. They need explanations for why the
merge is done, and what the merge pulls in. Not this "single line that
doesn't explain anything".

Dammit.

I've pulled this, but I'm upset. I'm upset because I've told people
literally hundreds of times by now. Merge commits are not some trivial
thing that should be ignored. Quite the reverse. Merge commits are
generally worth *more* explanation than normal commits, and should
take *more* effort and thought than some random code commit that is
obvious from just the code.

Exactly because merges are *not* obvious from just looking at the
code. It's not some one-liner that is self-explanatory.

If you cannot be bothered to make proper merge messages, then don't do
the merge. If y ou don't have a good reason for the merge that you can
articulate, then don't do the merge. If you can't explain what you are
merging, then don't do the merge.

It really is that simple.

I've pulled this, but I'm really fed up.

            Linus

Re: Re: [GIT PULL] gpio: updates for v5.15

[pr-tracker-bot]

The pull request you sent on Tue, 7 Sep 2021 12:36:25 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9c23aa51477a37f8b56c3c40192248db0663c196

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: Re: [GIT PULL] gpio: updates for v5.15

[Linus Torvalds]

On Tue, Sep 7, 2021 at 12:40 PM <pr-tracker-bot@kernel.org> wrote:
>
> The pull request you sent on Tue, 7 Sep 2021 12:36:25 -0700:
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl refs/heads/master
>
> has been merged into torvalds/linux.git:
> https://git.kernel.org/torvalds/c/9c23aa51477a37f8b56c3c40192248db0663c196

What what what?

Konstantin, is pr-tracker-bot confused?

I have in fact merged that gpio tree, but I haven't pushed the merge out.

And the thing pr-tracker-bot points to isn't the merge, nor is it the
commit that the pull request points to, ie that

   for you to fetch changes up to 889a1b3f35db6ba5ba6a0c23a3a55594570b6a17

which doesn't exist in my public tree yet (it does show up in gitweb,
but with a big

    Notice: this object is not reachable from any branch.

warning because it only shows up due to the object database being shared).

            Linus

Re: [GIT PULL] gpio: updates for v5.15

[Konstantin Ryabitsev]

On Tue, Sep 07, 2021 at 12:49:03PM -0700, Linus Torvalds wrote:
> > The pull request you sent on Tue, 7 Sep 2021 12:36:25 -0700:
> >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl refs/heads/master
> >
> > has been merged into torvalds/linux.git:
> > https://git.kernel.org/torvalds/c/9c23aa51477a37f8b56c3c40192248db0663c196
> 
> What what what?
> 
> Konstantin, is pr-tracker-bot confused?

Failure is always an option. Let me poke at the logs and see what happened
here.

-K

Re: [GIT PULL] gpio: updates for v5.15

[Linus Torvalds]

On Tue, Sep 7, 2021 at 12:56 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Failure is always an option. Let me poke at the logs and see what happened
> here.

I was spooked by how it actually sent the email just after I had done
the merge, but before I had pushed it out.

[ https://www.youtube.com/watch?v=-b5aW08ivHU plays ]

               Linus

Re: [GIT PULL] gpio: updates for v5.15

[pr-tracker-bot]

The pull request you sent on Tue,  7 Sep 2021 10:36:13 +0200:

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

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5e6a5845dd651b00754a62edec2f0a439182024d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] gpio: updates for v5.15

[Konstantin Ryabitsev]

On Tue, Sep 07, 2021 at 01:01:37PM -0700, Linus Torvalds wrote:
> On Tue, Sep 7, 2021 at 12:56 PM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > Failure is always an option. Let me poke at the logs and see what happened
> > here.
> 
> I was spooked by how it actually sent the email just after I had done
> the merge, but before I had pushed it out.

Uh... I'm borrowing some ideas from some large processor manufacturers and
implementing what I refer to as "speculative" pre-processing of pull requests.
If you've previously merged similar-looking requests in the past, then I'm
just extrapolating the average delay times and sending predictive
notifications.

The real reason this happened is just bot stupidity, actually. In your
response to the pull request in question [1], you had the following lines:

>     Merge branch 'ib-rockchip' of
>     git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
>     into gpio/for-next

[1] https://lore.kernel.org/all/CAHk-=wgQBgkut6zXTbZN45AtJmSceXwDw6Y60ZmwrPkOL__A8g@mail.gmail.com/

This was enough for the bot to think that this was a whole new pull request,
which it catalogued as pointing at commit 8096acd7442e613fad0354fc8dfdb2003cceea0b
(where linusw/linux-pinctrl master is). Then, since that commit already exists
in your tree, it sent out the notification.

I'm not sure what the right course of action here is. On the one hand,
recognizing your response as a pull request was clearly wrong. On the other
hand, a lot of valid pull requests are actually very similar to that (just
someone sending a "please pull" and a URL in the body -- often as a response
to a previous message, so we can't even reasonably weed out subjects with
"Re:").

So, we can either live with an occasional fail like this or I can try to
figure out how to narrow down the rules for what is and isn't a valid pull
request. One option is to check if the object is already in your tree and
over a few days old -- which would indicate that it's obviously not a pull
request to which we should be paying any attention.

-K

Re: [GIT PULL] gpio: updates for v5.15

[Linus Torvalds]

On Tue, Sep 7, 2021 at 1:14 PM <pr-tracker-bot@kernel.org> wrote:
>
> The pull request you sent on Tue,  7 Sep 2021 10:36:13 +0200:
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/gpio-updates-for-v5.15
>
> has been merged into torvalds/linux.git:
> https://git.kernel.org/torvalds/c/5e6a5845dd651b00754a62edec2f0a439182024d

Yup, this is the real pr-tracker-bot response for Bartosz' pull
request, not the over-eager slightly random one.

Looks like there was possibly some parsing problem with the email having that

      Merge branch 'ib-rockchip' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
into gpio/for-next

in the shortlog. Or something like that?

         Linus

Re: [GIT PULL] gpio: updates for v5.15

[Linus Torvalds]

On Tue, Sep 7, 2021 at 1:20 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> So, we can either live with an occasional fail like this or I can try to
> figure out how to narrow down the rules for what is and isn't a valid pull
> request.

I guess the occasional false positives are fine - if this was the
first time I noticed something like that in the almost three years (?)
we've had pr-tracker-bot, and you figured out what happened quickly,
it clearly isn't a huge problem in practice.

           Linus

Re: [GIT PULL] gpio: updates for v5.15

[Bartosz Golaszewski]

On Tue, Sep 7, 2021 at 9:36 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, Sep 7, 2021 at 1:36 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> >  We also have a new/old GPIO driver for rockchip - this
> > one has been split out of the pinctrl driver, hence the pull from the
> > pinctrl tree you can see in my branch. Another merge in the tree is from Andy
> > for the intel drivers.
>
> I appreciate the heads-up, but just *look* at those merges.
>
> The intel GPIO merge at least talks about what it does, and looks
> sane. I'm not convinced that automated shortlogs are great, but
> whatever. The merge isn't bad.
>
> The rockchip one?
>
> All I can say is "WTF?"
>
> This is the complete and full commit message:
>
>     Merge branch 'ib-rockchip' of
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> into gpio/for-next
>
> what part of that screams "that's an acceptable commit message" to you?
>
> If the reason for that merge was that you want to have the current
> state so that you can split it up, then SAY SO, for chrissake!
>
> Not that useless commit message.
>
> Why do I have to tell this to people SEVERAL TIMES EVERY SINGLE MERGE WINDOW?
>
> Merge commits need explanations. They need explanations for why the
> merge is done, and what the merge pulls in. Not this "single line that
> doesn't explain anything".
>
> Dammit.
>
> I've pulled this, but I'm upset. I'm upset because I've told people
> literally hundreds of times by now. Merge commits are not some trivial
> thing that should be ignored. Quite the reverse. Merge commits are
> generally worth *more* explanation than normal commits, and should
> take *more* effort and thought than some random code commit that is
> obvious from just the code.
>
> Exactly because merges are *not* obvious from just looking at the
> code. It's not some one-liner that is self-explanatory.
>
> If you cannot be bothered to make proper merge messages, then don't do
> the merge. If y ou don't have a good reason for the merge that you can
> articulate, then don't do the merge. If you can't explain what you are
> merging, then don't do the merge.
>
> It really is that simple.
>
> I've pulled this, but I'm really fed up.
>
>             Linus

Hi Linus,

Thanks and sorry, noted for the future PRs.

Bartosz