Messages in this thread | | | From | Saravana Kannan <> | Date | Wed, 1 Mar 2023 10:00:14 -0800 | Subject | Re: Raspberry Pi 4B: Failed to create device link with soc:firmware:gpio |
| |
On Wed, Mar 1, 2023 at 8:57 AM Stefan Wahren <stefan.wahren@i2se.com> wrote: > > 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@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). > 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).
Sigh... this is the connection I needed.
> > 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 > > 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
Definitely! Thanks!
Florian, don't bother with the rest of my debug request. I think I know what's going on. I'll come back if I need more help.
-Saravana
> > > 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@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
| |