linux-kernel - Re: [PATCH] usb: host: tegra: Reset Tegra USB controller before init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Feb 2013 11:16:43 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Venu Byravarasu <vbyravarasu@...dia.com>
CC:	gregkh@...uxfoundation.org, stern@...land.harvard.edu,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
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?

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. This may
also address Alan's query re: when the unexpected interrupt occurs; it's
triggered by (or correlated with at least) the PHY (or USB port in
general) being in device mode due to the boot ROM setting it up this
way, then switching to host mode via the Linux driver. I /think/ that
device/host mode switching is more related to the PHY than EHCI driver,
although I could well be wrong here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/