Message-ID: <ZulGr8Ul7y0T0NkQ@NAB-HP-ProDesk-600sony.com>
Date: Tue, 17 Sep 2024 14:36:55 +0530
From: Nayeemahmed Badebade <nayeemahmed.badebade@...y.com>
To: Greg KH <gregkh@...uxfoundation.org>
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

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

Powered by blists - more mailing lists