Gadget regression with enabling of MUSB babble interrupt handling
Hi,
Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct to recover from babble errors) causes MUSB gadgets to stop enumerating at least on omap3. Reverting the the commit fixes the issue.
Regards,
Tony
A message that is not in the archive (sent off-list or not yet received): [email protected]
(+ George)
Quoted 4 lines · Tony Lindgren
Looks like commit
ca88fc2ef0d7(usb: musb: add awork_structto recover from babble errors) causes MUSB gadgets to stop enumerating at least on omap3. Reverting the the commit fixes the issue.
Hmm, so do you see babble errors occuring?
Also, there are some more patches for musb and babble error recovery on the usb list, namely the ones starting here in v6:
http://marc.info/?l=linux-usb&m=140109627505065&w=4
Care to give them a try?
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines · Daniel Mack
(+ George)
Quoted 4 lines · Tony Lindgren
Looks like commit
ca88fc2ef0d7(usb: musb: add awork_structto recover from babble errors) causes MUSB gadgets to stop enumerating at least on omap3. Reverting the the commit fixes the issue.Hmm, so do you see babble errors occuring?
Not that I noticed of.
Quoted 6 lines
Also, there are some more patches for musb and babble error recovery on the usb list, namely the ones starting here in v6:
http://marc.info/?l=linux-usb&m=140109627505065&w=4
Care to give them a try?
I can confirm that "[PATCH v6 1/5] usb: musb: core: Handle Babble condition only in HOST mode" fixes the issue for me. Also the explanation in the patch description explains why it breaks, and probably for all gadgets too because "BABBLE and RESET share the same interrupt" so it's RESET in peripheral mode.
But that also raises a question: Were these patches merged for v3.16 ever even tested in peripheral mode?
Regards,
Tony
Hi Tony,
Quoted 16 lines · Tony Lindgren
Quoted 7 lines · Daniel Mack
Quoted 4 lines · Tony Lindgren
Looks like commit
ca88fc2ef0d7(usb: musb: add awork_structto recover from babble errors) causes MUSB gadgets to stop enumerating at least on omap3. Reverting the the commit fixes the issue.Hmm, so do you see babble errors occuring?
Not that I noticed of.
Quoted 5 lines
Also, there are some more patches for musb and babble error recovery on the usb list, namely the ones starting here in v6:
Quoted 7 lines
Quoted 1 line
Care to give them a try?
I can confirm that "[PATCH v6 1/5] usb: musb: core: Handle Babble condition only in HOST mode" fixes the issue for me. Also the explanation in the patch description explains why it breaks, and probably for all gadgets too because "BABBLE and RESET share the same interrupt" so it's RESET in peripheral mode.
Ok, thanks for testing. I was told Felipe was out for some weeks, so I don't know when these patches will be reviewed and merged.
Quoted 2 lines
But that also raises a question: Were these patches merged for v3.16 ever even tested in peripheral mode?
At the time, I had no such hardware to test this on, so I was hoping for more testers to give them a try in different environments, which apparently didn't happen. It fixed a dead USB port condition on host-mode enabled hardware, though.
We should make sure at least patch 1/5 from the series mentioned above makes it to 3.16.
Thanks,
Daniel
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 21 lines · Daniel Mack
Hi Tony,
Quoted 18 lines · Tony Lindgren
Quoted 7 lines · Daniel Mack
Quoted 4 lines · Tony Lindgren
Looks like commit
ca88fc2ef0d7(usb: musb: add awork_structto recover from babble errors) causes MUSB gadgets to stop enumerating at least on omap3. Reverting the the commit fixes the issue.Hmm, so do you see babble errors occuring?
Not that I noticed of.
Quoted 6 lines
Also, there are some more patches for musb and babble error recovery on the usb list, namely the ones starting here in v6:
http://marc.info/?l=linux-usb&m=140109627505065&w=4
Care to give them a try?
Quoted 8 lines
Quoted 5 lines
I can confirm that "[PATCH v6 1/5] usb: musb: core: Handle Babble condition only in HOST mode" fixes the issue for me. Also the explanation in the patch description explains why it breaks, and probably for all gadgets too because "BABBLE and RESET share the same interrupt" so it's RESET in peripheral mode.
Ok, thanks for testing. I was told Felipe was out for some weeks, so I don't know when these patches will be reviewed and merged.
He seems to be back now :)
Quoted 7 lines
Quoted 2 lines
But that also raises a question: Were these patches merged for v3.16 ever even tested in peripheral mode?
At the time, I had no such hardware to test this on, so I was hoping for more testers to give them a try in different environments, which apparently didn't happen. It fixed a dead USB port condition on host-mode enabled hardware, though.
Well we probably should not merge patches without proper acks and tested-by:s in general as things just seem to keep breaking constantly otherwise. And things not working will keep people from using linux next which will lead into even less testing..
Anyways, this driver is the only way to get a console on many devices, so we should ensure it always works properly.
Quoted 2 lines
We should make sure at least patch 1/5 from the series mentioned above makes it to 3.16.
Agreed.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 13 lines · Tony Lindgren
Quoted 11 lines · Daniel Mack
Quoted 5 lines · Tony Lindgren
Quoted 1 line · Daniel Mack
On 06/19/2014 11:56 AM, Tony Lindgren wrote:
But that also raises a question: Were these patches merged for v3.16 ever even tested in peripheral mode?
At the time, I had no such hardware to test this on, so I was hoping for more testers to give them a try in different environments, which apparently didn't happen. It fixed a dead USB port condition on host-mode enabled hardware, though.
Quoted 4 lines
Well we probably should not merge patches without proper acks and tested-by:s in general as things just seem to keep breaking constantly otherwise. And things not working will keep people from using linux next which will lead into even less testing..
I'm fairly sure the patch causing your trouble has been in linux-next for a while before they hit the merge window, so people with gadget enabled musb could have noticed the breakage early enough. The feedback rate for patches to this driver posted to linux-usb is also usually low, unfortunately.
Anyway, breaking things is certainly not good, and I'm sorry for that. I'm just uncertain what detail in the procedure should be tweaked in order to prevent that from happening in the future.
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 19 lines · Daniel Mack
Quoted 13 lines · Tony Lindgren
Quoted 11 lines · Daniel Mack
Quoted 5 lines · Tony Lindgren
Quoted 1 line · Daniel Mack
On 06/19/2014 11:56 AM, Tony Lindgren wrote:
But that also raises a question: Were these patches merged for v3.16 ever even tested in peripheral mode?
At the time, I had no such hardware to test this on, so I was hoping for more testers to give them a try in different environments, which apparently didn't happen. It fixed a dead USB port condition on host-mode enabled hardware, though.
Quoted 4 lines
Well we probably should not merge patches without proper acks and tested-by:s in general as things just seem to keep breaking constantly otherwise. And things not working will keep people from using linux next which will lead into even less testing..
Quoted 5 lines
I'm fairly sure the patch causing your trouble has been in linux-next for a while before they hit the merge window, so people with gadget enabled musb could have noticed the breakage early enough. The feedback rate for patches to this driver posted to linux-usb is also usually low, unfortunately.
Right but the problem is that people are not touching linux next because it's constantly broken :)
Quoted 3 lines
Anyway, breaking things is certainly not good, and I'm sorry for that. I'm just uncertain what detail in the procedure should be tweaked in order to prevent that from happening in the future.
Well I guess somebody should run basic tests on this driver in linux next, that would probably solve the issues.
Regards,
Tony
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Daniel Mack
Quoted 14 lines · Tony Lindgren
Quoted 9 lines · Daniel Mack
Quoted 4 lines · Tony Lindgren
Quoted 1 line · Daniel Mack
On 06/19/2014 11:56 AM, Tony Lindgren wrote:
But that also raises a question: Were these patches merged for v3.16 ever even tested in peripheral mode?
At the time, I had no such hardware to test this on, so I was hoping for more testers to give them a try in different environments, which apparently didn't happen. It fixed a dead USB port condition on host-mode enabled hardware, though.
Well we probably should not merge patches without proper acks and tested-by:s in general as things just seem to keep breaking constantly otherwise. And things not working will keep people from using linux next which will lead into even less testing..
Quoted 5 lines
Quoted 5 lines
I'm fairly sure the patch causing your trouble has been in linux-next for a while before they hit the merge window, so people with gadget enabled musb could have noticed the breakage early enough. The feedback rate for patches to this driver posted to linux-usb is also usually low, unfortunately.
I blame myself for not explicitly pointing out the fix. Instead I clubbed it with this series.
http://marc.info/?l=linux-usb&m=140109627505065&w=4
Sorry for that.
Quoted 8 lines
Right but the problem is that people are not touching linux next because it's constantly broken :)
Quoted 3 lines
Anyway, breaking things is certainly not good, and I'm sorry for that. I'm just uncertain what detail in the procedure should be tweaked in order to prevent that from happening in the future.
Well I guess somebody should run basic tests on this driver in linux next, that would probably solve the issues.
I am doing it.
Quoted 3 lines
Regards,
Tony
Signature · 1 line
-George
Quoted 31 lines · George Cherian
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Daniel Mack
Quoted 14 lines · Tony Lindgren
Quoted 9 lines · Daniel Mack
Quoted 4 lines · Tony Lindgren
Quoted 1 line · Daniel Mack
On 06/19/2014 11:56 AM, Tony Lindgren wrote:
But that also raises a question: Were these patches merged for v3.16 ever even tested in peripheral mode?
At the time, I had no such hardware to test this on, so I was hoping for more testers to give them a try in different environments, which apparently didn't happen. It fixed a dead USB port condition on host-mode enabled hardware, though.
Well we probably should not merge patches without proper acks and tested-by:s in general as things just seem to keep breaking constantly otherwise. And things not working will keep people from using linux next which will lead into even less testing..
Quoted 5 lines
Quoted 5 lines
I'm fairly sure the patch causing your trouble has been in linux-next for a while before they hit the merge window, so people with gadget enabled musb could have noticed the breakage early enough. The feedback rate for patches to this driver posted to linux-usb is also usually low, unfortunately.
I blame myself for not explicitly pointing out the fix. Instead I clubbed it with this series.
http://marc.info/?l=linux-usb&m=140109627505065&w=4
Sorry for that.
Quoted 2 lines
Right but the problem is that people are not touching linux next because it's constantly broken :)
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Anyway, breaking things is certainly not good, and I'm sorry for that. I'm just uncertain what detail in the procedure should be tweaked in order to prevent that from happening in the future.
Well I guess somebody should run basic tests on this driver in linux next, that would probably solve the issues.
I am doing it.
Great, good to hear thanks :)
Tony