Re: [PATCH] usb: Make sure usb/phy/of gets built-in

2017-04-17 Thread Frank Rowand 
On 04/13/17 05:33, Alexey Brodkin wrote:
> DWC3 driver uses of_usb_get_phy_mode() which is
> implemented in drivers/usb/phy/of.c and in bare minimal
> configuration it might not be pulled in kernel binary.
> 
> In case of ARC or ARM this could be easily reproduced with
> "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m.
> 
> On building all ends-up with:
> -->8--
>   Kernel: arch/arm/boot/Image is ready
>   Kernel: arch/arm/boot/zImage is ready
>   Building modules, stage 2.
>   MODPOST 5 modules
> ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> -->8--
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Greg Kroah-Hartman 
> Cc: Masahiro Yamada 
> Cc: Geert Uytterhoeven 
> Cc: Nicolas Pitre 
> Cc: Thomas Gleixner 
> Cc: Felipe Balbi 
> Cc: Felix Fietkau 
> Cc: Jeremy Kerr 
> Cc: linux-snps-...@lists.infradead.org
> Cc: sta...@vger.kernel.org
> ---
>  drivers/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 2eced9afba53..8f8bdc9e3d29 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -104,6 +104,7 @@ obj-$(CONFIG_USB_PHY) += usb/
>  obj-$(CONFIG_USB)+= usb/
>  obj-$(CONFIG_PCI)+= usb/
>  obj-$(CONFIG_USB_GADGET) += usb/

> +obj-$(CONFIG_OF) += usb/

Would CONFIG_USB_SUPPORT make more sense? (And does it work?)


>  obj-$(CONFIG_SERIO)  += input/serio/
>  obj-$(CONFIG_GAMEPORT)   += input/gameport/
>  obj-$(CONFIG_INPUT)  += input/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

2015-10-22 Thread Frank Rowand 
On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> 
> 
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>> But that's moot currently because Greg believes that the time spent
>> probing devices at boot time could be reduced enough so that the order
>> in which devices are probed becomes irrelevant. IME that would have to
>> be under 200ms so that the user doesn't notice and that's unicorn-far
>> from any bootlog I have ever seen.
> 
> But as no one has actually produced a bootlog, how do you know that?
> Where exactly is your time being spent?  What driver is causing long
> delays?  Why is the long-delay-drivers not being done in their own
> thread?  And most importantly, why are you ignoring the work that people
> did back in 2008 to solve the issue on other hardware platforms?
> 
>> Given that downstreams are already carrying as many hacks as they
>> could think of to speed total boot up, I think this is effectively
>> telling them to go away.
> 
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.
> 
> And when I ask for real data, you respond with the fact that you aren't
> trying to speed up boot time here at all, so what am I supposed to think

I also had the understanding that this patch series was about improving
boot time.  But I was kindly corrected that the behavior change was
getting the panel displaying stuff at an earlier point in the boot sequence,
_not_ completing the entire boot faster. 

The claim for the current series, in patch 0 in v7 is:

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

Just to get side-tracked, one other approach at ordering to reduce
deferrals reported a modest boot time reduction for four boards and a
very slight boot time increase for one other board.) The report of boot
times with that approach was in:

  http://article.gmane.org/gmane.linux.drivers.devicetree/133010

from Alexander Holler.

I have not searched further to see if there is more data of boot time
reductions from any of the other attempts to change driver binding
order to move dependencies before use of a resource.  But whether
there is a performance improvement or not, there continues to be
a stream of developers creatively impacting the binding order for
their specific driver(s) or board.  So it seems that maybe there
is an underlying problem, or we don't have adequate documentation
explaining how to avoid a need to order bindings, or the
documentation exists and is not being read.

I have been defaulting to the position that has been asserted by
the device tree maintainters, that probe deferrals work just fine
for at least the majority of cases (and is the message I have been
sharing in my conference presentations about device tree).  But I
suspect that there is at least a small minority of cases that are not
well served by probe deferral.  (Not to be read as an endorsement of
this specific patch series, just a generic observation.)

-Frank

> other than that you don't care enough to do the real work and are trying
> to hack the driver core up instead.
> 
>> Sorry for the rant,
> 
> No apologies needed, it's cathartic at times :)
> 
> thanks,
> 
> greg k-h
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

2015-10-21 Thread Frank Rowand 
On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> On 18 October 2015 at 21:53, Mark Brown  wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
 On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

