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
