[lkml]   [2012]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: will these methods work with firmware loading?
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.


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.


 \ /
  Last update: 2012-02-20 21:15    [W:0.040 / U:1.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site