Message ID | 20230110205626.183516-5-martin@kaiser.cx |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp2969783wrt; Tue, 10 Jan 2023 13:08:11 -0800 (PST) X-Google-Smtp-Source: AMrXdXt4vK1u0xtvr4bKrbWc6qCkshG4y9Uo1MqucSpkXc8lTjNF0R8PbUXuZMvSSu7H9ZsKDT7i X-Received: by 2002:a17:906:2816:b0:7c0:d452:2e74 with SMTP id r22-20020a170906281600b007c0d4522e74mr60271238ejc.4.1673384891691; Tue, 10 Jan 2023 13:08:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673384891; cv=none; d=google.com; s=arc-20160816; b=ytB4d+ZweCGu6JU1w3JyL6GeSYnMivQFw2+KXOTAuuXidHHSxLXddclA1YtL68jdRu 0FOdZ1udfzayzTQZ1WrJIRfbjocllRjp5kHoWhR8mfRiy2Z5UM9Fqjf3T719RtSEaOFH PY9ph2UbAPZIL8/3MOh25gMMwrbtaEV8RuWgg6ApQMRpTw+ZEE7kBBXWj67sEhofo3SH mywMDfmothkeIiFqHMzfgcAdCAiarcroRCi6eIdkbEZ4xOi53TmiCAY5hSwrmeLYBI8y BBpWHzaEjtrPJSKaYrOGC2oGjeISvHBAKQ1wwFZ4rzsAdtzZm2TzKkqapE5gIXnRie6B /BCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=JwWJFYLSd2CQWw/zaAQ5yw40Gca1r5k8HEaEV9iwZO0=; b=CxEBzBwclN7RjS/QcSXoILW/U4zL+K4PhVX4KJ3BL22if6j9kUgeXLBxfRL+uEduG+ znUYo7wJhbCMbosTxjhht5LGyfFtlIuVTsVwEZJSegSStrh5/O8qPqC2i2qgKRZD7DOW +hHloUp8Wc5wv1MlFN1TAAkgDN/6vH2erJGZ81k20mpClXFx19wOn9dZabeLmGfO0zzL xzbB1n5IYKa/xZ4BtXPkTJN34G2+vMgYSNg9ogx/ny8ooWo6ULmE5SFhPTnC4ROB9FGk tCUNWBbflnWyWb63r4ZTAReTJwh+cDMLJlrJZYBpj4wn3i2ygqfwCxOjjVnbqh1gG8mn KVxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id wv1-20020a170907080100b007c0c5cb19f6si12465655ejb.684.2023.01.10.13.07.47; Tue, 10 Jan 2023 13:08:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234109AbjAJU45 (ORCPT <rfc822;syz17693488234@gmail.com> + 99 others); Tue, 10 Jan 2023 15:56:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232392AbjAJU4r (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 10 Jan 2023 15:56:47 -0500 Received: from viti.kaiser.cx (viti.kaiser.cx [IPv6:2a01:238:43fe:e600:cd0c:bd4a:7a3:8e9f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CD8B5950E for <linux-kernel@vger.kernel.org>; Tue, 10 Jan 2023 12:56:47 -0800 (PST) Received: from dslb-178-004-206-224.178.004.pools.vodafone-ip.de ([178.4.206.224] helo=martin-debian-2.paytec.ch) by viti.kaiser.cx with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <martin@kaiser.cx>) id 1pFLfl-0001pw-3j; Tue, 10 Jan 2023 21:56:41 +0100 From: Martin Kaiser <martin@kaiser.cx> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Larry Finger <Larry.Finger@lwfinger.net>, Phillip Potter <phil@philpotter.co.uk>, Michael Straube <straube.linux@gmail.com>, Pavel Skripkin <paskripkin@gmail.com>, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, Martin Kaiser <martin@kaiser.cx> Subject: [PATCH 4/4] staging: r8188eu: always process urb status Date: Tue, 10 Jan 2023 21:56:26 +0100 Message-Id: <20230110205626.183516-5-martin@kaiser.cx> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230110205626.183516-1-martin@kaiser.cx> References: <20230110205626.183516-1-martin@kaiser.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754671236042452607?= X-GMAIL-MSGID: =?utf-8?q?1754671236042452607?= |
Series | staging: r8188eu: clean up usb_write_port_complete | |
Commit Message
Martin Kaiser
Jan. 10, 2023, 8:56 p.m. UTC
Remove the if clause in usb_write_port_complete and process the urb
status regardless of bSurpriseRemoved, bDriverStopped and
bWritePortCancel.
The only possible results of urb status processing are updates to
bSurpriseRemoved and bDriverStopped. All of the three status variable are
set to true only if the whole USB processing has to be stopped (when the
driver is unloaded or when the system goes to sleep).
It's no problem if one of the "stop everything" variables is already set
and the urb status processing sets another one.
This patch removes the last goto in usb_write_port_complete. It's also
part of the ongoing effort to limit the use of the "stop everything"
variables.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
drivers/staging/r8188eu/os_dep/usb_ops_linux.c | 4 ----
1 file changed, 4 deletions(-)
Comments
Hi Martin, Martin Kaiser <martin@kaiser.cx> says: > Remove the if clause in usb_write_port_complete and process the urb > status regardless of bSurpriseRemoved, bDriverStopped and > bWritePortCancel. > > The only possible results of urb status processing are updates to > bSurpriseRemoved and bDriverStopped. All of the three status variable are > set to true only if the whole USB processing has to be stopped (when the > driver is unloaded or when the system goes to sleep). > Not sure if it matters but we still have that weird rule that after 5 failed usb read/writes bSurpriseRemoved will be set to true Maybe also worth removing above logic? > It's no problem if one of the "stop everything" variables is already set > and the urb status processing sets another one. > > This patch removes the last goto in usb_write_port_complete. It's also > part of the ongoing effort to limit the use of the "stop everything" > variables. > > Signed-off-by: Martin Kaiser <martin@kaiser.cx> > --- > drivers/staging/r8188eu/os_dep/usb_ops_linux.c | 4 ---- > 1 file changed, 4 deletions(-) > > diff --git a/drivers/staging/r8188eu/os_dep/usb_ops_linux.c b/drivers/staging/r8188eu/os_dep/usb_ops_linux.c > index 3fd080091340..62106d2f82ad 100644 > --- a/drivers/staging/r8188eu/os_dep/usb_ops_linux.c > +++ b/drivers/staging/r8188eu/os_dep/usb_ops_linux.c > @@ -44,9 +44,6 @@ static void usb_write_port_complete(struct urb *purb) > if (pxmitbuf->flags == HIGH_QUEUE_INX) > rtw_chk_hi_queue_cmd(padapter); > > - if (padapter->bSurpriseRemoved || padapter->bDriverStopped || padapter->bWritePortCancel) > - goto check_completion; > - > switch (purb->status) { > case 0: > case -EINPROGRESS: > @@ -63,7 +60,6 @@ static void usb_write_port_complete(struct urb *purb) > break; > } > > -check_completion: > rtw_sctx_done_err(&pxmitbuf->sctx, > purb->status ? RTW_SCTX_DONE_WRITE_PORT_ERR : RTW_SCTX_DONE_SUCCESS); > rtw_free_xmitbuf(pxmitpriv, pxmitbuf); With regards, Pavel Skripkin
Hi Pavel, Thus wrote Pavel Skripkin (paskripkin@gmail.com): > Not sure if it matters but we still have that weird rule that after 5 failed > usb read/writes bSurpriseRemoved will be set to true > Maybe also worth removing above logic? thanks for making we aware of this retry counter. It does really look strange. Still, I'm not sure that I understand this well enough to submit a patch for removal. I'll play around with this as time permits... Best regards, Martin
diff --git a/drivers/staging/r8188eu/os_dep/usb_ops_linux.c b/drivers/staging/r8188eu/os_dep/usb_ops_linux.c index 3fd080091340..62106d2f82ad 100644 --- a/drivers/staging/r8188eu/os_dep/usb_ops_linux.c +++ b/drivers/staging/r8188eu/os_dep/usb_ops_linux.c @@ -44,9 +44,6 @@ static void usb_write_port_complete(struct urb *purb) if (pxmitbuf->flags == HIGH_QUEUE_INX) rtw_chk_hi_queue_cmd(padapter); - if (padapter->bSurpriseRemoved || padapter->bDriverStopped || padapter->bWritePortCancel) - goto check_completion; - switch (purb->status) { case 0: case -EINPROGRESS: @@ -63,7 +60,6 @@ static void usb_write_port_complete(struct urb *purb) break; } -check_completion: rtw_sctx_done_err(&pxmitbuf->sctx, purb->status ? RTW_SCTX_DONE_WRITE_PORT_ERR : RTW_SCTX_DONE_SUCCESS); rtw_free_xmitbuf(pxmitpriv, pxmitbuf);