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  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]
Date:	Mon, 28 Jul 2014 15:46:32 +0000
From:	Yuval Mintz <>
To:	"Luis R. Rodriguez" <>
CC:	"Luis R. Rodriguez" <>,
	"" <>,
	linux-kernel <>,
	Tetsuo Handa <>,
	Joseph Salisbury <>,
	Kay Sievers <>,
	"One Thousand Gnomes" <>,
	Tim Gardner <>,
	Pierre Fersing <>,
	Andrew Morton <>,
	Oleg Nesterov <>,
	Benjamin Poirier <>,
	Nagalakshmi Nandigama <>,
	Praveen Krishnamoorthy <>,
	Sreekanth Reddy <>,
	Abhijit Mahajan <>,
	Hariprasad S <>,
	Santosh Rastapur <>,
	linux-scsi <>,
	netdev <>
Subject: RE: [PATCH 1/3] driver core: enable drivers to use deferred probe
	from init

> Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from
> init
> On Mon, Jul 28, 2014 at 03:12:11PM +0000, Yuval Mintz wrote:
> > Perhaps this is a silly question, but what guarantees that the
> > deferred probe list will actually be triggered, e.g., in case the
> > delayed device is the last device in the system?
> The dev->init_delayed_probe is used to ensure that we'd add the device to the
> deferred probe list once making this a per device thing if the driver has the field
> delay_probe set to true. This technically also allows this to be a per device thing
> so with some more work we could enable drivers to only enable this for specific
> devices but at this point this did not seem required.

Sorry for not being clear, but I didn't meant 'what guarantees that the device
will be added to the deferred probe', but rather what guarantees that the
deferred workqueue will be scheduled.

To the best of my knowledge the deferring mechanism works only if one device
is dependent upon another, e.g., for Multi-function devices where one device
probe is dependent upon the others - which are soon-to-be probed.

[If I'm incorrect I'd appreciate if someone could correct me]

> > [From drivers/base/dd.c  - "A successful driver probe will trigger
> > moving all devices from the pending to the active list so that the
> > workqueue will eventually retry them]
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists