linux-kernel - Re: [ 011/108] powerpc/usb: fix bug of kernel hang when initializing usb

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]

Message-ID: <gpqbc8avn.fsf@dworkin.scrye.com>
Date:	Thu, 12 Apr 2012 23:21:48 -0600
From:	Anthony Foiani <tkil@...ye.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk,
	Shengzhou Liu <Shengzhou.Liu@...escale.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [ 011/108] powerpc/usb: fix bug of kernel hang when initializing usb

Greg KH <gregkh@...uxfoundation.org> writes:

> 3.0-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Shengzhou Liu <Shengzhou.Liu@...escale.com>
>
> commit 28c56ea1431421dec51b7b229369e991481453df upstream.
>
> If USB UTMI PHY is not enable, writing to portsc register will lead to
> kernel hang during boot up.

I apologize for the late response, but I was encountering this same
hang (on an 8315) and applied this patch.  (For what it's worth, I'm
only seeing it after many warm boots; a cold boot / hard power cycle
solves the issue, but since this is eventually going to be locked up
in a box without a console...)

I encountered the hang again this evening, so this fix (plus the snoop
fix) is not sufficientl

Reading through the original thread, it seems that an additional delay
might be required:

   http://article.gmane.org/gmane.linux.usb.general/58795

   > First, the SDK kernel had a delay after setting that bit, I added
   > that back in. This is not what fixed it but it looks like the
   > right thing to do, though please, use msleep rather than udelay
   > here if possible (not in atomic context).

However, I never saw a patch to that effect.  I'm assuming (hoping!)
it's something as simple as:

------------------------------------------------------------------------
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 09fd214..d58c1c6 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -236,6 +236,7 @@ static void ehci_fsl_setup_phy(struct ehci_hcd *ehci,
	case FSL_USB2_PHY_UTMI:
		/* enable UTMI PHY */
		setbits32(non_ehci + FSL_SOC_USB_CTRL, CTRL_UTMI_PHY_EN);
+		msleep(5);
		portsc |= PORT_PTS_UTMI;
		break;
	case FSL_USB2_PHY_NONE:
------------------------------------------------------------------------

But confirmation would be nice.  Also, which SDK kernel was this
compared against?  I just downloaded the 8315ERDB BSP, and the kernel
there doesn't seem to have any of this in it.

There was also the follow-on patch that enabled snooping (to deal with
cache coherency?):

   http://article.gmane.org/gmane.linux.usb.general/58798

(If there was a formal patch there, it looks like it got scrambled on
gmane, and I can't find another list archive.)

Is that also needed for consistent results here?  (Or are we wandering
astray from "-stable" material?)

Thanks,
Tony.
--
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/