linux-kernel - Re: [PATCH v3 1/3] dt-bindings: gpio: spacemit: add support for K1 SoC

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: <CACRpkdZPD2C2iPwOX_kW1Ug8jVkdHhhc7iFycHtzj5LQ0XWNgQ@mail.gmail.com>
Date: Fri, 27 Dec 2024 17:34:36 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Yixun Lan <dlan@...too.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Conor Dooley <conor@...nel.org>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Yangyu Chen <cyy@...self.name>, 
	Jisheng Zhang <jszhang@...nel.org>, Jesse Taube <mr.bossman075@...il.com>, 
	Inochi Amaoto <inochiama@...look.com>, Icenowy Zheng <uwu@...nowy.me>, 
	Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v3 1/3] dt-bindings: gpio: spacemit: add support for K1 SoC

On Wed, Dec 25, 2024 at 1:33 AM Yixun Lan <dlan@...too.org> wrote:

> The GPIO controller of K1 support basic functions as input/output,
> all pins can be used as interrupt which route to one IRQ line,
> trigger type can be select between rising edge, failing edge, or both.
> There are four GPIO banks, each consisting of 32 pins.
(...)
> +description:
> +  The controller's registers are organized as sets of eight 32-bit
> +  registers with each set controlling a bank of up to 32 pins.  A single
> +  interrupt is shared for all of the banks handled by the controller.

I looked at the driver and came to the conclusion that it's better to use
4 different instances of the chip, one for each set of 32bit registers,
so these 4 GPIO controllers are instantiated separately.

The operating system can handle the shared interrupt, there is no
need to use a single device instance just because the interrupt is
shared.

DT bindings are operating system neutral, but for example in Linux
(if we pretend this is just one possible example) then a driver
handling a shared IRQ can be requested with the flag IRQF_SHARED
and the driver can just return IRQ_HANDLED if it handled an IRQ
or IRQ_NONE if it didn't handle the irq (so other instances can
handle it).

Yours,
Linus Walleij