* NeilBrown <neil@xxxxxxxxxx> [150818 17:32]:
> On Tue, 18 Aug 2015 01:07:58 -0700 Tony Lindgren <tony@xxxxxxxxxxx>
> wrote:
>
> > * NeilBrown <neil@xxxxxxxxxx> [150729 17:29]:
> > > Now that twl4030_bci_probe can safely return -EPROBE_DEFER,
> > > do so when devm_usb_get_phy_by_node returns that error.
> > >
> > > Signed-off-by: NeilBrown <neil@xxxxxxxxxx>
> > > ---
> > > drivers/power/twl4030_charger.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
> > > index 045238370d3f..ffc123fb7158 100644
> > > --- a/drivers/power/twl4030_charger.c
> > > +++ b/drivers/power/twl4030_charger.c
> > > @@ -636,9 +636,13 @@ static int twl4030_bci_probe(struct platform_device *pdev)
> > >
> > > phynode = of_find_compatible_node(bci->dev->of_node->parent,
> > > NULL, "ti,twl4030-usb");
> > > - if (phynode)
> > > + if (phynode) {
> > > bci->transceiver = devm_usb_get_phy_by_node(
> > > bci->dev, phynode, &bci->usb_nb);
> > > + if (IS_ERR(bci->transceiver) &&
> > > + PTR_ERR(bci->transceiver) == -EPROBE_DEFER)
> > > + return -EPROBE_DEFER;
> > > + }
> > > }
> >
> > Neil, the return with -EPROBE_DEFER here causes flakeyness booting
> > for me somehow at least on my logicpd-torpedo-37xx-devkit using
> > omap2plus_defconfig.
> >
> > It seems that the twl4030_bci_probe keeps looping or something about
> > 1/3 of the boots and that probably prevents the other twl modules
> > from loading? Reverting this patch alone seems to fix the issue.
> >
> > I don't think I have a battery wired on this board the USB is wired
> > the same way as on beagle-xm. So I'd assume also flakeyness on beagle
> > xm with this patch.
>
> What dts file are you using?
> I'm guessing that it doesn't have something like:
>
> &usb_otg_hs {
> interface-type = <0>;
> usb-phy = <&usb2_phy>;
> phys = <&usb2_phy>;
> phy-names = "usb2-phy";
> mode = <3>;
> power = <50>;
> };
It's the logicpd-torpedo-37xx-devkit.dts like I mentioned above,
and yes it has the same entry above like beagle xm.
> ? i.e. with a usb-phy=<&usb2_phy> ?
>
> What if you add
>
> &usb2_phy {
> status = "disabled";
> }
>
> to your dts file?
Yes then the PHY driver won't get probed and modprobe of the
charger won't hang with -EPROBE_DEFER.. The USB is working on this
one like on beagle xm so that's not a solution.
> Should the 'status' be disabled in twl4030.dtsi, and then marked OK in
> any dts that uses it? I'm not at all clear on how 'status' is meant to
> be used.
Well status = "disabled" makes kernel completely ignore the
hardware, so the struct device is never created. I'd stay away from
using that in general for proper runtime idling of devices.. The
hardware is there for sure :)
Can you check if something like the the following allows you to
reproduce the hang of modprobe twl4030_charger:
# rmmod phy-twl4030-usb
# modprobe twl4030_charger
So just don't probe phy-twl4030-usb before twl4030_charger and
then modprobe of twl4030_charger hangs?
That is with proper usb2_phy configured in .dts file and not
set to status = "disabled".
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