< snip >

> hope you don't mind I summarize the points taken instead of replying
> to the individual emails. I tried to address all the concerns that
> have been raised again in the cover letter, but I guess I did a bad
> job at explaining myself, so here's another (more in-depth) go at it.

< snip >

> 3) Regarding total boot time, I don't expect this series to make much
> of a difference because though we would save a lot of matching and
> querying for resources, that's little time compared with how long we
> wait for hardware to react during probing. Async probing is more
> likely to help with drivers that take a long time to probe.

And then in your reply to Russell's reply to your email you say:

> To be clear, I was saying that this series should NOT affect total
> boot times much.

I'm confused.  If I understood correctly, improving boot time was
the key justification for accepting this patch set.  For example,
from "[PATCH v7 0/20] On-demand device probing":

   I have a problem with the panel on my Tegra Chromebook taking longer
   than expected to be ready during boot (Stéphane Marchesin reported what
   is basically the same issue in [0]), and have looked into ordered
   probing as a better way of solving this than moving nodes around in the
   DT or playing with initcall levels and linking order.

   ...

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

Alexander Holler reported improved boot times for his patch set
in August, which is another approach to ordering probes
(http://article.gmane.org/gmane.linux.drivers.devicetree/133010).
His results for 5 boards was four booted faster, one slightly
slower:

   Some numbers (5 boots on each board, without and with ordering drivers),
   all times are seconds.

   Kirkwood (dockstar, armv5):

   Boot to "Freeing unused kernel memory" (includes mounting the rootfs),
   unordered:
   4.456016 3.937801 4.114788 4.114526 3.949480 (average 4.1145222)
   ordered:
   3.173054 3.164045 3.141418 3.480679 3.459298 (3.2836988)
   Time needed to sort (of_init_build_order()):
   0.003024
   Time needed to match drivers to the order (without calling them):
   0.002884

   Beagleboard (rev C4, armv7):

   unordered:
   6.706024 6.821746 6.696014 6.673675 6.769866 (6.733465)
   ordered:
   5.544860 5.514160 5.505859 5.527374 5.496795 (5.5178096)
   sorting: 0.021209
   matching: 0.006165

   Beaglebone Black (rev A5, armv7):

   unordered:
   3.826531 3.825662 3.826648 3.825434 3.825263 (3.8259076)
   ordered:
   2.838554 2.838322 2.839459 2.838467 2.838421 (2.8386446)
   sorting: 0.004769
   matching: 0.004860

   imx6q (armv7):

   unordered:
   3.451998 3.418864 3.446952 3.429974 3.440996 (3.4377568)
   ordered:
   3.538312 3.549019 3.538105 3.515916 3.555715 (3.5394134)
   sorting: 0.004622
   matching: 0.003868

While not as dramatic as your results, they are somewhat supportive.
What has changed your assessment that the on-demand device probing
patches will give a big boot performance increase?  Do you have
new data or analysis?

-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Alternative approach to solve the deferred probe

2015-10-21 Thread Frank Rowand 
On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:

< snip >

>>> +
>>>  static bool driver_deferred_probe_enable = false;
>>> +
>>>  /**
>>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>   *
>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>> driver_deferred_probe_trigger();
>>
>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>> not add another round of probes.
> 
> The idea is not to report anything for drivers that were deferred
> during the normal bootup.  The above is part of the normal bootup,
> and the deferred activity should not be warned about.

The above is currently the last point for probe to succeed or defer
(until possibly, as you mentioned, module loading resolves the defer).
If a probe defers above, it will defer again below.  The set of defers
should be exactly the same above and below.

> 
> If we have any devices still deferring after _this_ round, that must
> indicate that some resource they want is not available, and that
> should be warned about.
> 
> Of course, modules can defer too - and I made some suggestions in my
> waffle above the patch about that.
> 

< adding back trimmed, for fuller context >

>>> /* Sort as many dependencies as possible before exiting initcalls */
>>> flush_workqueue(deferred_wq);
>>> +
>>> +   /* Now one final round, reporting any devices that remain deferred */
>>> +   driver_deferred_probe_report = true;
>>> +   driver_deferred_probe_trigger();
>>> +   /* Sort as many dependencies as possible before exiting initcalls */
>>> +   flush_workqueue(deferred_wq);
>>> +
>>> return 0;
>>>  }
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Alternative approach to solve the deferred probe

