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:54:52 +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

Hi Daniel,

On 5/13/2014 6:44 PM, Daniel Mack wrote:
> Hi George,
>
> On 05/13/2014 02:57 PM, George Cherian wrote:
>> 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)
> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
> without the patch: a full glue reset is conducted. Do I get you right
> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
> MUSB_BABBLE_SW_SESSION_CTRL is set?
>
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an 
IP reset .
2) Babble condition - which could be recovered from only by doing an IP 
reset.

Looks like you are always hitting case 2 (Most times am also hitting the 
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of 
now to
reproduce this case consistently.
> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
> (a_wait_bcon)
> [   19.685815] usb 1-1: USB disconnect, device number 3
> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 44
> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>
>
> I don't quite follow, especially as I lack documentation of the IP core.
> How do you test babble errors, is there any way to force them to happen
> reliably?

There is no 100% reliable method to force it to happen. Following is
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
> Anyway, the full glue layer solves this rare condition quite well for
> me. Is there any downside of this?
>
>
> 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/