Hi,

This patch series introduces a new framework in the form of a driver
probe-control, aimed at addressing the need for deferring the probes
from built-in drivers in kernels where modules are not used.
In such scenario, delaying the initialization of certain devices such
as pcie based devices not needed during boot and giving user the control
on probing these devices post boot, can help reduce overall boot time.
This is achieved without modifying the driver code, simply by configuring
the platform device tree.

This patch series includes 2 patches:

1) dt-binding document for the probe-control driver
   This document explains how device tree of a platform can be configured
   to use probe-control devices for deferring the probes of certain
   devices.

2) probe-control driver implementation
   This provides actual driver implementation along with relevant ABI
   documentation for the sys interfaces that driver provides to the user:
   /sys/kernel/probe_control/trigger - For triggering the probes
   /sys/kernel/debug/probe_control_status - For checking current probe status

TODO:
 * Fix changenotice warning related to MAINTAINERS file update based on
   community feedback for the patches proposed.

Thanks, Nayeem

Nayeemahmed Badebade (2):
  dt-bindings: probe-control: add probe control driver
  driver: core: add probe control driver

 .../ABI/testing/debugfs-probe-control         |  14 +
 .../ABI/testing/sysfs-kernel-probe-control    |  13 +
 .../probe-control/linux,probe-controller.yaml |  59 ++++
 drivers/base/Makefile                         |   1 +
 drivers/base/probe_control.c                  | 275 ++++++++++++++++++
 5 files changed, 362 insertions(+)
 create mode 100644 Documentation/ABI/testing/debugfs-probe-control
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-probe-control
 create mode 100644 Documentation/devicetree/bindings/probe-control/linux,probe-controller.yaml
 create mode 100644 drivers/base/probe_control.c


base-commit: 47ac09b91befbb6a235ab620c32af719f8208399
-- 
2.34.1

On Wed, Sep 11, 2024 at 07:53:17PM +0530, Nayeemahmed Badebade wrote:
> Hi,

If Rob hadn't responded, I wouldn't have noticed these as they ended up
in spam for some reason.  You might want to check your email settings...

> This patch series introduces a new framework in the form of a driver
> probe-control, aimed at addressing the need for deferring the probes
> from built-in drivers in kernels where modules are not used.

Wait, why?

> In such scenario, delaying the initialization of certain devices such
> as pcie based devices not needed during boot and giving user the control
> on probing these devices post boot, can help reduce overall boot time.
> This is achieved without modifying the driver code, simply by configuring
> the platform device tree.

PCI devices should not be on the platform device tree.

And what's wrong with async probing?  That was written for this very
issue.

> This patch series includes 2 patches:
> 
> 1) dt-binding document for the probe-control driver
>    This document explains how device tree of a platform can be configured
>    to use probe-control devices for deferring the probes of certain
>    devices.

But what does that have to do with PCI devices?

> 2) probe-control driver implementation
>    This provides actual driver implementation along with relevant ABI
>    documentation for the sys interfaces that driver provides to the user:
>    /sys/kernel/probe_control/trigger - For triggering the probes

What's wrong with the existing userspace api to trigger a probe again?
Why doesn't that work?

I think you need to explain and prove why the existing apis we have that
were designed to resolve stuff like this don't work.

And if you all are abusing platform drivers and the bus there, well, I
hate to say I told you so, but...

thanks,

greg k-h

Hi Greg,

Thank you for taking the time to check our patch and provide
valuable feedback. We appreciate your comments/suggestions.

Please find our reply to your comments.

On Fri, Sep 13, 2024 at 06:36:38AM +0200, Greg KH wrote:
> On Wed, Sep 11, 2024 at 07:53:17PM +0530, Nayeemahmed Badebade wrote:
> > Hi,
> 
> If Rob hadn't responded, I wouldn't have noticed these as they ended up
> in spam for some reason.  You might want to check your email settings...
> 

