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]

Message-ID: <53A87AC8.7010305@chelsio.com>
Date:	Mon, 23 Jun 2014 12:06:48 -0700
From:	Casey Leedom <leedom@...lsio.com>
To:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	hariprasad@...lsio.com
CC:	poswald@...e.com, santosh@...lsio.com, jcheung@...e.com,
	dchang@...e.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, mcgrof@...e.com
Subject: Re: [RFT 0/3] cxgb4: use request_firmware_nowait()

   I've looked through the patch and I might be wrong, but it appears 
that all the uses of the asynchronous request_firmware_nowait() are 
followed immediately by wait_for_completion() calls which essentially 
would be the same as the previous code with an added layer of 
mechanism.  Am I missing something?

   We do have a problem with initialization of multiple adapters with 
external PHYs since, for each adapter we can check to see if the main 
adapter firmware needs updating, and then load the PHY firmware.  If the 
main firmware needs updating on more than one adapter, the combined time 
to update each adapter's main firmware plus load the PHY firmware can 
exceed some Distribution's default limits for a driver module's load 
time (since the kernel seems to be processing the PCI Probe of each 
device sequentially).

   It seems to me that it's unfortunate that the limit isn't on a per 
device basis since a system could have an arbitrary number of devices 
managed by a driver module.  Also, it might be useful if there was a way 
for the driver module to "tell" the timeout mechanism that forward 
progress _is_ being made so it doesn't blow away the driver module 
load.  And maybe, if I'm right regarding the sequential nature of the 
introduction of devices to driver modules, it might make sense for a 
driver module to be able to "tell" the kernel that it has no per-device 
dependencies and multiple devices may be probed simultaneously ...

Casey

On 06/20/14 17:39, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@...e.com>
>
> Its reported that loading the cxgb4 can take over 1 minute,
> use the more sane request_firmware_nowait() API call just
> in case this amount of time is causing issues. The driver
> uses the firmware API 3 times, one for the firmware, one
> for configuration and another one for flash, this provides
> the port for all cases.
>
> I don't have the hardware so please test. I did verify we
> can use this during pci probe and also during the ethtool
> flash callback.
>
> Luis R. Rodriguez (3):
>    cxgb4: make ethtool set_flash use request_firmware_nowait()
>    cxgb4: make configuration load use request_firmware_nowait()
>    cxgb4: make device firmware load use request_firmware_nowait()
>
>   drivers/net/ethernet/chelsio/cxgb4/cxgb4.h      |  13 ++
>   drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 258 +++++++++++++++---------
>   2 files changed, 176 insertions(+), 95 deletions(-)
>

--
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/