Messages in this thread | | | From | Saravana Kannan <> | Date | Tue, 28 Feb 2023 23:49:21 -0800 | Subject | Re: Raspberry Pi 4B: Failed to create device link with soc:firmware:gpio |
| |
On Sun, Feb 26, 2023 at 11:14 AM Florian Fainelli <f.fainelli@gmail.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@gmail.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@7e200000 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).
Anyway, I see no supplier-consumer link between serial@7e201000 (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 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
| |