linux-kernel - Re: [PATCH v3 0/5] Add support for SW babble Control

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:	Tue, 13 May 2014 18:27:16 +0530
From:	George Cherian <george.cherian@...com>
To:	Daniel Mack <zonque@...il.com>, <linux-kernel@...r.kernel.org>,
	<linux-usb@...r.kernel.org>, <linux-omap@...r.kernel.org>
CC:	<balbi@...com>, <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v3 0/5] Add support for SW babble Control

On 5/13/2014 5:50 PM, Daniel Mack wrote:
> On 05/13/2014 01:57 PM, George Cherian wrote:
>> On 5/13/2014 3:16 PM, Daniel Mack wrote:
>>> On 05/13/2014 10:31 AM, George Cherian wrote:
>>>> Series add support for SW babble control logic found in
>>>> new silicon versions of AM335x. Runtime differentiation of
>>>> silicon version is done by checking the BABBLE_CTL register.
>>>> For newer silicon the register default value read is 0x4 and
>>>> for older versions its 0x0.
>>> I tested this on a AM33xx platform and don't see any regression at
>>> least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
>>> Anything particular you want me to test as well?
>> Are you seeing a wrapper restart done always or does it continue with a
>> restart
>> after the babble condition?
> MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE, so sw_babble_control() is
> called from dsps_musb_reset(). However, MUSB_BABBLE_CTL still returns
> 0x04 (MUSB_BABBLE_RCV_DISABLE) inside that function, which means
> (babble_ctl & MUSB_BABBLE_STUCK_J) is false, and hence
> sw_babble_control() returns 1.
Ah.... Missed a critical portion....
My bad...

I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
can you try with the following patch.

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
  	 * logic enabled.
  	 */
  	val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
-	if (val == MUSB_BABBLE_RCV_DISABLE)
+	if (val == MUSB_BABBLE_RCV_DISABLE) {
  		glue->sw_babble_enabled = true;
+		val |= MUSB_BABBLE_SW_SESSION_CTRL;
+	        dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
+	}
  
  	ret = dsps_musb_dbg_init(musb, glue);
  	if (ret)
-- 1.8.3.1

I will resend the series, if this works fine.
Thanks for all your help.

>   Consequently, the glue is fully reset in
> this case. Does this help?
>
> FWIW, this is the output of dsps_musb_reset() with dev_dbg() enabled:
>
> [   54.066124] CAUTION: musb: Babble Interrupt Occurred
> [   54.071856] usb 1-1: USB disconnect, device number 8
> [   54.159495] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 4
> [   54.166446] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>
>
> I only have one exact USB device to reproduce the babble condition, so I
> guess this is all I can do for now.
Same with me also . I also have only one device with which i get the issue.
>
>
> Thanks,
> Daniel
>


-- 
-George

--
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/