On Tue, Jun 24, 2014 at 09:34:19AM -0700, Casey Leedom wrote: > On 06/24/14 08:55, Casey Leedom wrote: >> On 06/23/14 17:29, Luis R. Rodriguez wrote: > So I just did this for a normal modprobe (after the system is up): > > Jiffies Process > ----------------------------------------------------------------------- > 0 begin firmware load process > 3 request_firmware() returns > 7 start looking at the adapter > 10 finish reading the first sector of existing adapter firmware > 26 we've decided that we're going to upgrade the firmware > 28 actual firmware upgrade process starts > 448 we've finished halting the adapter processor > 451 we enter the firmware write routine > 8,470 we've finished erasing the firmware FLASH sectors > 14,336 write of new firmware is complete > 14,340 the new firmware load is complete > 14,949 the adapter processor has been restarted; new firmware running > 14,952 firmware upgrade process complete > > Maybe request_firmware() takes more time during the boot phase but as we > can see from the above timings, it's the actual firmware upgrade process > which takes the most time ...
OK so yeah the kernel work on request_firmware() isn't what takes over a minute, its the actual hardware poking with the firmware it gets, and then doing all the things you mentioned (a port for each netdevice, etc). This is a particularly interesting driver, apart from this I see some code about bus master and loading firmware only once. Can you elaborate a bit on how that is designed to work? Is it that only one PCI bus master device is allowed, and that will do the request_firmware() for all PCI devices? I'm a bit confused about this part, are we sure the bus master device will probe first? We can surely keep all this code on the driver but it seems that if all these complexitities might become the norm we should consider an API for sharing a clean framework for it. As you noted the complexities on firmware loading, the number of different netdevices one device might actually have would make it impractical to try to do any completion on firmware on the ndo_init() with request_firmware_nowait(). Apart from a netdev specific API to handle all this cleanly, I wonder if drivers like these merit getting placed by default onto the deferred_probe_active_list. Typically this is triggered when drivers don't have a resource a subsystem hasn't yet brought up, the driver returns -EPROBE_DEFER and the core driver infrastructure later probes these devices on a secondary list. Greg? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
