* linusw/fixes build: 6 builds: 0 failed, 6 passed, 34 warnings (v5.3-rc4-2-g68e03b85474a)
From: kernelci.org bot @ 2019-08-14 10:24 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/fixes build: 6 builds: 0 failed, 6 passed, 34 warnings (v5.3-rc4-2-g68e03b85474a)
Full Build Summary: https://kernelci.org/build/linusw/branch/fixes/kernel/v5.3-rc4-2-g68e03b85474a/
Tree: linusw
Branch: fixes
Git Describe: v5.3-rc4-2-g68e03b85474a
Git Commit: 68e03b85474a51ec1921b4d13204782594ef7223
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Built: 6 unique architectures
Warnings Detected:
arc:
nsim_hs_defconfig (gcc-8): 5 warnings
arm64:
defconfig (gcc-8): 5 warnings
arm:
multi_v7_defconfig (gcc-8): 21 warnings
mips:
32r2el_defconfig (gcc-8): 3 warnings
riscv:
x86_64:
Warnings summary:
5 <stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
2 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:820:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:815:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 include/linux/compiler.h:328:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:459:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:440:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:424:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:370:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:352:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:332:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/sdhci-s3c.c:613:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2426:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2422:28: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2415:30: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/iommu/arm-smmu-v3.c:1189:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:992:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/dma/imx-dma.c:542:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
drivers/iommu/arm-smmu-v3.c:1189:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:815:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:820:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 21 warnings, 0 section mismatches
Warnings:
drivers/dma/imx-dma.c:542:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/sdhci-s3c.c:613:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2415:30: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2422:28: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2426:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:815:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:820:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:424:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:440:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:459:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:332:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:352:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:370:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:992:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
include/linux/compiler.h:328:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* linusw/devel build: 6 builds: 0 failed, 6 passed, 13 warnings (v5.3-rc1-25-g470219c619e9)
From: kernelci.org bot @ 2019-08-14 10:24 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/devel build: 6 builds: 0 failed, 6 passed, 13 warnings (v5.3-rc1-25-g470219c619e9)
Full Build Summary: https://kernelci.org/build/linusw/branch/devel/kernel/v5.3-rc1-25-g470219c619e9/
Tree: linusw
Branch: devel
Git Describe: v5.3-rc1-25-g470219c619e9
Git Commit: 470219c619e9f76e41497b9a90f2ec61dbedf3f2
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Built: 6 unique architectures
Warnings Detected:
arc:
nsim_hs_defconfig (gcc-8): 2 warnings
arm64:
arm:
multi_v7_defconfig (gcc-8): 6 warnings
mips:
32r2el_defconfig (gcc-8): 3 warnings
riscv:
defconfig (gcc-8): 2 warnings
x86_64:
Warnings summary:
7 <stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 6 warnings, 0 section mismatches
Warnings:
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* Re: [PATCH v2] gpiolib: Take MUX usage into account
From: Ramon Fried @ 2019-08-14 10:22 UTC (permalink / raw)
To: Stefan Wahren, linus.walleij, bgolaszewski; +Cc: linux-gpio, linux-kernel
In-Reply-To: <f568ca31-c9f0-0dc2-be12-22de25891794@gmx.net>
On Tue, 2019-08-13 at 18:32 +0200, Stefan Wahren wrote:
> Am 13.08.19 um 08:10 schrieb Fried, Ramon:
> > On 8/13/2019 08:38, Stefan Wahren wrote:
> > > Hi Ramon,
> > >
> > > On 13.08.19 03:42, Ramon Fried wrote:
> > > > From: Stefan Wahren <stefan.wahren@i2se.com>
> > > >
> > > > The user space like gpioinfo only see the GPIO usage but not
> > > > the
> > > > MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want
> > > > to
> > > > know which
> > > > pin is free/safe to use. So take the MUX usage of strict pinmux
> > > > controllers
> > > > into account to get a more realistic view for ioctl
> > > > GPIO_GET_LINEINFO_IOCTL.
> > > >
> > > > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > > > Tested-by: Ramon Fried <rfried.dev@gmail.com>
> > > > Signed-off-by: Ramon Fried <rfried.dev@gmail.com>
> > > > ---
> > > > v2: Address review from linus:
> > > > * ** Please notive logic was reversed **
> > > > * renamed pinctrl_gpio_is_in_use() to
> > > > pinctrl_gpio_can_use_line()
> > > > * renamed pinmux_is_in_use() to pinmux_can_be_used_for_gpio()
> > > > * changed dev_err to dev_dbg (Linus suggested removing it
> > > > altogether, I
> > > > find it better to keep it for debug).
> > > thanks for taking care of this.
> > > > drivers/gpio/gpiolib.c | 3 ++-
> > > > drivers/pinctrl/core.c | 28
> > > > ++++++++++++++++++++++++++++
> > > > drivers/pinctrl/pinmux.c | 27
> > > > +++++++++++++++++++++++++++
> > > > drivers/pinctrl/pinmux.h | 8 ++++++++
> > > > include/linux/pinctrl/consumer.h | 6 ++++++
> > > > 5 files changed, 71 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > > index f497003f119c..52937bf8e514 100644
> > > > --- a/drivers/gpio/gpiolib.c
> > > > +++ b/drivers/gpio/gpiolib.c
> > > > @@ -1084,7 +1084,8 @@ static long gpio_ioctl(struct file *filp,
> > > > unsigned int cmd, unsigned long arg)
> > > > test_bit(FLAG_IS_HOGGED, &desc->flags) ||
> > > > test_bit(FLAG_USED_AS_IRQ, &desc->flags) ||
> > > > test_bit(FLAG_EXPORT, &desc->flags) ||
> > > > - test_bit(FLAG_SYSFS, &desc->flags))
> > > > + test_bit(FLAG_SYSFS, &desc->flags) ||
> > > > + !pinctrl_gpio_can_use_line(chip->base +
> > > > lineinfo.line_offset))
> > > > lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
> > > > if (test_bit(FLAG_IS_OUT, &desc->flags))
> > > > lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
> > > > diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> > > > index b70df27874d1..2bbd8ee93507 100644
> > > > --- a/drivers/pinctrl/core.c
> > > > +++ b/drivers/pinctrl/core.c
> > > > @@ -736,6 +736,34 @@ int pinctrl_get_group_selector(struct
> > > > pinctrl_dev *pctldev,
> > > > return -EINVAL;
> > > > }
> > > > +bool pinctrl_gpio_can_use_line(unsigned gpio)
> > > > +{
> > > > + struct pinctrl_dev *pctldev;
> > > > + struct pinctrl_gpio_range *range;
> > > > + bool result;
> > > > + int pin;
> > > > +
> > > > + /*
> > > > + * Try to obtain GPIO range, if it fails
> > > > + * we're probably dealing with GPIO driver
> > > > + * without a backing pin controller - bail out.
> > > > + */
> > > > + if (pinctrl_get_device_gpio_range(gpio, &pctldev, &range))
> > > > + return true;
> > > > +
> > > > + mutex_lock(&pctldev->mutex);
> > > > +
> > > > + /* Convert to the pin controllers number space */
> > > > + pin = gpio_to_pin(range, gpio);
> > > > +
> > > > + result = pinmux_can_be_used_for_gpio(pctldev, pin);
> > > > +
> > > > + mutex_unlock(&pctldev->mutex);
> > > > +
> > > > + return result;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(pinctrl_gpio_can_use_line);
> > > > +
> > > > /**
> > > > * pinctrl_gpio_request() - request a single pin to be used
> > > > as GPIO
> > > > * @gpio: the GPIO pin number from the GPIO subsystem number
> > > > space
> > > > diff --git a/drivers/pinctrl/pinmux.c
> > > > b/drivers/pinctrl/pinmux.c
> > > > index 020e54f843f9..7e42a5738d82 100644
> > > > --- a/drivers/pinctrl/pinmux.c
> > > > +++ b/drivers/pinctrl/pinmux.c
> > > > @@ -70,6 +70,33 @@ int pinmux_validate_map(const struct
> > > > pinctrl_map
> > > > *map, int i)
> > > > return 0;
> > > > }
> > > > +/**
> > > > + * pinmux_can_be_used_for_gpio() - check if a specific pin
> > > > + * is either muxed to a different function or used as gpio.
> > > > + *
> > > > + * @pin: the pin number in the global pin space
> > > > + *
> > > > + * Controllers not defined as strict will always return true,
> > > > + * menaning that the gpio can be used.
> > > > + */
> > > > +bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev,
> > > > unsigned pin)
> > > > +{
> > > > + struct pin_desc *desc = pin_desc_get(pctldev, pin);
> > > > + const struct pinmux_ops *ops = pctldev->desc->pmxops;
> > > > +
> > > > + if (!desc) {
> > > > + dev_dbg(pctldev->dev,
> > > > + "pin %u is not registered so it cannot be
> > > > requested\n",
> > > > + pin);
> > > > + return true;
> > > This return value looks strange to me.
> >
> > Basically, it's just the reversed return value you returned in the
> > original patch,
> > It means in this context that if the pin is not owned by a
> > pin-controller it can be used for GPIO.
> As long as the provided pin is valid. Btw shouldn't we change the
> logic
> in the debug message?
Good catch. yes we should.
I'll send V3 shortly.
Thanks,
Ramon.
> > Thanks,
> > Ramon.
> >
> > > Stefan
> > >
^ permalink raw reply
* Re: [PATCH] gpio: lynxpoint: Pass irqchip when adding gpiochip
From: Linus Walleij @ 2019-08-14 9:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Mika Westerberg,
David Cohen, Thierry Reding
In-Reply-To: <20190814094022.GS30120@smile.fi.intel.com>
On Wed, Aug 14, 2019 at 11:40 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Wed, Aug 14, 2019 at 10:46:49AM +0200, Linus Walleij wrote:
> > On Mon, Aug 12, 2019 at 12:58 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Mon, Aug 12, 2019 at 10:13:51AM +0200, Linus Walleij wrote:
> >
> > > > + girq->num_parents = 1;
> > > > + girq->parents = devm_kcalloc(&pdev->dev, 1,
> > > > + sizeof(*girq->parents),
> > > > + GFP_KERNEL);
> > > > + if (!girq->parents)
> > > > + return -ENOMEM;
> > >
> > > I understand the point to use kcalloc() for one entry, though I would make
> > > intention more explicitly, i.e. use girq->num_parents in it instead of hard
> > > coded value.
> >
> > That is better, but I have a loose plan to get rid of this
> > and just set parents to a fixed width because all the allocation
> > is annoying.
>
> I see your intentions, though for current state I think the less hard coded
> constants the better. In any case I pushed updated versions to my trees.
Thanks a lot. Yeah we live with the API we have and work from there.
> > If you are sure that every consumer will call .set_type() you can
> > use handle_bad_irq, and that is preferred.
>
> They should do this. Let me prepare the patch for next cycle (v5.5) and I put
> it to my tree after merge window. If we see any complains from linux-next
> testers, we will act accordingly.
Sounds like a plan!
Thanks,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: lynxpoint: Pass irqchip when adding gpiochip
From: Andy Shevchenko @ 2019-08-14 9:40 UTC (permalink / raw)
To: Linus Walleij
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Mika Westerberg,
David Cohen, Thierry Reding
In-Reply-To: <CACRpkda_2T_eBf5AxpNG0P54KTLds-NvYDMcTWx5BtOa9kK-mA@mail.gmail.com>
On Wed, Aug 14, 2019 at 10:46:49AM +0200, Linus Walleij wrote:
> On Mon, Aug 12, 2019 at 12:58 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Aug 12, 2019 at 10:13:51AM +0200, Linus Walleij wrote:
>
> > > + girq->num_parents = 1;
> > > + girq->parents = devm_kcalloc(&pdev->dev, 1,
> > > + sizeof(*girq->parents),
> > > + GFP_KERNEL);
> > > + if (!girq->parents)
> > > + return -ENOMEM;
> >
> > I understand the point to use kcalloc() for one entry, though I would make
> > intention more explicitly, i.e. use girq->num_parents in it instead of hard
> > coded value.
>
> That is better, but I have a loose plan to get rid of this
> and just set parents to a fixed width because all the allocation
> is annoying.
I see your intentions, though for current state I think the less hard coded
constants the better. In any case I pushed updated versions to my trees.
> > > + girq->parents[0] = (unsigned)irq_rc->start;
> > > + girq->default_type = IRQ_TYPE_NONE;
> >
> > > + girq->handler = handle_simple_irq;
> >
> > > - ret = gpiochip_irqchip_add(gc, &lp_irqchip, 0,
> > > - handle_simple_irq, IRQ_TYPE_NONE);
> >
> > Hmm... Now I'm wondering, shall we use handle_bad_irq() here?
>
> If you are sure that every consumer will call .set_type() you can
> use handle_bad_irq, and that is preferred.
They should do this. Let me prepare the patch for next cycle (v5.5) and I put
it to my tree after merge window. If we see any complains from linux-next
testers, we will act accordingly.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] pinctrl/amd: disable spurious-firing GPIO IRQs
From: Daniel Drake @ 2019-08-14 9:05 UTC (permalink / raw)
To: linus.walleij
Cc: linux-gpio, linux, sandeep.singh, Shyam-sundar.S-k,
Nehal-Bakulchandra.shah
When cold-booting Asus X434DA, GPIO 7 is found to be already configured
as an interrupt, and the GPIO level is found to be in a state that
causes the interrupt to fire.
As soon as pinctrl-amd probes, this interrupt fires and invokes
amd_gpio_irq_handler(). The IRQ is acked, but no GPIO-IRQ handler was
invoked, so the GPIO level being unchanged just causes another interrupt
to fire again immediately after.
This results in an interrupt storm causing this platform to hang
during boot, right after pinctrl-amd is probed.
Detect this situation and disable the GPIO interrupt when this happens.
This enables the affected platform to boot as normal. GPIO 7 actually is
the I2C touchpad interrupt line, and later on, i2c-multitouch loads and
re-enables this interrupt when it is ready to handle it.
Instead of this approach, I considered disabling all GPIO interrupts at
probe time, however that seems a little risky, and I also confirmed that
Windows does not seem to have this behaviour: the same 41 GPIO IRQs are
enabled under both Linux and Windows, which is a far larger collection
than the GPIOs referenced by the DSDT on this platform.
Signed-off-by: Daniel Drake <drake@endlessm.com>
---
drivers/pinctrl/pinctrl-amd.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index 9b9c61e3f065..977792654e01 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -565,15 +565,25 @@ static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id)
!(regval & BIT(INTERRUPT_MASK_OFF)))
continue;
irq = irq_find_mapping(gc->irq.domain, irqnr + i);
- generic_handle_irq(irq);
+ if (irq != 0)
+ generic_handle_irq(irq);
/* Clear interrupt.
* We must read the pin register again, in case the
* value was changed while executing
* generic_handle_irq() above.
+ * If we didn't find a mapping for the interrupt,
+ * disable it in order to avoid a system hang caused
+ * by an interrupt storm.
*/
raw_spin_lock_irqsave(&gpio_dev->lock, flags);
regval = readl(regs + i);
+ if (irq == 0) {
+ regval &= ~BIT(INTERRUPT_ENABLE_OFF);
+ dev_dbg(&gpio_dev->pdev->dev,
+ "Disabling spurious GPIO IRQ %d\n",
+ irqnr + i);
+ }
writel(regval, regs + i);
raw_spin_unlock_irqrestore(&gpio_dev->lock, flags);
ret = IRQ_HANDLED;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] gpio: pl061: Fix the issue failed to register the ACPI interruption
From: Linus Walleij @ 2019-08-14 9:04 UTC (permalink / raw)
To: Wei Xu
Cc: open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Linuxarm,
Shameerali Kolothum Thodi, Jonathan Cameron, John Garry,
Salil Mehta, Shiju Jose, jinying, Zhangyi ac, Liguozhu (Kenneth),
Tangkunshan, huangdaode
In-Reply-To: <5D514D6F.4090904@hisilicon.com>
Hi Wei,
thanks for your patch!
This doesn't apply for my "devel" branch, can you rebase
on this:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
We have moved some ACPI headers around recently.
On Mon, Aug 12, 2019 at 1:28 PM Wei Xu <xuwei5@hisilicon.com> wrote:
> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
> attached to the pl061 acpi node to register interruption.
Makes sense.
> Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
I doubt this is a regression since I haven't seen anyone use this
gpiochip with ACPI before.
Please rename the patch "gpio: pl061: Add ACPI support" unless
you can convince me it worked without changes before.
Please include some ACPI people on review of this. From
MAINTAINERS:
ACPI
M: "Rafael J. Wysocki" <rjw@rjwysocki.net>
M: Len Brown <lenb@kernel.org>
L: linux-acpi@vger.kernel.org
I would also include Andy Shevchenko and Mika Westerberg for
the GPIO aspects.
Thanks!
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] gpiolib: Add for_each_gpio_suffix() helper
From: Linus Walleij @ 2019-08-14 8:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stefan Roese, open list:SERIAL DRIVERS, open list:GPIO SUBSYSTEM,
Andy Shevchenko, Pavel Machek, Greg Kroah-Hartman
In-Reply-To: <CAMuHMdXP8K+yvUHrjnegnNuViG3YsCAD=PxTsDHJcTLRRjJguQ@mail.gmail.com>
On Mon, Aug 12, 2019 at 1:18 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sat, Aug 10, 2019 at 10:27 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Thu, Aug 8, 2019 at 3:25 PM Stefan Roese <sr@denx.de> wrote:
> > > Add a helper macro to enable the interation over all supported GPIO
> > > suffixes (currently "gpios" & "gpio"). This will be used by the serial
> > > mctrl code to check, if a GPIO property exists before requesting it.
> > >
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Cc: Pavel Machek <pavel@denx.de>
> > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > I really like this patch, it makes things so much more readable.
>
> Do we really need to spread this *-gpio" legacy support all over the kernel?
Not really :/
Isn't it possible to use something like gpiod_count(dev, "foo") to
check for any GPIOs instead?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: lynxpoint: Pass irqchip when adding gpiochip
From: Linus Walleij @ 2019-08-14 8:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Mika Westerberg,
David Cohen, Thierry Reding
In-Reply-To: <20190812105825.GB30120@smile.fi.intel.com>
On Mon, Aug 12, 2019 at 12:58 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Mon, Aug 12, 2019 at 10:13:51AM +0200, Linus Walleij wrote:
> > + girq->num_parents = 1;
> > + girq->parents = devm_kcalloc(&pdev->dev, 1,
> > + sizeof(*girq->parents),
> > + GFP_KERNEL);
> > + if (!girq->parents)
> > + return -ENOMEM;
>
> I understand the point to use kcalloc() for one entry, though I would make
> intention more explicitly, i.e. use girq->num_parents in it instead of hard
> coded value.
That is better, but I have a loose plan to get rid of this
and just set parents to a fixed width because all the allocation
is annoying.
> > + girq->parents[0] = (unsigned)irq_rc->start;
> > + girq->default_type = IRQ_TYPE_NONE;
>
> > + girq->handler = handle_simple_irq;
>
> > - ret = gpiochip_irqchip_add(gc, &lp_irqchip, 0,
> > - handle_simple_irq, IRQ_TYPE_NONE);
>
> Hmm... Now I'm wondering, shall we use handle_bad_irq() here?
If you are sure that every consumer will call .set_type() you can
use handle_bad_irq, and that is preferred.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: aspeed: Remove mention of deprecated compatibles
From: Linus Walleij @ 2019-08-14 8:41 UTC (permalink / raw)
To: Lee Jones
Cc: Andrew Jeffery, linux-aspeed, Rob Herring, Mark Rutland,
Joel Stanley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM
In-Reply-To: <20190812101504.GF26727@dell>
On Mon, Aug 12, 2019 at 12:15 PM Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 05 Aug 2019, Linus Walleij wrote:
>
> > On Wed, Jul 24, 2019 at 10:13 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > > Guide readers away from using the aspeed,g[45].* compatible patterns.
> > >
> > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> >
> > Patch applied to the pinctrl tree.
>
> With my Ack?
Sorry no. :( Was I too trigger-happy?
Usually I take Rob's ACK as authoritative for anything under
Documentation/devicetree but if you have concerns about the
patch from an MFD point of view I will revert it pending further
discussion.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: cadence: Pass irqchip when adding gpiochip
From: Linus Walleij @ 2019-08-14 8:37 UTC (permalink / raw)
To: Jan Kotas; +Cc: linux-gpio@vger.kernel.org, Bartosz Golaszewski, Thierry Reding
In-Reply-To: <95B402CC-A698-42FE-9D3E-D4B05997ED3E@global.cadence.com>
On Mon, Aug 12, 2019 at 11:53 AM Jan Kotas <jank@cadence.com> wrote:
> > On 9 Aug 2019, at 15:18, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > We need to convert all old gpio irqchips to pass the irqchip
> > setup along when adding the gpio_chip. For more info see
> > drivers/gpio/TODO.
> >
> > For chained irqchips this is a pretty straight-forward
> > conversion.
> >
> > Cc: Jan Kotas <jank@cadence.com>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > Hi Jan, it'd be great if you could test/review this
> > patch.
>
> Everything seems to be OK in my tests.
Thanks, recorded as Tested-by and applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
From: Linus Walleij @ 2019-08-14 8:36 UTC (permalink / raw)
To: Martin Michlmayr
Cc: Dan Williams, Arnd Bergmann, soc, Russell King, Vinod Koul,
Bartosz Golaszewski, Linux ARM, Linux Kernel Mailing List,
dmaengine, open list:GPIO SUBSYSTEM, linux-i2c, Peter Teichmann
In-Reply-To: <20190812094456.GI10598@jirafa.cyrius.com>
On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote:
> As Arnd points out, Debian used to have support for various iop32x
> devices. While Debian hasn't supported iop32x in a number of years,
> these devices are still usable and in use (RMK being a prime example).
I suppose it could be a good idea to add support for iop32x to
OpenWrt and/or OpenEmbedded, both of which support some
pretty constrained systems. I am personally using these
distributions to support elder ARM hardware these days.
Just my €0.01
Linus Walleij
^ permalink raw reply
* Re: [PATCH v8 02/21] pinctrl: tegra: Add write barrier after all pinctrl register writes
From: Linus Walleij @ 2019-08-14 8:33 UTC (permalink / raw)
To: Sowjanya Komatineni
Cc: thierry.reding@gmail.com, Jon Hunter, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Stefan Agner, Mark Rutland,
Peter De Schrijver, Prashant Gaikwad, Stephen Boyd, linux-clk,
open list:GPIO SUBSYSTEM, jckuo, Joseph Lo, talho, linux-tegra,
linux-kernel@vger.kernel.org, Mikko Perttunen, spatra,
Rob Herring, Dmitry Osipenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rafael J. Wysocki, viresh kumar, Linux PM list
In-Reply-To: <1565308020-31952-3-git-send-email-skomatineni@nvidia.com>
On Fri, Aug 9, 2019 at 1:47 AM Sowjanya Komatineni
<skomatineni@nvidia.com> wrote:
> This patch adds write barrier after all pinctrl register writes
> during resume to make sure all pinctrl changes are complete.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Patch applied with the ACKs.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v8 01/21] pinctrl: tegra: Fix write barrier placement in pmx_writel
From: Linus Walleij @ 2019-08-14 8:32 UTC (permalink / raw)
To: Sowjanya Komatineni
Cc: thierry.reding@gmail.com, Jon Hunter, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Stefan Agner, Mark Rutland,
Peter De Schrijver, Prashant Gaikwad, Stephen Boyd, linux-clk,
open list:GPIO SUBSYSTEM, jckuo, Joseph Lo, talho, linux-tegra,
linux-kernel@vger.kernel.org, Mikko Perttunen, spatra,
Rob Herring, Dmitry Osipenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rafael J. Wysocki, viresh kumar, Linux PM list
In-Reply-To: <1565308020-31952-2-git-send-email-skomatineni@nvidia.com>
On Fri, Aug 9, 2019 at 1:47 AM Sowjanya Komatineni
<skomatineni@nvidia.com> wrote:
> pmx_writel uses writel which inserts write barrier before the
> register write rather.
>
> This patch has fix to replace writel with writel_relaxed followed
> by a write barrier to ensure write operation before the barrier
> is completed for successful pinctrl change.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Patch applied with the ACKs.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 4/6 v2] RFT: gpio: thunderx: Switch to GPIOLIB_IRQCHIP
From: Linus Walleij @ 2019-08-14 8:21 UTC (permalink / raw)
To: open list:GPIO SUBSYSTEM
Cc: Bartosz Golaszewski, David Daney, Thierry Reding, Brian Masney
In-Reply-To: <20190808123242.5359-4-linus.walleij@linaro.org>
On Thu, Aug 8, 2019 at 2:32 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> Use the new infrastructure for hierarchical irqchips in
> gpiolib.
>
> The major part of the rewrite was dues to the fact that
> the driver was passing around a per-irq pointer to
> struct thunderx_line * data container, and the central
> handlers will assume struct gpio_chip * to be passed
> to we need to use the hwirq as index to look up the
> struct thunderx_line * for each IRQ.
>
> The pushing and pop:ing of the irqdomain was confusing
> because I've never seen this before, but I tried to
> replicate it as best I could.
>
> I have no chance to test or debug this so I need
> help.
>
> Cc: David Daney <david.daney@cavium.com>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: Brian Masney <masneyb@onstation.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog RFT v1-> RFT v2:
> - Rebased.
As noone seems interested in reviewing or testing ThunderX
I have applied the patch, as I think there are ThunderX machines
in the test farms, things will crop out now.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/6 v2] qcom: spmi-gpio: convert to hierarchical IRQ helpers in gpio core
From: Linus Walleij @ 2019-08-14 8:19 UTC (permalink / raw)
To: open list:GPIO SUBSYSTEM; +Cc: Bartosz Golaszewski, Brian Masney
In-Reply-To: <20190808123242.5359-3-linus.walleij@linaro.org>
On Thu, Aug 8, 2019 at 2:32 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> From: Brian Masney <masneyb@onstation.org>
>
> Now that the GPIO core has support for hierarchical IRQ chips, convert
> Qualcomm's spmi-gpio over to use these new helpers to reduce duplicated
> code across drivers.
>
> This change was tested on a LG Nexus 5 (hammerhead) phone.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Change "child_pin_to_irq" into "child_offset_to_irq" so
> we avoid confusion with pin control.
This patch is now applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/6 v2] gpio: Add support for hierarchical IRQ domains
From: Linus Walleij @ 2019-08-14 8:18 UTC (permalink / raw)
To: open list:GPIO SUBSYSTEM
Cc: Bartosz Golaszewski, Thomas Gleixner, Marc Zyngier, Lina Iyer,
Jon Hunter, Sowjanya Komatineni, Bitan Biswas, linux-tegra,
David Daney, Masahiro Yamada, Brian Masney, Thierry Reding
In-Reply-To: <20190808123242.5359-1-linus.walleij@linaro.org>
On Thu, Aug 8, 2019 at 2:32 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> Hierarchical IRQ domains can be used to stack different IRQ
> controllers on top of each other.
This is now applied so we get a solid base for testing in linux-next.
Address further concerns with incremental patches, either written
by yourselves or by poking me to do them :)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: pinctrl: stm32: Fix 'st,syscfg' schema
From: Linus Walleij @ 2019-08-14 8:14 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Mark Rutland, Maxime Coquelin, Alexandre Torgue,
open list:GPIO SUBSYSTEM, linux-stm32, Linux ARM
In-Reply-To: <20190813205528.16651-1-robh@kernel.org>
On Tue, Aug 13, 2019 at 10:55 PM Rob Herring <robh@kernel.org> wrote:
> The proper way to add additional contraints to an existing json-schema
> is using 'allOf' to reference the base schema. Using just '$ref' doesn't
> work. Fix this for the 'st,syscfg' property.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-arm-kernel@lists.infradead.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> I've got some other fixes queued up and can take this via the DT tree.
OK!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/3] CP115 pinctrl support
From: Linus Walleij @ 2019-08-14 8:12 UTC (permalink / raw)
To: Miquel Raynal
Cc: Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai, open list:GPIO SUBSYSTEM,
Linux ARM, Grzegorz Jaszczyk, Marcin Wojtas, Stefan Chulski,
Yan Markman
In-Reply-To: <CACRpkdar5jE116CcywYxLR9JKWunRusJjNw7f3C0SFK4-4+dNQ@mail.gmail.com>
On Wed, Aug 7, 2019 at 2:47 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Aug 5, 2019 at 12:16 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > This is the second batch of changes (out of three) to support the brand
> > new Marvell CN9130 SoCs which are made of one AP807 and one CP115.
> >
> > We add a new compatible (and the relevant support in the pinctrl
> > driver) before the addition in batch 3/3 of CN9130 SoCs DT using it.
>
> Waiting for review from the Mvebu maintainers.
>
> If it takes too long just nudge me, it looks good to me.
So if the other MVEBU maintainers don't really look much at MVEBU
patches anymore while Miquel is working a lot on the platform,
what about listing Miquel as maintainer under the SoC entry, hm?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [v7 2/2] gpio: aspeed: Add SGPIO driver
From: Linus Walleij @ 2019-08-14 8:09 UTC (permalink / raw)
To: Hongwei Zhang
Cc: Andrew Jeffery, open list:GPIO SUBSYSTEM, Joel Stanley,
linux-aspeed, Bartosz Golaszewski, linux-kernel@vger.kernel.org,
Linux ARM
In-Reply-To: <1564603297-1391-3-git-send-email-hongweiz@ami.com>
Hi Hongwei,
thanks for your patch!
I have now merged the bindings so you only need to respin
this patch.
On Wed, Jul 31, 2019 at 10:02 PM Hongwei Zhang <hongweiz@ami.com> wrote:
> Add SGPIO driver support for Aspeed AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
I guess I need to go with this, there are some minor things
I still want to be fixed:
> +static void __aspeed_sgpio_set(struct gpio_chip *gc, unsigned int offset, int val)
I don't like __underscore_functions because their semantic
is ambiguous.
Rename this something like aspeed_sgpio_commit() or
whatever best fits the actual use.
> +static int aspeed_sgpio_setup_irqs(struct aspeed_sgpio *gpio,
> + struct platform_device *pdev)
> +{
(...)
> + rc = gpiochip_irqchip_add(&gpio->chip, &aspeed_sgpio_irqchip,
> + 0, handle_bad_irq, IRQ_TYPE_NONE);
(...)
> + gpiochip_set_chained_irqchip(&gpio->chip, &aspeed_sgpio_irqchip,
> + gpio->irq, aspeed_sgpio_irq_handler);
We do not set up chained irqchips like this anymore, sorry.
I am currently rewriting all existing chained drivers to pass
an initialized irqchip when registering the whole gpio chip.
See drivers/gpio/TODO.
Here are examples:
https://lore.kernel.org/linux-gpio/20190811080539.15647-1-linus.walleij@linaro.org/
https://lore.kernel.org/linux-gpio/20190812132554.18313-1-linus.walleij@linaro.org/
> + /* set all SGPIO pins as input (1). */
> + memset(gpio->dir_in, 0xff, sizeof(gpio->dir_in));
Do the irqchip set-up here, before adding the gpio_chip.
> + rc = devm_gpiochip_add_data(&pdev->dev, &gpio->chip, gpio);
> + if (rc < 0)
> + return rc;
> +
> + return aspeed_sgpio_setup_irqs(gpio, pdev);
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: zynq: Pass irqchip when adding gpiochip
From: Michal Simek @ 2019-08-14 8:04 UTC (permalink / raw)
To: Linus Walleij, linux-gpio
Cc: Bartosz Golaszewski, Michal Simek, Shubhrajyoti Datta,
Thierry Reding
In-Reply-To: <20190809132649.25176-1-linus.walleij@linaro.org>
On 09. 08. 19 15:26, Linus Walleij wrote:
> We need to convert all old gpio irqchips to pass the irqchip
> setup along when adding the gpio_chip. For more info see
> drivers/gpio/TODO.
>
> For chained irqchips this is a pretty straight-forward
> conversion.
>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/gpio/gpio-zynq.c | 37 +++++++++++++++++++++----------------
> 1 file changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
> index 86b0bd256c13..cd475ff4bcad 100644
> --- a/drivers/gpio/gpio-zynq.c
> +++ b/drivers/gpio/gpio-zynq.c
> @@ -830,6 +830,7 @@ static int zynq_gpio_probe(struct platform_device *pdev)
> int ret, bank_num;
> struct zynq_gpio *gpio;
> struct gpio_chip *chip;
> + struct gpio_irq_chip *girq;
> const struct of_device_id *match;
>
> gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL);
> @@ -885,34 +886,38 @@ static int zynq_gpio_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err_pm_dis;
>
> - /* report a bug if gpio chip registration fails */
> - ret = gpiochip_add_data(chip, gpio);
> - if (ret) {
> - dev_err(&pdev->dev, "Failed to add gpio chip\n");
> - goto err_pm_put;
> - }
> -
> /* disable interrupts for all banks */
> for (bank_num = 0; bank_num < gpio->p_data->max_bank; bank_num++)
> writel_relaxed(ZYNQ_GPIO_IXR_DISABLE_ALL, gpio->base_addr +
> ZYNQ_GPIO_INTDIS_OFFSET(bank_num));
>
> - ret = gpiochip_irqchip_add(chip, &zynq_gpio_edge_irqchip, 0,
> - handle_level_irq, IRQ_TYPE_NONE);
> - if (ret) {
> - dev_err(&pdev->dev, "Failed to add irq chip\n");
> - goto err_rm_gpiochip;
> + /* Set up the GPIO irqchip */
> + girq = &chip->irq;
> + girq->chip = &zynq_gpio_edge_irqchip;
> + girq->parent_handler = zynq_gpio_irqhandler;
> + girq->num_parents = 1;
> + girq->parents = devm_kcalloc(&pdev->dev, 1,
> + sizeof(*girq->parents),
> + GFP_KERNEL);
> + if (!girq->parents) {
> + ret = -ENOMEM;
> + goto err_pm_put;
> }
> + girq->parents[0] = gpio->irq;
> + girq->default_type = IRQ_TYPE_NONE;
> + girq->handler = handle_level_irq;
>
> - gpiochip_set_chained_irqchip(chip, &zynq_gpio_edge_irqchip, gpio->irq,
> - zynq_gpio_irqhandler);
> + /* report a bug if gpio chip registration fails */
> + ret = gpiochip_add_data(chip, gpio);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to add gpio chip\n");
> + goto err_pm_put;
> + }
>
> pm_runtime_put(&pdev->dev);
>
> return 0;
>
> -err_rm_gpiochip:
> - gpiochip_remove(chip);
> err_pm_put:
> pm_runtime_put(&pdev->dev);
> err_pm_dis:
>
Shubhrajyoti: Please retest it.
Thanks,
Michal
^ permalink raw reply
* Re: [v7 1/2] dt-bindings: gpio: aspeed: Add SGPIO support
From: Linus Walleij @ 2019-08-14 7:59 UTC (permalink / raw)
To: Hongwei Zhang
Cc: Andrew Jeffery, Joel Stanley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Bartosz Golaszewski, linux-aspeed,
linux-kernel@vger.kernel.org, Linux ARM, open list:GPIO SUBSYSTEM
In-Reply-To: <1564603297-1391-2-git-send-email-hongweiz@ami.com>
On Wed, Jul 31, 2019 at 10:01 PM Hongwei Zhang <hongweiz@ami.com> wrote:
> Add bindings to support SGPIO on AST2400 or AST2500.
>
> Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
OK timeout for further DT binding review. I adjusted a bunch
of things like whitespace and referencing other files when
applying.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: plat-samsung: Include GPIO driver header
From: Linus Walleij @ 2019-08-14 7:52 UTC (permalink / raw)
To: linux-gpio
Cc: Bartosz Golaszewski, Linus Walleij, Kukjin Kim,
Krzysztof Kozlowski, linux-samsung-soc
This file is using struct gpio_chip and needs to include
<linux/gpio/driver.h> to get that.
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Samsung maintainers: please apply this where appropriate.
---
arch/arm/plat-samsung/include/plat/gpio-core.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/plat-samsung/include/plat/gpio-core.h b/arch/arm/plat-samsung/include/plat/gpio-core.h
index 51e721f5e491..c0bfceb88340 100644
--- a/arch/arm/plat-samsung/include/plat/gpio-core.h
+++ b/arch/arm/plat-samsung/include/plat/gpio-core.h
@@ -12,6 +12,7 @@
/* Bring in machine-local definitions, especially S3C_GPIO_END */
#include <mach/gpio-samsung.h>
+#include <linux/gpio/driver.h>
#define GPIOCON_OFF (0x00)
#define GPIODAT_OFF (0x04)
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] pinctrl: sh-pfc: Include the right header
From: Geert Uytterhoeven @ 2019-08-14 7:41 UTC (permalink / raw)
To: Linus Walleij; +Cc: open list:GPIO SUBSYSTEM, Geert Uytterhoeven
In-Reply-To: <20190814072032.5876-1-linus.walleij@linaro.org>
Hi Linus,
On Wed, Aug 14, 2019 at 9:20 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> This is a GPIO driver, use the appropriate header
> <linux/gpio/driver.h> rather than the legacy <linux/gpio.h>
> header.
>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Geert tell me how you want me to handle this, you can send
> it with your pull requests or I can apply it directly
> if you're not queueing stuff right now.
I am, hence will queue in sh-pfc-for-v5.4.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] pinctrl: sh-pfc: Include the right header
From: Linus Walleij @ 2019-08-14 7:20 UTC (permalink / raw)
To: linux-gpio; +Cc: Linus Walleij, Geert Uytterhoeven
This is a GPIO driver, use the appropriate header
<linux/gpio/driver.h> rather than the legacy <linux/gpio.h>
header.
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Geert tell me how you want me to handle this, you can send
it with your pull requests or I can apply it directly
if you're not queueing stuff right now.
---
drivers/pinctrl/sh-pfc/gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index 64c09aa374ae..5a55b8da7919 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -7,7 +7,7 @@
*/
#include <linux/device.h>
-#include <linux/gpio.h>
+#include <linux/gpio/driver.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/pinctrl/consumer.h>
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox