linux-kernel - [PATCH] [RFC] usb: Do not attempt to reset the device while it is disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4DE4F166.8020207@gmail.com>
Date:	Tue, 31 May 2011 15:47:18 +0200
From:	Maarten Lankhorst <m.b.lankhorst@...il.com>
To:	"Xu, Andiry" <Andiry.Xu@....com>
CC:	linux-usb@...r.kernel.org,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	linux-kernel@...r.kernel.org
Subject: [PATCH] [RFC] usb: Do not attempt to reset the device while it is
 disabled

Hey Andiry,

Op 31-05-11 02:34, Xu, Andiry schreef:
>> -----Original Message-----
>> From:linux-usb-owner@...r.kernel.org  [mailto:linux-usb-
>> owner@...r.kernel.org] On Behalf Of Maarten Lankhorst
>> Sent: Monday, May 30, 2011 5:57 PM
>> To:linux-usb@...r.kernel.org
>> Cc: Sarah Sharp;linux-kernel@...r.kernel.org; Maarten Lankhorst
>> Subject: [PATCH] [RFC] usb: Broaden range of vendor codes for xhci
>>
>> My asrock P67 chipset sends code 192 on device reset. Allowing>= 192
>> to be treated as success fixes it, and allows me to use my USB3 port.
>>
> TRB completion code 192-223 is defined as Vendor defined error. Your
> host
> controller returns a error - don't know what causes the error since it's
> vendor defined.
Ahh, making it the same as COMP_EBADSLT/COMP_CTX_STATE I get this:
[72677.470421] xhci_hcd 0000:04:00.0: Can't reset device (slot ID 1) in 
enabled/disabled state

Should reset_device even be called when in that state? The comments 
above claim:
/* The Reset Device command can't fail, according to the 0.95/0.96 spec,
  * unless we tried to reset a slot ID that wasn't enabled,
  * or the device wasn't in the addressed or configured state.
  */

Ignoring the error seems to make it work fine. It seems to me that 
device reset shouldn't even be attempted since it hasn't been brought up 
yet. The reset that fails is the one that happens on the original 
hub_port_init when it calls hub_port_reset which calls 
xhci_discover_or_reset_device. The failure I'm getting seems to be a 
vendor specific variant of "you're trying to reset the device while it 
wasn't enabled".

Signed-off-by: Maarten Lankhorst<m.b.lankhorst@...il.com>

---
index 81b976e..9a869b2 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2307,6 +2307,10 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
  			return -EINVAL;
  	}

+	if (GET_SLOT_STATE(xhci_get_slot_ctx(xhci, virt_dev->out_ctx)->dev_state) == 0&&
+	    (xhci_get_ep_ctx(xhci, virt_dev->out_ctx, 0)->ep_info&  EP_STATE_MASK) == EP_STATE_DISABLED)
+		return 0;
+
  	xhci_dbg(xhci, "Resetting device with slot ID %u\n", slot_id);
  	/* Allocate the command structure that holds the struct completion.
  	 * Assume we're in process context, since the normal device reset


   

--
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/