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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAL_JsqLas2mi-kTrEY=9vnopU57qwJNDtvui0erMghfG4-pOZw@mail.gmail.com>
Date:   Thu, 26 Mar 2020 09:02:32 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>,
        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 <liviu.dudau@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Jon Hunter <jonathanh@...dia.com>,
        Pawel Moll <pawel.moll@....com>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [tip: timers/core] clocksource/drivers/timer-probe: Avoid
 creating dead devices

On Thu, Mar 26, 2020 at 4:34 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> 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.

IMO, commit 4f41fe386a946 should be reverted and be done with it.
There's no way the timer core can know whether a specific node should
be scanned or not. If you really want to avoid a struct device, then
set OF_POPULATED in specific timer drivers. But I'd rather not see
more places mucking with OF_POPULATED. It's really only bus code that
should be touching it.

Is having a struct device really a problem? If we want to save memory
usage, I have some ideas that would save much more than 1 or 2 struct
devices.

> 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?

The issue is DT nodes and Linux drivers aren't necessarily 1-1. That
would be nice, but hardware is messy and DT doesn't abstract that
away. If we tried to always make things 1-1, then if/when the Linux
driver structure changes we'd have to change the DT. If we decided to
add a node now, we'd still have to support the old DT for backwards
compatibility. We also have to consider the structure for another OS
may be different.

Generally, if I see a node with a compatible only it gets NAKed as
that's a sure sign of someone just trying to bind a driver and not
describing the h/w. We only do MFD sub-devices if those devices
provide or consume other DT resources.

Rob