[RFT PATCH v1 1/5] Revert "usb: ehci-hcd: Keep async schedule running"
Lukasz Majewski
lukma at denx.de
Tue Mar 24 08:06:17 CET 2020
Hi Marek,
> On 3/23/20 1:41 PM, Lukasz Majewski wrote:
> > Hi Marek,
>
> Hi,
>
> >> On 3/23/20 7:57 AM, Lukasz Majewski wrote:
> >>> Hi Marek,
> >>
> >> Hi,
> >>
> >>>> On 3/22/20 2:00 PM, Lukasz Majewski wrote:
> >>>>> This reverts commit 02b0e1a36c5bc20174299312556ec4e266872bd6.
> >>>>>
> >>>>> Signed-off-by: Lukasz Majewski <lukma at denx.de>
> >>>>
> >>>> This patch lacks any and all explanation why this is being
> >>>> reverted. The patch you are reverting here explains why it was
> >>>> added and what real issues it was fixing, so instead of reverting
> >>>> it, if there is an issue with that patch, you should identify the
> >>>> issue and fix it.
> >>>
> >>> Marek, have you received the cover letter for this patch series?
> >>>
> >>> In the cover letter I've written the rationale for reverting this
> >>> patch.
> >>
> >> That should have been explained in this patch description.
> >>
> >>> In short - qhtoken has value of 0x0, when the token variable shows
> >>> errors. As a result the error handling is broken.
> >>> Could you comment on those arguments?
> >>
> >> Maybe you are referencing/reading the wrong token ?
> >
> > I'm printing the token which is used afterwards for reacting on
> > possible errors.
> >
> >>
> >> You should probably figure out why this doesn't work first and then
> >> add fixes on top.
> >
> > Haven't you seen such problem during code development on your setup
> > when developing this patch?
>
> During the development of the patch, I don't remember, sorry. I most
> certainly saw various failure modes, however those should not be
> present mainline.
The issue is that the qhtoken is not updated at all.
Maybe you remember - is Linux using async setup by default (as
introduced in SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6) ?
>
> I tested this patch with the problematic USB sticks on R-Car Gen3 and
> with SMSC95xx USB ethernet adapter last weekend and I didn't see a
> problem.
Ok.
For i.MX6Q:
The SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6 patch causes the
iMX6Q to fail after a few minutes of testing. General in i.MX6Q the
usb is NOT robust at all.
For i.MX53:
With patch 02b0e1a36c5bc20174299312556ec4e266872bd6 applied it also
breaks after a few minutes.
With this patch series applied it works for 2 days now without any
issue.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200324/717bba31/attachment.sig>
More information about the U-Boot
mailing list