I have ensured standard settings which we have been using are used this
time, let me know if this email is received properly.

> > This patch series introduces a new framework in the form of a driver
> > probe-control, aimed at addressing the need for deferring the probes
> > from built-in drivers in kernels where modules are not used.
> 
> Wait, why?
>

We have a scenario where a driver cannot be built as a module and ends up
as a built-in driver. We don't want to probe this driver during boot as its
not required at the time of booting.
Example: drivers/pci/controller/dwc/pci-imx6.c
So the intention is to only postpone some driver probes similar to:
https://elinux.org/Deferred_Initcalls
But instead of delaying initcall execution(which requires initmem to be kept
and not freed during boot) we are trying to delay driver probes as this is
much simpler.
The proposed driver is a generic solution for managing such driver
probes.

> > In such scenario, delaying the initialization of certain devices such
> > as pcie based devices not needed during boot and giving user the control
> > on probing these devices post boot, can help reduce overall boot time.
> > This is achieved without modifying the driver code, simply by configuring
> > the platform device tree.
> 
> PCI devices should not be on the platform device tree.
>

You are right, we are referring to the pci host controller that will be
listed in device tree and skipping its probe during boot as an example
here.

> And what's wrong with async probing?  That was written for this very
> issue.
>

We have explored async probe as an option, but we noticed below:
1) Probe initiated via async
2) Boot continues with other setup.
3) Boot reaches stage where ip configuration is to be done via
   ip_auto_config() and 1) is still in progress, then boot waits for all
   async calls to be completed before proceeding with network setup.
   ip_auto_config()
    -> wait_for_devices()
      -> wait_for_device_probe()
         -> async_synchronize_full()
4) Similar thing happens with rootfs mount step in prepare_namespace()
   initcall

So to avoid getting blocked on these probes which are not required
during boot, we proposed this driver for managing such built-in driver
probes execution.

> > This patch series includes 2 patches:
> > 
> > 1) dt-binding document for the probe-control driver
> >    This document explains how device tree of a platform can be configured
> >    to use probe-control devices for deferring the probes of certain
> >    devices.
> 
> But what does that have to do with PCI devices?

As explained before, the driver is generic one and is for managing probes of
drivers that are built-in.

To delay such probes, in DT we add dummy devices managed by the proposed
driver. These dummy devices(probe control devices) will be setup as
supplier to the device nodes that we want to probe later.
dt-binding doc patch explains this process with pci controller node as
an example that needs to be probed later after the boot.

> 
> > 2) probe-control driver implementation
> >    This provides actual driver implementation along with relevant ABI
> >    documentation for the sys interfaces that driver provides to the user:
> >    /sys/kernel/probe_control/trigger - For triggering the probes
> 
> What's wrong with the existing userspace api to trigger a probe again?
> Why doesn't that work?
> 

The interface is specific to triggering probes of these dummy device
nodes(probe control devices) setup as supplier to device node we want
to probe later.
As multiple probe control devices can be setup in DT, this one common
interface allows triggering of specific probe control device or all
probe control devices.
The probes of these dummy device node return success only when they are
probed like this and existing kernel framework will then probe their
consumers automatically(these are the devices we wanted to probe later
after the boot).

> I think you need to explain and prove why the existing apis we have that
> were designed to resolve stuff like this don't work.
> 
> And if you all are abusing platform drivers and the bus there, well, I
> hate to say I told you so, but...
> 
> thanks,
> 
> greg k-h

We have explained the scenario for which this driver was written and why
existing options such as async probe may not work in such scenario.
Let us know your comments on this.

Thanks,
Nayeem

