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 12:48:32 -0700
From:	"Luis R. Rodriguez" <>
To:	Greg KH <>,
	Santosh Rastapur <>,
	Hariprasad S <>
Cc:	Takashi Iwai <>,
	"" <>,
	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 <>,,
	Linux SCSI List <>,
	"" <>
Subject: Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe
 from init

On Mon, Jul 28, 2014 at 12:04 PM, Luis R. Rodriguez
<> wrote:
> On Mon, Jul 28, 2014 at 11:55 AM, Greg KH <> wrote:
>> So, what drivers are having problems in their init sequence, and why
>> aren't they using async firmware loading?
> Fixing drivers is one thing, fixing drivers *now* because *now*
> drivers are failing due to a regression is another thing and that's
> what we have now so lets just be clear on that. The 30 second rule is
> a major driver requirement change and it should not be taken slightly,
> all of a sudden this is a new requirement but you won't know that
> unless you're reading these threads or hit an issue. That's an issue
> in itself.
> The cxgb4: driver is an example where although I did propose patches
> to use asynch firmware loading the entire registration of the
> netdevice would need to be changed as well in order to get this right.
> In short we have to scramble now to first identify drivers that have
> long init sequences and then fix. There's an assumption that we can
> easily fix drivers, this can take time. This series, although does
> take advantage of a kernel interface for other uses, lets us identify
> these drivers on the kernel ring buffer, so we can go and address
> fixing them with time.

Another thing that came up during asynch firmware review / integration
on cxgb4 was that it would not be the only thing that would need to be
fixed, the driver also has a ton of ports and at least as per my
review the proper fix would be to use platform regiister stuff. It is
a major rewrite of the driver but an example of a driver that needs
quite a bit of work to meet this new 30 second driver requirement.

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