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

[Luis R. Rodriguez]

On Mon, Jul 28, 2014 at 12:04 PM, Luis R. Rodriguez
<mcgrof@xxxxxxxxxxxxxxxx> wrote:
> On Mon, Jul 28, 2014 at 11:55 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/