On Wed 21 Jul 13:00 CDT 2021, Saravana Kannan wrote: > On Wed, Jul 21, 2021 at 10:24 AM John Stultz <john.stultz@xxxxxxxxxx> wrote: > > > > On Wed, Jul 21, 2021 at 4:54 AM Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, Jul 07, 2021 at 04:53:20AM +0000, John Stultz wrote: > > > > Allow the qcom_scm driver to be loadable as a permenent module. > > > > > > This feels like a regression, it should be allowed to be a module. > > > > I'm sorry, I'm not sure I'm following you, Greg. This patch is trying > > to enable the driver to be able to be loaded as a module. > > I think the mix up might be that Greg mentally read "permanent module" > as "builtin"? > > "permanent module" is just something that can't be unloaded once it's > loaded. It's not "builtin". > Afaict there's nothing in this patch that makes it more or less permanent. The module will be quite permanent (in practice) because several other core modules reference symbols in the qcom_scm module. But thanks to a previous patch, the qcom_scm device comes with suppress_bind_attrs, to prevent that the device goes away from a simple unbind operation - which the API and client drivers aren't designed to handle. So, it would have been better in this case to omit the word "permanent" from the commit message, but the change is good and I don't want to rebase my tree to drop that word. Thanks, Bjorn > -Saravana > > > > > > > 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. > > > > > > fw_devlink was supposed to resolve these issues and _allow_ code to be > > > built as modules and not forced to be built into the kernel. > > > > Right. I'm re-submitting this patch to enable a driver to work as a > > module, because earlier attempts to submit it ran into boot trouble > > because fw_devlink wasn't yet enabled. > > > > I worry something in my description made it seem otherwise, so let me > > know how you read it and I'll try to avoid such confusion in the > > future. > > > > thanks > > -john