On Tue, Sep 17, 2024 at 02:36:55PM +0530, Nayeemahmed Badebade wrote:
> Hi Greg,
> 
> Thank you for taking the time to check our patch and provide
> valuable feedback. We appreciate your comments/suggestions.
> 
> Please find our reply to your comments.
> 
> On Fri, Sep 13, 2024 at 06:36:38AM +0200, Greg KH wrote:
> > On Wed, Sep 11, 2024 at 07:53:17PM +0530, Nayeemahmed Badebade wrote:
> > > Hi,
> > 
> > If Rob hadn't responded, I wouldn't have noticed these as they ended up
> > in spam for some reason.  You might want to check your email settings...
> > 
> 
> I have ensured standard settings which we have been using are used this
> time, let me know if this email is received properly.

I got it this time, thanks.

> > > This patch series introduces a new framework in the form of a driver
> > > probe-control, aimed at addressing the need for deferring the probes
> > > from built-in drivers in kernels where modules are not used.
> > 
> > Wait, why?
> >
> 
> We have a scenario where a driver cannot be built as a module and ends up
> as a built-in driver. We don't want to probe this driver during boot as its
> not required at the time of booting.
> Example: drivers/pci/controller/dwc/pci-imx6.c
> So the intention is to only postpone some driver probes similar to:
> https://elinux.org/Deferred_Initcalls
> But instead of delaying initcall execution(which requires initmem to be kept
> and not freed during boot) we are trying to delay driver probes as this is
> much simpler.
> The proposed driver is a generic solution for managing such driver
> probes.

Again, please fix the drivers that are having problems with this, and
build them as a module and load them when you need/want them and can be
probed correctly.

> > > In such scenario, delaying the initialization of certain devices such
> > > as pcie based devices not needed during boot and giving user the control
> > > on probing these devices post boot, can help reduce overall boot time.
> > > This is achieved without modifying the driver code, simply by configuring
> > > the platform device tree.
> > 
> > PCI devices should not be on the platform device tree.
> >
> 
> You are right, we are referring to the pci host controller that will be
> listed in device tree and skipping its probe during boot as an example
> here.

pci host controllers should really be availble at boot time, wow your
hardware is b0rked, sorry.  Just make it a module and load it when you
want/need it.

> > And what's wrong with async probing?  That was written for this very
> > issue.
> >
> 
> We have explored async probe as an option, but we noticed below:
> 1) Probe initiated via async
> 2) Boot continues with other setup.
> 3) Boot reaches stage where ip configuration is to be done via
>    ip_auto_config() and 1) is still in progress, then boot waits for all
>    async calls to be completed before proceeding with network setup.
>    ip_auto_config()
>     -> wait_for_devices()
>       -> wait_for_device_probe()
>          -> async_synchronize_full()
> 4) Similar thing happens with rootfs mount step in prepare_namespace()
>    initcall

Again, if you make the problem driver as a module you should be ok,
right?

> So to avoid getting blocked on these probes which are not required
> during boot, we proposed this driver for managing such built-in driver
> probes execution.

Fix the broken drivers please :)

thanks,

greg k-h

Hi Greg,

Sorry for the delay in our response.
Please find our reply to your comments:

On Tue, Sep 17, 2024 at 12:11:22PM +0200, Greg KH wrote:
> > On Fri, Sep 13, 2024 at 06:36:38AM +0200, Greg KH wrote:
> > > > This patch series introduces a new framework in the form of a driver
> > > > probe-control, aimed at addressing the need for deferring the probes
> > > > from built-in drivers in kernels where modules are not used.
> > > 
> > > Wait, why?
> > >
> > 
> > We have a scenario where a driver cannot be built as a module and ends up
> > as a built-in driver. We don't want to probe this driver during boot as its
> > not required at the time of booting.
> > Example: drivers/pci/controller/dwc/pci-imx6.c
> > So the intention is to only postpone some driver probes similar to:
> > https://elinux.org/Deferred_Initcalls
> > But instead of delaying initcall execution(which requires initmem to be kept
> > and not freed during boot) we are trying to delay driver probes as this is
> > much simpler.
> > The proposed driver is a generic solution for managing such driver
> > probes.
> 
> Again, please fix the drivers that are having problems with this, and
> build them as a module and load them when you need/want them and can be
> probed correctly.
> 