2015-10-21 Thread Frank Rowand 
On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>>   static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>>   /**
>>>>>* driver_deferred_probe_trigger() - Kick off re-probing deferred 
>>>>> devices
>>>>>*
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>   driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup.  The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below.  The set of defers
>> should be exactly the same above and below.
>>
> 
> Unfortunately this is not "the last point for probe to succeed or defer".
> There are still a bunch of drivers in Kernel which will be probed at 
> late_initcall() level.
> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);

Yes, cpsw_init() should _not_ be a late_initcall.  This is yet another
example of playing games with ordering probes that we have been trying
to eliminate.

Thanks for pointing out one of the resulting problems this causes for the
deferred probe mechanism.

> Yes - they probably need to be updated to use module_init(), but that's what
> we have now). Those drivers will re-trigger deferred device probing if their
> probe succeeded.

Yes, if cpsw_init() leads to a successful probe, then deferred device probing
will be re-triggered.  I do not know if cpsw_init() will be called before or
after deferred_probe_initcall().  The general initcall mechanism does not
provide any ordering guarantees between the two functions because they are
at the same initcall level.

> 
> As result, it is impossible to say when will it happen the 
> "final round of deferred device probing" :( and final list of drivers which
> was "deferred forever" will be know only when kernel exits to User space 
> ("deferred forever" - before loading modules).
> 
> May be, we also can consider adding debug_fs entry which can be used to 
> display
> actual state of deferred_probe_pending_list? 
> 
>>>
>>> If we have any devices still deferring after _this_ round, that must
>>> indicate that some resource they want is not available, and that
>>> should be warned about.
>>>
>>> Of course, modules can defer too - and I made some suggestions in my
>>> waffle above the patch about that.
>>>
>>
>> < adding back trimmed, for fuller context >
>>
>>>>>   /* Sort as many dependencies as possible before exiting 
>>>>> initcalls */
>>>>>   flush_workqueue(deferred_wq);
>>>>> +
>>>>> + /* Now one final round, reporting any devices that remain deferred */
>>>>> + driver_deferred_probe_report = true;
>>>>> + driver_deferred_probe_trigger();
>>>>> + /* Sort as many dependencies as possible before exiting initcalls */
>>>>> + flush_workqueue(deferred_wq);
>>>>> +
>>>>>   return 0;
>>>>>   }
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

2015-10-21 Thread Frank Rowand 
On 10/21/2015 9:27 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> 
>>> To be clear, I was saying that this series should NOT affect total
>>> boot times much.
> 
>> I'm confused.  If I understood correctly, improving boot time was
>> the key justification for accepting this patch set.  For example,
>> from "[PATCH v7 0/20] On-demand device probing":
>>
>>I have a problem with the panel on my Tegra Chromebook taking longer
>>than expected to be ready during boot (Stéphane Marchesin reported what
>>is basically the same issue in [0]), and have looked into ordered
>>probing as a better way of solving this than moving nodes around in the
>>DT or playing with initcall levels and linking order.
>>
>>...
>>
>>With this series I get the kernel to output to the panel in 0.5s,
>>instead of 2.8s.
> 
> Overall boot time and time to get some individual built in component up
> and running aren't the same thing - what this'll do is get things up
> more in the link order of the leaf consumers rather than deferring those
> leaf consumers when their dependencies aren't ready yet.

Thanks!  I read too much into what was being improved.

So this patch series, which on other merits may be a good idea, is as
a by product solving a specific ordering issue, moving successful panel
initialization to an earlier point in the boot sequence, if I now
understand more correctly.

In that context, this seems like yet another ad hoc way of causing the
probe order to change in a way to solves one specific issue?  Could
it just as likely move the boot order of some other driver on some
other board later, to the detriment of somebody else?


> 
>> While not as dramatic as your results, they are somewhat supportive.
>> What has changed your assessment that the on-demand device probing
>> patches will give a big boot performance increase?  Do you have
>> new data or analysis?
> 
> See above, my understanding was that the performance improvements were
> more around improved control/predictability/handwave of the boot
> ordering rather than total time.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

