linux-kernel - Re: [PATCH 0/2] Add framework for user controlled driver probes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024091747-monorail-unbutton-7ebd@gregkh>
Date: Tue, 17 Sep 2024 11:21:32 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Krzysztof Kozlowski <krzk@...nel.org>,
	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 11:03:14AM +0200, Krzysztof Kozlowski wrote:
> On 17/09/2024 11:06, 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.
> > 
> >>> 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
> 
> Fix this instead.

Agreed, that should be much simpler to do instead of adding core driver
code that will affect all drivers/devices because just one driver
doesn't seem to be able to be fixed?

What driver is this that is causing the problem?

> > not required at the time of booting.
> > Example: drivers/pci/controller/dwc/pci-imx6.c

Just this one?  I don't see anything obvious that can't turn that into a
module, have you tried?  What went wrong?

thanks,

greg k-h