Sure, we will try to do that.

> > > > In such scenario, delaying the initialization of certain devices such
> > > > as pcie based devices not needed during boot and giving user the control
> > > > on probing these devices post boot, can help reduce overall boot time.
> > > > This is achieved without modifying the driver code, simply by configuring
> > > > the platform device tree.
> > > 
> > > PCI devices should not be on the platform device tree.
> > >
> > 
> > You are right, we are referring to the pci host controller that will be
> > listed in device tree and skipping its probe during boot as an example
> > here.
> 
> pci host controllers should really be availble at boot time, wow your
> hardware is b0rked, sorry.  Just make it a module and load it when you
> want/need it.
> 
> > > And what's wrong with async probing?  That was written for this very
> > > issue.
> > >
> > 
> > We have explored async probe as an option, but we noticed below:
> > 1) Probe initiated via async
> > 2) Boot continues with other setup.
> > 3) Boot reaches stage where ip configuration is to be done via
> >    ip_auto_config() and 1) is still in progress, then boot waits for all
> >    async calls to be completed before proceeding with network setup.
> >    ip_auto_config()
> >     -> wait_for_devices()
> >       -> wait_for_device_probe()
> >          -> async_synchronize_full()
> > 4) Similar thing happens with rootfs mount step in prepare_namespace()
> >    initcall
> 
> Again, if you make the problem driver as a module you should be ok,
> right?
> 

Yes.

> > So to avoid getting blocked on these probes which are not required
> > during boot, we proposed this driver for managing such built-in driver
> > probes execution.
> 
> Fix the broken drivers please :)
> 

Sure, we will do that.
Thank you for your feedback.

Regards,
Nayeem

On 17/09/2024 11:06, Nayeemahmed Badebade wrote:
> Hi Greg,
> 
> Thank you for taking the time to check our patch and provide
> valuable feedback. We appreciate your comments/suggestions.
> 
> Please find our reply to your comments.
> 
> On Fri, Sep 13, 2024 at 06:36:38AM +0200, Greg KH wrote:
>> On Wed, Sep 11, 2024 at 07:53:17PM +0530, Nayeemahmed Badebade wrote:
>>> Hi,
>>
>> If Rob hadn't responded, I wouldn't have noticed these as they ended up
>> in spam for some reason.  You might want to check your email settings...
>>
> 
> I have ensured standard settings which we have been using are used this
> time, let me know if this email is received properly.
> 
>>> This patch series introduces a new framework in the form of a driver
>>> probe-control, aimed at addressing the need for deferring the probes
>>> from built-in drivers in kernels where modules are not used.
>>
>> Wait, why?
>>
> 
> We have a scenario where a driver cannot be built as a module and ends up
> as a built-in driver. We don't want to probe this driver during boot as its

Fix this instead.

> not required at the time of booting.
> Example: drivers/pci/controller/dwc/pci-imx6.c
> So the intention is to only postpone some driver probes similar to:
> https://elinux.org/Deferred_Initcalls
> But instead of delaying initcall execution(which requires initmem to be kept
> and not freed during boot) we are trying to delay driver probes as this is
> much simpler.
> The proposed driver is a generic solution for managing such driver
> probes.
> 
>>> In such scenario, delaying the initialization of certain devices such
>>> as pcie based devices not needed during boot and giving user the control
>>> on probing these devices post boot, can help reduce overall boot time.
>>> This is achieved without modifying the driver code, simply by configuring
>>> the platform device tree.
>>
>> PCI devices should not be on the platform device tree.
>>
> 
> You are right, we are referring to the pci host controller that will be
> listed in device tree and skipping its probe during boot as an example
> here.
> 
>> And what's wrong with async probing?  That was written for this very
>> issue.
>>
> 
> We have explored async probe as an option, but we noticed below:
> 1) Probe initiated via async
> 2) Boot continues with other setup.
> 3) Boot reaches stage where ip configuration is to be done via
>    ip_auto_config() and 1) is still in progress, then boot waits for all
>    async calls to be completed before proceeding with network setup.
>    ip_auto_config()
>     -> wait_for_devices()
>       -> wait_for_device_probe()
>          -> async_synchronize_full()
> 4) Similar thing happens with rootfs mount step in prepare_namespace()
>    initcall
> 
> So to avoid getting blocked on these probes which are not required
> during boot, we proposed this driver for managing such built-in driver
> probes execution.
> 
>>> This patch series includes 2 patches:
>>>
>>> 1) dt-binding document for the probe-control driver
>>>    This document explains how device tree of a platform can be configured
>>>    to use probe-control devices for deferring the probes of certain
>>>    devices.
>>
>> But what does that have to do with PCI devices?
> 
> As explained before, the driver is generic one and is for managing probes of
> drivers that are built-in.
> 
> To delay such probes, in DT we add dummy devices managed by the proposed
> driver. These dummy devices(probe control devices) will be setup as
> supplier to the device nodes that we want to probe later.

