From patchwork Thu Apr 3 14:48:56 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Genoud X-Patchwork-Id: 3932761 Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 7C1CABFF02 for ; Thu, 3 Apr 2014 14:49:29 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8F4AC20260 for ; Thu, 3 Apr 2014 14:49:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BAECF2018E for ; Thu, 3 Apr 2014 14:49:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752517AbaDCOtL (ORCPT ); Thu, 3 Apr 2014 10:49:11 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:47910 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752350AbaDCOtK (ORCPT ); Thu, 3 Apr 2014 10:49:10 -0400 Received: by mail-we0-f174.google.com with SMTP id t60so1959149wes.19 for ; Thu, 03 Apr 2014 07:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=pt3csn+YnEXEPjSy0uBbf4d61Cif8axcleV/UuGeWaY=; b=0FBB+xsBqUgnA8B/cScJ8c9vOCb0xDvUjT+FmuYo+vOTHWfgLnGJONsAqFjPU/V63I NfMyAsXUa9lBMExnce14fT+W5smJEX2poatODLWhJEyjrxbqZZObYihpgvkaVWydh5e+ KsiAZ3sqyQ0H6M6qyi9+aIdTq6Mu4PBTLVRPFO2XbHwERYzVodf0F6SMmNasUjnmacvL 4YIernJKsv1G5k4v133+HeM9/Vn2mt7pOyNpDt1iHpdEaDYKRj5LEv8jXqp1hX/nVXPj 3h0qowgP/WbjbMm+RVCPUcjqzv5DfVLDMSRirF/TUrkWlpQSVCp19J1Xono2XDFtuIma O3Ug== X-Received: by 10.180.24.134 with SMTP id u6mr38798041wif.41.1396536548464; Thu, 03 Apr 2014 07:49:08 -0700 (PDT) Received: from localhost (lyon.paratronic.fr. [213.41.177.106]) by mx.google.com with ESMTPSA id gr2sm8019435wjc.12.2014.04.03.07.49.05 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 03 Apr 2014 07:49:07 -0700 (PDT) From: Richard Genoud To: Ivo van Doorn Cc: Gertjan van Wingerde , Helmut Schaa , "John W. Linville" , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Richard Genoud Subject: [PATCH] rt2x00: Endless loop on hub port power down Date: Thu, 3 Apr 2014 16:48:56 +0200 Message-Id: <1396536536-26423-1-git-send-email-richard.genoud@gmail.com> X-Mailer: git-send-email 1.8.5.5 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I've met an endless (or at least very long) loop if I power down the usb port on witch a usb wifi key is plugged. (Ok, it's not very smart to power down a usb port when a usb key is in used... but still, I think that should not lead to an endless loop). I have a lot of: ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71 (-71==-EPROTO) How to reproduce: - plug an usb wifi key - ip link set wlan0 up - hub-ctrl -b usb_bus -d usb_device -P usb_port -p 0 hub-ctrl source: https://github.com/codazoda/hub-ctrl.c/blob/master/hub-ctrl.c The following patch prevents the endless loop, but I'm really not sure that The Right Way To Do It (R) Signed-off-by: Richard Genoud --- drivers/net/wireless/rt2x00/rt2x00usb.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c index 14142b099019..6bf4067ebf63 100644 --- a/drivers/net/wireless/rt2x00/rt2x00usb.c +++ b/drivers/net/wireless/rt2x00/rt2x00usb.c @@ -68,6 +68,12 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev, } } + /* If the port is powered down, we get a -EPROTO error, and this + * leads to a endless loop. So just say that the device is gone. + */ + if (status == -EPROTO) + clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags); + rt2x00_err(rt2x00dev, "Vendor Request 0x%02x failed for offset 0x%04x with error %d\n", request, offset, status);