Message ID | 20221015151115.232095-4-martin@kaiser.cx |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp679430wrs; Sat, 15 Oct 2022 08:13:36 -0700 (PDT) X-Google-Smtp-Source: AMsMyM791EVtv3X346TRyy1zqp8brt0blB7ngvBQRvO9mCnntlAXt0XyvkYuhlW26G3CXzaj/ija X-Received: by 2002:a05:6402:5489:b0:43b:b935:db37 with SMTP id fg9-20020a056402548900b0043bb935db37mr2738546edb.347.1665846816300; Sat, 15 Oct 2022 08:13:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665846816; cv=none; d=google.com; s=arc-20160816; b=vz1YAFKz64XkwYfiGkUe8ne0tgCpUkbLL9/tGLmjCXgcMz+bmoPOszvLLQmrnGymPl ANj4Ss9v5XfeA4LWadA7j1KjAwMNu3n/77s+jx6Kp2wvOCjQnM0b1qOwYeHiVlHLV441 cK7gUF/XwVk9xLqgBXN3oJCNFkWVWZCItzS36rMt17j5Etqt6L2pFR45w8v8W97QMmel xSG7VdGGumMtbivLRA+5BPIha6rfB7h/szFbbD96CbZyhSRCAlGOkKbkemKG0T+5fNtR 9iRn/740TTmhLQuXo1iH1SQDDBA+Jd8sMf5Zf/ttkwMZMK8O0GF/iz2MKdGpOM1bB6Wy b/Zw== 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=0u9BVPii3t/g91G8+4Assb8fy9cWfsFpT2S8XNEP8p4=; b=PRGBv6fKwGNmgV7SGsBc7S+ztpOxJ8OFcKU0MU+OmzVKSy8SDw5iiwDvXrcR0RNf/5 5/kRXaODE7jfR123a/vDranmtu3/pCG+arGYP6Dec4e5dnWCQeGUthrcthiZ9AIELJjp geMZJd37lZ2H1WJ1RsGophejKjRIALtxt/mQSg54zfHGPnv4hSyJvDsvyAroxidoRc3h NiI/sNprJ5xEiWOVFAHy9w5407Qx2OLsaxCIlgIVkpjAJARZ8J/5BekiHYQ3Ozu08Ms3 Ei+biB9RGNR/nlMjz87t0WJEAi9bQhkPYtKDIvHcBHuUXtD4pPWjxMTAPSNFEBD3x+Zv ydng== 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 hr40-20020a1709073fa800b00780cb1272eesi5753444ejc.466.2022.10.15.08.13.10; Sat, 15 Oct 2022 08:13:36 -0700 (PDT) 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 S229775AbiJOPLw (ORCPT <rfc822;rhyswoolcott@gmail.com> + 99 others); Sat, 15 Oct 2022 11:11:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229776AbiJOPLm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 15 Oct 2022 11:11:42 -0400 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 7DA6F44CFE for <linux-kernel@vger.kernel.org>; Sat, 15 Oct 2022 08:11:38 -0700 (PDT) Received: from ipservice-092-217-066-135.092.217.pools.vodafone-ip.de ([92.217.66.135] 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 1ojip3-0006sp-Bf; Sat, 15 Oct 2022 17:11:33 +0200 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 03/10] staging: r8188eu: fix status updates in SwLedOff Date: Sat, 15 Oct 2022 17:11:08 +0200 Message-Id: <20221015151115.232095-4-martin@kaiser.cx> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20221015151115.232095-1-martin@kaiser.cx> References: <20221015151115.232095-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?1746766991458483662?= X-GMAIL-MSGID: =?utf-8?q?1746766991458483662?= |
Series |
staging: r8188eu: led layer fix and cleanups
|
|
Commit Message
Martin Kaiser
Oct. 15, 2022, 3:11 p.m. UTC
Update bLedOn only if we could update the REG_LEDCFG2 register.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
drivers/staging/r8188eu/core/rtw_led.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Comments
Hi Martin, Martin Kaiser <martin@kaiser.cx> says: > Update bLedOn only if we could update the REG_LEDCFG2 register. > > Signed-off-by: Martin Kaiser <martin@kaiser.cx> > --- > drivers/staging/r8188eu/core/rtw_led.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/r8188eu/core/rtw_led.c b/drivers/staging/r8188eu/core/rtw_led.c > index 4f1cad890cae..38433296d327 100644 > --- a/drivers/staging/r8188eu/core/rtw_led.c > +++ b/drivers/staging/r8188eu/core/rtw_led.c > @@ -43,10 +43,11 @@ static void SwLedOn(struct adapter *padapter, struct led_priv *pLed) > static void SwLedOff(struct adapter *padapter, struct led_priv *pLed) > { > if (padapter->bDriverStopped) > - goto exit; > + return; > + > + if (rtw_write8(padapter, REG_LEDCFG2, BIT(5) | BIT(3)) != _SUCCESS) > + return; > > - rtw_write8(padapter, REG_LEDCFG2, BIT(5) | BIT(3)); > -exit: > pLed->bLedOn = false; > } > If we don't always update the state then, I think, it's better to inform the callers about it I guess, this won't happen often, but you are changing semantic of the function With regards, Pavel Skripkin
Hi Pavel, Thus wrote Pavel Skripkin (paskripkin@gmail.com): > Hi Martin, > Martin Kaiser <martin@kaiser.cx> says: > > Update bLedOn only if we could update the REG_LEDCFG2 register. > > Signed-off-by: Martin Kaiser <martin@kaiser.cx> > > --- > > drivers/staging/r8188eu/core/rtw_led.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/r8188eu/core/rtw_led.c b/drivers/staging/r8188eu/core/rtw_led.c > > index 4f1cad890cae..38433296d327 100644 > > --- a/drivers/staging/r8188eu/core/rtw_led.c > > +++ b/drivers/staging/r8188eu/core/rtw_led.c > > @@ -43,10 +43,11 @@ static void SwLedOn(struct adapter *padapter, struct led_priv *pLed) > > static void SwLedOff(struct adapter *padapter, struct led_priv *pLed) > > { > > if (padapter->bDriverStopped) > > - goto exit; > > + return; > > + > > + if (rtw_write8(padapter, REG_LEDCFG2, BIT(5) | BIT(3)) != _SUCCESS) > > + return; > > - rtw_write8(padapter, REG_LEDCFG2, BIT(5) | BIT(3)); > > -exit: > > pLed->bLedOn = false; > > } > If we don't always update the state then, I think, it's better to inform the > callers about it > I guess, this won't happen often, but you are changing semantic of the > function Changing the state without changing the led feels like a bug to me. It's done only for SwLedOff, nor for SwLedOn. We could add a return value and inform the caller that we could not change the led register. How would callers of SwLedOn or SwLedLOff handle such errors? blink_work looks at bLedOn and calls either SwLedOn or SwLedOff. If bLedOn is not updated and the led is not changed, the next run of the worker will retry. This does already happen with the current code, a return value of SwLedOn/Off would not help here. Best regards, Martin
diff --git a/drivers/staging/r8188eu/core/rtw_led.c b/drivers/staging/r8188eu/core/rtw_led.c index 4f1cad890cae..38433296d327 100644 --- a/drivers/staging/r8188eu/core/rtw_led.c +++ b/drivers/staging/r8188eu/core/rtw_led.c @@ -43,10 +43,11 @@ static void SwLedOn(struct adapter *padapter, struct led_priv *pLed) static void SwLedOff(struct adapter *padapter, struct led_priv *pLed) { if (padapter->bDriverStopped) - goto exit; + return; + + if (rtw_write8(padapter, REG_LEDCFG2, BIT(5) | BIT(3)) != _SUCCESS) + return; - rtw_write8(padapter, REG_LEDCFG2, BIT(5) | BIT(3)); -exit: pLed->bLedOn = false; }