You embedded OS policy into DT. That's not really the way to go. Look
how boot phase does it. First of all - it already solves your problem.
Second - it's property of each device, not some fake provider.

> dt-binding doc patch explains this process with pci controller node as
> an example that needs to be probed later after the boot.
> 
>>


Best regards,
Krzysztof

On Tue, Sep 17, 2024 at 11:03:14AM +0200, Krzysztof Kozlowski wrote:
> On 17/09/2024 11:06, Nayeemahmed Badebade wrote:
> > Hi Greg,
> > 
> > Thank you for taking the time to check our patch and provide
> > valuable feedback. We appreciate your comments/suggestions.
> > 
> > Please find our reply to your comments.
> > 
> > On Fri, Sep 13, 2024 at 06:36:38AM +0200, Greg KH wrote:
> >> On Wed, Sep 11, 2024 at 07:53:17PM +0530, Nayeemahmed Badebade wrote:
> >>> Hi,
> >>
> >> If Rob hadn't responded, I wouldn't have noticed these as they ended up
> >> in spam for some reason.  You might want to check your email settings...
> >>
> > 
> > I have ensured standard settings which we have been using are used this
> > time, let me know if this email is received properly.
> > 
> >>> This patch series introduces a new framework in the form of a driver
> >>> probe-control, aimed at addressing the need for deferring the probes
> >>> from built-in drivers in kernels where modules are not used.
> >>
> >> Wait, why?
> >>
> > 
> > We have a scenario where a driver cannot be built as a module and ends up
> > as a built-in driver. We don't want to probe this driver during boot as its
> 
> Fix this instead.

Agreed, that should be much simpler to do instead of adding core driver
code that will affect all drivers/devices because just one driver
doesn't seem to be able to be fixed?

What driver is this that is causing the problem?

> > not required at the time of booting.
> > Example: drivers/pci/controller/dwc/pci-imx6.c

Just this one?  I don't see anything obvious that can't turn that into a
module, have you tried?  What went wrong?

thanks,

greg k-h

Hi,

Sorry for the delay in our response.
Please find our reply to your comments:

