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] [thread-next>] [day] [month] [year] [list]
Message-ID: <4360c54bccf9c5a34052d1ad2b7eb049@kernel.org>
Date:   Wed, 20 Jan 2021 10:04:25 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Saravana Kannan <saravanak@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Kevin Hilman <khilman@...libre.com>,
        Android Kernel Team <kernel-team@...roid.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] of: property: Add device link support for interrupts

On 2021-01-20 09:53, Geert Uytterhoeven wrote:
> Hi Saravana,
> 
> On Fri, Dec 18, 2020 at 10:11 PM Saravana Kannan <saravanak@...gle.com> 
> wrote:
>> Add support for creating device links out of interrupts property.
>> 
>> Cc: Marc Zyngier <maz@...nel.org>
>> Cc: Kevin Hilman <khilman@...libre.com>
>> Signed-off-by: Saravana Kannan <saravanak@...gle.com>
> 
> Thanks for your patch!
> 
> This does not seem to add all links.  I see links being created to the
> secondary interrupt controller (e61c0000 "renesas,irqc"), but not to
> the primary interrupt controller (GIC)
> 
> Which is good, as the GIC driver is not a platform_driver, and thus
> creating links would break everything ;-)
> 
> BTW, I'd _love_ the GIC driver to be a platform_driver, as the GIC is
> part of a power/and or clock domain on Renesas SoCs...

The trouble is that we need the GIC much earlier than the device model
is available, because the timer needs to be available super early.
This isn't specific to the GIC, by the way, but also to all root
interrupt controllers that end-up controlling the per-CPU interrupts.

If you try to relax this constraint, you'll end up observing some of the
very weird dependencies between sysfs, sched, and the device model (I 
went
there a few years back, wasted a week on it, did a reset --hard on the 
branch,
and swore never to look at this again! ;-)

But for a start, I'd like the ITS code to be turned into a platform 
driver,
as this would potentially allow for the various domains to be 
instantiated
dynamically. One day.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