lkml.org 
[lkml]   [2013]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/2] firmware, fix request_firmware_nowait() freeze with no uevent
From
On Wed, Oct 23, 2013 at 7:15 AM, Prarit Bhargava <prarit@redhat.com> wrote:
> On 10/21/2013 10:35 PM, Ming Lei wrote:
>>
>> That is why NOHOTPLUG isn't encouraged to be taken, actually
>> I don't suggest you to do that too, :-)
> Okay ... I can certainly switch to HOTPLUG.

OK, that should be the right approach.

>
>>
>> You need to make sure your approach won't break micro-code
>> update application in current/previous distributions.
>
> I've tested the following distributions today on a Dell PE 1850: Ubuntu, SuSe,
> Linux Mint, and of course Fedora. I do not see any issues with either the
> microcode update or the dell_rbu driver. Unfortunately I do not have access to

Actually I am wondering if your tests are enough because kernel
can't break user-space, which means lots of previous old version
distributions should surely be covered, :-)

If you keep HOTPLUG, only change to request_firmware_nowait(),
that should be OK since the loading protocol between userspace and
kernel won't change wrt. microcode updating.

> a system that uses the lattice-ecp3-config, however, from code inspection it
> looks like the driver looks at a specific place for the FW update and then
> applies it via the call function in request_firmware_nowait() so it looks like
> it is solid too.
>
> I think maybe this patchset should be split into two separate submits, one for
> the microcode and the second to figure out if the code really should wait
> indefinitely. AFAICT neither use case in the kernel expects an indefinite wait.

If you switch to HOTPLUG, you needn't worry about waiting indefinitely,
need you?

Thanks,
--
Ming Lei


\
 
 \ /
  Last update: 2013-10-23 07:01    [W:0.082 / U:1.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site