On Tue, Sep 17, 2024 at 11:21:32AM +0200, Greg KH wrote:
> On Tue, Sep 17, 2024 at 11:03:14AM +0200, Krzysztof Kozlowski wrote:
> > On 17/09/2024 11:06, Nayeemahmed Badebade wrote:
> > > Hi Greg,
> > > 
> > > Thank you for taking the time to check our patch and provide
> > > valuable feedback. We appreciate your comments/suggestions.
> > > 
> > > Please find our reply to your comments.
> > > 
> > > On Fri, Sep 13, 2024 at 06:36:38AM +0200, Greg KH wrote:
> > >> On Wed, Sep 11, 2024 at 07:53:17PM +0530, Nayeemahmed Badebade wrote:
> > >>> Hi,
> > >>
> > >> If Rob hadn't responded, I wouldn't have noticed these as they ended up
> > >> in spam for some reason.  You might want to check your email settings...
> > >>
> > > 
> > > I have ensured standard settings which we have been using are used this
> > > time, let me know if this email is received properly.
> > > 
> > >>> This patch series introduces a new framework in the form of a driver
> > >>> probe-control, aimed at addressing the need for deferring the probes
> > >>> from built-in drivers in kernels where modules are not used.
> > >>
> > >> Wait, why?
> > >>
> > > 
> > > We have a scenario where a driver cannot be built as a module and ends up
> > > as a built-in driver. We don't want to probe this driver during boot as its
> > 
> > Fix this instead.
> 
> Agreed, that should be much simpler to do instead of adding core driver
> code that will affect all drivers/devices because just one driver
> doesn't seem to be able to be fixed?
> 
> What driver is this that is causing the problem?
> 
> > > not required at the time of booting.
> > > Example: drivers/pci/controller/dwc/pci-imx6.c
> 
> Just this one?  I don't see anything obvious that can't turn that into a
> module, have you tried?  What went wrong?
> 

Yes we have tried building it as a module.
This driver currently registers abort handler for pci using function
hook_fault_code() on arm. This function is not exported and marked with __init
tag. So we can't use it post boot.
Also from past attempt made to modularize this driver in community, we saw the
hook is not safe to be used post boot.
Reference:
 https://lore.kernel.org/linux-arm-kernel/1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com/T/#m8995c6dcc40c54baef0665a7ee16d4209cb59655

We will further check this.
Thank you for your feedback.

Regards,
Nayeem

On 26/09/2024 13:07, Nayeemahmed Badebade wrote:
>>
>>>> not required at the time of booting.
>>>> Example: drivers/pci/controller/dwc/pci-imx6.c
>>
>> Just this one?  I don't see anything obvious that can't turn that into a
>> module, have you tried?  What went wrong?
>>
> 
> Yes we have tried building it as a module.
> This driver currently registers abort handler for pci using function
> hook_fault_code() on arm. This function is not exported and marked with __init
> tag. So we can't use it post boot.

Then this is something to fix.

> Also from past attempt made to modularize this driver in community, we saw the
> hook is not safe to be used post boot.
> Reference:
>  https://lore.kernel.org/linux-arm-kernel/1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com/T/#m8995c6dcc40c54baef0665a7ee16d4209cb59655


Best regards,
Krzysztof

On Thu, Sep 26, 2024 at 02:34:26PM +0200, Krzysztof Kozlowski wrote:
> On 26/09/2024 13:07, Nayeemahmed Badebade wrote:
> >>
> >>>> not required at the time of booting.
> >>>> Example: drivers/pci/controller/dwc/pci-imx6.c
> >>
> >> Just this one?  I don't see anything obvious that can't turn that into a
> >> module, have you tried?  What went wrong?
> >>
> > 
> > Yes we have tried building it as a module.
> > This driver currently registers abort handler for pci using function
> > hook_fault_code() on arm. This function is not exported and marked with __init
> > tag. So we can't use it post boot.
> 
> Then this is something to fix.
> 
Thank you for the suggestion.
As per discussion in below link, its mentioned that hooks should be static and
should not change during runtime due to locking support not being there.
So its not safe to export this function to use in modules as per the comments
there.
We would appreciate any suggestions you might have on any possible
alternatives.
> > Also from past attempt made to modularize this driver in community, we saw the
> > hook is not safe to be used post boot.
> > Reference:
> >  https://lore.kernel.org/linux-arm-kernel/1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com/T/#m8995c6dcc40c54baef0665a7ee16d4209cb59655
> 
> 
> Best regards,
> Krzysztof
> 

Thank you.

Regards,
Nayeem

