From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754590Ab3AVPir (ORCPT ); Tue, 22 Jan 2013 10:38:47 -0500 Received: from comal.ext.ti.com ([198.47.26.152]:40114 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753725Ab3AVPiq (ORCPT ); Tue, 22 Jan 2013 10:38:46 -0500 Message-ID: <50FEB275.80504@ti.com> Date: Tue, 22 Jan 2013 16:38:29 +0100 From: Peter Ujfalusi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130115 Thunderbird/17.0.2 MIME-Version: 1.0 To: kishon CC: Roger Quadros , , , , , , , , , , , Subject: Re: [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot References: <1358848694-20145-1-git-send-email-kishon@ti.com> <1358848694-20145-7-git-send-email-kishon@ti.com> <50FE9F5C.2010501@ti.com> <50FEA447.1090701@ti.com> <50FEA696.8000506@ti.com> <50FEAE96.30706@ti.com> In-Reply-To: <50FEAE96.30706@ti.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/22/2013 04:21 PM, kishon wrote: > But it's better to check if deferred probing > takes place whenever a new driver is bound to a device as you just mentioned. Whenever you load (might be also when you unload) a driver the deferred modules will try to probe again. This is to check back if the dependency of the deferred modules has been fulfilled by the new driver or not. -- Péter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Ujfalusi Subject: Re: [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot Date: Tue, 22 Jan 2013 16:38:29 +0100 Message-ID: <50FEB275.80504@ti.com> References: <1358848694-20145-1-git-send-email-kishon@ti.com> <1358848694-20145-7-git-send-email-kishon@ti.com> <50FE9F5C.2010501@ti.com> <50FEA447.1090701@ti.com> <50FEA696.8000506@ti.com> <50FEAE96.30706@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <50FEAE96.30706-l0cyMroinI0@public.gmane.org> Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: kishon Cc: Roger Quadros , linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, balbi-l0cyMroinI0@public.gmane.org, eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On 01/22/2013 04:21 PM, kishon wrote: > But it's better to check if deferred probing > takes place whenever a new driver is bound to a device as you just me= ntioned. Whenever you load (might be also when you unload) a driver the deferred modules will try to probe again. This is to check back if the dependenc= y of the deferred modules has been fulfilled by the new driver or not. --=20 P=E9ter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter.ujfalusi@ti.com (Peter Ujfalusi) Date: Tue, 22 Jan 2013 16:38:29 +0100 Subject: [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot In-Reply-To: <50FEAE96.30706@ti.com> References: <1358848694-20145-1-git-send-email-kishon@ti.com> <1358848694-20145-7-git-send-email-kishon@ti.com> <50FE9F5C.2010501@ti.com> <50FEA447.1090701@ti.com> <50FEA696.8000506@ti.com> <50FEAE96.30706@ti.com> Message-ID: <50FEB275.80504@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 01/22/2013 04:21 PM, kishon wrote: > But it's better to check if deferred probing > takes place whenever a new driver is bound to a device as you just mentioned. Whenever you load (might be also when you unload) a driver the deferred modules will try to probe again. This is to check back if the dependency of the deferred modules has been fulfilled by the new driver or not. -- P?ter