Re: [PATCH v3 00/22] usb: musb: the big MUSB patch bomb
Felipe, On Fri, Feb 27, 2015 at 3:45 PM, Felipe Balbi wrote: > On Fri, Feb 27, 2015 at 03:22:11PM -0600, Bin Liu wrote: >> Felipe, >> >> On Thu, Feb 26, 2015 at 2:53 PM, Felipe Balbi wrote: >> > Hi folks, >> > >> > this is v3 of my patchset which has been in discussion with >> > Bin Liu (hey, thanks). >> >> Thanks for clean this up. Dropping reset from the babble handling has >> been on my TODO for a long time, but never got a chance to do it. >> >> > >> > patches have been tested with AM335x BBB using g_zero and >> > g_mass_storage. >> > >> > My BBB, for whatever reason, always causes babble when I >> > connect the peripheral port to the host port on the same >> > board. So that was a great platform for testing this patchset. >> > >> > I can see that after babble recovery runs, we drop the session, >> > tell usbcore about it and restart the session, which causes >> > g_zero to enumerate. If, after that, I drop g_zero and plug >> > a mass storage pendrive or load g_mass_storage on the peripheral >> > port, everything works fine. >> >> I tested it on AM335x GP EVM, babble recovery seems working fine. >> >> Please feel free to add me to 'Tested-by', or 'Reviewed-by', or >> 'Signed-off-by', or whatever on patch #16, 17, 19, and 22. I really >> don't know the meaning among them in kernel anyway... > > well, since you tested the whole series, I'll add Tested-by to the > entire series, thanks. Ok. Thanks. -Bin. > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/22] usb: musb: the big MUSB patch bomb
On Fri, Feb 27, 2015 at 03:22:11PM -0600, Bin Liu wrote: > Felipe, > > On Thu, Feb 26, 2015 at 2:53 PM, Felipe Balbi wrote: > > Hi folks, > > > > this is v3 of my patchset which has been in discussion with > > Bin Liu (hey, thanks). > > Thanks for clean this up. Dropping reset from the babble handling has > been on my TODO for a long time, but never got a chance to do it. > > > > > patches have been tested with AM335x BBB using g_zero and > > g_mass_storage. > > > > My BBB, for whatever reason, always causes babble when I > > connect the peripheral port to the host port on the same > > board. So that was a great platform for testing this patchset. > > > > I can see that after babble recovery runs, we drop the session, > > tell usbcore about it and restart the session, which causes > > g_zero to enumerate. If, after that, I drop g_zero and plug > > a mass storage pendrive or load g_mass_storage on the peripheral > > port, everything works fine. > > I tested it on AM335x GP EVM, babble recovery seems working fine. > > Please feel free to add me to 'Tested-by', or 'Reviewed-by', or > 'Signed-off-by', or whatever on patch #16, 17, 19, and 22. I really > don't know the meaning among them in kernel anyway... well, since you tested the whole series, I'll add Tested-by to the entire series, thanks. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 00/22] usb: musb: the big MUSB patch bomb
Felipe, On Thu, Feb 26, 2015 at 2:53 PM, Felipe Balbi wrote: > Hi folks, > > this is v3 of my patchset which has been in discussion with > Bin Liu (hey, thanks). Thanks for clean this up. Dropping reset from the babble handling has been on my TODO for a long time, but never got a chance to do it. > > patches have been tested with AM335x BBB using g_zero and > g_mass_storage. > > My BBB, for whatever reason, always causes babble when I > connect the peripheral port to the host port on the same > board. So that was a great platform for testing this patchset. > > I can see that after babble recovery runs, we drop the session, > tell usbcore about it and restart the session, which causes > g_zero to enumerate. If, after that, I drop g_zero and plug > a mass storage pendrive or load g_mass_storage on the peripheral > port, everything works fine. I tested it on AM335x GP EVM, babble recovery seems working fine. Please feel free to add me to 'Tested-by', or 'Reviewed-by', or 'Signed-off-by', or whatever on patch #16, 17, 19, and 22. I really don't know the meaning among them in kernel anyway... Thanks, -Bin. > > cheers > > Felipe Balbi (22): > usb: musb: core: remove unnecessary logical comparison > usb: musb: core: add missing curly braces > usb: musb: core: fix highspeed check > usb: musb: dsps: return error code if reset fails > usb: musb: core: move babble recovery inside babble check > usb: musb: core: break long line > usb: musb: core: remove unnecessary reg access from resume IRQ > usb: musb: core: there is no connect interrupt in peripheral mode > usb: musb: dsps: remove babble check from dsps irq handler > usb: musb: dsps: check for the single bit > usb: musb: core: controller drops session automatically > usb: musb: dsps: add dsps_ prefix to sw_babble_control > usb: musb: core: refactor IRQ enable/disable to separate functions > usb: musb: don't touch devctl from babble recovery > usb: musb: core: decrease delayed_work time > usb: musb: dsps: do not reset musb on babble > usb: musb: core: simplify musb_recover_work() > usb: musb: rename ->reset() to ->recover() > usb: musb: core: drop recover_work > usb: musb: core: remove unnecessary forward declaration > usb: musb: core: disable irqs inside babble recovery > usb: musb: core: always try to recover from babble > > drivers/usb/musb/musb_core.c | 132 > +-- > drivers/usb/musb/musb_core.h | 14 ++--- > drivers/usb/musb/musb_dsps.c | 49 +++- > 3 files changed, 78 insertions(+), 117 deletions(-) > > -- > 2.3.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/22] usb: musb: the big MUSB patch bomb
Hi folks, this is v3 of my patchset which has been in discussion with Bin Liu (hey, thanks). patches have been tested with AM335x BBB using g_zero and g_mass_storage. My BBB, for whatever reason, always causes babble when I connect the peripheral port to the host port on the same board. So that was a great platform for testing this patchset. I can see that after babble recovery runs, we drop the session, tell usbcore about it and restart the session, which causes g_zero to enumerate. If, after that, I drop g_zero and plug a mass storage pendrive or load g_mass_storage on the peripheral port, everything works fine. cheers Felipe Balbi (22): usb: musb: core: remove unnecessary logical comparison usb: musb: core: add missing curly braces usb: musb: core: fix highspeed check usb: musb: dsps: return error code if reset fails usb: musb: core: move babble recovery inside babble check usb: musb: core: break long line usb: musb: core: remove unnecessary reg access from resume IRQ usb: musb: core: there is no connect interrupt in peripheral mode usb: musb: dsps: remove babble check from dsps irq handler usb: musb: dsps: check for the single bit usb: musb: core: controller drops session automatically usb: musb: dsps: add dsps_ prefix to sw_babble_control usb: musb: core: refactor IRQ enable/disable to separate functions usb: musb: don't touch devctl from babble recovery usb: musb: core: decrease delayed_work time usb: musb: dsps: do not reset musb on babble usb: musb: core: simplify musb_recover_work() usb: musb: rename ->reset() to ->recover() usb: musb: core: drop recover_work usb: musb: core: remove unnecessary forward declaration usb: musb: core: disable irqs inside babble recovery usb: musb: core: always try to recover from babble drivers/usb/musb/musb_core.c | 132 +-- drivers/usb/musb/musb_core.h | 14 ++--- drivers/usb/musb/musb_dsps.c | 49 +++- 3 files changed, 78 insertions(+), 117 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html