From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754458AbbCSQdj (ORCPT ); Thu, 19 Mar 2015 12:33:39 -0400 Received: from mail-vc0-f176.google.com ([209.85.220.176]:49603 "EHLO mail-vc0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753650AbbCSQdf (ORCPT ); Thu, 19 Mar 2015 12:33:35 -0400 Date: Thu, 19 Mar 2015 12:33:30 -0400 From: Tejun Heo To: Borislav Petkov Cc: Dmitry Torokhov , Doug Thompson , linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, Mauro Carvalho Chehab , Tetsuo Handa , Olof Johansson , Arjan van de Ven , Greg Kroah-Hartman , "Luis R . Rodriguez" Subject: Re: [PATCH 3/3] EDAC: amd64_edac: decide if driver can load successfully early. Message-ID: <20150319163330.GN25365@htj.duckdns.org> References: <1426726150-983-1-git-send-email-dmitry.torokhov@gmail.com> <1426726150-983-4-git-send-email-dmitry.torokhov@gmail.com> <20150319094054.GC10860@pd.tnic> <20150319152957.GI25365@htj.duckdns.org> <20150319153505.GD11715@pd.tnic> <20150319155253.GA30732@dtor-ws> <20150319155953.GF11715@pd.tnic> <20150319161226.GC30732@dtor-ws> <20150319162301.GH11715@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150319162301.GH11715@pd.tnic> 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 Hello, Borislav. On Thu, Mar 19, 2015 at 05:23:02PM +0100, Borislav Petkov wrote: > On Thu, Mar 19, 2015 at 09:12:26AM -0700, Dmitry Torokhov wrote: > > By the same token it only makes sense to load e1000e when I have e1000e > > device loaded, but we allow it to load anyway. Or psmouse. Or pretty > > much any other drivers (sans some platform code). The fact is that we > > for long time have separated module loading and driver binding. Loading > > driver even without the devices is standard behavior. > > FWIW, I always hated that. You understand that there are technical reasons behind the current behavior? This is not something people just did on a whim. We used to have autounload and all that but over time moved away from it because the trade-offs around the behavior shifted. I don't get why you don't understand this. As a general rule, we don't go and implement one-off behaviors like this because it's well understood that things like this are more costly in the longer term. As said multiple times before, if you think this is a class of problem worth solving, do so properly. Please stop shell scripting in your ->probe() in kernel. > If I detect at least one NB which is ok, I can then continue and do > pci_register_driver(). If there are no suitable NBs, I return an error > and don't even touch PCI. Please don't. Consider it nacked preemptively. If you want to solve this and can justify the added complexity, solve it in a general way - teach it to the driver model. Thanks. -- tejun