Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [tip: timers/core] clocksource/drivers/timer-probe: Avoid creating dead devices | Date | Thu, 26 Mar 2020 11:33:56 +0100 |
| |
Saravana Kannan <saravanak@google.com> writes: > On Wed, Mar 25, 2020 at 2:47 PM Thomas Gleixner <tglx@linutronix.de> wrote: > >> Saravana Kannan <saravanak@google.com> writes: >> > On Tue, Mar 24, 2020 at 11:34 AM Saravana Kannan <saravanak@google.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
| |