Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752741AbaG1PrN (ORCPT ); Mon, 28 Jul 2014 11:47:13 -0400 Received: from mx0b-0016ce01.pphosted.com ([67.231.156.153]:40242 "EHLO mx0b-0016ce01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999AbaG1PrK convert rfc822-to-8bit (ORCPT ); Mon, 28 Jul 2014 11:47:10 -0400 From: Yuval Mintz To: "Luis R. Rodriguez" CC: "Luis R. Rodriguez" , "gregkh@linuxfoundation.org" , linux-kernel , 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 , Hariprasad S , Santosh Rastapur , "MPT-FusionLinux.pdl@avagotech.com" , linux-scsi , netdev Subject: RE: [PATCH 1/3] driver core: enable drivers to use deferred probe from init Thread-Topic: [PATCH 1/3] driver core: enable drivers to use deferred probe from init Thread-Index: AQHPqnnzAnxQWE7GzUSaZGTElDLpfpu1n4JQ Date: Mon, 28 Jul 2014 15:46:32 +0000 Message-ID: References: <1406558067-25308-1-git-send-email-mcgrof@do-not-panic.com> <20140728153811.GD21930@wotan.suse.de> In-Reply-To: <20140728153811.GD21930@wotan.suse.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.4.10] disclaimer: bypass Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7512 signatures=670489 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407280182 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from > init > > On Mon, Jul 28, 2014 at 03:12:11PM +0000, Yuval Mintz wrote: > > Perhaps this is a silly question, but what guarantees that the > > deferred probe list will actually be triggered, e.g., in case the > > delayed device is the last device in the system? > > The dev->init_delayed_probe is used to ensure that we'd add the device to the > deferred probe list once making this a per device thing if the driver has the field > delay_probe set to true. This technically also allows this to be a per device thing > so with some more work we could enable drivers to only enable this for specific > devices but at this point this did not seem required. Sorry for not being clear, but I didn't meant 'what guarantees that the device will be added to the deferred probe', but rather what guarantees that the deferred workqueue will be scheduled. To the best of my knowledge the deferring mechanism works only if one device is dependent upon another, e.g., for Multi-function devices where one device probe is dependent upon the others - which are soon-to-be probed. [If I'm incorrect I'd appreciate if someone could correct me] > > > [From drivers/base/dd.c - "A successful driver probe will trigger > > moving all devices from the pending to the active list so that the > > workqueue will eventually retry them] -- 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/