Michael Grzeschik <mgr@xxxxxxxxxxxxxx> writes: > On Wed, Mar 27, 2013 at 10:24:04PM +0200, Alexander Shishkin wrote: >> Michael Grzeschik <mgr@xxxxxxxxxxxxxx> writes: >> >> > On Wed, Mar 27, 2013 at 06:35:30PM +0200, Alexander Shishkin wrote: >> >> Michael Grzeschik <m.grzeschik@xxxxxxxxxxxxxx> writes: >> >> >> >> > Hi, >> >> > >> >> > this series solve some issues with the chipidea udc. >> >> > >> >> > The series is based on v3.9-rc4. >> >> > >> >> > Michael Grzeschik (6): >> >> > usb: chipidea: udc: add attribute aligned(4) to shared memory structs >> >> > usb: chipidea: udc: only clear active and halted bits in qhead >> >> > usb: chipidea: udc: move ZLT flag change to ep_enable >> >> > usb: chipidea: udc: read status of td only once in hardware_dequeue >> >> > usb: chipidea: udc: don't truncate requests to single tds >> >> > usb: chipidea: udc: move _ep_queue into an unlocked function >> >> >> >> Actually, do any of these patches fix tangible bugs, that can be >> >> reproduced? If so, you should certainly mention that. But somehow I doubt >> >> that, because otherwise the driver will be totally unusable. >> >> >> >> What I see is patches that bring some parts of udc code in accordance >> >> with the spec, which is a good thing to do, but doesn't fix any "real >> >> bugs that bother people". Or does it? >> > >> > Obviously we were hunting a real issue while writing that patches. The >> > most essential one is Patch 1/6, which definitely is a stable patch. I >> > will clearify that in the patch description. >> >> Does it then fall in "never worked before" category, since it looks like >> it has never worked before on armv5 or did it work with older compilers? > > We used gcc-4.6.2 and gcc-4.7.2. In both cases we tested on the mx28 and > the system got stuck after some transfers when using the following test: > > user@target$ getty /dev/ttyGS0 > user@host$ microcom -p /dev/ttyACM0 > > Within the shell we started the following command: > $(while true; do find /; done) > >> At least the xscale version seems to be fine. > > Could you test the above with the xscale? Just checked, gcc does generate a bunch of byte loads and stores on xscale too (which makes sense, of course) for TD/QH accesses. But since we don't support xscale in chipidea in mainline yet, it wasn't an issue. It's different for imx, however. So now I'm convinced this should go to stable. > I will refer to another patch which is pretty similar > and adressing in detail the same problamatic situation: > > http://www.spinics.net/lists/linux-usb/msg60768.html > > The only reason the fsl_udc_core driver does not > have run into that, is that its shared structures > are not marked with the attribute ((packed)). > >> > The others though should go into v3.10, agreed? Waaait, "go into v3.10" means those patches need to be based on my tree and not v3.9-rc4. Those that are based on -rc4 are fixes for v3.9 and are intending to go into v3.9-rcX. I see you just sent 8 patches based on rc4 and only the first one should be. >> Agreed. What about the multi-td patch and the rest? Are you going to >> resend them still? > > I will clean up this series first and add the following patch to it: > > usb: chipidea: udc: prepare qhead with dma_alloc_coherent > > The rest are cleanup and feature patches which will come in seperate > series, as Felipe suggested. Felipe, since you have brought this up, which of these patches seem like v3.9 fixes to you? They are all reasonable improvements, but I see no reason sending them to v3.9, save for the first one. Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
