> -----Original Message----- > From: Stephen Warren [mailto:swarren@xxxxxxxxxxxxx] > Sent: Thursday, February 28, 2013 11:47 PM > To: Venu Byravarasu > Cc: gregkh@xxxxxxxxxxxxxxxxxxx; stern@xxxxxxxxxxxxxxxxxxx; linux- > usb@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] usb: host: tegra: Reset Tegra USB controller before init > > On 02/27/2013 11:36 PM, Venu Byravarasu wrote: > > To clear any configurations made by U-Boot on Tegra USB controller, > > reset it before init in probe. > > > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c > > > @@ -691,6 +692,10 @@ static int tegra_ehci_probe(struct platform_device > *pdev) > > if (err) > > goto fail_clk; > > > > + tegra_periph_reset_assert(tegra->clk); > > + udelay(1); > > + tegra_periph_reset_deassert(tegra->clk); > > I think this patch might cause unintended consequences. > > When the Tegra PHY code is converted to a driver (i.e. has its own > probe), the initial order of execution of the PHY and EHCI driver probes > will not be guaranteed. > > In particular, since the EHCI probe will attempt to "find" the PHY > device, and defer the EHCI probe until it can do so, this guarantees > that the PHY's probe() will have completed before EHCI's probe() > completes (although EHCI's probe may start running first some number of > times, and be retried with -EPROBE_DEFERRED for a variety of reasons). > > Now, if the PHY driver's probe() actually touches HW and sets up some > registers, isn't this reset call going to trash any of that register > setup? Or, will PHY probe() not touch registers, but only do so during > the standard PHY open/init "op"/API calls? Yes, PHY driver probe does not touch any registers. It just sets up the PHY API hooks. These APIs will be called from ehci-tegra.c as part of ehci tegra probe function, after getting PHY handle, which in turn happens after issuing above reset. Thanks to Stephen & Alan, for the review comments. > > I think the way to solve this is to put the reset call into the PHY > driver. I assume it has access to the appropriate clock object. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
