Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754217Ab2JCUjq (ORCPT ); Wed, 3 Oct 2012 16:39:46 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:62788 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753722Ab2JCUjo (ORCPT ); Wed, 3 Oct 2012 16:39:44 -0400 MIME-Version: 1.0 In-Reply-To: <20121003195059.GA13541@kroah.com> References: <4FE9169D.5020300@redhat.com> <20121002100319.59146693@redhat.com> <20121002221239.GA30990@kroah.com> <20121002222333.GA32207@kroah.com> <506C562E.5090909@redhat.com> <20121003170907.GA23473@ZenIV.linux.org.uk> <20121003195059.GA13541@kroah.com> From: Linus Torvalds Date: Wed, 3 Oct 2012 13:39:23 -0700 X-Google-Sender-Auth: 17X-Nk6letcuwJyf3ji9HjnFy-U Message-ID: Subject: Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() To: Greg KH Cc: Al Viro , Mauro Carvalho Chehab , Ming Lei , Kay Sievers , Lennart Poettering , Linux Kernel Mailing List , Kay Sievers , Linux Media Mailing List , Michael Krufky , Ivan Kalvachev Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1344 Lines: 31 On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote: >> >> Ok, like this? > > This looks good to me. Having udev do firmware loading and tieing it to > the driver model may have not been such a good idea so many years ago. > Doing it this way makes more sense. Ok, I wish this had been getting more testing in Linux-next or something, but I suspect that what I'll do is to commit this patch asap, and then commit another patch that turns off udev firmware loading entirely for the synchronous firmware loading case. Why? Just to get more testing, and seeing if there are reports of breakage. Maybe some udev out there has a different search path (or because udev runs in a different filesystem namespace or whatever), in which case running udev as a fallback would otherwise hide the fact that he direct kernel firmware loading isn't working. We can (and will) revert things if that turns out to break things, but I'd like to make any failures of the firmware direct-load path be fast and hard, so that we can see when/what it breaks. Ok? Comments? Linus -- 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/