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-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
