[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D45567F@AcuExch.aculab.com>
Date: Wed, 8 Jan 2014 17:24:42 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Alan Stern' <stern@...land.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
walt <w41ter@...il.com>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within
a USB payload burst
> From: Alan Stern
> On Wed, 8 Jan 2014, David Laight wrote:
>
> > > From: Alan Stern
> > >
> > > This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> > > the first place?
> >
> > Because it can't write in a link TRB because other parts of the
> > code use link TRBs to detect the end of the ring.
> >
> > The problem is that it can't put a link TRB in the middle of
> > a chain of data fragments unless it is at a 'suitable' offset
> > from the start of the data TD. Given arbitrary input fragmentation
> > this means that you can't put a link TRB in the middle of a TD.
> > (The documented alignment might be as high as 16kB.)
> >
> > If the rest of the code used a 'ring end pointer' then a link TRB
> > could be used instead.
>
> I see. Sounds like a poor design decision in hindsight. Can it be
> changed?
Anything can be changed :-)
But it is a bit pervasive.
Padding out with nops isolated the change.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists