linux-kernel - Re: [PATCH v2 05/11] mfd: pm8xxx: disassociate old virq if hwirq mapping already exists

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: <CACRpkdbFQ2B7AvVW38etdsq-R38p5uX7eMrD2oKxTtDE3_W5aA@mail.gmail.com>
Date:   Fri, 22 Feb 2019 10:07:44 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     Stephen Boyd <sboyd@...nel.org>,
        Brian Masney <masneyb@...tation.org>,
        Andy Gross <andy.gross@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Doug Anderson <dianders@...omium.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Nicolas Dechesne <nicolas.dechesne@...aro.org>,
        Niklas Cassel <niklas.cassel@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        linux-arm-msm@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 05/11] mfd: pm8xxx: disassociate old virq if hwirq
 mapping already exists

On Fri, Feb 22, 2019 at 9:57 AM Marc Zyngier <marc.zyngier@....com> wrote:

> To be honest, I'd like to make progress on that too, if only to put
> something in core code so that individual drivers don't have to play
> that kind of game.

I am trying to pull hierarchical IRQ into the gpiolib core by refactoring
based on these and some other patches (like the IXP4xx GPIO driver).

I am working under the assumptions of what compatible strings
indicating the hierarchy topology and hard coded ranges of
offsets from parent to child in the driver only associated with
the compatible string, so no IRQ range mapping in the device
tree.

AFAICT that is how hierarchical irqdomain is engineered as of
today.

Yours,
Linus Walleij