[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150106101904.GA31830@ulmo.nvidia.com>
Date: Tue, 6 Jan 2015 11:19:05 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Stephen Warren <swarren@...dotorg.org>
Cc: balbi@...com, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: phy: Restore deferred probing path
On Mon, Jan 05, 2015 at 12:33:51PM -0700, Stephen Warren wrote:
> On 12/23/2014 11:36 AM, Felipe Balbi wrote:
> >On Thu, Dec 04, 2014 at 01:06:07PM +0100, Thierry Reding wrote:
> >>From: Thierry Reding <treding@...dia.com>
> >>
> >>Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
> >>failure") broke platforms that rely on deferred probing to order probing
> >>of PHY and host controller drivers. The reason is that the commit simply
> >>propagates errors from __of_usb_find_phy(), which returns -ENODEV if no
> >>PHY has been registered yet for a given device tree node. The only case
> >>in which -EPROBE_DEFER would now be returned is if try_module_get() did
> >>fail, which does not make sense.
> >>
> >>The correct thing to do is to return -EPROBE_DEFER if a PHY hasn't been
> >>registered yet. The only condition under which it makes sense to return
> >>-ENODEV is if the device tree node representing the PHY has been
> >>disabled (via the status property) because in that case the PHY will
> >>never be registered.
> >>
> >>This patch addresses the problem by making __of_usb_find_phy() return an
> >>appropriate error code while keeping in line with the above-mentioned
> >>commit to propagate error codes rather than overwriting them. At the
> >>same time the check for a valid PHY is decoupled from the check for the
> >>try_module_get() call and a separate error code is returned if the
> >>latter fails.
> >>
> >>Signed-off-by: Thierry Reding <treding@...dia.com>
> >
> >you forgot to add the magic "Fixes: foo bar" here, I'll add it this
> >time, but I've already sent my -rc2 pull request, so this will only show
> >up on -rc3.
>
> Presumably also add the following, since the patch fixes a regression in a
> previous kernel release:
>
> Cc: stable # v3.18
>
> ?
The offending commit was only merged in v3.19-rc1. That's also the
reason why I didn't deem it necessary to include the Fixes: line. Given
that the patch was posted prior to the merge window opening and that it
fixes a regression I had assumed it would be merged in the same pull-
request as the commit causing the regression.
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists