linux-kernel - Re: [PATCH v4] amba: Remove deferred device addition

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]

Date:   Tue, 19 Jul 2022 14:33:40 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Marek Szyprowski <m.szyprowski@...sung.com>,
        Russell King <linux@...linux.org.uk>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Sudeep Holla <sudeep.holla@....com>,
        Rob Herring <robh@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        kernel-team@...roid.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] amba: Remove deferred device addition

On Mon, Jul 18, 2022 at 06:51:29PM -0700, Saravana Kannan wrote:
> On Tue, Jul 12, 2022 at 11:53 PM Marek Szyprowski
> <m.szyprowski@...sung.com> wrote:

[..]

> Longer explanation follows:
> 
> 5a46079a9645 ("PM: domains: Delete usage of
> driver_deferred_probe_check_state()") correctly assumed fw_devlink
> will block calls to __genpd_dev_pm_attach() before the power domain
> has probed or we have given up waiting on suppliers at the driver core
> level. So, __genpd_dev_pm_attach() returning -2 was not a problem
> (well, there are other issues, but we'll pretend they don't exist for
> now).
> 
> Until this amba patch, that was true because really_probe() calls
> device_links_check_suppliers() before you'll get anywhere near
> __genpd_dev_pm_attach().
>

Last time I started looking at this patch, I was suspecting some issue
around __genpd_dev_pm_attach() but your explanation makes sense to me
now and I am more or less convinced this was what happening on Juno.

> But with this amba patch, we try to get power domains before we get to
> really_probe() and that doesn't get the device links check. So,
> amba_match() has to always return -EPROBE_DEFER on any error until we
> optimize out match() calls for devices whose suppliers aren't ready
> yet. I'm considering reverting 5a46079a9645 due to other issues, so I
> think v4 might be okay as is.
>

OK, do I need to check with 5a46079a9645 reverted then ?

-- 
Regards,
Sudeep