Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755184AbaFYUFO (ORCPT ); Wed, 25 Jun 2014 16:05:14 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47785 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752833AbaFYUFN (ORCPT ); Wed, 25 Jun 2014 16:05:13 -0400 Date: Wed, 25 Jun 2014 22:05:10 +0200 From: "Luis R. Rodriguez" To: Casey Leedom Cc: "Luis R. Rodriguez" , tiwai@suse.de, chunkeey@googlemail.com, cocci@systeme.lip6.fr, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, Philip Oswald , Santosh Rastapur , Jeffrey Cheung , David Chang , Hariprasad Shenai Subject: Re: [PATCH 2/3] cxgb4: make configuration load use request_firmware_direct() Message-ID: <20140625200510.GY27687@wotan.suse.de> References: <1403649583-12707-1-git-send-email-mcgrof@do-not-panic.com> <1403649583-12707-3-git-send-email-mcgrof@do-not-panic.com> <20140625015048.GI27687@wotan.suse.de> <53AB02F4.1090701@chelsio.com> <20140625173156.GW27687@wotan.suse.de> <53AB1BEC.4080107@chelsio.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53AB1BEC.4080107@chelsio.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/