2015-10-21 Thread Frank Rowand 
On 10/21/2015 2:12 PM, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.l...@gmail.com> wrote:
>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>
>>>>> To be clear, I was saying that this series should NOT affect total
>>>>> boot times much.
>>>
>>>> I'm confused.  If I understood correctly, improving boot time was
>>>> the key justification for accepting this patch set.  For example,
>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>
>>>>I have a problem with the panel on my Tegra Chromebook taking longer
>>>>than expected to be ready during boot (Stéphane Marchesin reported what
>>>>is basically the same issue in [0]), and have looked into ordered
>>>>probing as a better way of solving this than moving nodes around in the
>>>>DT or playing with initcall levels and linking order.
>>>>
>>>>...
>>>>
>>>>With this series I get the kernel to output to the panel in 0.5s,
>>>>instead of 2.8s.
>>>
>>> Overall boot time and time to get some individual built in component up
>>> and running aren't the same thing - what this'll do is get things up
>>> more in the link order of the leaf consumers rather than deferring those
>>> leaf consumers when their dependencies aren't ready yet.
>>
>> Thanks!  I read too much into what was being improved.
>>
>> So this patch series, which on other merits may be a good idea, is as
>> a by product solving a specific ordering issue, moving successful panel
>> initialization to an earlier point in the boot sequence, if I now
>> understand more correctly.
>>
>> In that context, this seems like yet another ad hoc way of causing the
>> probe order to change in a way to solves one specific issue?  Could
>> it just as likely move the boot order of some other driver on some
>> other board later, to the detriment of somebody else?
> 
> Time to display on is important for many products. Having the console
> up as early as possible is another case. CAN bus is another. This is a
> real problem that is not just bad drivers.

Yes, I agree.

What I am seeing is that there continues to be a need for the ability
to explicitly order at least some driver initialization (at some
granularity), despite the push back against explicit ordering that
has been present in the past.


> I don't think it is completely ad hoc. Given all devices are
> registered after drivers, drivers will still probe first in initcall
> level order and then link order AFAIK. We may not take (more) initcall
> level tweak hacks, but that is a much more simple change for
> downstream. Don't get me wrong, I'd really like to see a way to
> control order independent of initcall level.
> 
> Rob

Yep, it is not directly ad hoc, just a fortunate side effect in
this case.  So just accidently ad hoc. :-)

-Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Alternative approach to solve the deferred probe