On Fri, Sep 27, 2024 at 10:04 AM Nayeemahmed Badebade
<nayeemahmed.badebade@sony.com> wrote:
>
> On Thu, Sep 26, 2024 at 02:34:26PM +0200, Krzysztof Kozlowski wrote:
> > On 26/09/2024 13:07, Nayeemahmed Badebade wrote:
> > >>
> > >>>> not required at the time of booting.
> > >>>> Example: drivers/pci/controller/dwc/pci-imx6.c
> > >>
> > >> Just this one?  I don't see anything obvious that can't turn that into a
> > >> module, have you tried?  What went wrong?
> > >>
> > >
> > > Yes we have tried building it as a module.
> > > This driver currently registers abort handler for pci using function
> > > hook_fault_code() on arm. This function is not exported and marked with __init
> > > tag. So we can't use it post boot.
> >
> > Then this is something to fix.
> >
> Thank you for the suggestion.
> As per discussion in below link, its mentioned that hooks should be static and
> should not change during runtime due to locking support not being there.
> So its not safe to export this function to use in modules as per the comments
> there.
> We would appreciate any suggestions you might have on any possible
> alternatives.
> > > Also from past attempt made to modularize this driver in community, we saw the
> > > hook is not safe to be used post boot.
> > > Reference:
> > >  https://lore.kernel.org/linux-arm-kernel/1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com/T/#m8995c6dcc40c54baef0665a7ee16d4209cb59655

The hook implementations have no interaction with the drivers other
than being installed by the driver. So move them out of the drivers
and the handler can be built-in with the driver as a module. For
example, see arch/arm/mach-bcm/bcm_5301x.c. Could possibly combine
some implementations. I haven't figured out why imx6 checks 2
different instructions while keystone only handles one. But imx6's
implementation being a superset should work for keystone perhaps.

Rob

On Fri, Sep 27, 2024 at 12:36:40PM -0500, Rob Herring wrote:
> On Fri, Sep 27, 2024 at 10:04 AM Nayeemahmed Badebade
> <nayeemahmed.badebade@sony.com> wrote:
> >
> > On Thu, Sep 26, 2024 at 02:34:26PM +0200, Krzysztof Kozlowski wrote:
> > > On 26/09/2024 13:07, Nayeemahmed Badebade wrote:
> > > >>
> > > >>>> not required at the time of booting.
> > > >>>> Example: drivers/pci/controller/dwc/pci-imx6.c
> > > >>
> > > >> Just this one?  I don't see anything obvious that can't turn that into a
> > > >> module, have you tried?  What went wrong?
> > > >>
> > > >
> > > > Yes we have tried building it as a module.
> > > > This driver currently registers abort handler for pci using function
> > > > hook_fault_code() on arm. This function is not exported and marked with __init
> > > > tag. So we can't use it post boot.
> > >
> > > Then this is something to fix.
> > >
> > Thank you for the suggestion.
> > As per discussion in below link, its mentioned that hooks should be static and
> > should not change during runtime due to locking support not being there.
> > So its not safe to export this function to use in modules as per the comments
> > there.
> > We would appreciate any suggestions you might have on any possible
> > alternatives.
> > > > Also from past attempt made to modularize this driver in community, we saw the
> > > > hook is not safe to be used post boot.
> > > > Reference:
> > > >  https://lore.kernel.org/linux-arm-kernel/1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com/T/#m8995c6dcc40c54baef0665a7ee16d4209cb59655
> 
> The hook implementations have no interaction with the drivers other
> than being installed by the driver. So move them out of the drivers
> and the handler can be built-in with the driver as a module. For
> example, see arch/arm/mach-bcm/bcm_5301x.c. Could possibly combine
> some implementations. I haven't figured out why imx6 checks 2
> different instructions while keystone only handles one. But imx6's
> implementation being a superset should work for keystone perhaps.
> 
> Rob

Thank you for your suggestions Rob.
Yes, this seems reasonable and we will work on updating the driver
accordingly to build it as a module.

Regards,
Nayeem