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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAhV-H7KDgWR0p3jaVSDhAeXtM0Aj-86N1NtK7bEZLScQ8ux9Q@mail.gmail.com>
Date: Sun, 24 Aug 2025 22:41:39 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Yao Zi <ziyao@...root.org>
Cc: Yinbo Zhu <zhuyinbo@...ngson.cn>, Linus Walleij <linus.walleij@...aro.org>, 
	Bartosz Golaszewski <brgl@...ev.pl>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	WANG Xuerui <kernel@...0n.name>, Philipp Zabel <p.zabel@...gutronix.de>, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	loongarch@...ts.linux.dev, Mingcong Bai <jeffbai@...c.io>, 
	Kexy Biscuit <kexybiscuit@...c.io>
Subject: Re: [PATCH 1/3] dt-bindings: gpio: loongson: Document GPIO controller
 of 2K0300 SoC

On Sun, Aug 17, 2025 at 12:08 AM Yao Zi <ziyao@...root.org> wrote:
>
> On Sat, Aug 16, 2025 at 10:18:57PM +0800, Huacai Chen wrote:
> > On Sat, Aug 16, 2025 at 11:51 AM Yao Zi <ziyao@...root.org> wrote:
> > >
> > > Loongson 2K0300 ships a GPIO controller whose input/output control logic
> > > is similar to previous generation of SoCs. Additionally, it acts as an
> > > interrupt-controller supporting both level and edge interrupts and has a
> > > distinct reset signal.
> > >
> > > Describe its compatible in devicetree. We enlarge the maximum value of
> > > ngpios to 128, since the controller technically supports at most 128
> > > pins, although only 106 are routed out of the package. Properties for
> > > interrupt-controllers and resets are introduced and limited as 2K0300
> > > only.
> > >
> > > Signed-off-by: Yao Zi <ziyao@...root.org>
> > > ---
> > >  .../bindings/gpio/loongson,ls-gpio.yaml       | 28 ++++++++++++++++++-
> > >  1 file changed, 27 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml
> > > index b68159600e2b..69852444df23 100644
> > > --- a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml
> > > +++ b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml
> > > @@ -14,6 +14,7 @@ properties:
> > >      oneOf:
> > >        - enum:
> > >            - loongson,ls2k-gpio
> > > +          - loongson,ls2k0300-gpio
> > >            - loongson,ls2k0500-gpio0
> > >            - loongson,ls2k0500-gpio1
> > >            - loongson,ls2k2000-gpio0
> > > @@ -36,7 +37,7 @@ properties:
> > >
> > >    ngpios:
> > >      minimum: 1
> > > -    maximum: 64
> > > +    maximum: 128
> > >
> > >    "#gpio-cells":
> > >      const: 2
> > > @@ -49,6 +50,14 @@ properties:
> > >      minItems: 1
> > >      maxItems: 64
> > >
> > > +  "#interrupt-cells":
> > > +    const: 2
> > > +
> > > +  interrupt-controller: true
> > ls2k300 supports interrupt-controller while others don't?
>
> For these SoCs' GPIO controllers (I didn't carefully check 3A{5,6}00 and
> 7A{1,2}00), there're three different cases,
>
> 1. Controller of 2K0500, 2K1000:
>
>    These controllers have only interrupt enable bits for each GPIO.
>    Interrupts are routed directly to the parent interrupt controller and
>    there're multiple pins share the same interrupt in the parent, e.g.,
>    GPIO 0-31 share interrupt 26 of the second liointc on 2K0500.
>
>    Since we have neither an interrupt status register nor interrupt ack
>    bits, it's hard to tell which GPIO line is triggering the interrupt.
>    And we even cannot configure the polarity/edge for triggering
>    interrupts, thus I don't think these GPIO controller should be
>    described as interrupt controllers.
>
>    For these controllers, gpio-loongson-64bit.c implements GPIO
>    controller's .to_irq() method which translates GPIO descriptor to
>    corresponding IRQ number. This should work as long as there's at most
>    one interrupt consumer for each group of GPIOs that share the same
>    parent interrupt line.
>
> 2. Node controller of 2K1500 and 2K2000:
>
>    These SoCs have GPIO controllers directly attached to the "node" (I
>    think it means the CPU core, but am not sure). These controllers are
>    similar to the first class, but they have an additional feature that
>    the polarity for triggering interrupts could be configured.
>
>    Still we couldn't precisely tell which GPIO line is triggering the
>    interrupt, thus it's hard to implement it as a fully-functional
>    irqchip, either. But if we don't do so, I cannot come up with a way
>    to describe the polarity settings. I'm unsure whether these
>    controllers should be implemented as interrupt controllers.
>
> 3. South-bridge controller of 2K1500 and 2K2000, and 2K0300's
>    controller:
>
>    Reading through the public TRM, I'm sure these're all fully
>    functional interrupt controllers, and should be implemented as
>    interrupt controllers.
>
>    However, this also means the current binding for 2K1500/2K2000's
>    south-bridge controller is WRONG, and a fix it seems to bring in ABI
>    breakages (interrupt-controller/interrupt-cells are a must). But
>    since I don't have these devices on hand, and they are at least not
>    related to the situation of 2K0300, I decided to keep them as-is.
>
> So the answer to the original question is, no, at least 2K1500/2K2000's
> south-bridge GPIO controllers are also interrupt controllers according
> to their public documentation. But I cannot test my GPIO changes against
> them since I don't have such boards, and fixing the binding up may break
> the ABI, thus I leave them as-is in this "support for 2K0300" series.
Then I think more SOCs rather than LS2K0300 support
interrupt-controller. Though the driver is not support yet, they can
be improved later (of course unnecessary in this series), so in my
opinion just keep the dt-binding in the same file is reasonable.


Huacai

>
> > Huacai
>
> Best regards,
> Yao Zi
>
> > > +
> > > +  resets:
> > > +    maxItems: 1
> > > +
> > >  required:
> > >    - compatible
> > >    - reg
> > > @@ -58,6 +67,23 @@ required:
> > >    - gpio-ranges
> > >    - interrupts
> > >
> > > +allOf:
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          contains:
> > > +            const: loongson,ls2k0300-gpio
> > > +    then:
> > > +      required:
> > > +        - "#interrupt-cells"
> > > +        - interrupt-controller
> > > +        - resets
> > > +    else:
> > > +      properties:
> > > +        "#interrupts-cells": false
> > > +        interrupt-controller: false
> > > +        resets: false
> > > +
> > >  additionalProperties: false
> > >
> > >  examples:
> > > --
> > > 2.50.1
> > >

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