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
