linux-kernel - Re: [RFT 0/3] cxgb4: use request_firmware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Jun 2014 01:39:51 +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 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 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/