2015-10-21 Thread Frank Rowand 
On 10/21/2015 1:35 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>>  static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>>  /**
>>>>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>   *
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>   driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup.  The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below.  The set of defers
>> should be exactly the same above and below.
> 
> Why should it?

My assertion was incorrect.  A probe in the deferral processing can
result in the driver being placed on the new deferred list, then when
a later probe of another deferred driver succeeds, the first driver
will be moved to the active deferred list, and might succeed on
the second probe attempt (or with the current messages would result
in a second set of deferred messages).  So yes, placing
"driver_deferred_probe_report = true" where your patch put it and
running through the deferred probe processing again is correct.

-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Alternative approach to solve the deferred probe

2015-10-20 Thread Frank Rowand 
On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
>> Hi Russell,
>>
>> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>>  wrote:
> What you can do is print those devices which have failed to probe at
> late_initcall() time - possibly augmenting that with reports from
> subsystems showing what resources are not available, but that's only
> a guide, because of the "it might or might not be in a kernel module"
> problem.

 Well, adding those reports would give you a changelog similar to the
 one in this series...
>>>
>>> I'm not sure about that, because what I was thinking of is adding
>>> a flag which would be set at late_initcall() time prior to running
>>> a final round of deferred device probing.
>>
>> Which round is the final round?
>> That's the one which didn't manage to bind any new devices to drivers,
>> which is something you only know _after_ the round has been run.
>>
>> So I think we need one extra round to handle this.
>>
>>> This flag would then be used in a deferred_warn() printk function
>>> which would normally be silent, but when this flag is set, it would
>>> print the reason for the deferral - and this would replace (or be
>>> added) to the subsystems and drivers which return -EPROBE_DEFER.
>>>
>>> That has the effect of hiding all the deferrals up until just before
>>> launching into userspace, which should then acomplish two things -
>>> firstly, getting rid of the rather useless deferred messages up to
>>> that point, and secondly printing the reason why the remaining
>>> deferrals are happening.
>>>
>>> That should be a small number of new lines plus a one-line change
>>> in subsystems and drivers.
>>
>> Apart from the extra round we probably can't get rid of, that sounds OK to 
>> me.
> 
> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
> 
> We could make driver_deferred_probe_report something that can be
> deactivated again after the last deferred probe run, and provide the
> user with a knob that they can turn it back on again.
> 
> I've tried this out on two of my platforms, including forcing
> driver_deferred_probe_report to be enabled, and I get exactly one
> deferred probe, so not a particularly good test.
> 
> The patch won't apply as-is to mainline for all files; it's based on my
> tree which has some 360 additional patches (which seems to be about
> normal for my tree now.)

I like the concept (I have been thinking along similar lines lately).
But I think this might make the console messages more confusing than
they are now.  The problem is that debug, warn, and error messages
come from a somewhat random set of locations at the moment.  Some
come from the driver probe routines and some come from the subsystems
that the probe routines call.  So the patch is suppressing some
messages, but not others.

One thing that seemed pretty obvious from the patches is that the
current probe routines are somewhat inconsistent in terms of messages,
and that there is room for a set of best practices for messaging.  That
is on my long term wish list, but I'm not sure I'll ever chase after
those windmills.

A couple of specific comments below.


> 
>  drivers/base/dd.c   | 29 +
>  drivers/base/power/domain.c |  7 +--
>  drivers/clk/clkdev.c|  9 -
>  drivers/gpio/gpiolib-of.c   |  5 +
>  drivers/gpu/drm/bridge/dw_hdmi.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
>  drivers/gpu/drm/imx/imx-ldb.c   |  5 +++--
>  drivers/gpu/drm/msm/dsi/dsi.c   |  2 +-
>  drivers/gpu/drm/msm/msm_drv.c   |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
>  drivers/of/irq.c|  5 -
>  drivers/pci/host/pci-mvebu.c|  1 +
>  drivers/pinctrl/core.c  |  5 +++--
>  drivers/pinctrl/devicetree.c|  4 ++--
>  drivers/regulator/core.c|  5 +++--
>  include/linux/device.h  |  1 +
>  16 files changed, 71 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index be0eb4639128..bb12224f2901 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
>   mutex_unlock(_probe_mutex);
>  }
>  
> +static bool driver_deferred_probe_report;
> +
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void

Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout

2013-03-22 Thread Frank Rowand 
On 03/22/13 03:03, Mats Liljegren wrote:
 Frank Rowand wrote:
 On 03/21/13 07:41, Alan Stern wrote:
 On Wed, 20 Mar 2013, Frank Rowand wrote:

 Hi All,

 Not quite sure quite where the problem is (USB, OMAP, smsc95xx driver, 
 other???),
 so casting the nets wide...

 The PandaBoard frequently fails to boot with an eth0 error when mounting
 the root file system via NFS (ethernet driver fails due to a USB timeout;
 no ethernet means NFS won't work).  A typical set of error messages is:

 [3.264373] smsc95xx 1-1.1:1.0: usb_probe_interface
 [3.269500] smsc95xx 1-1.1:1.0: usb_probe_interface - got id
 [3.275543] smsc95xx v1.0.4
 [8.078674] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at 
 usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 82:b9:1d:fa:67:0d
 [8.091003] hub 1-1:1.0: state 7 ports 5 chg  evt 0002
 [   13.509918] usb 1-1.1: swapper/0 timed out on ep0out len=0/4
 [   13.515869] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 
 0x0108
 [   13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
 [   13.529998] IP-Config: Failed to open eth0

 I have bisected this to:

   commit 18aafe64d75d0e27dae206cacf4171e4e485d285
   Author: Alan Stern st...@rowland.harvard.edu
   Date:   Wed Jul 11 11:23:04 2012 -0400

  USB: EHCI: use hrtimer for the I/O watchdog

 I don't understand how that commit could cause a timeout unless there 
 are at least two other bugs present in your system.

 Note that to compile this version of the kernel, an additional fix must
 also be applied:

   commit ba5952e0711b14d8d4fe172671f8aa6091ace3ee
   Author: Ming Lei ming@canonical.com
   Date:   Fri Jul 13 17:25:24 2012 +0800

  USB: ehci-omap: fix compile failure(v1)

 The symptom can be worked around by retrying the USB access if a timeout
 occurs.  This is clearly _not_ the fix, just a hack that I used to
 investigate the problem:

   http://article.gmane.org/gmane.linux.rt.user/9773

 My kernel configuration is:

   arch/arm/configs/omap2plus_defconfig

   plus to get the ethernet driver I add:

 CONFIG_USB_EHCI_HCD
 CONFIG_USB_NET_SMSC95XX

 I found the problem on 3.6.11, but have not replicated it on 3.9-rcX
 yet because my config fails to build on 3.9-rc1 and 3.9-rc2.  I'll try
 to work on that issue tomorrow.

 Let me know how it works out.

 My PandaBoard builds fail on 3.9-rcX due to ARM multiplatform issues.
 Either there is something I need to change about the way I build it,
 or it is broken (that is a side issue).  My simple expedient was to
 hack around multiplatform, and just make it build (patch below if
 anyone else wants a _temporary_ hack).
 
 I have built 3.9-RC2 for PandaBoard ES and the only problem I have seen is
 that you need to add LOADADDR=0x80008000 when building uImage target.

Yes, that is essentially what my hack patch does.  The result of my patch
is that arch/arm/boot/Makefile is invoked with MACHINE=arch/arm/mach-omap2
so that at the top of the makefile, the include 
$(srctree)/$(MACHINE)/Makefile.boot
which pulls in the proper values for addresses.

-Frank


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout

2013-03-21 Thread Frank Rowand 
On 03/21/13 02:00, Ming Lei wrote:
 Hi Frank,
 
 On Thu, Mar 21, 2013 at 11:29 AM, Frank Rowand frank.row...@am.sony.com 
 wrote:

 I found the problem on 3.6.11, but have not replicated it on 3.9-rcX
 yet because my config fails to build on 3.9-rc1 and 3.9-rc2.  I'll try
 to work on that issue tomorrow.
 
 I play upstream kernel on Pandaboard A1 frequently, looks not
 see the failure problem before. Maybe the problem is config dependent.
 
 If you may share your config file, I'd like to do the test too.

I will do a separate reply with the actual config at the point where
the bisect completed.

I create the config for each commit during the bisect with scripts
that do the equivalent of:

  make omap2plus_defconfig

  make menuconfig

# this allows USB thumb drive
# Device Drivers - USB support - EHCI HCD (USB 2.0) support
CONFIG_USB_EHCI_HCD=y

# ethernet device
# Device Drivers - Network device support - USB Network Adapters -
#  Multi-purpose USB Networking Framework -
#  SMSC LAN95XX based USB 2.0 10/100 ethernet devices
CONFIG_USB_NET_SMSC95XX=y


Some more random information that may be helpful

--
$ cat /proc/cmdline 
ip=192.168.1.85:192.168.1.1:192.168.1.1:255.255.255.0:panda 
nfsroot=192.168.1.1:/a/target/panda root=/dev/nfs ip=dhcp mem=463M 
console=ttyO2,115200n8 debug earlyprintk


--
The percentage of boots that show the problem varies quite a bit between
the kernel versions that I tried during my bisect.  For my first attempt
at bisecting, I decided a version was good if it booted 12 times.  That
bisect failed for various reasons.  For my second attempt at bisecting,
I decided a version was good if it booted 18 times.


--
There are some timeout messages that I am not positive are symptoms of
the problem.  With these messages, the smsc95xx driver initialization is
successful, so the ethernet device is available.  For the first bisect
attempt, I did not treat these messages as errors.  For the second bisect
attempt I treated these messages as errors.  A typical example of the
timeout message is:

  [9.537811] hub 1-1:1.0: state 7 ports 5 chg  evt 0002
  [   17.056701] usb 1-1.1: swapper/0 timed out on ep0out len=0/4
  [   17.062652] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 
0x0108
  [   17.070343] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
  [   17.076751] IP-Config: Failed to open eth0

  The mention of swapper is not relevent, it just happens to be the
  current process when the time out occurs.

I have only seen these timeout messages in the boot log, so they may not
be a very visible symptom.  They also _might_ be unrelated to the problem,
but my gut feel is that they are related.


--
The problem manifests as a timeout from at least two different locations
in drivers/net/usb/smsc95xx.c:

 656 static int smsc95xx_set_mac_address(struct usbnet *dev)
 657 {
 ...
 663 ret = smsc95xx_write_reg(dev, ADDRL, addr_lo);
 664 if (ret  0) {
 665 netdev_warn(dev-net, Failed to write ADDRL: %d\n, ret);
 666 return ret;
 667 }

751 static int smsc95xx_reset(struct usbnet *dev)
 752 {
 ...
 783 write_buf = PM_CTL_PHY_RST_;
 784 ret = smsc95xx_write_reg(dev, PM_CTRL, write_buf);
 785 if (ret  0) {
 786 netdev_warn(dev-net, Failed to write PM_CTRL: %d\n, 
ret);
 787 return ret;
 788 }

There may be additional locations.  These are just two that I captured when
debugging.  Some of the other smsc95xx_write_reg() calls in smsc95xx_reset()
are protected with checks for timeout, with up to 100 retries.  I don't know
if more checks for timeout, or longer timeout, is a solution or just an
incorrect way of papering over the real problem -- this is not an area of
expertise for me.


Thanks,

Frank

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout

2013-03-21 Thread Frank Rowand 
On 03/21/13 13:25, Frank Rowand wrote:
 On 03/21/13 02:00, Ming Lei wrote:

 snip 

 --
 There are some timeout messages that I am not positive are symptoms of
 the problem.  With these messages, the smsc95xx driver initialization is
 successful, so the ethernet device is available.  For the first bisect
 attempt, I did not treat these messages as errors.  For the second bisect
 attempt I treated these messages as errors.  A typical example of the
 timeout message is:
 
   [9.537811] hub 1-1:1.0: state 7 ports 5 chg  evt 0002
   [   17.056701] usb 1-1.1: swapper/0 timed out on ep0out len=0/4
   [   17.062652] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 
 0x0108
   [   17.070343] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
   [   17.076751] IP-Config: Failed to open eth0

Oops, pasted the wrong example.  This is an example of a timeout, but the
driver still works, and the system boots:

  [6.072357] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at 
usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, fa:50:73:02:79:67
  [6.084655] hub 1-1:1.0: state 7 ports 5 chg  evt 0002
  [   11.220672] usb 1-1.1: swapper/0 timed out on ep0out len=4/4
  [   18.183441] usb 1-1.1: link qh8-0001/dc8d6640 start 2 [1/0 us]
  [   19.822296] IP-Config: Complete:

 
   The mention of swapper is not relevent, it just happens to be the
   current process when the time out occurs.
 
 I have only seen these timeout messages in the boot log, so they may not
 be a very visible symptom.  They also _might_ be unrelated to the problem,
 but my gut feel is that they are related.

 snip 

-Frank

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout

2013-03-21 Thread Frank Rowand 
On 03/21/13 07:41, Alan Stern wrote:
 On Wed, 20 Mar 2013, Frank Rowand wrote:
 
 Hi All,

 Not quite sure quite where the problem is (USB, OMAP, smsc95xx driver, 
 other???),
 so casting the nets wide...

 The PandaBoard frequently fails to boot with an eth0 error when mounting
 the root file system via NFS (ethernet driver fails due to a USB timeout;
 no ethernet means NFS won't work).  A typical set of error messages is:

 [3.264373] smsc95xx 1-1.1:1.0: usb_probe_interface
 [3.269500] smsc95xx 1-1.1:1.0: usb_probe_interface - got id
 [3.275543] smsc95xx v1.0.4
 [8.078674] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at 
 usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 82:b9:1d:fa:67:0d
 [8.091003] hub 1-1:1.0: state 7 ports 5 chg  evt 0002
 [   13.509918] usb 1-1.1: swapper/0 timed out on ep0out len=0/4
 [   13.515869] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 
 0x0108
 [   13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
 [   13.529998] IP-Config: Failed to open eth0

 I have bisected this to:

   commit 18aafe64d75d0e27dae206cacf4171e4e485d285
   Author: Alan Stern st...@rowland.harvard.edu
   Date:   Wed Jul 11 11:23:04 2012 -0400

  USB: EHCI: use hrtimer for the I/O watchdog
 
 I don't understand how that commit could cause a timeout unless there 
 are at least two other bugs present in your system.
 
 Note that to compile this version of the kernel, an additional fix must
 also be applied:

   commit ba5952e0711b14d8d4fe172671f8aa6091ace3ee
   Author: Ming Lei ming@canonical.com
   Date:   Fri Jul 13 17:25:24 2012 +0800

  USB: ehci-omap: fix compile failure(v1)

 The symptom can be worked around by retrying the USB access if a timeout
 occurs.  This is clearly _not_ the fix, just a hack that I used to
 investigate the problem:

   http://article.gmane.org/gmane.linux.rt.user/9773

 My kernel configuration is:

   arch/arm/configs/omap2plus_defconfig

   plus to get the ethernet driver I add:

 CONFIG_USB_EHCI_HCD
 CONFIG_USB_NET_SMSC95XX

 I found the problem on 3.6.11, but have not replicated it on 3.9-rcX
 yet because my config fails to build on 3.9-rc1 and 3.9-rc2.  I'll try
 to work on that issue tomorrow.
 
 Let me know how it works out.

My PandaBoard builds fail on 3.9-rcX due to ARM multiplatform issues.
Either there is something I need to change about the way I build it,
or it is broken (that is a side issue).  My simple expedient was to
hack around multiplatform, and just make it build (patch below if
anyone else wants a _temporary_ hack).

The problem appears to not be present in 3.9-rc3.  In older kernel versions,
the worst case to see the problem was 18 boots.  For 3.9-rc3 I booted 42
times without seeing the problem.

The problem occurs at least up through 3.8.  I'll try to reverse bisect
between 3.8 and 3.9-rc3 to see when the problem disappeared (I'm running
short of time, so no promises for a near term result).

-Frank


This patch is a _temporary_ hack, not fit for man or beast.  Avert
your eyes, do not apply to any respectable repository!

---
 arch/arm/Kconfig  |2   1 + 1 - 0 !
 arch/arm/Makefile |2   2 + 0 - 0 !
 2 files changed, 3 insertions(+), 1 deletion(-)

Index: b/arch/arm/Kconfig
===
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1013,7 +1013,7 @@ config ARCH_MULTI_V7
bool ARMv7 based platforms (Cortex-A, PJ4, Krait)
default y
select ARCH_MULTI_V6_V7
-   select ARCH_VEXPRESS
+   select ARCH_VEXPRESS if !ARCH_OMAP2PLUS
select CPU_V7
 
 config ARCH_MULTI_V6_V7
Index: b/arch/arm/Makefile
===
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -227,8 +227,10 @@ else
 MACHINE  :=
 endif
 ifeq ($(CONFIG_ARCH_MULTIPLATFORM),y)
+ifneq ($(CONFIG_ARCH_OMAP2PLUS),y)
 MACHINE  :=
 endif
+endif
 
 machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y))
 platdirs := $(patsubst %,arch/arm/plat-%/,$(plat-y))

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout

2013-03-20 Thread Frank Rowand 
Hi All,

Not quite sure quite where the problem is (USB, OMAP, smsc95xx driver, 
other???),
so casting the nets wide...

The PandaBoard frequently fails to boot with an eth0 error when mounting
the root file system via NFS (ethernet driver fails due to a USB timeout;
no ethernet means NFS won't work).  A typical set of error messages is:

[3.264373] smsc95xx 1-1.1:1.0: usb_probe_interface
[3.269500] smsc95xx 1-1.1:1.0: usb_probe_interface - got id
[3.275543] smsc95xx v1.0.4
[8.078674] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at 
usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 82:b9:1d:fa:67:0d
[8.091003] hub 1-1:1.0: state 7 ports 5 chg  evt 0002
[   13.509918] usb 1-1.1: swapper/0 timed out on ep0out len=0/4
[   13.515869] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 
0x0108
[   13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
[   13.529998] IP-Config: Failed to open eth0

I have bisected this to:

  commit 18aafe64d75d0e27dae206cacf4171e4e485d285
  Author: Alan Stern st...@rowland.harvard.edu
  Date:   Wed Jul 11 11:23:04 2012 -0400

 USB: EHCI: use hrtimer for the I/O watchdog

Note that to compile this version of the kernel, an additional fix must
also be applied:

  commit ba5952e0711b14d8d4fe172671f8aa6091ace3ee
  Author: Ming Lei ming@canonical.com
  Date:   Fri Jul 13 17:25:24 2012 +0800

 USB: ehci-omap: fix compile failure(v1)

The symptom can be worked around by retrying the USB access if a timeout
occurs.  This is clearly _not_ the fix, just a hack that I used to
investigate the problem:

  http://article.gmane.org/gmane.linux.rt.user/9773

My kernel configuration is:

  arch/arm/configs/omap2plus_defconfig

  plus to get the ethernet driver I add:

CONFIG_USB_EHCI_HCD
CONFIG_USB_NET_SMSC95XX

I found the problem on 3.6.11, but have not replicated it on 3.9-rcX
yet because my config fails to build on 3.9-rc1 and 3.9-rc2.  I'll try
to work on that issue tomorrow.

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html