On Wed, May 8, 2013 at 6:26 PM, Takashi Iwai <ti...@suse.de> wrote: > At Thu, 9 May 2013 00:07:17 +0800, > Ming Lei wrote:
>> On Wed, May 8, 2013 at 2:56 PM, Takashi Iwai <ti...@suse.de> wrote: >> > Hi, >> > >> > this is a series of patches for the issue we faced in the firmware >> > loader code during debugging the problem with dell_rbu driver with >> > 3.9 kernel. >> > >> > The original problem was that the shutdown gets stuck when DELL BIOS >> > update is performed. This turned out to be a problem in the firmware >> > loader. Although the reason of dell_rbu driver breakage is still >> >> Sorry, from these patchset, I can't see why it is a problem in firmware. >> >> > unclear, we should fix the firmware loader side, at least, not to >> > stall during shutdown. >> >> Firstly you need to describe what/why is the stall? In fact, firmware >> loading can't stall forever and it will timeout, but the current 60sec >> timeout might be too long. > > The timeout check is activated only when uevent flag is set, and > dell_rbu driver doesn't set it explicitly (because it's not supposed > to be handled via udev or whatever). These use the firmware loader not in the way the interface was intended: drivers/misc/lattice-ecp3-config.c drivers/firmware/dell_rbu.c They just use the mechanism without any of the usual userspace setup. It's really a nasty hack to hijack the interface that way. The commit 6e3eaab02028c4087a92711b20abb9e72cc803a7 is a pretty broken idea to start with. If something triggers uevents during runtime which is not uncommon, these on-demand silently created firmware devices would get really confused and race against the udev firmware loader which cancels the events. As if the userspace firmware loading in general wasn't a bad enough idea already. :) Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
