linux-kernel - Re: [PATCH RESEND] driver core: export device_is

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: <X7Zut1JGd+9yET2W@kroah.com>
Date:   Thu, 19 Nov 2020 14:10:15 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Aisheng Dong <aisheng.dong@....com>
Cc:     Saravana Kannan <saravanak@...gle.com>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Stephen Boyd <sboyd@...nel.org>
Subject: Re: [PATCH RESEND] driver core: export device_is_bound() to fix
 build failure

On Thu, Nov 19, 2020 at 04:13:34AM +0000, Aisheng Dong wrote:
> > Long story short, either
> > 
> > * Don't care about the power domain in your clock driver.
> > 
> > Or,
> > 
> > * List the power domain in the clock controller's DT node and then use the
> > normal APIs to get the power domain. And defer like any other driver if you
> > can't get the power domain.
> > 
> 
> Yes, I understand those are for normal cases. But our case is a bit different and we don't want
> imx_clk_scu() API return PROBE_DEFER which is unnecessary for a hundred of clocks. 
> Even we want to defer probe, we prefer to defer in imx_clk_scu_init() rather than in imx_clk_scu().

What is wrong with PROBE_DEFER, that is what it is there for.

> Maybe the things can be simplified as a simple requirement:
> How users can make Driver A (CLK) to be probed after Driver B (PD) without explicit
> firmware function dependency description (e.g. phandle in DT)?
> 
> As kernel core does not want to support it, then the left way may be change scu-pd driver
> Inicall level or provide a private callback to query the readiness.

No, do not mess with that, as it totally breaks when things are built as
a module.

Rely on the deferred probing, that is what it was designed for, and it
should not take very long at all, and it keeps you from having to dig
into the driver core in ways that no one else has to.

Please just fix up your DT file (sorry I didn't know ordering wouldn't
solve this), and you should be fine.

thanks,

greg k-h