Re: [PATCH 0/2] Add framework for user controlled driver probes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx> 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@xxxxxxxxxxxxx/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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux