Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759354Ab3EWOsO (ORCPT ); Thu, 23 May 2013 10:48:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51443 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757589Ab3EWOsN (ORCPT ); Thu, 23 May 2013 10:48:13 -0400 Date: Thu, 23 May 2013 10:48:00 -0400 From: Dave Jones To: Takashi Iwai Cc: Ming Lei , "H. Peter Anvin" , Linux Kernel , x86@kernel.org, fenghua.yu@intel.com Subject: Re: microcode loading got really slow. Message-ID: <20130523144800.GB16419@redhat.com> Mail-Followup-To: Dave Jones , Takashi Iwai , Ming Lei , "H. Peter Anvin" , Linux Kernel , x86@kernel.org, fenghua.yu@intel.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1636 Lines: 40 On Thu, May 23, 2013 at 04:36:20PM +0200, Takashi Iwai wrote: > > >> Also udev supports user-defined rules to load firmware, which > > >> means some drivers may not put their firmware in the default > > >> path of distribution's firmware. > > > > > > It's why I suggested to put a warning in that path as the first step. > > > So we can see whether there is any actual user. > > > > If you plan to do it, it'd better to add default firmware path of some > > distributions into firmware_class.c first, otherwise it may cause > > unnecessary noise for this distribution. > > > > But if more default search paths are added, it might cause mistaken > > firmwares found under incorrect path, for example, android's > > default path is "/etc/firmware" and "/vendor/firmware"(maybe different > > for different versions). > > > > Also, putting default search paths into kernel isn't good, which was > > introduced unwillingly for well-known reason. > > Maybe we can create a new Kconfig to specify non-standard firmware > path? You keep mentioning non-standard paths for firmware, but in this case, I don't think Fedora is doing anything unusual. We have microcode firmware in /lib/firmware/intel-ucode/ just like (afaik) everyone else. What *is* happening, I think is that the CPU is new enough that there's no newer firmware file available for it. thoughts? Dave -- 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/