From: Reto Schneider <[email protected]>
This is needed for gpiochip_sysfs_register() to properly export
/sys/class/gpio/gpiochip{0,32,64}.
Without this fix, the field base in gpio_device remains at its
initialization value, which is -1. This causes
gpiochip_add_data_with_key() to call gpiochip_find_base(), which in turn
dynamically determines the base to be at ARCH_NR_GPIOS - 32/64/96,
resulting in gpiochip{480,448,416}.
Detected/fixed/tested on a MediaTek MT7688 based GARDENA smart gateway.
Signed-off-by: Reto Schneider <[email protected]>
---
drivers/gpio/gpio-mt7621.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
index 82fb20dca53a..403d64cd65a6 100644
--- a/drivers/gpio/gpio-mt7621.c
+++ b/drivers/gpio/gpio-mt7621.c
@@ -234,6 +234,7 @@ mediatek_gpio_bank_probe(struct device *dev,
return ret;
}
+ rg->chip.base = rg->bank * MTK_BANK_WIDTH;
rg->chip.of_gpio_n_cells = 2;
rg->chip.of_xlate = mediatek_gpio_xlate;
rg->chip.label = devm_kasprintf(dev, GFP_KERNEL, "%s-bank%d",
--
2.30.2
Hi Andy,
On 13.06.21 14:44, Andy Shevchenko wrote:
> It smells like a fixing non-existing bug. Yes, I understand that there
> is some custom hardware with custom firmware which is using Linux kernel
> with some never upstreamed patches. On top of this sysfs interface is
> deprecated for already a few years and shouldn’t be considered as 1st
> class citizen.
>
> That’s said, if there is no Fixes tag provided with clear point that _at
> some point_ it was like this in upstream, I would tend to NAK this patch.
I did some digging and indeed, it turned out that I used the
pre-mainline GPIO driver from OpenWRT even on Kernel 4.19 (for which the
current driver already got mainlined).
Surely do agree on not breaking the interface in mainline, and the NAK.
Sorry for wasting your time!
Kind regards,
Reto
On Sun, Jun 13, 2021 at 5:51 PM Reto Schneider <[email protected]> wrote:
> I did some digging and indeed, it turned out that I used the
> pre-mainline GPIO driver from OpenWRT even on Kernel 4.19 (for which the
> current driver already got mainlined).
Hm isn't OpenWrt switched to the mainline driver?
Another thing we should do is to add libgpiod to the OpenWrt
base distribution so as to encourage people to use the character
device ABI.
Yours,
Linus Walleij
Hi Linus,
On 14.06.21 01:24, Linus Walleij wrote:
> Hm isn't OpenWrt switched to the mainline driver?
They did, and people are now seeing this "issue" too [1]. Which got me
to post my "fix" [2] and then trying to upstream it here. :)
Kind regards,
Reto
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2020-May/028926.html
[2] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035497.html