linux-kernel - Re: [PATCH 2/2] gpio: add support for GPIO controller on Siflower SoCs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdb4bMFqV+hfAHuUvLezyCA8PTE+SQOpYzh_y1JXzDHLvw@mail.gmail.com>
Date: Fri, 27 Dec 2024 17:51:49 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Chuanhong Guo <gch981213@...il.com>
Cc: linux-gpio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Bartosz Golaszewski <brgl@...ev.pl>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Philipp Zabel <p.zabel@...gutronix.de>, Qingfang Deng <qingfang.deng@...lower.com.cn>
Subject: Re: [PATCH 2/2] gpio: add support for GPIO controller on Siflower SoCs

Hi Chuanhong,

thanks for your patch!

I think it is better to split the driver instances into 4, one for each
physical block, as explained in the binding patch.

On Wed, Dec 25, 2024 at 4:59 AM Chuanhong Guo <gch981213@...il.com> wrote:

> From: Qingfang Deng <qingfang.deng@...lower.com.cn>
>
> Add a driver for the GPIO controller on Siflower SoCs.
> This controller is found on all current Siflower MIPS and RISC-V
> chips including SF19A2890, SF21A6826 and SF21H8898.
>
> Signed-off-by: Qingfang Deng <qingfang.deng@...lower.com.cn>
> Signed-off-by: Chuanhong Guo <gch981213@...il.com>

> +config GPIO_SIFLOWER
> +       tristate "SiFlower GPIO support"
> +       depends on OF_GPIO
> +       depends on MIPS || RISCV || COMPILE_TEST
> +       select GPIOLIB_IRQCHIP

select GPIO_GENERIC

As you have only a set of 32-bit registers to handle for each
instance, then some IRQs on top, you can untilize the MMIO
library.

> +#define GPIO_IR(n)     (0x40 * (n) + 0x00)
> +#define GPIO_OR(n)     (0x40 * (n) + 0x04)
> +#define GPIO_OEN(n)    (0x40 * (n) + 0x08)
> +#define GPIO_IMR(n)    (0x40 * (n) + 0x0c)
> +#define GPIO_GPIMR(n)  (0x40 * (n) + 0x10)
> +#define GPIO_PIR(n)    (0x40 * (n) + 0x14)
> +#define GPIO_ITR(n)    (0x40 * (n) + 0x18)
> +#define GPIO_IFR(n)    (0x40 * (n) + 0x1c)
> +#define GPIO_ICR(n)    (0x40 * (n) + 0x20)
> +#define GPIO_GPxIR(n)  (0x4 * (n) + 0x4000)

Just define GPIO_IR 0, GPIO_OR 4, etc.

Look up the GPIO_GPIR register separately from the
device tree and use it without offset.

Always register 16 GPIO lines unless ngpios is set.

Look at example drivers such as
drivers/gpio/gpio-pl061.c
drivers/gpio/gpio-ftgpio010.c
on how to use the MMIO helper library to implement
a simple driver for one instance reusing the common code.

You will also get implementations for get/set_multiple()
for free with this approach, as the library implements
them!

Yours,
Linus Walleij