From mboxrd@z Thu Jan 1 00:00:00 1970 From: Larry Finger Date: Mon, 20 Feb 2012 20:12:37 +0000 Subject: Re: will these methods work with firmware loading? Message-Id: <4F42A935.90603@lwfinger.net> List-Id: References: <4F414230.5040506@lwfinger.net> <4F421A0E.8030805@broadcom.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Kay Sievers Cc: Arend van Spriel , LKML , driverdevel , wireless , "linux-hotplug@vger.kernel.org" On 02/20/2012 04:19 AM, Kay Sievers wrote: > On Mon, Feb 20, 2012 at 11:01, Arend van Spriel wrote: >> On 02/19/2012 07:40 PM, Larry Finger wrote: > >>> Similarly, if I were to create a work queue, init and schedule it from >>> module_init(), and then use synchronous loads to get the firmware from the >>> work >>> queue callback, would that get around the boot problem? I know it works as >>> I >>> have trial patches; however, my version of udev is not one affected. This >>> method >>> is very easy to implement, but again I would like confirmation from an >>> expert. > > It sounds like it should work, because the modprobe event returns, not > waiting for the firmware request. Chaining one firmware request after > the other sounds not like a problem, as long as they are chained with > the return from the earlier request and not from inside the earlier > request, which would have duplicated device name issues in the kernel > too. > >> What boot problem are you referring to? > > The pci event calls modprobe, the module init for the pci driver > creates a child event of the pci device, this child event is queued in > udev to be started after the pci event has finished. The pci event > does not finish in time because the firmware request blocks itself. > > The current udev logic limits the timeout to 30 sec, while the > firmware request is 60 sec, so it usually works with a logged error, > and a 30 second delay. > >> The blocking modprobe? > > Yes, blocking in the module init path, will deadlock udev. Linking > code into the kernel must not depend on device init or firmware > loading. > >> 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. Kay, Thanks for your very helpful comments. I think I will keep my second method, i.e. start a work queue entry from the probe routine, and then use synchronous firmware loads from that queue's callback routine. In most cases, the firmware loading is already done from a separate routine, thus the flow is not that different from the current code. Larry