From: John Stultz <john.stultz@linaro.org> To: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: lkml <linux-kernel@vger.kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Andy Gross <agross@kernel.org>, Joerg Roedel <joro@8bytes.org>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <maz@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Vinod Koul <vkoul@kernel.org>, Kalle Valo <kvalo@codeaurora.org>, Maulik Shah <mkshah@codeaurora.org>, Saravana Kannan <saravanak@google.com>, Todd Kjos <tkjos@google.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, "list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>," <iommu@lists.linux-foundation.org>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org> Subject: Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module Date: Mon, 19 Jul 2021 12:00:05 -0700 [thread overview] Message-ID: <CALAqxLUzTNiA7u=4_y9pkrh=Q_+vpPgFrhf_6F8-U0XPQU9crQ@mail.gmail.com> (raw) In-Reply-To: <YPJkF21ItYlKODyq@yoga> On Fri, Jul 16, 2021 at 10:01 PM Bjorn Andersson <bjorn.andersson@linaro.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? > 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. 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'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. 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. thanks -john
WARNING: multiple messages have this Message-ID (diff)
From: John Stultz <john.stultz@linaro.org> To: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Maulik Shah <mkshah@codeaurora.org>, Saravana Kannan <saravanak@google.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Catalin Marinas <catalin.marinas@arm.com>, lkml <linux-kernel@vger.kernel.org>, "list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, " <iommu@lists.linux-foundation.org>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, Vinod Koul <vkoul@kernel.org>, Andy Gross <agross@kernel.org>, Marc Zyngier <maz@kernel.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Will Deacon <will@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Kalle Valo <kvalo@codeaurora.org>, Todd Kjos <tkjos@google.com> Subject: Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module Date: Mon, 19 Jul 2021 12:00:05 -0700 [thread overview] Message-ID: <CALAqxLUzTNiA7u=4_y9pkrh=Q_+vpPgFrhf_6F8-U0XPQU9crQ@mail.gmail.com> (raw) In-Reply-To: <YPJkF21ItYlKODyq@yoga> On Fri, Jul 16, 2021 at 10:01 PM Bjorn Andersson <bjorn.andersson@linaro.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? > 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. 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'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. 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. thanks -john _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-07-19 20:18 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-07 4:53 [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module John Stultz 2021-07-07 4:53 ` John Stultz 2021-07-17 5:01 ` Bjorn Andersson 2021-07-17 5:01 ` Bjorn Andersson 2021-07-19 19:00 ` John Stultz [this message] 2021-07-19 19:00 ` John Stultz 2021-07-19 19:36 ` Bjorn Andersson 2021-07-19 19:36 ` Bjorn Andersson 2021-07-19 21:53 ` Saravana Kannan 2021-07-19 21:53 ` Saravana Kannan via iommu 2021-07-21 20:13 ` Bjorn Andersson 2021-07-21 20:13 ` Bjorn Andersson 2021-07-21 11:54 ` Greg Kroah-Hartman 2021-07-21 11:54 ` Greg Kroah-Hartman 2021-07-21 17:24 ` John Stultz 2021-07-21 17:24 ` John Stultz 2021-07-21 18:00 ` Saravana Kannan 2021-07-21 18:00 ` Saravana Kannan via iommu 2021-07-21 20:23 ` Bjorn Andersson 2021-07-21 20:23 ` Bjorn Andersson 2021-07-21 21:07 ` Saravana Kannan 2021-07-21 21:07 ` Saravana Kannan via iommu 2021-07-23 14:24 ` Bjorn Andersson 2021-07-23 14:24 ` Bjorn Andersson 2021-07-23 12:21 ` Greg Kroah-Hartman 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='CALAqxLUzTNiA7u=4_y9pkrh=Q_+vpPgFrhf_6F8-U0XPQU9crQ@mail.gmail.com' \ --to=john.stultz@linaro.org \ --cc=agross@kernel.org \ --cc=bjorn.andersson@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=gregkh@linuxfoundation.org \ --cc=iommu@lists.linux-foundation.org \ --cc=joro@8bytes.org \ --cc=kvalo@codeaurora.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maz@kernel.org \ --cc=mkshah@codeaurora.org \ --cc=saravanak@google.com \ --cc=tglx@linutronix.de \ --cc=tkjos@google.com \ --cc=vkoul@kernel.org \ --cc=will@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.