From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932363AbaHGNXu (ORCPT ); Thu, 7 Aug 2014 09:23:50 -0400 Received: from mail-yk0-f173.google.com ([209.85.160.173]:34127 "EHLO mail-yk0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932082AbaHGNXs (ORCPT ); Thu, 7 Aug 2014 09:23:48 -0400 MIME-Version: 1.0 In-Reply-To: References: <14048583172593@kroah.com> <8B2F6FFD0BD1E448853114367400A37306FD6FBBE9@BLRX7MCDC203.AMER.DELL.COM> <8B2F6FFD0BD1E448853114367400A37306FD6FBBF8@BLRX7MCDC203.AMER.DELL.COM> <8B2F6FFD0BD1E448853114367400A37306FD6FBC06@BLRX7MCDC203.AMER.DELL.COM> <8B2F6FFD0BD1E448853114367400A37306FD6FBDAB@BLRX7MCDC203.AMER.DELL.COM> <8B2F6FFD0BD1E448853114367400A37306FE07C773@BLRX7MCDC203.AMER.DELL.COM> <8B2F6FFD0BD1E448853114367400A37306FE07CC64@BLRX7MCDC203.AMER.DELL.COM> <8B2F6FFD0BD1E448853114367400A37306FE311D74@BLRX7MCDC203.AMER.DELL.COM> Date: Thu, 7 Aug 2014 07:23:47 -0600 Message-ID: Subject: Re: patch "firmware loader: allow disabling of udev as firmware loader" added to driver-core tree From: Shuah Khan To: Takashi Iwai Cc: Jean-Michel Hautbois , B_B_Singh@dell.com, Greg KH , Arnd Bergmann , Kay Sievers , Ming Lei , Stefan Roese , Tom Gundersen , Stuart_Hayes@dell.com, Srinivas_G_Gowda@dell.com, linux-kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 7, 2014 at 1:57 AM, Takashi Iwai wrote: >> >> Hm? 3.16 doesn't contain my patch yet. It's merged for 3.17-rc1. >> > >> > Oh, you are right of course, I am on upstream kernel and I have your >> > patch. I don't mean your match is causing the issue though ;-). >> > >> >> I think this is what is going on and this patch is the cause: >> fw_load_from_user_helper() is a stub that returns -ENOENT with this >> patch. > > ... unless specifying the new Kconfig > CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y. This is exactly the purpose > of the commit. Right - I figured that is the intent. > >> As a result, in _request_firmware() after fw_get_filesystem_firmware() >> fails to find the file, fw_load_from_user_helper() gets called and it >> returns right >> away with -ENOENT. >> >> In some cases if rootfs mount is in progress, fw_load_from_user_helper() >> steps into load the firmware. > > When a module in initrd requires a firmware, it should be put in > initrd, too. Right. This is something drivers have to watch out for with this change. -- Shuah