Return-path: Received: from mms3.broadcom.com ([216.31.210.19]:4344 "EHLO MMS3.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752505Ab2BTKdA (ORCPT ); Mon, 20 Feb 2012 05:33:00 -0500 Message-ID: <4F422152.3030603@broadcom.com> (sfid-20120220_113325_738596_F8FDDCEA) Date: Mon, 20 Feb 2012 11:32:50 +0100 From: "Arend van Spriel" MIME-Version: 1.0 To: "Kay Sievers" cc: "Larry Finger" , LKML , driverdevel , wireless , "linux-hotplug@vger.kernel.org" Subject: Re: will these methods work with firmware loading? References: <4F414230.5040506@lwfinger.net> <4F421A0E.8030805@broadcom.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 02/20/2012 11:19 AM, Kay Sievers wrote: >> For that >> > problem I would say yes. Also here the problem of handling error flows >> > exist. If the driver is kicked of during boot with a initramfs missing the >> > firmware, should we retry until the real root is mounted? > I don't think so. Drivers are not supposed to know about bootup or > initramfs issues. If they want, they can disable the timeout, and wait > for userspace to handle the request any time later, but they should > not try to be smart here. > > Currently, firmware requests are cancelled if the firmware isn't > found, but that's a userspace issue, and nothing the kernel should try > to work around. I can not agree more. I prefer to keep my driver happily unaware. I will just take the firmware loading away from the module init path and stop worrying about userspace issues ;-) Gr. AvS