linux-kernel - Re: Regression in probing some AMBA devices possibly devlink related

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:   Sat, 25 Feb 2023 15:55:39 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: Regression in probing some AMBA devices possibly devlink related

On Sat, Feb 25, 2023 at 6:29 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> Hi Saravana,
>
> I have a boot regression for Ux500 on mainline, but bisecting mainline
> isn't quite working for misc reasons :/
>
> I'm not sure about this regression, but it smells like devlink-related.
>
> Ux500 have a bunch of normal and some AMBA devices. After
> boot this happens and we hang waiting for rootfs (which is on eMMC):

Hmmm... my recent changes were definitely tested on systems with AMBA
devices and it worked.

> [   31.849586] amba 80126000.mmc: deferred probe pending
> [   31.854801] amba 80118000.mmc: deferred probe pending
> [   31.859895] amba 80005000.mmc: deferred probe pending
> [   31.870297] amba 80120000.uart: deferred probe pending
> [   31.875472] amba 80121000.uart: deferred probe pending
> [   31.880689] amba 80004000.i2c: deferred probe pending
> [   31.885799] amba 80128000.i2c: deferred probe pending
> [   31.890932] amba 80110000.i2c: deferred probe pending
> [   51.688361] vmem_3v3: disabling

What does /debug/devices_deferred say about these? That should tell us
exactly what's blocking it.

Also if you convert all the pr_debug and dev_dbg in
drivers/base/core.c that should give us enough of an idea of what's
happening. Can you do that too and send it as an attachment (I logs
are hard to read when they get word wrapped)?

> The last regulator (vmem_3v3) is something the eMMC that didn't
> probe was supposed to use.
>
> All the failing drivers are AMBA PrimeCell devices:
> drivers/mmc/host/mmci.c
> drivers/tty/serial/amba-pl011.c
> drivers/i2c/busses/i2c-nomadik.c
>
> This makes me suspect something was done for ordinary (platform)
> devices that didn't happen for AMBA devices?
>
> This is the main portion of the device tree containing these
> devices and their resources:
> arch/arm/boot/dts/ste-dbx5x0.dtsi

I'll take a closer look on Monday. Btw, I always prefer the dts file
because there's always some property that adds a dependency and that
might be the clue to whatever is broken. But I'll take a look at this.

It's unlikely the patch attached might fix it, but can you give it a shot?

-Saravana

View attachment "0001-add-class-support-to-device-links.patch" of type "text/x-patch" (1562 bytes)