On Thu, May 23, 2013 at 11:06 PM, Takashi Iwai <ti...@suse.de> wrote: > At Thu, 23 May 2013 10:48:00 -0400, > Dave Jones wrote: >> >> 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? > > Yes, in your case, everything is fine in the kernel itself. And no > microcode update is needed for new CPU, thus no firmware.
Can the driver decide if the CPU need microcode? Or there will be the microcode for the CPU in future? > > The problem is that the f/w loader tries to call udev and udev gets > stuck when invoked from module init. This doesn't hit most drivers > because usually the firmware is mandatory and it must exist. Thus the > direct f/w loading always works for them. If it hits, it's only the > error case. > > But, for the microcode loader, it's normal that the firmware doesn't > exist, like your case. Unfortunately, this falls back to user helper > mode, and now you're seeing the problem. The problem is that if driver call request_firmware(), it means it need the firmware and it know there should be one. So maybe the driver shouldn't call request_firmware() if it can figure out that case. > So, the option would be to fix udev, let it behaving like before. > The second option would be to change ("fix") the kernel behavior, but > the question is which way. Sounds like the microcode driver depends on userspace or filesystem to decide if there is one microcode available for me, is the way correct? Thanks, -- Ming Lei -- 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/