Re: [PATCH v7 0/6] usb: chipidea: udc: bugfixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]