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] [day] [month] [year] [list]
Message-ID: <CAMuHMdUV-179XEVF9UMdiB6p_2gQeWJKz+25qCfn+b_h8VSdcQ@mail.gmail.com>
Date:   Fri, 24 Apr 2020 10:36:14 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Eugeniu Rosca <erosca@...adit-jv.com>
Cc:     Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Marek Vasut <marek.vasut+renesas@...il.com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Biju Das <biju.das@...renesas.com>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Chris Paterson <chris.paterson2@...esas.com>,
        Yusuke Ashiduka <ashiduka@...itsu.com>,
        Torii Kenichi <torii.ken1@...fujitsu.com>,
        Fukui Yohhei <yohhei.fukui@...so-ten.com>,
        Yasushi Asano <yasano@...adit-jv.com>,
        Yuichi Kusakabe <yuichi.kusakabe@...so-ten.com>,
        Andrew Gabbasov <andrew_gabbasov@...tor.com>,
        Jiada Wang <jiada_wang@...tor.com>,
        Eugeniu Rosca <rosca.eugeniu@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Stefano Stabellini <sstabellini@...nel.org>
Subject: Re: [RFC PATCH 2/3] gpio: rcar: Add support for GPIO alternative interrupt

Hi Eugeniu,

CC devicetree
CC Stefano

Thanks for forwarding this patch!

On Wed, Apr 22, 2020 at 12:11 PM Eugeniu Rosca <erosca@...adit-jv.com> wrote:
> From: Torii Kenichi <torii.ken1@...fujitsu.com>
>
> INTC-AP accepts both GPIO interrupt and GPIO alternative interrupt,
> but INTC-RT can only handle GPIO interrupt, as depicted in below excerpt
> from 'Figure 7.1 GPIO Block Configuration (1)' of
> 'R-Car3 HW User's Manual Rev.2.00, Jul 2019':
>
>   +------------------------------+
>   | Interrupt  display register  +----> GPIO.ch*  (to INTC-AP, INTC-RT)
>   |           (INTDTn)           +----> GPIO.ch*A (to INTC-AP)
>   +------------------------------+

Note that GPIO.ch[67]A seem to be available on INTC-RT, too. But for
the other channels, you're right in that the "A" variants are connected
to INTC-AP only.

> It seems to be also the case for earlier Renesas SoCs like RZ/G,
> as per 'Figure 6.1 GPIO Block Configuration' in
> 'RZ/G Series User’s Manual: Hardware Rev.1.00 Sep 2016' [1].

On R-Car Gen2, they're called "EXT_INT" resp. "EXT_ALT_INT" instead of
"GPIO.ch*" and "GPIO.ch*A".

> To reduce the interference between RT domain (CR7/SH) and the AP domain
> (Cortex A5x) and to independently control GPIO interrupts in these two
> domains, add support for processing GPIO alternative interrupts in AP.
>
> This allows handling normal GPIO interrupts exclusively by INTC-RT.
> The change is DT-driven and depends on the enablement of the
> 'use-alternative-interrupt' DTS property.
>
> One caveat is that the 'interrupts' property update must go hand in hand
> with the newly added 'use-alternative-interrupt' property.

As I replied to the DT bindings patch, I think the "interrupts" property
should contain both, so "use-alternative-interrupt" can pick the one it
needs.

> Signed-off-by: Torii Kenichi <torii.ken1@...fujitsu.com>
> [erosca: enrich commit description]
> Signed-off-by: Eugeniu Rosca <erosca@...adit-jv.com>

[actual patch[1] deleted, as it doesn't really matter for the discussion].

You may want to look at "LTD20-205 System Device Tree Project"[2],
where Stefano talks about using DT to describe the full system
(I've read the slides, but haven't watched the video yet).

Your patch shows that the assumption "All devices have interrupts routed
to both interrupt controllers" isn't always true.

[1] https://lore.kernel.org/linux-gpio/20200422101026.9220-3-erosca@de.adit-jv.com/
[2] https://connect.linaro.org/resources/ltd20/ltd20-205/

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