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: <2024091327-repacking-avatar-ec23@gregkh>
Date: Fri, 13 Sep 2024 06:36:38 +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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