linux-kernel - Re: [PATCH V2 13/14] dt-bindings: arm-gic: Add documentation for Tegra210 AGIC

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: <CAMuHMdVbDrD2_yun14iSPYx=Wn93g=g535L=mHwGX=4bF-1tSg@mail.gmail.com>
Date:	Wed, 27 Apr 2016 20:02:51 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Jon Hunter <jonathanh@...dia.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <marc.zyngier@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Kevin Hilman <khilman@...nel.org>,
	Grygorii Strashko <grygorii.strashko@...com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-tegra@...r.kernel.org,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 13/14] dt-bindings: arm-gic: Add documentation for
 Tegra210 AGIC

On Wed, Apr 27, 2016 at 7:38 PM, Mark Rutland <mark.rutland@....com> wrote:
> On Wed, Apr 27, 2016 at 04:34:53PM +0100, Jon Hunter wrote:
>> On 22/04/16 12:22, Mark Rutland wrote:
>> [snip]
>>
>> >>>> I am not sure if it will be popular to add Tegra specific clock names
>> >>>> to the GIC DT docs. However, in that case, then possibly the only
>> >>>> alternative is to move the Tegra AGIC driver into its own file and
>> >>>> expose the GIC APIs for it to use. Then we could add our own DT doc
>> >>>> for the Tegra AGIC as well (based upon the ARM GIC).
>> >>>
>> >>> The clock-names don't seem right to me, as they sound like provide names
>> >>> or global clock line names rather than consumer-side names ("clk" and
>> >>> "apb_pclk").
>> >>
>> >> Yes that would be fine with me.
>> >
>> > Ok; if we model the apb_pclk as owned by the AXI switch (which it is),
>> > then there's no change for the GIC binding, short of the additional
>> > compatible string as an extension of "arm,gic-400", as we already model
>> > that clock in the GIC-400 binding.
>>
>> I have been re-working this based upon the feedback received. In the GIC
>> driver we have the following definitions ...
>>
>>  IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);
>>  IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", gic_of_init);
>>  IRQCHIP_DECLARE(arm1176jzf_dc_gic, "arm,arm1176jzf-devchip-gic", gic_of_init);
>>  IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
>>  IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
>>  IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
>>  IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
>>  IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
>>  IRQCHIP_DECLARE(pl390, "arm,pl390", gic_of_init);
>>
>>
>> If I have something like the following in my dts ...
>>
>>       agic: interrupt-controller@...f9000 {
>>               compatible = "nvidia,tegra210-agic", "arm,gic-400";
>>               ...
>>       };
>>
>> The problem with this is that it tries to register the interrupt controller
>> early during of_irq_init() before the platform driver has chance to
>> initialise it.
>
> Probe order strikes again...
>
>> To avoid this I got rid of the "nvidia,tegra210-agic" string and added
>> the following for the platform driver ...
>>
>> static const struct of_device_id gic_match[] = {
>>        { .compatible = "arm,arm11mp-gic-pm",    .data = &arm11mp_gic_data   },
>>        { .compatible = "arm,cortex-a15-gic-pm", .data = &cortexa15_gic_data },
>>        { .compatible = "arm,cortex-a9-gic-pm",  .data = &cortexa9_gic_data  },
>>        { .compatible = "arm,gic400-pm",         .data = &gic400_data        },
>>        { .compatible = "arm,pl390-pm",          .data = &pl390_data         },
>>        {},
>> };
>>
>> It is not ideal as now we have a *-pm variant of each compatible string :-(
>
> Yeah, that's a non-starter. :(
>
>> Another option would be to add some code in gic_of_init() to check for the
>> presence of a "clocks" node in the DT binding and bail out of the early
>> initialisation if found but may be that is a bit of a hack.

Or the presence of a power-domains property...

> I fear that someone may validly have a clocks property in their root GIC
> node, at which point things would fall apart. I was under the impression
> this was the case for some Renesas boards (though I didn't find an
> example in tree).

We don't have the GIC clocks in the GIC nodes yet, as there's no suitable
mechanism (e.g. CLK_ENABLE_HAND_OFF) in upstream yet to prevent them
from being disabled ("unused" clocks are disabled).

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