[PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Lu Baolu]

Phy drivers and the ulpi interface providers depend on the
registration of the ulpi bus.  Ulpi registers the bus in
module_init(). This could cause unnecessary probe delays.

Reported-by: Zhuo Qiuxu <qiuxu.zhuo@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
 drivers/usb/common/ulpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..01c0c04 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -242,7 +242,7 @@ static int __init ulpi_init(void)
 {
 	return bus_register(&ulpi_bus);
 }
-module_init(ulpi_init);
+subsys_initcall(ulpi_init);
 
 static void __exit ulpi_exit(void)
 {
-- 
2.1.4

Re: [PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Greg Kroah-Hartman]

On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote:
> Phy drivers and the ulpi interface providers depend on the
> registration of the ulpi bus.  Ulpi registers the bus in
> module_init(). This could cause unnecessary probe delays.

What do you mean by "probe delays"?

> 
> Reported-by: Zhuo Qiuxu <qiuxu.zhuo@intel.com>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
>  drivers/usb/common/ulpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index 0e6f968..01c0c04 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -242,7 +242,7 @@ static int __init ulpi_init(void)
>  {
>  	return bus_register(&ulpi_bus);
>  }
> -module_init(ulpi_init);
> +subsys_initcall(ulpi_init);

Hasn't this already been rejected?

confused,

greg k-h

Re: [PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Greg Kroah-Hartman]

On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote:
> Phy drivers and the ulpi interface providers depend on the
> registration of the ulpi bus.  Ulpi registers the bus in
> module_init(). This could cause unnecessary probe delays.
> 
> Reported-by: Zhuo Qiuxu <qiuxu.zhuo@intel.com>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
>  drivers/usb/common/ulpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

A v4 patch with no "changelog" as to what is different from previous
versions?  That's reason enough for me to just ignore this :(

Re: [PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[David Cohen]

Hi,

On Tue, May 26, 2015 at 07:37:02PM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote:
> > Phy drivers and the ulpi interface providers depend on the
> > registration of the ulpi bus.  Ulpi registers the bus in
> > module_init(). This could cause unnecessary probe delays.
> 
> What do you mean by "probe delays"?

I believe he meant the bus users' probe delays. i.e. unnecessary
-EPROBE_DEFER happening on ulpi_drivers in case they're registered
before ulpi bus itself.

Is that correct, Baolu?

Br, David

Re: [PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Lu, Baolu]

On 05/28/2015 12:53 AM, David Cohen wrote:
> Hi,
>
> On Tue, May 26, 2015 at 07:37:02PM -0700, Greg Kroah-Hartman wrote:
>> On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote:
>>> Phy drivers and the ulpi interface providers depend on the
>>> registration of the ulpi bus.  Ulpi registers the bus in
>>> module_init(). This could cause unnecessary probe delays.
>> What do you mean by "probe delays"?
> I believe he meant the bus users' probe delays. i.e. unnecessary
> -EPROBE_DEFER happening on ulpi_drivers in case they're registered
> before ulpi bus itself.
>
> Is that correct, Baolu?

Yes.

>
> Br, David
> --
> 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/
>

Re: [PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Heikki Krogerus]

Hi Baolu,

On Thu, May 28, 2015 at 08:50:12AM +0800, Lu, Baolu wrote:
> On 05/28/2015 12:53 AM, David Cohen wrote:
> >Hi,
> >
> >On Tue, May 26, 2015 at 07:37:02PM -0700, Greg Kroah-Hartman wrote:
> >>On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote:
> >>>Phy drivers and the ulpi interface providers depend on the
> >>>registration of the ulpi bus.  Ulpi registers the bus in
> >>>module_init(). This could cause unnecessary probe delays.
> >>What do you mean by "probe delays"?
> >I believe he meant the bus users' probe delays. i.e. unnecessary
> >-EPROBE_DEFER happening on ulpi_drivers in case they're registered
> >before ulpi bus itself.
> >
> >Is that correct, Baolu?
> 
> Yes.

Could you prepare one more version of this patche with the change log
included.


Thanks,

-- 
heikki

Re: [PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Lu, Baolu]

On 06/04/2015 08:17 PM, Heikki Krogerus wrote:
> Hi Baolu,
>
> On Thu, May 28, 2015 at 08:50:12AM +0800, Lu, Baolu wrote:
>> On 05/28/2015 12:53 AM, David Cohen wrote:
>>> Hi,
>>>
>>> On Tue, May 26, 2015 at 07:37:02PM -0700, Greg Kroah-Hartman wrote:
>>>> On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote:
>>>>> Phy drivers and the ulpi interface providers depend on the
>>>>> registration of the ulpi bus.  Ulpi registers the bus in
>>>>> module_init(). This could cause unnecessary probe delays.
>>>> What do you mean by "probe delays"?
>>> I believe he meant the bus users' probe delays. i.e. unnecessary
>>> -EPROBE_DEFER happening on ulpi_drivers in case they're registered
>>> before ulpi bus itself.
>>>
>>> Is that correct, Baolu?
>> Yes.
> Could you prepare one more version of this patche with the change log
> included.

Sure. I will resent it soon.

>
>
> Thanks,
>