* [gpio:devel] BUILD SUCCESS 80606cb24161d504acb4d89f406d68f72196575e
From: kernel test robot @ 2020-07-18 2:05 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-gpio
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git devel
branch HEAD: 80606cb24161d504acb4d89f406d68f72196575e gpio: max77620: Use helper variable and clarify
elapsed time: 722m
configs tested: 86
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
nds32 allnoconfig
powerpc ppc64e_defconfig
arm viper_defconfig
ia64 alldefconfig
sh se7721_defconfig
ia64 tiger_defconfig
mips jmr3927_defconfig
arm xcep_defconfig
h8300 allyesconfig
powerpc linkstation_defconfig
sparc sparc32_defconfig
arm badge4_defconfig
powerpc pmac32_defconfig
riscv rv32_defconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
i386 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [gpio:for-next] BUILD SUCCESS 70d7cd6c82a906bfc45e5043fed5456d46a92662
From: kernel test robot @ 2020-07-18 2:05 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-gpio
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
branch HEAD: 70d7cd6c82a906bfc45e5043fed5456d46a92662 Merge branch 'devel' into for-next
elapsed time: 722m
configs tested: 86
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
nds32 allnoconfig
powerpc ppc64e_defconfig
arm viper_defconfig
ia64 alldefconfig
sh se7721_defconfig
ia64 tiger_defconfig
mips jmr3927_defconfig
arm xcep_defconfig
h8300 allyesconfig
powerpc linkstation_defconfig
sparc sparc32_defconfig
arm badge4_defconfig
powerpc pmac32_defconfig
riscv rv32_defconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
i386 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [gpio:no-irqchip-nested-threading] BUILD SUCCESS d20743e24eec787d0333d423479ea2f137496f06
From: kernel test robot @ 2020-07-18 2:05 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-gpio
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git no-irqchip-nested-threading
branch HEAD: d20743e24eec787d0333d423479ea2f137496f06 gpio: crystalcove: Use irqchip template
elapsed time: 722m
configs tested: 86
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
nds32 allnoconfig
powerpc ppc64e_defconfig
arm viper_defconfig
ia64 alldefconfig
sh se7721_defconfig
ia64 tiger_defconfig
mips jmr3927_defconfig
arm xcep_defconfig
h8300 allyesconfig
powerpc linkstation_defconfig
sparc sparc32_defconfig
arm badge4_defconfig
powerpc pmac32_defconfig
riscv rv32_defconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
i386 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] pinctrl: single: print gpio number in pins debugfs file
From: Drew Fustini @ 2020-07-17 22:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tony Lindgren, Haojian Zhuang, Linus Walleij,
Linux OMAP Mailing List, open list:GPIO SUBSYSTEM, Jason Kridner,
Robert Nelson
In-Reply-To: <CAHp75VcL8Cz3E5HB6WkpddNzGRBY8w5m5m_vbxEr5EfBz7mWdA@mail.gmail.com>
On Fri, Jul 17, 2020 at 11:09:11PM +0300, Andy Shevchenko wrote:
> On Fri, Jul 17, 2020 at 10:50 PM Drew Fustini <drew@beagleboard.org> wrote:
> > On Fri, Jul 17, 2020 at 06:14:06PM +0300, Andy Shevchenko wrote:
> > > On Fri, Jul 17, 2020 at 4:36 AM Drew Fustini <drew@beagleboard.org> wrote:
>
> ...
>
> > > > pin 0 (PIN0) 44e10800 00000027 pinctrl-single GPIO-32
> > > > pin 1 (PIN1) 44e10804 00000027 pinctrl-single GPIO-33
> > > > pin 2 (PIN2) 44e10808 00000027 pinctrl-single GPIO-34
> > > > pin 3 (PIN3) 44e1080c 00000027 pinctrl-single GPIO-35
> > > > pin 4 (PIN4) 44e10810 00000027 pinctrl-single GPIO-36
> > > > pin 5 (PIN5) 44e10814 00000027 pinctrl-single GPIO-37
> > > > pin 6 (PIN6) 44e10818 00000027 pinctrl-single GPIO-38
> > > > pin 7 (PIN7) 44e1081c 00000027 pinctrl-single GPIO-39
> > > > pin 8 (PIN8) 44e10820 00000027 pinctrl-single GPIO-22
> > > > pin 9 (PIN9) 44e10824 00000030 pinctrl-single GPIO-23
> > >
> > > Wouldn't it be better to have this for all types of pin controllers?
> > > But I'm not sure about the format of output.
>
> ...
>
> > I added the gpio column based on Tony's feedback [0].
> >
> > I'm not sure how I could do it genericly.
> >
> > The pin_dbg_show callback is implemented in pcs_pin_dbg_show() which
> > prints the contents of each line in the 'pins' file.
> >
> > Any advice on how I could implement a gpio column for 'pins' file
> > without chaning the pin_dbg_show in all the drivers?A
>
> My question was exactly about changing core, i.e. pinctrl_pins_show(),
> rather than each driver.
>
> --
> With Best Regards,
> Andy Shevchenko
Ah ok, so I see in pinctrl_pins_show() that it prints:
seq_printf(s, "pin %d (%s) ", pin, desc->name);
and then calls ops->pin_dbg_show() to have the driver finish printing
the line.
I will try to add the gpio number to the seq_printf() after desc->name.
thanks,
drew
^ permalink raw reply
* Re: [PATCH v5 12/13] arm64: dts: freescale: sl28: enable LED support
From: Michael Walle @ 2020-07-17 21:54 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
linux-watchdog, linux-arm-kernel, Linus Walleij,
Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
Lee Jones, Thierry Reding, Uwe Kleine-K??nig, Wim Van Sebroeck,
Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Mark Brown, Greg Kroah-Hartman, Andy Shevchenko
In-Reply-To: <20200717083610.GC1027@bug>
Hi Pavel,
Am 2020-07-17 10:36, schrieb Pavel Machek:
> Hi!
>
>> Now that we have support for GPIO lines of the SMARC connector, enable
>> LED support on the KBox A-230-LS. There are two LEDs without fixed
>> functions, one is yellow and one is green. Unfortunately, it is just
>> one
>> multi-color LED, thus while it is possible to enable both at the same
>> time it is hard to tell the difference between "yellow only" and
>> "yellow
>> and green".
>
>> + user_yellow {
>> + label = "s1914:yellow:user";
>> + gpios = <&sl28cpld_gpio0 0 0>;
>> + };
>> +
>> + user_green {
>> + label = "s1914:green:user";
>> + gpios = <&sl28cpld_gpio1 3 0>;
>> + };
>
> This is not suitable label for such LEDs... there's zero chance
> userland will
> know what to do with these.
>
> Do they have some kind of "usual" function?
Unfortunately, they do not. I guess the green one could be something
like
"application ready" and the yellow one could be an indication that some
fault occurred.
Do you have any suggestions?
-michael
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: Use irqchip template
From: Andy Shevchenko @ 2020-07-17 20:34 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-gpio, Bartosz Golaszewski, Marek Vasut,
Uwe Kleine-König, Adam Ford, Vignesh Raghavendra
In-Reply-To: <20200717144040.63253-1-linus.walleij@linaro.org>
On Fri, Jul 17, 2020 at 04:40:40PM +0200, Linus Walleij wrote:
> This makes the driver use the irqchip template to assign
> properties to the gpio_irq_chip instead of using the
> explicit calls to gpiochip_irqchip_add_nested() and
> gpiochip_set_nested_irqchip(). The irqchip is instead
> added while adding the gpiochip.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Marek Vasut <marek.vasut@gmail.com>
> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Cc: Adam Ford <aford173@gmail.com>
> Cc: Vignesh Raghavendra <vigneshr@ti.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/gpio/gpio-pca953x.c | 25 +++++++++++++------------
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index 9c90cf3aac5a..ab22152bf3e8 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -834,6 +834,7 @@ static int pca953x_irq_setup(struct pca953x_chip *chip, int irq_base)
> struct irq_chip *irq_chip = &chip->irq_chip;
> DECLARE_BITMAP(reg_direction, MAX_LINE);
> DECLARE_BITMAP(irq_stat, MAX_LINE);
> + struct gpio_irq_chip *girq;
> int ret;
>
> if (dmi_first_match(pca953x_dmi_acpi_irq_info)) {
> @@ -883,16 +884,16 @@ static int pca953x_irq_setup(struct pca953x_chip *chip, int irq_base)
> irq_chip->irq_set_type = pca953x_irq_set_type;
> irq_chip->irq_shutdown = pca953x_irq_shutdown;
>
> - ret = gpiochip_irqchip_add_nested(&chip->gpio_chip, irq_chip,
> - irq_base, handle_simple_irq,
> - IRQ_TYPE_NONE);
> - if (ret) {
> - dev_err(&client->dev,
> - "could not connect irqchip to gpiochip\n");
> - return ret;
> - }
> -
> - gpiochip_set_nested_irqchip(&chip->gpio_chip, irq_chip, client->irq);
> + girq = &chip->gpio_chip.irq;
> + girq->chip = irq_chip;
> + /* This will let us handle the parent IRQ in the driver */
> + girq->parent_handler = NULL;
> + girq->num_parents = 0;
> + girq->parents = NULL;
> + girq->default_type = IRQ_TYPE_NONE;
> + girq->handler = handle_simple_irq;
> + girq->threaded = true;
> + girq->first = irq_base; /* FIXME: get rid of this */
>
> return 0;
> }
> @@ -1080,11 +1081,11 @@ static int pca953x_probe(struct i2c_client *client,
> if (ret)
> goto err_exit;
>
> - ret = devm_gpiochip_add_data(&client->dev, &chip->gpio_chip, chip);
> + ret = pca953x_irq_setup(chip, irq_base);
> if (ret)
> goto err_exit;
>
> - ret = pca953x_irq_setup(chip, irq_base);
> + ret = devm_gpiochip_add_data(&client->dev, &chip->gpio_chip, chip);
> if (ret)
> goto err_exit;
>
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] pinctrl: single: print gpio number in pins debugfs file
From: Andy Shevchenko @ 2020-07-17 20:09 UTC (permalink / raw)
To: Drew Fustini
Cc: Tony Lindgren, Haojian Zhuang, Linus Walleij,
Linux OMAP Mailing List, open list:GPIO SUBSYSTEM, Jason Kridner,
Robert Nelson
In-Reply-To: <20200717195028.GA1775511@x1>
On Fri, Jul 17, 2020 at 10:50 PM Drew Fustini <drew@beagleboard.org> wrote:
> On Fri, Jul 17, 2020 at 06:14:06PM +0300, Andy Shevchenko wrote:
> > On Fri, Jul 17, 2020 at 4:36 AM Drew Fustini <drew@beagleboard.org> wrote:
...
> > > pin 0 (PIN0) 44e10800 00000027 pinctrl-single GPIO-32
> > > pin 1 (PIN1) 44e10804 00000027 pinctrl-single GPIO-33
> > > pin 2 (PIN2) 44e10808 00000027 pinctrl-single GPIO-34
> > > pin 3 (PIN3) 44e1080c 00000027 pinctrl-single GPIO-35
> > > pin 4 (PIN4) 44e10810 00000027 pinctrl-single GPIO-36
> > > pin 5 (PIN5) 44e10814 00000027 pinctrl-single GPIO-37
> > > pin 6 (PIN6) 44e10818 00000027 pinctrl-single GPIO-38
> > > pin 7 (PIN7) 44e1081c 00000027 pinctrl-single GPIO-39
> > > pin 8 (PIN8) 44e10820 00000027 pinctrl-single GPIO-22
> > > pin 9 (PIN9) 44e10824 00000030 pinctrl-single GPIO-23
> >
> > Wouldn't it be better to have this for all types of pin controllers?
> > But I'm not sure about the format of output.
...
> I added the gpio column based on Tony's feedback [0].
>
> I'm not sure how I could do it genericly.
>
> The pin_dbg_show callback is implemented in pcs_pin_dbg_show() which
> prints the contents of each line in the 'pins' file.
>
> Any advice on how I could implement a gpio column for 'pins' file
> without chaning the pin_dbg_show in all the drivers?A
My question was exactly about changing core, i.e. pinctrl_pins_show(),
rather than each driver.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] pinctrl: single: print gpio number in pins debugfs file
From: Drew Fustini @ 2020-07-17 19:50 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tony Lindgren, Haojian Zhuang, Linus Walleij,
Linux OMAP Mailing List, open list:GPIO SUBSYSTEM, Jason Kridner,
Robert Nelson
In-Reply-To: <CAHp75Vd_s-W7Z1iG4fA5JvY51OzstkTYUcQcd=OGJUQtcJ75Ww@mail.gmail.com>
On Fri, Jul 17, 2020 at 06:14:06PM +0300, Andy Shevchenko wrote:
> On Fri, Jul 17, 2020 at 4:36 AM Drew Fustini <drew@beagleboard.org> wrote:
> >
> > If there is a gpio range mapping for the pin, then print out the gpio
> > number for the pin in the debugfs 'pins' file.
> >
> > Here is an example on the BeagleBone Black:
>
> > pin 0 (PIN0) 44e10800 00000027 pinctrl-single GPIO-32
> > pin 1 (PIN1) 44e10804 00000027 pinctrl-single GPIO-33
> > pin 2 (PIN2) 44e10808 00000027 pinctrl-single GPIO-34
> > pin 3 (PIN3) 44e1080c 00000027 pinctrl-single GPIO-35
> > pin 4 (PIN4) 44e10810 00000027 pinctrl-single GPIO-36
> > pin 5 (PIN5) 44e10814 00000027 pinctrl-single GPIO-37
> > pin 6 (PIN6) 44e10818 00000027 pinctrl-single GPIO-38
> > pin 7 (PIN7) 44e1081c 00000027 pinctrl-single GPIO-39
> > pin 8 (PIN8) 44e10820 00000027 pinctrl-single GPIO-22
> > pin 9 (PIN9) 44e10824 00000030 pinctrl-single GPIO-23
>
> Wouldn't it be better to have this for all types of pin controllers?
> But I'm not sure about the format of output.
>
> --
> With Best Regards,
> Andy Shevchenko
I added the gpio column based on Tony's feedback [0].
I'm not sure how I could do it genericly.
The pin_dbg_show callback is implemented in pcs_pin_dbg_show() which
prints the contents of each line in the 'pins' file.
Any advice on how I could implement a gpio column for 'pins' file
without chaning the pin_dbg_show in all the drivers?A
thanks,
drew
[0] https://lore.kernel.org/linux-gpio/20200713180519.GN5849@atomide.com/
^ permalink raw reply
* Re: [PATCH v2] gpio: omap: handle pin config bias flags
From: Drew Fustini @ 2020-07-17 19:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tony Lindgren, Haojian Zhuang, Grygorii Strashko, Linus Walleij,
Linux OMAP Mailing List, open list:GPIO SUBSYSTEM, Jason Kridner,
Robert Nelson
In-Reply-To: <CAPgEAj4gJsZLWDEkjfF+THcD92y6HL8T00NWzpECLDdXQYLVfA@mail.gmail.com>
On Fri, Jul 17, 2020 at 08:56:45PM +0200, Drew Fustini wrote:
> On Fri, Jul 17, 2020, 17:15 Andy Shevchenko <andy.shevchenko@gmail.com>
> wrote:
>
> > On Thu, Jul 16, 2020 at 12:38 AM Drew Fustini <drew@beagleboard.org>
> > wrote:
> > >
> > > Modify omap_gpio_set_config() to handle pin config bias flags by calling
> > > gpiochip_generic_config().
> > >
> > > The pin group for the gpio line must have the corresponding pinconf
> > > properties:
> > >
> > > PIN_CONFIG_BIAS_PULL_UP requires "pinctrl-single,bias-pullup"
> > > PIN_CONFIG_BIAS_PULL_DOWN requires "pinctrl-single,bias-pulldown"
> > >
> > > This is necessary for pcs_pinconf_set() to find the requested bias
> > > parameter in the PIN_MAP_TYPE_CONFIGS_GROUP pinctrl map.
> >
> > ...
> >
> > > + if ((pinconf_to_config_param(config) == PIN_CONFIG_BIAS_DISABLE)
> > ||
> > > + (pinconf_to_config_param(config) == PIN_CONFIG_BIAS_PULL_UP)
> > ||
> > > + (pinconf_to_config_param(config) ==
> > PIN_CONFIG_BIAS_PULL_DOWN))
> > > + {
> > > + ret = gpiochip_generic_config(chip, offset, config);
> > > + }
> > > + else if (pinconf_to_config_param(config) ==
> > PIN_CONFIG_INPUT_DEBOUNCE)
> > > + {
> > > + debounce = pinconf_to_config_argument(config);
> > > + ret = omap_gpio_debounce(chip, offset, debounce);
> > > + }
> >
> > It's a rather strange indentation of the curly braces. Don't you run
> > checkpatch?
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
>
> Thanks for pointing that out. I should have caught that.
>
> Linus - I submitted a v2 with the braces fixed. Please let me know if I
> should send a patch just for the braces on top of what is already in
> for-next.
>
> Thanks,
> Drew
Sorry for the noise. I failed to realize that I had already sent v2
(regarding the handling of the return value). I have now submitted v3
patch [0] to fix the braces formatting that Andy pointed out.
thanks,
drew
[0] https://lore.kernel.org/linux-omap/20200717194043.1774643-1-drew@beagleboard.org/
^ permalink raw reply
* [PATCH v3] gpio: omap: handle pin config bias flags
From: Drew Fustini @ 2020-07-17 19:40 UTC (permalink / raw)
To: Tony Lindgren, Haojian Zhuang, Linus Walleij, Grygorii Strashko,
linux-omap, linux-gpio, Jason Kridner, Robert Nelson
Cc: Drew Fustini
Modify omap_gpio_set_config() to handle pin config bias flags by calling
gpiochip_generic_config().
The pin group for the gpio line must have the corresponding pinconf
properties:
PIN_CONFIG_BIAS_PULL_UP requires "pinctrl-single,bias-pullup"
PIN_CONFIG_BIAS_PULL_DOWN requires "pinctrl-single,bias-pulldown"
This is necessary for pcs_pinconf_set() to find the requested bias
parameter in the PIN_MAP_TYPE_CONFIGS_GROUP pinctrl map.
Signed-off-by: Drew Fustini <drew@beagleboard.org>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200715213738.1640030-1-drew@beagleboard.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpio-omap.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
v3 changes:
- adjust the braces to match the correct coding style
- note: I originally re-submitted this as v2 by accident when it should
have been v3. Sorry for the noise.
v2 changes:
- simplify handling of -ENOTSUPP return value per Grygorii's suggestion
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index b8e2ecc3eade..0ccb31de0b67 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -896,12 +896,18 @@ static int omap_gpio_set_config(struct gpio_chip *chip, unsigned offset,
unsigned long config)
{
u32 debounce;
+ int ret = -ENOTSUPP;
+
+ if ((pinconf_to_config_param(config) == PIN_CONFIG_BIAS_DISABLE) ||
+ (pinconf_to_config_param(config) == PIN_CONFIG_BIAS_PULL_UP) ||
+ (pinconf_to_config_param(config) == PIN_CONFIG_BIAS_PULL_DOWN)) {
+ ret = gpiochip_generic_config(chip, offset, config);
+ } else if (pinconf_to_config_param(config) == PIN_CONFIG_INPUT_DEBOUNCE) {
+ debounce = pinconf_to_config_argument(config);
+ ret = omap_gpio_debounce(chip, offset, debounce);
+ }
- if (pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
- return -ENOTSUPP;
-
- debounce = pinconf_to_config_argument(config);
- return omap_gpio_debounce(chip, offset, debounce);
+ return ret;
}
static void omap_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
--
2.25.1
^ permalink raw reply related
* linusw/for-next baseline: 60 runs, 2 regressions (v5.8-rc5-69-g70d7cd6c82a9)
From: kernelci.org bot @ 2020-07-17 19:01 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/for-next baseline: 60 runs, 2 regressions (v5.8-rc5-69-g70d7cd6c82a9)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | results
-----------------------------+-------+--------------+----------+-----------+--------
bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
meson-gxl-s805x-libretech-ac | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
Details: https://kernelci.org/test/job/linusw/branch/for-next/kernel/v5.8-rc5-69-g70d7cd6c82a9/plan/baseline/
Test: baseline
Tree: linusw
Branch: for-next
Describe: v5.8-rc5-69-g70d7cd6c82a9
URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
SHA: 70d7cd6c82a906bfc45e5043fed5456d46a92662
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | results
-----------------------------+-------+--------------+----------+-----------+--------
bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
Details: https://kernelci.org/test/plan/id/5f11eb8ae9c3faa1c685bb47
Results: 4 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//linusw/for-next/v5.8-rc5-69-g70d7cd6c82a9/arm64/defconfig/gcc-8/lab-baylibre/baseline-bcm2837-rpi-3-b.txt
HTML log: https://storage.kernelci.org//linusw/for-next/v5.8-rc5-69-g70d7cd6c82a9/arm64/defconfig/gcc-8/lab-baylibre/baseline-bcm2837-rpi-3-b.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/arm64/baseline/rootfs.cpio.gz
* baseline.dmesg.crit: https://kernelci.org/test/case/id/5f11eb8ae9c3faa1c685bb4a
failing since 1 day (last pass: gpio-v5.8-2-58-g1752911c6d10, first fail: v5.8-rc5-68-geb211a587e18)
2 lines
platform | arch | lab | compiler | defconfig | results
-----------------------------+-------+--------------+----------+-----------+--------
meson-gxl-s805x-libretech-ac | arm64 | lab-baylibre | gcc-8 | defconfig | 4/5
Details: https://kernelci.org/test/plan/id/5f11ebc3c911c70d4385bb22
Results: 4 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//linusw/for-next/v5.8-rc5-69-g70d7cd6c82a9/arm64/defconfig/gcc-8/lab-baylibre/baseline-meson-gxl-s805x-libretech-ac.txt
HTML log: https://storage.kernelci.org//linusw/for-next/v5.8-rc5-69-g70d7cd6c82a9/arm64/defconfig/gcc-8/lab-baylibre/baseline-meson-gxl-s805x-libretech-ac.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/arm64/baseline/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/5f11ebc3c911c70d4385bb27
new failure (last pass: v5.8-rc5-68-geb211a587e18)
2 lines
^ permalink raw reply
* linusw/devel baseline: 71 runs, 2 regressions (gpio-v5.8-2-68-g80606cb24161)
From: kernelci.org bot @ 2020-07-17 18:43 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/devel baseline: 71 runs, 2 regressions (gpio-v5.8-2-68-g80606cb24161)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | results
----------------------+-------+--------------+----------+--------------------+--------
at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 0/1
hifive-unleashed-a00 | riscv | lab-baylibre | gcc-8 | defconfig | 0/1
Details: https://kernelci.org/test/job/linusw/branch/devel/kernel/gpio-v5.8-2-68-g80606cb24161/plan/baseline/
Test: baseline
Tree: linusw
Branch: devel
Describe: gpio-v5.8-2-68-g80606cb24161
URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
SHA: 80606cb24161d504acb4d89f406d68f72196575e
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | results
----------------------+-------+--------------+----------+--------------------+--------
at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 0/1
Details: https://kernelci.org/test/plan/id/5f11e310f6e8e8654485bb28
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//linusw/devel/gpio-v5.8-2-68-g80606cb24161/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-at91-sama5d4_xplained.txt
HTML log: https://storage.kernelci.org//linusw/devel/gpio-v5.8-2-68-g80606cb24161/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-at91-sama5d4_xplained.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/5f11e310f6e8e8654485bb29
failing since 31 days (last pass: gpio-v5.8-1-1-gf6d984418ffd, first fail: v5.8-rc1)
platform | arch | lab | compiler | defconfig | results
----------------------+-------+--------------+----------+--------------------+--------
hifive-unleashed-a00 | riscv | lab-baylibre | gcc-8 | defconfig | 0/1
Details: https://kernelci.org/test/plan/id/5f11e08b858665a13285bb25
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-8 (riscv64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//linusw/devel/gpio-v5.8-2-68-g80606cb24161/riscv/defconfig/gcc-8/lab-baylibre/baseline-hifive-unleashed-a00.txt
HTML log: https://storage.kernelci.org//linusw/devel/gpio-v5.8-2-68-g80606cb24161/riscv/defconfig/gcc-8/lab-baylibre/baseline-hifive-unleashed-a00.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/riscv/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/5f11e08b858665a13285bb26
failing since 31 days (last pass: gpio-v5.8-1-1-gf6d984418ffd, first fail: v5.8-rc1)
^ permalink raw reply
* linusw/for-next build: 7 builds: 0 failed, 7 passed, 8 warnings (v5.8-rc5-69-g70d7cd6c82a9)
From: kernelci.org bot @ 2020-07-17 18:16 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/for-next build: 7 builds: 0 failed, 7 passed, 8 warnings (v5.8-rc5-69-g70d7cd6c82a9)
Full Build Summary: https://kernelci.org/build/linusw/branch/for-next/kernel/v5.8-rc5-69-g70d7cd6c82a9/
Tree: linusw
Branch: for-next
Git Describe: v5.8-rc5-69-g70d7cd6c82a9
Git Commit: 70d7cd6c82a906bfc45e5043fed5456d46a92662
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Built: 7 unique architectures
Warnings Detected:
arc:
arm64:
defconfig (gcc-8): 8 warnings
arm:
i386:
mips:
riscv:
x86_64:
Warnings summary:
3 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
3 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
1 arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
1 arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 8 warnings, 0 section mismatches
Warnings:
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
--------------------------------------------------------------------------------
haps_hs_smp_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
i386_defconfig (i386, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
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
* [PATCH v2] gpio: omap: handle pin config bias flags
From: Drew Fustini @ 2020-07-17 18:12 UTC (permalink / raw)
To: Tony Lindgren, Haojian Zhuang, Linus Walleij, linux-omap,
linux-gpio, Jason Kridner, Robert Nelson
Cc: Drew Fustini, Grygorii Strashko
Modify omap_gpio_set_config() to handle pin config bias flags by calling
gpiochip_generic_config().
The pin group for the gpio line must have the corresponding pinconf
properties:
PIN_CONFIG_BIAS_PULL_UP requires "pinctrl-single,bias-pullup"
PIN_CONFIG_BIAS_PULL_DOWN requires "pinctrl-single,bias-pulldown"
This is necessary for pcs_pinconf_set() to find the requested bias
parameter in the PIN_MAP_TYPE_CONFIGS_GROUP pinctrl map.
Signed-off-by: Drew Fustini <drew@beagleboard.org>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200715213738.1640030-1-drew@beagleboard.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpio-omap.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
V2 changes:
- adjust the braces to match the correct coding style
- Linus: should I be creating a patch that is just the delta for the
braces?
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index b8e2ecc3eade..0ccb31de0b67 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -896,12 +896,18 @@ static int omap_gpio_set_config(struct gpio_chip *chip, unsigned offset,
unsigned long config)
{
u32 debounce;
+ int ret = -ENOTSUPP;
+
+ if ((pinconf_to_config_param(config) == PIN_CONFIG_BIAS_DISABLE) ||
+ (pinconf_to_config_param(config) == PIN_CONFIG_BIAS_PULL_UP) ||
+ (pinconf_to_config_param(config) == PIN_CONFIG_BIAS_PULL_DOWN)) {
+ ret = gpiochip_generic_config(chip, offset, config);
+ } else if (pinconf_to_config_param(config) == PIN_CONFIG_INPUT_DEBOUNCE) {
+ debounce = pinconf_to_config_argument(config);
+ ret = omap_gpio_debounce(chip, offset, debounce);
+ }
- if (pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
- return -ENOTSUPP;
-
- debounce = pinconf_to_config_argument(config);
- return omap_gpio_debounce(chip, offset, debounce);
+ return ret;
}
static void omap_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
--
2.25.1
^ permalink raw reply related
* linusw/devel build: 5 builds: 0 failed, 5 passed, 21 warnings (gpio-v5.8-2-68-g80606cb24161)
From: kernelci.org bot @ 2020-07-17 17:58 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/devel build: 5 builds: 0 failed, 5 passed, 21 warnings (gpio-v5.8-2-68-g80606cb24161)
Full Build Summary: https://kernelci.org/build/linusw/branch/devel/kernel/gpio-v5.8-2-68-g80606cb24161/
Tree: linusw
Branch: devel
Git Describe: gpio-v5.8-2-68-g80606cb24161
Git Commit: 80606cb24161d504acb4d89f406d68f72196575e
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Built: 5 unique architectures
Warnings Detected:
arm64:
defconfig (gcc-8): 8 warnings
arm:
multi_v7_defconfig (gcc-8): 12 warnings
i386:
mips:
riscv:
defconfig (gcc-8): 1 warning
Warnings summary:
3 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
3 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
1 drivers/net/ethernet/intel/e1000e/netdev.c:137:13: warning: ‘e1000e_check_me’ defined but not used [-Wunused-function]
1 arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
1 arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
1 arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:161.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@300/ipmb7@10:reg: I2C address must be less than 10-bits, got "0x40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:159.11-163.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@300/ipmb7@10: I2C bus unit address format error, expected "40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:150.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@180/ipmb5@10:reg: I2C address must be less than 10-bits, got "0x40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:148.11-152.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@180/ipmb5@10: I2C bus unit address format error, expected "40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:139.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@100/ipmb3@10:reg: I2C address must be less than 10-bits, got "0x40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:137.11-141.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@100/ipmb3@10: I2C bus unit address format error, expected "40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:128.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@80/ipmb1@10:reg: I2C address must be less than 10-bits, got "0x40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:126.11-130.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@80/ipmb1@10: I2C bus unit address format error, expected "40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts:523.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@380/ipmb0@10:reg: I2C address must be less than 10-bits, got "0x40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts:521.11-525.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@380/ipmb0@10: I2C bus unit address format error, expected "40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts:437.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@140/ipmb0@10:reg: I2C address must be less than 10-bits, got "0x40000010"
1 arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts:435.11-439.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@140/ipmb0@10: I2C bus unit address format error, expected "40000010"
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/net/ethernet/intel/e1000e/netdev.c:137:13: warning: ‘e1000e_check_me’ defined but not used [-Wunused-function]
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 8 warnings, 0 section mismatches
Warnings:
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:127.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
--------------------------------------------------------------------------------
i386_defconfig (i386, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 12 warnings, 0 section mismatches
Warnings:
arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts:435.11-439.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@140/ipmb0@10: I2C bus unit address format error, expected "40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts:437.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@140/ipmb0@10:reg: I2C address must be less than 10-bits, got "0x40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts:521.11-525.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@380/ipmb0@10: I2C bus unit address format error, expected "40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts:523.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@380/ipmb0@10:reg: I2C address must be less than 10-bits, got "0x40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:126.11-130.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@80/ipmb1@10: I2C bus unit address format error, expected "40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:128.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@80/ipmb1@10:reg: I2C address must be less than 10-bits, got "0x40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:137.11-141.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@100/ipmb3@10: I2C bus unit address format error, expected "40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:139.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@100/ipmb3@10:reg: I2C address must be less than 10-bits, got "0x40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:148.11-152.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@180/ipmb5@10: I2C bus unit address format error, expected "40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:150.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@180/ipmb5@10:reg: I2C address must be less than 10-bits, got "0x40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:159.11-163.4: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@300/ipmb7@10: I2C bus unit address format error, expected "40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:161.3-30: Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@300/ipmb7@10:reg: I2C address must be less than 10-bits, got "0x40000010"
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* [PATCH v2 0/2] Enable USB support on iW-RainboW-G21D-Q7 board
From: Lad Prabhakar @ 2020-07-17 17:00 UTC (permalink / raw)
To: Geert Uytterhoeven, Rob Herring, Linus Walleij, devicetree
Cc: Magnus Damm, linux-renesas-soc, linux-kernel, linux-gpio,
Prabhakar, Lad Prabhakar
Hi All,
This series enables support for following peripherals in iW-RainboW-G21D-Q7
development platform:
* HSUSB
* USB2.0
* xHCI
Changes for v2:
* Added USB1 pwen pin and group
* Fixed pinmux pins for usb1
[v1] https://lkml.org/lkml/2020/5/27/1478
* Rest of the patches from v1 have been accepted
Cheers,
Prabhakar
Lad Prabhakar (2):
pinctrl: sh-pfc: r8a7790: Add USB1 PWEN pin and group
ARM: dts: r8a7742-iwg21d-q7: Enable HSUSB, USB2.0 and xHCI
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 42 +++++++++++++++++++++++++
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 11 ++++++-
2 files changed, 52 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply
* [PATCH v2 1/2] pinctrl: sh-pfc: r8a7790: Add USB1 PWEN pin and group
From: Lad Prabhakar @ 2020-07-17 17:00 UTC (permalink / raw)
To: Geert Uytterhoeven, Rob Herring, Linus Walleij, devicetree
Cc: Magnus Damm, linux-renesas-soc, linux-kernel, linux-gpio,
Prabhakar, Lad Prabhakar
In-Reply-To: <1595005225-11519-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Add USB1 PWEN pin and group for USB1 interface.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index f524401fec5f..39ba1e7cc1c3 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -3611,6 +3611,13 @@ static const unsigned int usb1_pins[] = {
static const unsigned int usb1_mux[] = {
USB1_PWEN_MARK, USB1_OVC_MARK,
};
+static const unsigned int usb1_pwen_pins[] = {
+ /* PWEN */
+ RCAR_GP_PIN(5, 20),
+};
+static const unsigned int usb1_pwen_mux[] = {
+ USB1_PWEN_MARK,
+};
/* - USB2 ------------------------------------------------------------------- */
static const unsigned int usb2_pins[] = {
/* PWEN, OVC */
@@ -3939,7 +3946,7 @@ static const unsigned int vin3_clk_mux[] = {
};
static const struct {
- struct sh_pfc_pin_group common[289];
+ struct sh_pfc_pin_group common[290];
struct sh_pfc_pin_group automotive[1];
} pinmux_groups = {
.common = {
@@ -4193,6 +4200,7 @@ static const struct {
SH_PFC_PIN_GROUP(usb0),
SH_PFC_PIN_GROUP(usb0_ovc_vbus),
SH_PFC_PIN_GROUP(usb1),
+ SH_PFC_PIN_GROUP(usb1_pwen),
SH_PFC_PIN_GROUP(usb2),
VIN_DATA_PIN_GROUP(vin0_data, 24),
VIN_DATA_PIN_GROUP(vin0_data, 20),
@@ -4640,6 +4648,7 @@ static const char * const usb0_groups[] = {
static const char * const usb1_groups[] = {
"usb1",
+ "usb1_pwen",
};
static const char * const usb2_groups[] = {
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: r8a7742-iwg21d-q7: Enable HSUSB, USB2.0 and xHCI
From: Lad Prabhakar @ 2020-07-17 17:00 UTC (permalink / raw)
To: Geert Uytterhoeven, Rob Herring, Linus Walleij, devicetree
Cc: Magnus Damm, linux-renesas-soc, linux-kernel, linux-gpio,
Prabhakar, Lad Prabhakar
In-Reply-To: <1595005225-11519-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Enable support for HSUSB, USB2.0 and xHCI on iWave RZ/G1H carrier board.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
---
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 42 +++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
index e90aaf1c94f0..f4910e709b87 100644
--- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
+++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
@@ -131,6 +131,30 @@
};
};
+&hsusb {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&pci0 {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+ /* Disable hsusb to enable USB2.0 host mode support on J2 */
+ /* status = "okay"; */
+};
+
+&pci1 {
+ pinctrl-0 = <&usb1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&pci2 {
+ /* Disable xhci to enable USB2.0 host mode support on J23 bottom port */
+ /* status = "okay"; */
+};
+
&pfc {
avb_pins: avb {
groups = "avb_mdio", "avb_gmii";
@@ -168,6 +192,16 @@
groups = "ssi34_ctrl", "ssi3_data", "ssi4_data";
function = "ssi";
};
+
+ usb0_pins: usb0 {
+ groups = "usb0";
+ function = "usb0";
+ };
+
+ usb1_pins: usb1 {
+ groups = "usb1_pwen";
+ function = "usb1";
+ };
};
&rcar_sound {
@@ -222,3 +256,11 @@
&ssi4 {
shared-pin;
};
+
+&usbphy {
+ status = "okay";
+};
+
+&xhci {
+ status = "okay";
+};
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 1/3] gpio: mxc: Support module build
From: Mark Brown @ 2020-07-17 15:36 UTC (permalink / raw)
To: Greg KH
Cc: Arnd Bergmann, Catalin Marinas, Linus Walleij, Bjorn Andersson,
oleksandr.suvorov@toradex.com, Fabio Estevam, Anson Huang,
Jon Corbet, Will Deacon, Olof Johansson, Russell King,
Bartosz Golaszewski, Andreas Kemnade, Geert Uytterhoeven,
dl-linux-imx, Sascha Hauer, open list:GPIO SUBSYSTEM, John Stultz,
Adam Ford, Linux ARM, linux-kernel@vger.kernel.org, Leo Li,
Vinod Koul, Sascha Hauer, Kevin Hilman, hverkuil-cisco@xs4all.nl,
Shawn Guo
In-Reply-To: <20200717141344.GA2992942@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]
On Fri, Jul 17, 2020 at 04:13:44PM +0200, Greg KH wrote:
> On Fri, Jul 17, 2020 at 03:54:49PM +0200, Arnd Bergmann wrote:
> > > And look at the driver core work for many driver subsystems to be fixed
> > > up just to get a single kernel image to work on multiple platforms.
> > > Just because older ones did it, doesn't mean it actually works today :)
> > Can you give a specific example? The only problem I'm aware of for
> > those SoCs is drivers being outside of the mainline kernel. Clearly
> > having support for loadable modules helps SoC vendors because it
> > allows them to support a new platform with an existing binary kernel
> > by shipping third-party driver modules, but for stuff that is already
> > in mainline, we could in theory support all hardware in a single gigantic
> > binary kernel with no support for loadable modules at all.
> That did not work for many drivers for some reason, look at all the work
> Saravana had to do in the driver core and device tree code for it to
> happen correctly over the past year.
Could you be more specific about these issues? I'm aware of his work
around probe ordering but that's not at all arch specific, the same
issues affect every architecture, so doesn't seem to be what you're
talking about.
arm64 has never supported anything other than a multiplatform kernel,
and the actively maintained 32 bit platforms have supported one for more
than half a decade at this point. CI systems keep managing to test
these kernels, distributions seem to keep managing to ship them and
users appear able to install and use them so it doesn't seem quite so
fundamentally broken as all that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] gpio: wcove: Use irqchip template
From: Linus Walleij @ 2020-07-17 15:19 UTC (permalink / raw)
To: linux-gpio
Cc: Bartosz Golaszewski, Linus Walleij, Bin Gao, Andy Shevchenko,
Hans de Goede
This makes the driver use the irqchip template to assign
properties to the gpio_irq_chip instead of using the
explicit calls to gpiochip_irqchip_add_nested() and
gpiochip_set_nested_irqchip(). The irqchip is instead
added while adding the gpiochip.
Cc: Bin Gao <bin.gao@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Same notices as on the Crystalcove: this one I actually
managed to compiletest properly.
---
drivers/gpio/gpio-wcove.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-wcove.c b/drivers/gpio/gpio-wcove.c
index 8b481b3c1ebe..135645096575 100644
--- a/drivers/gpio/gpio-wcove.c
+++ b/drivers/gpio/gpio-wcove.c
@@ -400,6 +400,7 @@ static int wcove_gpio_probe(struct platform_device *pdev)
struct wcove_gpio *wg;
int virq, ret, irq;
struct device *dev;
+ struct gpio_irq_chip *girq;
/*
* This gpio platform device is created by a mfd device (see
@@ -442,19 +443,6 @@ static int wcove_gpio_probe(struct platform_device *pdev)
wg->dev = dev;
wg->regmap = pmic->regmap;
- ret = devm_gpiochip_add_data(dev, &wg->chip, wg);
- if (ret) {
- dev_err(dev, "Failed to add gpiochip: %d\n", ret);
- return ret;
- }
-
- ret = gpiochip_irqchip_add_nested(&wg->chip, &wcove_irqchip, 0,
- handle_simple_irq, IRQ_TYPE_NONE);
- if (ret) {
- dev_err(dev, "Failed to add irqchip: %d\n", ret);
- return ret;
- }
-
virq = regmap_irq_get_virq(wg->regmap_irq_chip, irq);
if (virq < 0) {
dev_err(dev, "Failed to get virq by irq %d\n", irq);
@@ -468,7 +456,21 @@ static int wcove_gpio_probe(struct platform_device *pdev)
return ret;
}
- gpiochip_set_nested_irqchip(&wg->chip, &wcove_irqchip, virq);
+ girq = &wg->chip.irq;
+ girq->chip = &wcove_irqchip;
+ /* This will let us handle the parent IRQ in the driver */
+ girq->parent_handler = NULL;
+ girq->num_parents = 0;
+ girq->parents = NULL;
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->handler = handle_simple_irq;
+ girq->threaded = true;
+
+ ret = devm_gpiochip_add_data(dev, &wg->chip, wg);
+ if (ret) {
+ dev_err(dev, "Failed to add gpiochip: %d\n", ret);
+ return ret;
+ }
/* Enable GPIO0 interrupts */
ret = regmap_update_bits(wg->regmap, IRQ_MASK_BASE, GPIO_IRQ0_MASK,
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v2] gpio: omap: handle pin config bias flags
From: Andy Shevchenko @ 2020-07-17 15:15 UTC (permalink / raw)
To: Drew Fustini
Cc: Tony Lindgren, Haojian Zhuang, Grygorii Strashko, Linus Walleij,
Linux OMAP Mailing List, open list:GPIO SUBSYSTEM, Jason Kridner,
Robert Nelson
In-Reply-To: <20200715213738.1640030-1-drew@beagleboard.org>
On Thu, Jul 16, 2020 at 12:38 AM Drew Fustini <drew@beagleboard.org> wrote:
>
> Modify omap_gpio_set_config() to handle pin config bias flags by calling
> gpiochip_generic_config().
>
> The pin group for the gpio line must have the corresponding pinconf
> properties:
>
> PIN_CONFIG_BIAS_PULL_UP requires "pinctrl-single,bias-pullup"
> PIN_CONFIG_BIAS_PULL_DOWN requires "pinctrl-single,bias-pulldown"
>
> This is necessary for pcs_pinconf_set() to find the requested bias
> parameter in the PIN_MAP_TYPE_CONFIGS_GROUP pinctrl map.
...
> + if ((pinconf_to_config_param(config) == PIN_CONFIG_BIAS_DISABLE) ||
> + (pinconf_to_config_param(config) == PIN_CONFIG_BIAS_PULL_UP) ||
> + (pinconf_to_config_param(config) == PIN_CONFIG_BIAS_PULL_DOWN))
> + {
> + ret = gpiochip_generic_config(chip, offset, config);
> + }
> + else if (pinconf_to_config_param(config) == PIN_CONFIG_INPUT_DEBOUNCE)
> + {
> + debounce = pinconf_to_config_argument(config);
> + ret = omap_gpio_debounce(chip, offset, debounce);
> + }
It's a rather strange indentation of the curly braces. Don't you run checkpatch?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] pinctrl: single: print gpio number in pins debugfs file
From: Andy Shevchenko @ 2020-07-17 15:14 UTC (permalink / raw)
To: Drew Fustini
Cc: Tony Lindgren, Haojian Zhuang, Linus Walleij,
Linux OMAP Mailing List, open list:GPIO SUBSYSTEM, Jason Kridner,
Robert Nelson
In-Reply-To: <20200717013338.1741659-1-drew@beagleboard.org>
On Fri, Jul 17, 2020 at 4:36 AM Drew Fustini <drew@beagleboard.org> wrote:
>
> If there is a gpio range mapping for the pin, then print out the gpio
> number for the pin in the debugfs 'pins' file.
>
> Here is an example on the BeagleBone Black:
> pin 0 (PIN0) 44e10800 00000027 pinctrl-single GPIO-32
> pin 1 (PIN1) 44e10804 00000027 pinctrl-single GPIO-33
> pin 2 (PIN2) 44e10808 00000027 pinctrl-single GPIO-34
> pin 3 (PIN3) 44e1080c 00000027 pinctrl-single GPIO-35
> pin 4 (PIN4) 44e10810 00000027 pinctrl-single GPIO-36
> pin 5 (PIN5) 44e10814 00000027 pinctrl-single GPIO-37
> pin 6 (PIN6) 44e10818 00000027 pinctrl-single GPIO-38
> pin 7 (PIN7) 44e1081c 00000027 pinctrl-single GPIO-39
> pin 8 (PIN8) 44e10820 00000027 pinctrl-single GPIO-22
> pin 9 (PIN9) 44e10824 00000030 pinctrl-single GPIO-23
Wouldn't it be better to have this for all types of pin controllers?
But I'm not sure about the format of output.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: gpiolib gpio_chrdev_release duration is about 30 ms
From: Andy Shevchenko @ 2020-07-17 15:07 UTC (permalink / raw)
To: Maxim Kochetkov
Cc: Linus Walleij, open list:GPIO SUBSYSTEM, Bartosz Golaszewski
In-Reply-To: <190bca20-946f-52f9-64f8-8971da17d38b@inbox.ru>
On Fri, Jul 17, 2020 at 5:17 PM Maxim Kochetkov <fido_max@inbox.ru> wrote:
>
> I need a small userspace program to do some GPIO magic to communicate
> other hardware like devmem. This program takes about 2,5 seconds just to
> find GPIO lines by name.
>
> replacing synchronize_rcu to synchronize_rcu_expedited in
> atomic_notifier_chain_unregister gives the same boost as removing
> synchronize_rcu
Have you tried to replace an atomic notifier call with a regular one?
IIRC it's still not clear why atomic is used there.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] gpio: pcf857x: Use irqchip template
From: Linus Walleij @ 2020-07-17 14:48 UTC (permalink / raw)
To: linux-gpio
Cc: Bartosz Golaszewski, Linus Walleij, Geert Uytterhoeven,
Anders Darander, Roger Quadros
This makes the driver use the irqchip template to assign
properties to the gpio_irq_chip instead of using the
explicit calls to gpiochip_irqchip_add_nested() and
gpiochip_set_nested_irqchip(). The irqchip is instead
added while adding the gpiochip.
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Anders Darander <anders@chargestorm.se>
Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpio-pcf857x.c | 47 +++++++++++++++++++------------------
1 file changed, 24 insertions(+), 23 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 14fb8f6a1ad2..a2a8d155c75e 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -334,29 +334,19 @@ static int pcf857x_probe(struct i2c_client *client,
gpio->out = ~n_latch;
gpio->status = gpio->out;
- status = devm_gpiochip_add_data(&client->dev, &gpio->chip, gpio);
- if (status < 0)
- goto fail;
-
/* Enable irqchip if we have an interrupt */
if (client->irq) {
- gpio->irqchip.name = "pcf857x",
- gpio->irqchip.irq_enable = pcf857x_irq_enable,
- gpio->irqchip.irq_disable = pcf857x_irq_disable,
- gpio->irqchip.irq_ack = noop,
- gpio->irqchip.irq_mask = noop,
- gpio->irqchip.irq_unmask = noop,
- gpio->irqchip.irq_set_wake = pcf857x_irq_set_wake,
- gpio->irqchip.irq_bus_lock = pcf857x_irq_bus_lock,
- gpio->irqchip.irq_bus_sync_unlock = pcf857x_irq_bus_sync_unlock,
- status = gpiochip_irqchip_add_nested(&gpio->chip,
- &gpio->irqchip,
- 0, handle_level_irq,
- IRQ_TYPE_NONE);
- if (status) {
- dev_err(&client->dev, "cannot add irqchip\n");
- goto fail;
- }
+ struct gpio_irq_chip *girq;
+
+ gpio->irqchip.name = "pcf857x";
+ gpio->irqchip.irq_enable = pcf857x_irq_enable;
+ gpio->irqchip.irq_disable = pcf857x_irq_disable;
+ gpio->irqchip.irq_ack = noop;
+ gpio->irqchip.irq_mask = noop;
+ gpio->irqchip.irq_unmask = noop;
+ gpio->irqchip.irq_set_wake = pcf857x_irq_set_wake;
+ gpio->irqchip.irq_bus_lock = pcf857x_irq_bus_lock;
+ gpio->irqchip.irq_bus_sync_unlock = pcf857x_irq_bus_sync_unlock;
status = devm_request_threaded_irq(&client->dev, client->irq,
NULL, pcf857x_irq, IRQF_ONESHOT |
@@ -365,10 +355,21 @@ static int pcf857x_probe(struct i2c_client *client,
if (status)
goto fail;
- gpiochip_set_nested_irqchip(&gpio->chip, &gpio->irqchip,
- client->irq);
+ girq = &gpio->chip.irq;
+ girq->chip = &gpio->irqchip;
+ /* This will let us handle the parent IRQ in the driver */
+ girq->parent_handler = NULL;
+ girq->num_parents = 0;
+ girq->parents = NULL;
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->handler = handle_level_irq;
+ girq->threaded = true;
}
+ status = devm_gpiochip_add_data(&client->dev, &gpio->chip, gpio);
+ if (status < 0)
+ goto fail;
+
/* Let platform code set up the GPIOs and their users.
* Now is the first time anyone could use them.
*/
--
2.26.2
^ permalink raw reply related
* [PATCH] gpio: pca953x: Use irqchip template
From: Linus Walleij @ 2020-07-17 14:40 UTC (permalink / raw)
To: linux-gpio
Cc: Bartosz Golaszewski, Linus Walleij, Andy Shevchenko, Marek Vasut,
Uwe Kleine-König, Adam Ford, Vignesh Raghavendra
This makes the driver use the irqchip template to assign
properties to the gpio_irq_chip instead of using the
explicit calls to gpiochip_irqchip_add_nested() and
gpiochip_set_nested_irqchip(). The irqchip is instead
added while adding the gpiochip.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpio-pca953x.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 9c90cf3aac5a..ab22152bf3e8 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -834,6 +834,7 @@ static int pca953x_irq_setup(struct pca953x_chip *chip, int irq_base)
struct irq_chip *irq_chip = &chip->irq_chip;
DECLARE_BITMAP(reg_direction, MAX_LINE);
DECLARE_BITMAP(irq_stat, MAX_LINE);
+ struct gpio_irq_chip *girq;
int ret;
if (dmi_first_match(pca953x_dmi_acpi_irq_info)) {
@@ -883,16 +884,16 @@ static int pca953x_irq_setup(struct pca953x_chip *chip, int irq_base)
irq_chip->irq_set_type = pca953x_irq_set_type;
irq_chip->irq_shutdown = pca953x_irq_shutdown;
- ret = gpiochip_irqchip_add_nested(&chip->gpio_chip, irq_chip,
- irq_base, handle_simple_irq,
- IRQ_TYPE_NONE);
- if (ret) {
- dev_err(&client->dev,
- "could not connect irqchip to gpiochip\n");
- return ret;
- }
-
- gpiochip_set_nested_irqchip(&chip->gpio_chip, irq_chip, client->irq);
+ girq = &chip->gpio_chip.irq;
+ girq->chip = irq_chip;
+ /* This will let us handle the parent IRQ in the driver */
+ girq->parent_handler = NULL;
+ girq->num_parents = 0;
+ girq->parents = NULL;
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->handler = handle_simple_irq;
+ girq->threaded = true;
+ girq->first = irq_base; /* FIXME: get rid of this */
return 0;
}
@@ -1080,11 +1081,11 @@ static int pca953x_probe(struct i2c_client *client,
if (ret)
goto err_exit;
- ret = devm_gpiochip_add_data(&client->dev, &chip->gpio_chip, chip);
+ ret = pca953x_irq_setup(chip, irq_base);
if (ret)
goto err_exit;
- ret = pca953x_irq_setup(chip, irq_base);
+ ret = devm_gpiochip_add_data(&client->dev, &chip->gpio_chip, chip);
if (ret)
goto err_exit;
--
2.26.2
^ 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