linux-kernel - Re: [PATCH v4 1/2] drivers: bus: simple-pm-bus: Add support for probing simple bus only 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: <CAGETcx_YEUxEBSBnzFaBxW=9=jO6BO0GuThaMGF+JPkDeC-ivw@mail.gmail.com>
Date:   Mon, 31 Jan 2022 21:30:09 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Kevin Hilman <khilman@...libre.com>
Cc:     Russell King <linux@...linux.org.uk>,
        Neil Armstrong <narmstrong@...libre.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        Tony Lindgren <tony@...mide.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Damien Le Moal <damien.lemoal@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>, kernel-team@...roid.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-oxnas@...ups.io, linux-renesas-soc@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v4 1/2] drivers: bus: simple-pm-bus: Add support for
 probing simple bus only devices

On Mon, Jan 31, 2022 at 7:18 PM Kevin Hilman <khilman@...libre.com> wrote:
>
> Hi Saravana,
>
> Saravana Kannan <saravanak@...gle.com> writes:
>
> > fw_devlink could end up creating device links for bus only devices.
> > However, bus only devices don't get probed and can block probe() or
> > sync_state() [1] call backs of other devices. To avoid this, probe these
> > devices using the simple-pm-bus driver.
> >
> > However, there are instances of devices that are not simple buses (they get
> > probed by their specific drivers) that also list the "simple-bus" (or other
> > bus only compatible strings) in their compatible property to automatically
> > populate their child devices. We still want these devices to get probed by
> > their specific drivers. So, we make sure this driver only probes devices
> > that are only buses.
> >
> > [1] - https://lore.kernel.org/lkml/CAPDyKFo9Bxremkb1dDrr4OcXSpE0keVze94Cm=zrkOVxHHxBmQ@mail.gmail.com/
> > Fixes: c442a0d18744 ("driver core: Set fw_devlink to "permissive" behavior by default")
> > Signed-off-by: Saravana Kannan <saravanak@...gle.com>
> > Tested-by: Saravana Kannan <saravanak@...gle.com>
> > Tested-by: Ulf Hansson <ulf.hansson@...aro.org>
>
> This patch landed in stable/linux-5.10.y as commit d5f13bbb5104 and it
> broke suspend/resume on at least one TI AM335x board I'm testing on:
> upstream dts: arch/arm/boot/dts/am335x-icev2.dts, upstream defconfig:
> arch/arm/configs/omap2plus_defconfig.
>
> Bisecting between vanilla v5.10 (good) and stable/linux-5.10.y (bad)
> pointed me to this patch, and I confirmed that reverting just this patch
> on top of stable/linux-5.10.y makes it work again.
>
> Also interesting, this same platform works fine on vanilla v5.15, which
> also includes this patch.  That suggests that either 1) this patch
> should not have been backported to v5.10 stable or 2) there are some
> other dependencies that are missing in v5.10.
>
> Since vanilla v5.10 works fine, I'm leaning towards (1), but if you have
> any ideas for deps that need backporting, I'm happy to try.

Oh wow! I didn't realize I made so many changes AFTER 5.10! Unless I'm
doing something wrong with my git commands.
$ git log v5.10..v5.15 --oneline -- drivers/of/property.c
$ git log v5.10..v5.15 --oneline --author=saravanak -- drivers/base/

If you don't think I got my git command completely wrong, yeah, way
too many patches are missing on 5.10. I'd go with the option of
dropping this patch on 5.10.

> I haven't debugged exactly where it's hanging yet, but, enabling
> CONFIG_DEBUG_DRIVER=y, and suspending with "no_console_suspend" on the
> command line, the last line before it hangs is:
>
>    [   28.129966] simple-pm-bus ocp: noirq power domain suspend
>
> Any ideas?

I'd guess it's either a sync_state() happening too soon since some of
the dependencies aren't tracked. Or some dependency cycle that'd be
handled correctly if the rest of the patches were picked up. Yeah, a
pretty broad/vague answer.

-Saravana