Okay, thanks, sounds good. I personally don't care that much about the
stable backport. Let me respin this with a fixed commit message and
the type change Felipe suggested.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 04/29/2014 06:11 AM, Julius Werner wrote:
*bump*
Sarah, Mathias, can we decide how to proceed with this? I think the
section Alan quoted is a pretty good argument in favor of my
interpretation (although of course this would not be the first time
that two sections of a spec contradict each
On 04/29/2014 06:11 AM, Julius Werner wrote:
*bump*
Sarah, Mathias, can we decide how to proceed with this? I think the
section Alan quoted is a pretty good argument in favor of my
interpretation (although of course this would not be the first time
that two sections of a spec contradict each
Okay, thanks, sounds good. I personally don't care that much about the
stable backport. Let me respin this with a fixed commit message and
the type change Felipe suggested.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
*bump*
Sarah, Mathias, can we decide how to proceed with this? I think the
section Alan quoted is a pretty good argument in favor of my
interpretation (although of course this would not be the first time
that two sections of a spec contradict each other). But more
importantly, we have a case that
*bump*
Sarah, Mathias, can we decide how to proceed with this? I think the
section Alan quoted is a pretty good argument in favor of my
interpretation (although of course this would not be the first time
that two sections of a spec contradict each other). But more
importantly, we have a case that
On Tue, 1 Apr 2014, Julius Werner wrote:
> > http://marc.info/?l=linux-usb=137158978503741=2
> >
> > There's an xHCI spec ambiguity: Does the last valid context entry refer
> > to the last valid endpoint context in the *input* device context or the
> > *output* device context?
It's not
> http://marc.info/?l=linux-usb=137158978503741=2
>
> There's an xHCI spec ambiguity: Does the last valid context entry refer
> to the last valid endpoint context in the *input* device context or the
> *output* device context?
>
> The code currently assumes it refers to the input device context,
http://marc.info/?l=linux-usbm=137158978503741w=2
There's an xHCI spec ambiguity: Does the last valid context entry refer
to the last valid endpoint context in the *input* device context or the
*output* device context?
The code currently assumes it refers to the input device context,
On Tue, 1 Apr 2014, Julius Werner wrote:
http://marc.info/?l=linux-usbm=137158978503741w=2
There's an xHCI spec ambiguity: Does the last valid context entry refer
to the last valid endpoint context in the *input* device context or the
*output* device context?
It's not ambiguous at
On Tue, Mar 25, 2014 at 11:42:43AM -0700, Julius Werner wrote:
> The current XHCI driver recalculates the Context Entries field in the
> Slot Context on every add_endpoint() and drop_endpoint() call. In the
> case of drop_endpoint(), it seems to assume that the add_flags will
> always contain
On Tue, Mar 25, 2014 at 11:42:43AM -0700, Julius Werner wrote:
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every
On 03/25/2014 08:42 PM, Julius Werner wrote:
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new
Hi,
On Tue, Mar 25, 2014 at 11:42:43AM -0700, Julius Werner wrote:
> @@ -2723,8 +2697,19 @@ int xhci_check_bandwidth(struct usb_hcd *hcd, struct
> usb_device *udev)
> ctrl_ctx->drop_flags == 0)
> return 0;
>
> - xhci_dbg(xhci, "New Input Control
Hi,
On Tue, Mar 25, 2014 at 11:42:43AM -0700, Julius Werner wrote:
@@ -2723,8 +2697,19 @@ int xhci_check_bandwidth(struct usb_hcd *hcd, struct
usb_device *udev)
ctrl_ctx-drop_flags == 0)
return 0;
- xhci_dbg(xhci, New Input Control Context:\n);
+
On 03/25/2014 08:42 PM, Julius Werner wrote:
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new configuration, which is not
necessarily correct
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new configuration, which is not
necessarily correct
18 matches
Mail list logo
