public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alexandre Courbot <gnurou@gmail.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	linux-usb@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH v3 2/2] usb: host: ehci-tegra: Avoid getting the same reset twice
Date: Wed, 4 May 2016 11:23:20 -0600	[thread overview]
Message-ID: <572A3008.4020602@wwwdotorg.org> (raw)
In-Reply-To: <1462372800-30900-2-git-send-email-thierry.reding@gmail.com>

On 05/04/2016 08:40 AM, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Starting with commit 0b52297f2288 ("reset: Add support for shared reset
> controls") there is a reference count for reset control assertions. The
> goal is to allow resets to be shared by multiple devices and an assert
> will take effect only when all instances have asserted the reset.
>
> In order to preserve backwards-compatibility, all reset controls become
> exclusive by default. This is to ensure that reset_control_assert() can
> immediately assert in hardware.
>
> However, this new behaviour triggers the following warning in the EHCI
> driver for Tegra:
...
> The reason is that Tegra SoCs have three EHCI controllers, each with a
> separate reset line. However the first controller contains UTMI pads
> configuration registers that are shared with its siblings and that are
> reset as part of the first controller's reset. There is special code in
> the driver to assert and deassert this shared reset at probe time, and
> it does so irrespective of which controller is probed first to ensure
> that these shared registers are reset before any of the controllers are
> initialized. Unfortunately this means that if the first controller gets
> probed first, it will request its own reset line and will subsequently
> request the same reset line again (temporarily) to perform the reset.
> This used to work fine before the above-mentioned commit, but now
> triggers the new WARN.
>
> Work around this by making sure we reuse the controller's reset if the
> controller happens to be the first controller.

> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c

> @@ -81,15 +81,23 @@ static int tegra_reset_usb_controller(struct platform_device *pdev)

> +	bool has_utmi_pad_registers = false;
>
>   	phy_np = of_parse_phandle(pdev->dev.of_node, "nvidia,phy", 0);
>   	if (!phy_np)
>   		return -ENOENT;
>
> +	if (of_property_read_bool(phy_np, "nvidia,has-utmi-pad-registers"))
> +		has_utmi_pad_registers = true;

Isn't that just:

has_utmi_pad_registers = of_property_read_bool(phy_np,
     "nvidia,has-utmi-pad-registers");

... and then you can remove " = false" from the declaration too?

>   	if (!usb1_reset_attempted) {
>   		struct reset_control *usb1_reset;
>
> -		usb1_reset = of_reset_control_get(phy_np, "utmi-pads");
> +		if (!has_utmi_pad_registers)
> +			usb1_reset = of_reset_control_get(phy_np, "utmi-pads");
> +		else
> +			usb1_reset = tegra->rst;
...
>   		usb1_reset_attempted = true;
>   	}

This is a pre-existing issue, but what happens if the probes for two USB 
controllers run in parallel; there seems to be missing locking related 
to testing/setting usb1_reset_attempted, which could cause multiple 
parallel attempts to get the "utmi-pads" reset object, which would 
presumably cause essentially the same issue this patch is solving in 
other cases?

  parent reply	other threads:[~2016-05-04 17:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-04 14:39 [PATCH v3 1/2] usb: host: ehci-tegra: Grab the correct UTMI pads reset Thierry Reding
2016-05-04 14:40 ` [PATCH v3 2/2] usb: host: ehci-tegra: Avoid getting the same reset twice Thierry Reding
2016-05-04 17:22   ` Philipp Zabel
2016-05-04 20:16     ` Thierry Reding
2016-05-04 17:23   ` Stephen Warren [this message]
2016-05-04 20:25     ` Thierry Reding
2016-05-05  8:05       ` Hans de Goede
2016-05-05 16:00         ` Stephen Warren
2016-05-05 17:12           ` Hans de Goede
2016-05-05 17:05   ` Jon Hunter
2016-05-05 17:10     ` Jon Hunter
2016-05-04 14:57 ` [PATCH v3 1/2] usb: host: ehci-tegra: Grab the correct UTMI pads reset Greg Kroah-Hartman
2016-05-04 15:26   ` Thierry Reding
2016-05-05 16:05     ` Tuomas Tynkkynen
2016-05-04 17:14 ` Stephen Warren
2016-05-04 20:30   ` Thierry Reding
2016-05-05  7:39 ` Jon Hunter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=572A3008.4020602@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=gnurou@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=stern@rowland.harvard.edu \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox