linux-kernel - Re: [PATCH 2/3] cxgb4: make configuration load 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: <20140625200510.GY27687@wotan.suse.de>
Date:	Wed, 25 Jun 2014 22:05:10 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Casey Leedom <leedom@...lsio.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>, tiwai@...e.de,
	chunkeey@...glemail.com, cocci@...teme.lip6.fr,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	gregkh@...uxfoundation.org, Philip Oswald <poswald@...e.com>,
	Santosh Rastapur <santosh@...lsio.com>,
	Jeffrey Cheung <jcheung@...e.com>,
	David Chang <dchang@...e.com>,
	Hariprasad Shenai <hariprasad@...lsio.com>
Subject: Re: [PATCH 2/3] cxgb4: make configuration load use
	request_firmware_direct()

On Wed, Jun 25, 2014 at 11:58:52AM -0700, Casey Leedom wrote:
>   Okay, I'll leave the whole request_firmware{,_direct,_nowait}() thing 
> alone.  The request_firmware_direct() will "solve" a non-problem (since all 
> of our "firmware" files are _supposed to be_ always present.

The code does not reflect that, it allows for files to not be present for
the config stuff. If in practice files are always present that's a bit
different.

> (And the 60 
> second timeout for udev to confirm that a file doesn't exist seems like 
> udev is just basically broken.)

Its one reason it being tossed.

>   That aside, we still need to solve the real problem that we're 
> experiencing in that the boot-time load of cxgb4 is timing out on SLE12 
> because a maximum load timeout has been instituted in that distribution for 
> driver modules and if there are two 10Gb/s-BT adapters present in a system 
> which need both base firmware and BT PHY firmware, we exceed that timeout.  

As for that it'd be great if you can answer some questions I had about
the rest of firmware load processing on the other thread, I had a bit
of questions for you there.

> The timeout really should be per device (since there ~could~ be an 
> arbitrary number of devices in a system) and there probably should be a way 
> for the driver to notify the kernel timeout mechanism that forward progress 
> is being made ...

I'd prefer we dive into this on the other thread.

  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/