linux-kernel - Re: [tip: timers/core] clocksource/drivers/timer-probe: Avoid creating dead devices

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Mar 2020 11:33:56 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Ionela Voinescu <ionela.voinescu@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-tip-commits@...r.kernel.org, x86 <x86@...nel.org>,
        liviu.dudau@....com, sudeep.holla@....com,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Jon Hunter <jonathanh@...dia.com>,
        Pawel Moll <pawel.moll@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [tip: timers/core] clocksource/drivers/timer-probe: Avoid creating dead devices

Saravana Kannan <saravanak@...gle.com> writes:
> On Wed, Mar 25, 2020 at 2:47 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>
>> Saravana Kannan <saravanak@...gle.com> writes:
>> > On Tue, Mar 24, 2020 at 11:34 AM Saravana Kannan <saravanak@...gle.com> wrote:
>> > I took a closer look. So two different drivers [1] [2] are saying they
>> > know how to handle "arm,vexpress-sysreg" and are expecting to run at
>> > the same time. That seems a bit unusual to me. I wonder if this is a
>> > violation of the device-driver model because this expectation would
>> > never be allowed if these device drivers were actual drivers
>> > registered with driver-core. But that's a discussion for another time.
>> >
>> > To fix this issue you are facing, this patch should work:
>> > https://lore.kernel.org/lkml/20200324195302.203115-1-saravanak@google.com/T/#u
>>
>> Sorry, that's not a fix. That's a crude hack.
>
> If device nodes are being handled by drivers without binding a driver
> to struct devices, then not setting OF_POPULATED is wrong. So the
> original patch sets it. There are also very valid reasons for allowing
> OF_POPULATED to be cleared by a driver as discussed here [1].
>
> The approach of the original patch (setting the flag and letting the
> driver sometimes clear it) is also followed by many other frameworks
> like irq, clk, i2c, etc. Even ingenic-timer.c already does it for the
> exact same reason.
>
> So, why is the vexpress fix a crude hack?

If it's the right thing to do and accepted by the DT folks, then the
changelog should provide a proper explanation for it. The one you
provided just baffles me. Plus the clearing of the flag really needs a
big fat comment.

It still does not make any sense to me.

arm,vexpress-sysreg is a MFD device, so can the ARM people please
explain, why the sched clock part is not just another MFD sub-device or
simply has it's own DT match?

>> As this is also causing trouble on tegra30-cardhu-a04 the only sane
>> solution is to revert it and start over with a proper solution for the
>> vexpress problem and a root cause analysis for the tegra.
>
> If someone can tell me which of the timer drivers are relevant for
> tegra30-cardhu-a04, I can help fix it.

git grep perhaps? And that's pretty much the same problem:

drivers/clocksource/timer-tegra.c:TIMER_OF_DECLARE(tegra20_rtc, "nvidia,tegra20-rtc", tegra20_init_rtc);
drivers/rtc/rtc-tegra.c:        { .compatible = "nvidia,tegra20-rtc", },

Without looking deeper I suspect that these two are not the only ones.

Can the DT folks pretty please comment on this and provide some guidance
how to fix that w/o sprinkling 

    of_node_clear_flag(node, OF_POPULATED);

all over the place?

Thanks,

        tglx