Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752050AbbD2SoE (ORCPT ); Wed, 29 Apr 2015 14:44:04 -0400 Received: from mail.skyhub.de ([78.46.96.112]:37791 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751965AbbD2Sn6 (ORCPT ); Wed, 29 Apr 2015 14:43:58 -0400 Date: Wed, 29 Apr 2015 20:43:38 +0200 From: Borislav Petkov To: Henrique de Moraes Holschuh Cc: Daniel J Blueman , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Quentin Casasnovas , Steffen Persvold , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH] x86: Unbreak early processor microcode loading Message-ID: <20150429184338.GF5498@pd.tnic> References: <20150318184249.GC3249@pd.tnic> <1426750223.3578.2@cpanel21.proisp.no> <20150319092703.GA10860@pd.tnic> <20150429182357.GB14218@khazad-dum.debian.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150429182357.GB14218@khazad-dum.debian.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2076 Lines: 55 On Wed, Apr 29, 2015 at 03:23:57PM -0300, Henrique de Moraes Holschuh wrote: > That would obviously work, but people often have other firmware > built-in, so the likehood of CONFIG_EXTRA_FIRMWARE_DIR pointing to the > root of a linux-firmware work tree or to "/lib/firmware" is not low at > all. > > In fact, it is natural to expect that CONFIG_EXTRA_FIRMWARE should point > to something that will result in the same filenames as the kernel would > want to use for regular firmware loading. The current text of the > Kconfig help for CONFIG_EXTRA_FIRMWARE even says so. You mean that: "These files should exist under the directory specified by the EXTRA_FIRMWARE_DIR option, which is by default the firmware subdirectory of the kernel source tree. For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy the usb8388.bin file into the firmware directory, and build the kernel. Then any request_firmware("usb8388.bin") will be satisfied internally without needing to call out to userspace." So people with lotsa firmware should put it all under one directory and all should just work. > So, FWIW, I do think we should always use the same path for builtin and > regular firmware requests, based on the least-surprise principle. We don't hardcode the path - only the name. What I gave was an example only. The regular microcode updates, i.e. the late ones, use firmware class which has a bunch of hardcoded paths: static const char * const fw_path[] = { fw_path_para, "/lib/firmware/updates/" UTS_RELEASE, "/lib/firmware/updates", "/lib/firmware/" UTS_RELEASE, "/lib/firmware" }; and that's different from CONFIG_FIRMWARE_DIR. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/