From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe() Date: Tue, 19 Mar 2013 16:48:31 +0000 Message-ID: <201303191648.31527.arnd@arndb.de> References: <1363266691-15757-1-git-send-email-fabio.porcedda@gmail.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: Received: from moutng.kundenserver.de ([212.227.126.187]:56488 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753730Ab3CSQsm (ORCPT ); Tue, 19 Mar 2013 12:48:42 -0400 In-Reply-To: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Geert Uytterhoeven Cc: Fabio Porcedda , H Hartley Sweeten , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" , "linux-ide@vger.kernel.org" , "lm-sensors@lm-sensors.org" , "linux-input@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , Greg Kroah-Hartman , Hans-Christian Egtvedt , Grant Likely On Tuesday 19 March 2013, Geert Uytterhoeven wrote: > Hmm, so we may have drivers that (now) work perfectly fine with > module_platform_driver_probe()/platform_driver_probe(), but will start > failing suddenly in the future? They will fail if someone changes the initialization order. That would already break drivers before deferred probing support (and was the reason we added feature in the first place), but now we can be much more liberal with the order in which drivers are initialized, except when they are using platform_driver_probe() > I guess we need a big fat WARN_ON(-EPROBE_DEFER) in > platform_driver_probe() to catch these? Yes, very good idea. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757132Ab3CSQso (ORCPT ); Tue, 19 Mar 2013 12:48:44 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]:56488 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753730Ab3CSQsm (ORCPT ); Tue, 19 Mar 2013 12:48:42 -0400 From: Arnd Bergmann To: Geert Uytterhoeven Subject: Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe() Date: Tue, 19 Mar 2013 16:48:31 +0000 User-Agent: KMail/1.12.2 (Linux/3.8.0-8-generic; KDE/4.3.2; x86_64; ; ) Cc: Fabio Porcedda , H Hartley Sweeten , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" , "linux-ide@vger.kernel.org" , "lm-sensors@lm-sensors.org" , "linux-input@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , "Greg Kroah-Hartman" , "Hans-Christian Egtvedt" , Grant Likely References: <1363266691-15757-1-git-send-email-fabio.porcedda@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201303191648.31527.arnd@arndb.de> X-Provags-ID: V02:K0:4yuG0bkLjypCGhvOb8sJHv2G8/JHBU7680pzJHFvDfi MOnHH++QEQ2xmGW8qvmTh/42cQm3SWWPf/5QW5bzJ+T6tmvpCo e7GeSfO8PjsyDr1Umj3hZ3UazbO/83kJjj1oP5540INlW/CtAy 9rU4/eLQnMGeUsP3eCFZbbLmPNFLbZd2k1CLU2hbuP+ZIzGs91 onmJ1T7U02hAnQQJMsIR+qj4nuAwduHjN1gaFEYn0kEi3IvpBq sJ8i5CJy6iJeXc3NKOcpOEBve1ExAVmWdKVzdoF6Sx4RLuTAlV 8RzcZp3gbBA0cqIYH83NkUk5DhVC+8sS1R8Wr1LXNYS8/Q/jHl EVCme5RrSEoaQP4XPLFU= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 19 March 2013, Geert Uytterhoeven wrote: > Hmm, so we may have drivers that (now) work perfectly fine with > module_platform_driver_probe()/platform_driver_probe(), but will start > failing suddenly in the future? They will fail if someone changes the initialization order. That would already break drivers before deferred probing support (and was the reason we added feature in the first place), but now we can be much more liberal with the order in which drivers are initialized, except when they are using platform_driver_probe() > I guess we need a big fat WARN_ON(-EPROBE_DEFER) in > platform_driver_probe() to catch these? Yes, very good idea. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Tue, 19 Mar 2013 16:48:31 +0000 Subject: Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe() Message-Id: <201303191648.31527.arnd@arndb.de> List-Id: References: <1363266691-15757-1-git-send-email-fabio.porcedda@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Tuesday 19 March 2013, Geert Uytterhoeven wrote: > Hmm, so we may have drivers that (now) work perfectly fine with > module_platform_driver_probe()/platform_driver_probe(), but will start > failing suddenly in the future? They will fail if someone changes the initialization order. That would already break drivers before deferred probing support (and was the reason we added feature in the first place), but now we can be much more liberal with the order in which drivers are initialized, except when they are using platform_driver_probe() > I guess we need a big fat WARN_ON(-EPROBE_DEFER) in > platform_driver_probe() to catch these? Yes, very good idea. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 19 Mar 2013 16:48:31 +0000 Subject: [PATCH 10/10] drivers: misc: use module_platform_driver_probe() In-Reply-To: References: <1363266691-15757-1-git-send-email-fabio.porcedda@gmail.com> Message-ID: <201303191648.31527.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 19 March 2013, Geert Uytterhoeven wrote: > Hmm, so we may have drivers that (now) work perfectly fine with > module_platform_driver_probe()/platform_driver_probe(), but will start > failing suddenly in the future? They will fail if someone changes the initialization order. That would already break drivers before deferred probing support (and was the reason we added feature in the first place), but now we can be much more liberal with the order in which drivers are initialized, except when they are using platform_driver_probe() > I guess we need a big fat WARN_ON(-EPROBE_DEFER) in > platform_driver_probe() to catch these? Yes, very good idea. Arnd