Re: [RFCv2 00/10] xhci: re-work command queue management

2014-02-05 Thread Dan Williams
On Wed, Feb 5, 2014 at 9:05 AM, David Laight wrote: > From: Dan Williams >> Yes, but I think we need to centralize the context under which >> commands are submitted. The complicating factor is the mix of >> synchronous command submission and interrupt driven asynchronous >> command queuing. I th

RE: [RFCv2 00/10] xhci: re-work command queue management

2014-02-05 Thread David Laight
From: Dan Williams > Yes, but I think we need to centralize the context under which > commands are submitted. The complicating factor is the mix of > synchronous command submission and interrupt driven asynchronous > command queuing. I think we can simplify it by making it all > submitted from a

Re: [RFCv2 00/10] xhci: re-work command queue management

2014-02-05 Thread Dan Williams
On Wed, Feb 5, 2014 at 1:22 AM, David Laight wrote: > From: Dan Williams >> > Adding another list that will have its own set of bugs seems retrograde >> > top me. >> >> What bugs? Please be specific. The problem to be addressed is not >> the allocation of commands, but that timeouts of one comm

RE: [RFCv2 00/10] xhci: re-work command queue management

2014-02-05 Thread David Laight
From: Dan Williams > > Adding another list that will have its own set of bugs seems retrograde top > > me. > > What bugs? Please be specific. The problem to be addressed is not > the allocation of commands, but that timeouts of one command eat the > timeout periods of subsequent commands. I'm

Re: [RFCv2 00/10] xhci: re-work command queue management

2014-02-04 Thread Dan Williams
On Thu, Jan 30, 2014 at 6:25 AM, David Laight wrote: > From: Mathias Nyman >> Only changes since v1 are fixing smatch warnings and errors. >> patch 01/10 >> Check for null return from alloc_command, release lock in error path and >> don't dereference possible null pointer in error path.

Re: [RFCv2 00/10] xhci: re-work command queue management

2014-01-30 Thread Sarah Sharp
On Thu, Jan 30, 2014 at 02:25:48PM +, David Laight wrote: > I think it would be much simpler to allocate a parallel array to the actual > hardware command ring that contains the additional information for the request > (instead of allocating it pre-request). > This would immediately solve any p

RE: [RFCv2 00/10] xhci: re-work command queue management

2014-01-30 Thread David Laight
From: Mathias Nyman > Only changes since v1 are fixing smatch warnings and errors. > patch 01/10 > Check for null return from alloc_command, release lock in error path and > don't dereference possible null pointer in error path. > > patch 04/10 > release lock in xhci_stop_dev() err

[RFCv2 00/10] xhci: re-work command queue management

2014-01-30 Thread Mathias Nyman
Only changes since v1 are fixing smatch warnings and errors. patch 01/10 Check for null return from alloc_command, release lock in error path and don't dereference possible null pointer in error path. patch 04/10 release lock in xhci_stop_dev() error path. This is the second