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... > 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? > 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. And what's wrong with async probing? That was written for this very issue. > 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? > 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? 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
