Regression in probing some AMBA devices possibly devlink related

[Saravana Kannan]

On Sat, Feb 25, 2023 at 6:29 AM Linus Walleij <linus.walleij at linaro.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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-class-support-to-device-links.patch
Type: text/x-patch
Size: 1562 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230225/84d0077f/attachment.bin>