On Fri, Aug 23, 2013 at 11:15:16AM +0300, Xenia Ragiadakou wrote:
> This patch replaces the 'event' argument of xhci_handle_cmd_set_deq() and
> xhci_handle_cmd_reset_ep(), which is used to retrieve the command completion
> status code, with the cmd_comp_code directly since it is available.
> 
> Signed-off-by: Xenia Ragiadakou <burzalod...@gmail.com>

Acked-by: Sarah Sharp <sarah.a.sh...@linux.intel.com>

> ---
>  drivers/usb/host/xhci-ring.c | 17 ++++++++---------
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 405db44..e13531f 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1059,7 +1059,7 @@ static void update_ring_for_set_deq_completion(struct 
> xhci_hcd *xhci,
>   * cancellations pending.
>   */
>  static void xhci_handle_cmd_set_deq(struct xhci_hcd *xhci, int slot_id,
> -             struct xhci_event_cmd *event, union xhci_trb *trb)
> +             union xhci_trb *trb, u32 cmd_comp_code)
>  {
>       unsigned int ep_index;
>       unsigned int stream_id;
> @@ -1085,11 +1085,11 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
> *xhci, int slot_id,
>       ep_ctx = xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
>       slot_ctx = xhci_get_slot_ctx(xhci, dev->out_ctx);
>  
> -     if (GET_COMP_CODE(le32_to_cpu(event->status)) != COMP_SUCCESS) {
> +     if (cmd_comp_code != COMP_SUCCESS) {
>               unsigned int ep_state;
>               unsigned int slot_state;
>  
> -             switch (GET_COMP_CODE(le32_to_cpu(event->status))) {
> +             switch (cmd_comp_code) {
>               case COMP_TRB_ERR:
>                       xhci_warn(xhci, "WARN Set TR Deq Ptr cmd invalid 
> because "
>                                       "of stream ID configuration\n");
> @@ -1112,7 +1112,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
> *xhci, int slot_id,
>               default:
>                       xhci_warn(xhci, "WARN Set TR Deq Ptr cmd with unknown "
>                                       "completion code of %u.\n",
> -                               GET_COMP_CODE(le32_to_cpu(event->status)));
> +                               cmd_comp_code);
>                       break;
>               }
>               /* OK what do we do now?  The endpoint state is hosed, and we
> @@ -1150,7 +1150,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
> *xhci, int slot_id,
>  }
>  
>  static void xhci_handle_cmd_reset_ep(struct xhci_hcd *xhci, int slot_id,
> -             struct xhci_event_cmd *event, union xhci_trb *trb)
> +             union xhci_trb *trb, u32 cmd_comp_code)
>  {
>       unsigned int ep_index;
>  
> @@ -1159,8 +1159,7 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd 
> *xhci, int slot_id,
>        * but we don't care.
>        */
>       xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep,
> -             "Ignoring reset ep completion code of %u",
> -              GET_COMP_CODE(le32_to_cpu(event->status)));
> +             "Ignoring reset ep completion code of %u", cmd_comp_code);
>  
>       /* HW with the reset endpoint quirk needs to have a configure endpoint
>        * command complete before the endpoint can be used.  Queue that here
> @@ -1550,12 +1549,12 @@ static void handle_cmd_completion(struct xhci_hcd 
> *xhci,
>               xhci_handle_cmd_stop_ep(xhci, slot_id, cmd_trb, event);
>               break;
>       case TRB_SET_DEQ:
> -             xhci_handle_cmd_set_deq(xhci, slot_id, event, cmd_trb);
> +             xhci_handle_cmd_set_deq(xhci, slot_id, cmd_trb, cmd_comp_code);
>               break;
>       case TRB_CMD_NOOP:
>               break;
>       case TRB_RESET_EP:
> -             xhci_handle_cmd_reset_ep(xhci, slot_id, event, cmd_trb);
> +             xhci_handle_cmd_reset_ep(xhci, slot_id, cmd_trb, cmd_comp_code);
>               break;
>       case TRB_RESET_DEV:
>               xhci_handle_cmd_reset_dev(xhci, slot_id, event);
> -- 
> 1.8.3.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to