Dear Marek Vasut,
> > > > @@ -246,19 +247,20 @@ ehci_submit_async(struct usb_device *dev,
> > > > unsigned
> > > > long pipe, void *buffer, */
> > > >
> > > > qh->qh_link = cpu_to_hc32((uint32_t)qh_list |
> > > > QH_LINK_TYPE_QH);
> > > > c = (usb_pipespeed(pipe) != USB_SPEED_HIGH &&
> > > >
> > > > - usb_pipeendpoint(pipe) == 0) ? 1 : 0;
> > > > - endpt = (8 << 28) |
> > > > - (c << 27) |
> > > > - (usb_maxpacket(dev, pipe) << 16) |
> > > > - (0 << 15) |
> > > > - (1 << 14) |
> > > > - (usb_pipespeed(pipe) << 12) |
> > > > - (usb_pipeendpoint(pipe) << 8) |
> > > > - (0 << 7) | (usb_pipedevice(pipe) << 0);
> > > > + usb_pipeendpoint(pipe) == 0);
> > > > + endpt = (8 << QH_ENDPT1_RL) |
> > > > + (c << QH_ENDPT1_C) |
> > >
> > > Maybe define it as #deifne QH_ENDPT1(x) ((x) << SEOMTHING) ?
> > > [...]
> >
> > For all of these?
>
> Yes, do you not think it's better than define the offsets only?
Yes, I hesitated with this solution when writing this code.
Where the offset is needed, I can instead write additional extraction macros.
> > > > @@ -398,50 +408,53 @@ ehci_submit_async(struct usb_device *dev,
> > > > unsigned
> > > > long pipe, void *buffer, ALIGN((uint32_t)buffer + length,
> > > > ARCH_DMA_MINALIGN));
> > > >
> > > > /* Check that the TD processing happened */
> > > >
> > > > - if (token & 0x80) {
> > > > + if (token & (QT_TOKEN_STATUS_ACTIVE << QT_TOKEN_STATUS))
> > > >
> > > > printf("EHCI timed out on TD - token=%#x\n", token);
> > > >
> > > > - }
> > > >
> > > > /* Disable async schedule. */
> > > > cmd = ehci_readl(&hcor->or_usbcmd);
> > > > cmd &= ~CMD_ASE;
> > > > ehci_writel(&hcor->or_usbcmd, cmd);
> > > >
> > > > - ret = handshake((uint32_t *)&hcor->or_usbsts, STD_ASS, 0,
> > > > + ret = handshake((uint32_t *)&hcor->or_usbsts, STS_ASS, 0,
> > >
> > > Ooooh, nice catch :)
> > >
> > > [...]
> > > The rest is cool.
> > >
> > > btw when (I hope you will) resubmitting next time, just submit
> > > the
> > > whole series
> > > under 0/8 patch (or 1/8) of the old one to make it a nice thread.
> >
> > OK, so with 2/8 removed since you have applied it.
>
> Yes
>
> > What is the rule here? I
> > thought that a new version of a patch should be posted as a reply
> > to the
> > previous version so that patchwork could mark the old version as
> > superseded
>
> Yes, unless the series changed so much (aka. too much reordering
> etc), that it's
> easier to repost it in reply to the first patch in the series.
>
> > (even if this feature is not yet available for U-Boot). Does it
> > apply only
> > to single patches while series should be replied to the previous
> > 0/n?
>
> I didn't figure out these gems in patchwork myself. I'm not a big fan
> of PW
> either.
>
> > And should 3/n be a reply to 2/n, to 0/n (or to 1/n if no 0/n), or
> > to
> > nothing?
>
> Just use the standard threading git send-email does.
>
> > I will wait for your review of 8/8.
>
> I think it's fine to just resend it so I'll either pick first 7 or
> all 8. First
> 7 are certain once we agree on the above stuff :)
OK.
Best regards,
Benoît
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
