Message-ID: <20140625020019.GJ27687@wotan.suse.de>
Date:	Wed, 25 Jun 2014 04:00:19 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Casey Leedom <leedom@...lsio.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	hariprasad@...lsio.com, poswald@...e.com, santosh@...lsio.com,
	jcheung@...e.com, dchang@...e.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists