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
