Message-ID: <2024091743-germinate-fructose-3ded@gregkh>
Date: Tue, 17 Sep 2024 12:11:22 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Nayeemahmed Badebade <nayeemahmed.badebade@...y.com>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
	rafael@...nel.org, yoshihiro.toyama@...y.com,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/2] Add framework for user controlled driver probes

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

Powered by blists - more mailing lists