linux-kernel - Re: [PATCH v2 2/2] irqchip: add driver for imx-irqsteer controller

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: <6a863d56-de66-c00e-ebb0-cf00fda2773f@arm.com>
Date:   Mon, 17 Dec 2018 14:41:52 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Lucas Stach <l.stach@...gutronix.de>
Cc:     Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org,
        Jason Cooper <jason@...edaemon.net>,
        linux-kernel@...r.kernel.org, patchwork-lst@...gutronix.de,
        Rob Herring <robh+dt@...nel.org>, kernel@...gutronix.de,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 2/2] irqchip: add driver for imx-irqsteer controller

On 17/12/2018 13:52, Lucas Stach wrote:
> Am Montag, den 17.12.2018, 10:32 +0000 schrieb Marc Zyngier:
> [...]
>> OK, this is now making sense, thanks for that. I'm wondering if it'd
>> make sense to expose both IRQs in the DT for each irqsteer, and use
>> fsl,channel as the selector? It doesn't change much in the driver, but
>> seems to describe the HW in a more complete way.
>>
>> I don't care much either way, and I'll leave it for you and the DT folks
>> to decide.
> 
> At least according to the preliminary documentation available about the
> i.MX8QM not all of the channels are routed to an upstream IRQ which is
> visible to the Linux system. Some of them may also go to the Cortex-M
> subsystem, so for your suggestion to work I would need a scheme to
> describe the output interrupts with holes in between them.
> 
> I guess that complicates things a bit too much for little gain, as I
> don't see us switching the controller between different channels at
> runtime (which is the only thing I could imagine which would benefit
> from this more complete HW description). The current binding can deal
> with having some channels which route to something invisible to the
> Linux system just fine, so I'm leaning toward keeping things as they
> are now.

Fair enough. I'll freeze the tree tomorrow, so if you want this into
4.21, now is the time.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...