From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964916AbbCSRWj (ORCPT ); Thu, 19 Mar 2015 13:22:39 -0400 Received: from mail-vc0-f172.google.com ([209.85.220.172]:62204 "EHLO mail-vc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756341AbbCSRWd (ORCPT ); Thu, 19 Mar 2015 13:22:33 -0400 Date: Thu, 19 Mar 2015 13:22:28 -0400 From: Tejun Heo To: Dmitry Torokhov Cc: Borislav Petkov , 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: <20150319172228.GT25365@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> <20150319155553.GK25365@htj.duckdns.org> <20150319160132.GG11715@pd.tnic> <20150319161241.GL25365@htj.duckdns.org> <20150319165741.GH30732@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150319165741.GH30732@dtor-ws> 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 On Thu, Mar 19, 2015 at 09:57:41AM -0700, Dmitry Torokhov wrote: > In all fairness platform_driver_probe() does pretty much the same and > forces us to mark thus drivers with PROBE_FORCE_SYNCHRONOUS as well. And > there are quite a few of them: > > dtor@dtor-ws:~/kernel/work$ grep -r "platform_driver_probe" drivers/ | > wc -l > 186 > > What makes edac unusual is that PCI bus is hot-pluggable and thus PCI > drivers are rarely one-shot. As long as it's not buried in each driver and has some generic model, it's okay. They're at least annotated and digging them out and handling them as a class of drivers is okay but we really should stay away from one-off hacks in individual drivers. Things like that add a lot of overhead in the long term. I'm just kinda baffled that Borislav's response to "that's hacky, let's not do that or do that in a generic manner" is coming back with more hacks. Thanks. -- tejun