From: Bjorn Andersson <firstname.lastname@example.org> To: Saravana Kannan <email@example.com> Cc: John Stultz <firstname.lastname@example.org>, lkml <email@example.com>, Catalin Marinas <firstname.lastname@example.org>, Will Deacon <email@example.com>, Andy Gross <firstname.lastname@example.org>, Joerg Roedel <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, Marc Zyngier <email@example.com>, Linus Walleij <firstname.lastname@example.org>, Vinod Koul <email@example.com>, Kalle Valo <firstname.lastname@example.org>, Maulik Shah <email@example.com>, Todd Kjos <firstname.lastname@example.org>, Greg Kroah-Hartman <email@example.com>, linux-arm-msm <firstname.lastname@example.org>, "email@example.com:IOMMU DRIVERS <firstname.lastname@example.org>, Joerg Roedel <email@example.com>," <firstname.lastname@example.org>, "open list:GPIO SUBSYSTEM" <email@example.com>, Android Kernel Team <firstname.lastname@example.org> Subject: Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module Date: Wed, 21 Jul 2021 15:13:08 -0500 [thread overview] Message-ID: <YPh/1IN1A9BixMrw@yoga> (raw) In-Reply-To: <CAGETcx90xNFzEB9yfWvLg=X+ptrgNaQg9Ncxi-U_Z0vXHrUcgw@mail.gmail.com> On Mon 19 Jul 16:53 CDT 2021, Saravana Kannan wrote: > On Mon, Jul 19, 2021 at 12:36 PM Bjorn Andersson > <email@example.com> wrote: > > > > On Mon 19 Jul 14:00 CDT 2021, John Stultz wrote: > > > > > On Fri, Jul 16, 2021 at 10:01 PM Bjorn Andersson > > > <firstname.lastname@example.org> wrote: > > > > On Tue 06 Jul 23:53 CDT 2021, John Stultz wrote: > > > > > Allow the qcom_scm driver to be loadable as a permenent module. > > > > > > > > > > This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to > > > > > ensure that drivers that call into the qcom_scm driver are > > > > > also built as modules. While not ideal in some cases its the > > > > > only safe way I can find to avoid build errors without having > > > > > those drivers select QCOM_SCM and have to force it on (as > > > > > QCOM_SCM=n can be valid for those drivers). > > > > > > > > > > Reviving this now that Saravana's fw_devlink defaults to on, > > > > > which should avoid loading troubles seen before. > > > > > > > > > > > > > Are you (in this last paragraph) saying that all those who have been > > > > burnt by fw_devlink during the last months and therefor run with it > > > > disabled will have a less fun experience once this is merged? > > > > > > Bjorn, > > I jump in and help with any reports of issues with fw_devlink if I'm > cc'ed. Please feel free to add me and I'll help fix any issues you > have with fw_devlink=on. > Thanks Saravana, unfortunately I've only heard these reports second hand so far, not been able to reproduce them on my own. I appreciate your support and will certainly reach out if I need some assistance. > > > > > > I guess potentially. So way back when this was originally submitted, > > > some folks had trouble booting if it was set as a module due to it > > > loading due to the deferred_probe_timeout expiring. > > > My attempts to change the default timeout value to be larger ran into > > > trouble, but Saravana's fw_devlink does manage to resolve things > > > properly for this case. > > > > > > > Unfortunately I see really weird things coming out of that, e.g. display > > on my db845c is waiting for the USB hub on PCIe to load its firmware, > > which typically times out after 60 seconds. > > > > I've stared at it quite a bit and I don't understand how they are > > related. > > Can you please add me to any email thread with the details? I'd be > happy to help. > > First step is to make sure all the devices probe as with > fw_devlink=permissive. After that if you are still seeing issues, it's > generally timing issues in the driver. But if the actual timing issue > is identified (by you or whoever knows the driver seeing the issue), > then I can help with fixes or suggestions for fixes. > > > > But if folks are having issues w/ fw_devlink, and have it disabled, > > > and set QCOM_SCM=m they could still trip over the issue with the > > > timeout firing before it is loaded (especially if they are loading > > > modules from late mounted storage rather than ramdisk). > > > > > > > I guess we'll have to force QCOM_SCM=y in the defconfig and hope people > > don't make it =m. > > > > > > (I'm picking this up, but I don't fancy the idea that some people are > > > > turning the boot process into a lottery) > > > > > > Me neither, and I definitely think the deferred_probe_timeout logic is > > > way too fragile, which is why I'm eager for fw_devlink as it's a much > > > less racy approach to handling module loading dependencies. > > > > Right, deferred_probe_timeout is the main issue here. Without it we > > might get some weird probe deferral runs, but either some driver is > > missing or it settles eventually. > > > > With deferred_probe_timeout it's rather common for me to see things > > end up probe out of order (even more now with fw_devlink finding cyclic > > dependencies) and deferred_probe_timeout just breaking things. > > Again, please CC me on these threads and I'd be happy to help. > > > > > > So if you > > > want to hold on this, while any remaining fw_devlink issues get > > > sorted, that's fine. But I'd also not cast too much ire at > > > fw_devlink, as the global probe timeout approach for handling optional > > > links isn't great, and we need a better solution. > > > > > > > There's no end to the possible and valid ways you can setup your > > defconfig and run into the probe deferral issues, so I see no point in > > holding this one back any longer. I just hope that one day it will be > > possible to boot the upstream kernel in a reliable fashion. > > Might not be believable, but I'm hoping fw_devlink helps you meet this goal :) > Sounds good, I hope so too :) Regards, Bjorn
next prev parent reply other threads:[~2021-07-21 20:13 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-07 4:53 John Stultz 2021-07-17 5:01 ` Bjorn Andersson 2021-07-19 19:00 ` John Stultz 2021-07-19 19:36 ` Bjorn Andersson 2021-07-19 21:53 ` Saravana Kannan 2021-07-21 20:13 ` Bjorn Andersson [this message] 2021-07-21 11:54 ` Greg Kroah-Hartman 2021-07-21 17:24 ` John Stultz 2021-07-21 18:00 ` Saravana Kannan 2021-07-21 20:23 ` Bjorn Andersson 2021-07-21 21:07 ` Saravana Kannan 2021-07-23 14:24 ` Bjorn Andersson 2021-07-23 12:21 ` Greg Kroah-Hartman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YPh/1IN1A9BixMrw@yoga \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).