Thread (25 messages) read the whole thread 25 messages, 8 authors, 2022-02-02

Re: [PATCH v4 2/2] drivers: bus: Delete CONFIG_SIMPLE_PM_BUS

From: Saravana Kannan <hidden>
Date: 2021-10-26 00:30:42
Also in: linux-arm-kernel, linux-renesas-soc, linux-riscv, lkml

On Fri, Oct 22, 2021 at 10:00 AM Amit Pundir [off-list ref] wrote:
On Fri, 22 Oct 2021 at 05:13, Saravana Kannan [off-list ref] wrote:
quoted
On Thu, Oct 21, 2021 at 4:21 AM Amit Pundir [off-list ref] wrote:
quoted
Hi Saravana,

This patch broke v5.15-rc6 on RB5 (sm8250 | qcom/qrb5165-rb5.dts).
I can't boot past this point https://www.irccloud.com/pastebin/raw/Nv6ZwHmW.
Amit top posting? How did that happen? :)

The fact you are seeing this issue is super strange though. The driver
literally does nothing other than allowing some sync_state() callbacks
to happen. I also grepped for the occurence of "simple-bus" in
arch/arm64/boot/dts/qcom/ and the only instance for 8250 is for the
soc node.

The only thing I can think of is that without my patch some
sync_state() callbacks weren't getting called and maybe it was masking
some other issue.

Can you try to boot with this log (see log patch below) and see if the
device hangs right after a sync_state() callback? Also, looking at the
different sync_state() implementations in upstream, I'm guessing one
of the devices isn't voting for interconnect bandwidth when it should
have.

Another thing you could do is boot without the simple-bus changes and
then look for all instances of "state_synced" in /sys/devices and then
see if any of them has the value "0" after boot up is complete.
Turned out RB5 is not even reaching up to
device_links_flush_sync_list() and seem to be stuck somewhere in
device_links_driver_bound(). So I added more print logs to narrow down
to any specific lock state but those additional prints seem to have
added enough delay to unblock that particular driver (Serial:
8250/16550 driver if I understood the logs correctly) and I eventually
booted to UI.
Ugh... I think I know what's going on. It popped into my head over the weekend.

Couple of ways to confirm my theory:
1. After it finishes booting in both cases, can you compare the output
of the command below? I'm expecting to see a significant drop in the
number of device links.
ls -l /sys/class/devlink | wc -l

2. Can you try out this terrible hack patch (not final fix, no code
reviews please) on top of Tot to see if it fixes your issue without
having to add hacky logs?

Thanks,
Saravana
--- a/drivers/bus/simple-pm-bus.c
+++ b/drivers/bus/simple-pm-bus.c
@@ -38,10 +38,12 @@ static int simple_pm_bus_probe(struct platform_device *pdev)
         * a device that has a more specific driver.
         */
        if (match && match->data) {
-               if (of_property_match_string(np, "compatible",
match->compatible) == 0)
+               if (of_property_match_string(np, "compatible",
match->compatible) == 0) {
+                       of_platform_populate(np, NULL, lookup, &pdev->dev);
                        return 0;
-               else
+               } else {
                        return -ENODEV;
+               }
        }
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help