diff mbox series

[v1] gpio: mt7621: Assign base field in gpio_chip

Message ID 20210613120608.1527394-1-code@reto-schneider.ch (mailing list archive)
State New
Headers show
Series [v1] gpio: mt7621: Assign base field in gpio_chip | expand

Commit Message

Reto Schneider June 13, 2021, 12:06 p.m. UTC
From: Reto Schneider <reto.schneider@husqvarnagroup.com>

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 <reto.schneider@husqvarnagroup.com>

---

 drivers/gpio/gpio-mt7621.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Reto Schneider June 13, 2021, 3:51 p.m. UTC | #1
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
Linus Walleij June 13, 2021, 11:24 p.m. UTC | #2
On Sun, Jun 13, 2021 at 5:51 PM Reto Schneider <code@reto-schneider.ch> 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
Reto Schneider June 13, 2021, 11:57 p.m. UTC | #3
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
diff mbox series

Patch

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",