linux-kernel - Re: [PATCH/RFC] drivers/irqchip: add irq-inverter

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: <87czlez64l.wl-maz@kernel.org>
Date:   Thu, 30 Dec 2021 11:25:46 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Nikita Yushchenko <nikita.yoush@...entembedded.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH/RFC] drivers/irqchip: add irq-inverter

On Thu, 30 Dec 2021 10:53:30 +0000,
Nikita Yushchenko <nikita.yoush@...entembedded.com> wrote:
> 
> >>>>> The right way to do it is to use the existing API by exposing the
> >>>>> inverter (there are existing examples in the tree, using the
> >>>>> hierarchical model)...
> >>> 
> >>> A much simpler version can be written in a few minutes, see below...
> >> 
> >> Can something like that be used if the parent domain is not
> >> hierarchical (i.e. does not provide alloc(), but provides map()
> >> instead)?
> > 
> > No. This definitely relies on the parent being hierarchical, as that's
> > exactly what it was designed for the first place.
> 
> Is supporting hierarchical API now mandatory for kernel irqchips?

It isn't. But you are definitely giving me some ideas now.

> 
> If yes, then perhaps you can at least document it somewhere?
> E.g. declare irq_domain.map() as deprecated?
> 
> If no, then I'd like to discuss a solution for irq_inverter that can
> work for non-hierarchical case.

You are still missing the point. Any active element on the interrupt
path that changes the signal without multiplexing must be described in
the hierarchical model. Anything else is wrong, and I am not
interested in reinventing that particular wheel (it was painful enough
to kill all these hacks years ago, and I'm not doing it again).

Moving these GPIO chips into the hierarchical model isn't rocket
science, as there is plenty of support for that already, and is the
right thing to do.

	M.

-- 
Without deviation from the norm, progress is not possible.