Re: will these methods work with firmware loading?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 02/20/2012 04:19 AM, Kay Sievers wrote:
On Mon, Feb 20, 2012 at 11:01, Arend van Spriel<arend@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html