netdev - Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

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: <CAB=NE6Xmi2zUCis22q+X8_AKRcwMrAtmx-aqSSvTB70Xjet6VQ@mail.gmail.com>
Date:	Mon, 28 Jul 2014 12:48:32 -0700
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	Greg KH <gregkh@...uxfoundation.org>,
	Santosh Rastapur <santosh@...lsio.com>,
	Hariprasad S <hariprasad@...lsio.com>
Cc:	Takashi Iwai <tiwai@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Joseph Salisbury <joseph.salisbury@...onical.com>,
	Kay Sievers <kay@...y.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tim Gardner <tim.gardner@...onical.com>,
	Pierre Fersing <pierre-fersing@...rref.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Benjamin Poirier <bpoirier@...e.de>,
	Nagalakshmi Nandigama <nagalakshmi.nandigama@...gotech.com>,
	Praveen Krishnamoorthy <praveen.krishnamoorthy@...gotech.com>,
	Sreekanth Reddy <sreekanth.reddy@...gotech.com>,
	Abhijit Mahajan <abhijit.mahajan@...gotech.com>,
	MPT-FusionLinux.pdl@...gotech.com,
	Linux SCSI List <linux-scsi@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
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
<mcgrof@...not-panic.com> wrote:
> On Mon, Jul 28, 2014 at 11:55 AM, Greg KH <gregkh@...uxfoundation.org> 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.

 Luis
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html