[U-Boot] [PULL] u-boot-usb/master

Marek Vasut
2016-01-02T17:14:41Z

On Saturday, January 02, 2016 at 06:06:30 PM, Tom Rini wrote:
> On Thu, Dec 31, 2015 at 04:17:22PM +0100, Marek Vasut wrote:
> > On Thursday, December 31, 2015 at 02:41:21 PM, Tom Rini wrote:
> > > On Thu, Dec 31, 2015 at 10:30:02AM +0100, Marek Vasut wrote:
> > > > The following changes since commit
78680314c53a95c0bb25e942662979843b60d7b9:
> > > > Merge branch 'master' of http://git.denx.de/u-boot-sunxi
> > > > (2015-12-27 09:15:57
> > > >
> > > > -0500)
> > > >
> > > > are available in the git repository at:
> > > > git://git.denx.de/u-boot-usb.git master
> > > >
> > > > for you to fetch changes up to f3643fe7d0dcd8a799fe8882db0903b3477e6338:
> > > > usb: musb: Fix hub port setting for SPLIT transactions (2015-12-31
> > > > 10:05:32
> > > >
> > > > +0100)
> > > >
> > > > ----------------------------------------------------------------
> > > >
> > > > Stefan Br?ns (4):
> > > > usb: Alloc buffer for USB descriptor dynamically
> > > > usb: dwc2: avoid out of bounds access
> > > > usb: Move determination of TT hub address/port into separate
> > > > function usb: musb: Fix hub port setting for SPLIT transactions
> > >
> > > It looks like nearly everything is failing with:
> > > +(T1024RDB_SPIFLASH) ../drivers/usb/host/ehci-hcd.c: In function
> > > 'ehci_update_endpt2_dev_n_port': +(T1024RDB_SPIFLASH)
> > > ../drivers/usb/host/ehci-hcd.c:290:2: error: expected ';' before 'qh'
> > > +(T1024RDB_SPIFLASH) qh->qh_endpt2 |=
> > > cpu_to_hc32(QH_ENDPT2_PORTNUM(portnr) | +(T1024RDB_SPIFLASH) ^
> > > +(T1024RDB_SPIFLASH) make[2]: *** [drivers/usb/host/ehci-hcd.o] Error 1
> > > +(T1024RDB_SPIFLASH) make[1]: *** [drivers/usb/host] Error 2
> > > +(T1024RDB_SPIFLASH) make: *** [sub-make] Error 2
> > >
> > > mx6dlarm2 is another one, if you don't have powerpc toolchain handy.
> >
> > I should stop trusting people that they even compile-tested their patches
> > :-( Well, please pull again, I fixed the patch and pushed again ...
>
> And this is really just bugfixes rather than new functionality that can
> wait? Thanks!

Cleanup and bugfixes. There is no significant new functionality, so I think
this is safe to apply.

Best regards,
Marek Vasut