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
On Tue, Sep 7, 2021 at 1:36 AM Bartosz Golaszewski <[email protected]> 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
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
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
On Tue, Sep 7, 2021 at 12:56 PM Konstantin Ryabitsev
<[email protected]> 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
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
On Tue, Sep 07, 2021 at 01:01:37PM -0700, Linus Torvalds wrote:
> On Tue, Sep 7, 2021 at 12:56 PM Konstantin Ryabitsev
> <[email protected]> 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
On Tue, Sep 7, 2021 at 12:40 PM <[email protected]> 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
On Tue, Sep 7, 2021 at 1:14 PM <[email protected]> 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
On Tue, Sep 7, 2021 at 1:20 PM Konstantin Ryabitsev
<[email protected]> 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
On Tue, Sep 7, 2021 at 9:36 PM Linus Torvalds
<[email protected]> wrote:
>
> On Tue, Sep 7, 2021 at 1:36 AM Bartosz Golaszewski <[email protected]> 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