On Wed, Aug 6, 2014 at 3:44 AM, Jean-Michel Hautbois <jhautb...@gmail.com> wrote: > 2014-08-06 11:24 GMT+02:00 Takashi Iwai <ti...@suse.de>: >> At Wed, 6 Aug 2014 11:10:27 +0200, >> Jean-Michel Hautbois wrote: >>> >>> 2014-08-05 21:22 GMT+02:00 Shuah Khan <shuahk...@gmail.com>: >>> > On Tue, Aug 5, 2014 at 10:01 AM, Takashi Iwai <ti...@suse.de> wrote: >>> >>> Yes, it worked, if the firmware was in the /lib/firmware directory. >>> >> >>> > >>> > ok it works when the firmware is in /lib/firmware. It sounds to me the >>> > reason load fails when the firmware is under /sys/class/firmware is >>> > fw_load_from_user_helper() returns -ENOENT when >>> > CONFIG_FW_LOADER_USER_HELPER is disabled. >>> > >>> > It would be nice to see the entire dmesg with debug enabled though. >>> > >>> > -- Shuah >>> >>> It does not work with the 3.16 kernel even when firmware is in >>> /lib/firmware, it worked before this patch is applied. >> >> 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. 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. A quick way to test is by adding a dev_info() in the fw_load_from_user_helper() and see if that is path it is taking. -- Shuah -- 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/