Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754468AbaG2XOw (ORCPT ); Tue, 29 Jul 2014 19:14:52 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:59523 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750929AbaG2XOu (ORCPT ); Tue, 29 Jul 2014 19:14:50 -0400 Date: Tue, 29 Jul 2014 16:14:22 -0700 From: Greg KH To: "Luis R. Rodriguez" Cc: Santosh Rastapur , Hariprasad S , Takashi Iwai , "linux-kernel@vger.kernel.org" , Tetsuo Handa , Joseph Salisbury , Kay Sievers , One Thousand Gnomes , Tim Gardner , Pierre Fersing , Andrew Morton , Oleg Nesterov , Benjamin Poirier , Nagalakshmi Nandigama , Praveen Krishnamoorthy , Sreekanth Reddy , Abhijit Mahajan , MPT-FusionLinux.pdl@avagotech.com, Linux SCSI List , "netdev@vger.kernel.org" Subject: Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init Message-ID: <20140729231422.GA14494@kroah.com> References: <1406572110-26823-1-git-send-email-mcgrof@do-not-panic.com> <1406572110-26823-3-git-send-email-mcgrof@do-not-panic.com> <20140728185538.GB17609@kroah.com> <20140728234644.GA18729@kroah.com> <20140729003501.GA17020@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Jul 28, 2014 at 06:13:43PM -0700, Luis R. Rodriguez wrote: > >> > Why not just put the initial "register the device" in a single-shot > >> > workqueue or thread or something like that so that modprobe returns > >> > instantly back with a success and all is fine? > >> > >> That surely is possible but why not a general solution for such kludges? > > > > Because the driver should be fixed. How hard would it be to do what I > > just suggested here, 20 lines added at most? > > I appreciate the feedback, but don't look at me, I'd happy to go nutty > on ripping things apart from hairy drivers, however Chelsie folks > expressed concerns over major rework on the driver... so even if we > did have something I expect things to take a while to bake / gain > confidence from others. "rework"? Heh, here's a patch that adds 10 lines to the mptsas driver that should also work for any other driver as well. Why not just do this instead? > This also just addresses this *one* Ethernet driver, there was that > SCSI driver that created the original report -- Canonical merged > Joseph's fix as a work around, What fix was that? > there is no general solution for this yet, and again with that work > around you won't find which drivers run into this issue. Great, fix them as they are found, that's fine. Again, don't add stuff to the driver core to paper over crappy drivers, I'm not going to take that type of change. I _only_ took the defer binding code as there was no other way for an individual driver to deal with things if it's resources were not present yet due to binding order in the system. So, anyone care to test the patch below on a system that has this problem to let me know if it would work or not? Odds are, this should be a workqueue, to make it cleaner, but a kthread is just so easy to use... thanks, greg k-h diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c index 711fcb5cec87..4fd4f36a2d9e 100644 --- a/drivers/message/fusion/mptsas.c +++ b/drivers/message/fusion/mptsas.c @@ -51,6 +51,7 @@ #include #include #include /* for mdelay */ +#include #include #include @@ -5393,8 +5394,7 @@ static struct pci_driver mptsas_driver = { #endif }; -static int __init -mptsas_init(void) +static int mptsas_real_init(void *data) { int error; @@ -5429,9 +5429,19 @@ mptsas_init(void) return error; } +static struct task_struct *init_thread; + +static int __init +mptsas_init(void) +{ + init_thread = kthread_run(mptsas_real_init, NULL, "mptsas_init"); + return 0; +} + static void __exit mptsas_exit(void) { + kthread_stop(init_thread); pci_unregister_driver(&mptsas_driver); sas_release_transport(mptsas_transport_template); -- 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/