Message-ID: <465a444d-3edb-e6ae-3505-59be9f7509c2@i2se.com>
Date:   Wed, 1 Mar 2023 17:57:41 +0100
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Saravana Kannan <saravanak@...gle.com>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: Raspberry Pi 4B: Failed to create device link with
 soc:firmware:gpio

Hi Saravana,

Am 01.03.23 um 08:49 schrieb Saravana Kannan:
> On Sun, Feb 26, 2023 at 11:14 AM Florian Fainelli <f.fainelli@...il.com> wrote:
>>
>>
>> On 2/25/2023 5:58 PM, Florian Fainelli wrote:
>>>
>>> On 2/25/2023 4:01 PM, Saravana Kannan wrote:
>>>> On Sat, Feb 25, 2023 at 7:38 AM Florian Fainelli
>>>> <f.fainelli@...il.com> wrote:
>>>>> Hi Saravana,
>>>>>
>>>>> Using v6.2-10217-ga93e884edf61v my Raspberry Pi 4B issues the following
>>>>> for the "extended GPIO" provider:
>>>>>
>>>>> [    5.969855] uart-pl011 fe201000.serial: Failed to create device link
>>>>> with soc:firmware:gpio
>>>> Outside of this error, is it actually breaking anything?
>>> There is just this warning, there does not appear to be a functional issue.
>>>
>>>> Also, can you
>>>> pull in this patch and tell me what it says? I want to know what the
>>>> flags are.
>>>> https://lore.kernel.org/lkml/20230225064148.274376-1-saravanak@google.com/
>> Pulling in this patch results in the following being printed:
>>
>> [   14.866835] uart-pl011 fe201000.serial: Failed to create device link
>> (0x180) with soc:firmware:gpio
> I spent at least 2 hours looking at the logs and the DT files and I'm
> still kinda lost.
>
> The 0x180 means it's a DL_FLAG_INFERRED | DL_FLAG_SYNC_STATE_ONLY.
> That's just fw_devlink trying to create a "proxy" link where an
> ancestor of a consumer (can be several levels above consumer) creates
> a SYNC_STATE_ONLY link to the supplier while we wait for the consumer
> device to get added. This prevents sync_state() from being called too
> early on the supplier.
>
> There are so many includes in the dts/dtsi files that my head is
> spinning. I finally found out where the soc:firmware:gpio device was
> coming from (after confusing myself with gpio@...00000 for a bit) and
> where fe201000.serial was coming from. I still couldn't figure out how
> the address got mapped to fe201000 in fe201000.serial -- that
> generally means the parent has some address offset, but I don't see
> that in DT (but it is not important for this discussion, so we can
> ignore that).
This is uart0 which is at first defined in bcm283x.dtsi. On the 
Raspberry Pi 4 this UART is connected to the Bluetooth IC. On Linux 
probing of the serial communication via DT is done via serial device bus 
(see bcm283x-rpi-wifi-bt.dtsi).
> Anyway, I see no supplier-consumer link between serial@...01000 (or
> any of its zero descendants) and soc:firmware:gpio (which is the node
> expgpio:). So I'm very confused why we might even try to create this
> sync state only device link between these two.
>
> There are actually two times where we try to create such a link:
>
> First attempt that actually succeeds -- but I have no idea why we even do this:
> [    0.100047] device:
> 'platform:soc:firmware:gpio--amba:fe201000.serial': device_add
> [    0.100232] amba fe201000.serial: Linked as a sync state only
> consumer to soc:firmware:gpio

I assume the link is established by raspberry,firmware-gpio which 
provides the necessary BT shutdown-gpios defined in bcm2711-rpi-4-b.dts. 
Seems to me that the problem is, that necessary underlying firmware 
driver is probed "too late":

[ 15.456506] raspberrypi-firmware soc:firmware: Attached to firmware 
from 2020-02-12T12:36:21

Hope this helps a little bit

> the "amba" prefix tells us a driver hasn't been bound to fe201000.serial yet.
>
> Second attempt is the one that fails.
> [   15.516166] uart-pl011 fe201000.serial: Failed to create device
> link (0x180) with soc:firmware:gpio
> The uart-pl011 tells us that the driver has bound to fe201000.serial.
>
> And it fails because of this sensible check I had put up a while ago
> inside device_link_add():
>          /*
>           * SYNC_STATE_ONLY links are useless once a consumer device
> has probed.
>           * So, only create it if the consumer hasn't probed yet.
>           */
>          if (flags & DL_FLAG_SYNC_STATE_ONLY &&
>              consumer->links.status != DL_DEV_NO_DRIVER &&
>              consumer->links.status != DL_DEV_PROBING) {
>                  link = NULL;
>                  goto out;
>          }
>
> So the real question is still to figure out why fw_devlink is trying
> to create this device link.
>
> So to debug this further the following would help a lot:
> 1. Pull the dtb from the device and then decompile it and provide me
> the result. This way, I can be sure I'm not missing something and
> don't have to dig through all the includes -- I forgot the exact
> commands for it, but it's been shared in LKML before. Let me know if
> you need me to dig this up.
>
> 2. I think a stack backtrace when these two device link attempts are
> made might help me figure out why they are being created. To get these
> backtraces, can you do the following please?
> a. Put a WARN_ON() inside device_add() for when the device name matches:
> platform:soc:firmware:gpio--amba:fe201000.serial
> b. Put a WARN_ON(1) where we print "Failed to create device link..."
>
> Feel free to dig more into 2a and 2b if you find that the stack trace
> doesn't tell much -- one problem with the stack trace is that it
> doesn't show the params being passed to
> __fw_devlink_link_to_consumers() and __fw_devlink_link_to_suppliers()
>
> Thanks,
> Saravana
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists