lkml.org 
[lkml]   [2014]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFT 0/3] cxgb4: use request_firmware_nowait()
On Wed, Jun 25, 2014 at 01:39:51AM +0200, Luis R. Rodriguez wrote:
> 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?

Actually another option to clean this up is to use platform_device_register_simple()
after the initial firmware load and start poking at stuff there. Check out
drivers/net/ethernet/8390/ne.c for an example with probe and all. I think
that can help split up the code paths quite nicely and let you do your
pre port thing there. Thoughts?

I still do have that question about bus master requirement though and ensuring
that there are no races.

Luis


\
 
 \ /
  Last update: 2014-06-25 04:41    [W:0.055 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site