On Fri, Jul 19, 2019 at 04:22:10PM +0100, Michael Brown wrote:
> On 19/07/2019 12:53, Leif Lindholm wrote:
> > The patches look good, and I don't mind you upstreaming Michael's
> > code, *but* I don't want patches submitted with anyone other than the
> > contributor's Signed-off-by:. (It's the
On Fri, Jul 19, 2019 at 04:40:48PM +0100, Pete Batard wrote:
> > (If patches are modified after contribution, but before being pushed,
> > then then additional contributions can be reflected with additional
> > Signed-off-bys. Make sense?)
> >
> > The From: tag ensures he still retains
Hi Leif,
On 2019.07.19 12:53, Leif Lindholm wrote:
Hi Pete,
On Wed, Jul 17, 2019 at 12:46:42PM +0100, Pete Batard wrote:
Networking applications (e.g. iPXE) might experience failures when submitting
a bulk IN for the NIC's RX endpoint, because the bulk IN (correctly) times out
when no
On 19/07/2019 12:53, Leif Lindholm wrote:
The patches look good, and I don't mind you upstreaming Michael's
code, *but* I don't want patches submitted with anyone other than the
contributor's Signed-off-by:. (It's the equivalent of saying "Yeah,
Michael says he's OK with
Hi Pete,
On Wed, Jul 17, 2019 at 12:46:42PM +0100, Pete Batard wrote:
> Networking applications (e.g. iPXE) might experience failures when submitting
> a bulk IN for the NIC's RX endpoint, because the bulk IN (correctly) times out
> when no received packet is waiting, but DwUsbHostDxe.c treats
Networking applications (e.g. iPXE) might experience failures when submitting
a bulk IN for the NIC's RX endpoint, because the bulk IN (correctly) times out
when no received packet is waiting, but DwUsbHostDxe.c treats this as a fatal
error.
With these patches, iPXE is able to successfully
