From: Pavel Skripkin <paskripkin@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: gregkh@linuxfoundation.org, Larry.Finger@lwfinger.net,
phil@philpotter.co.uk, straube.linux@gmail.com,
fmdefrancesco@gmail.com, linux-kernel@vger.kernel.org,
linux-staging@lists.linux.dev
Subject: Re: [PATCH 1/4] staging: r8188eu: add error handling of rtw_read8
Date: Thu, 19 May 2022 08:43:23 +0300 [thread overview]
Message-ID: <ff322920-6ddd-159d-b2f2-c0e4fc2e518f@gmail.com> (raw)
In-Reply-To: <20220519043306.GS4009@kadam>
[-- Attachment #1.1: Type: text/plain, Size: 2777 bytes --]
Hi Dan,
On 5/19/22 07:33, Dan Carpenter wrote:
> On Thu, May 19, 2022 at 01:11:51AM +0300, Pavel Skripkin wrote:
>> @@ -240,12 +259,14 @@ int rtl8188e_firmware_download(struct adapter *padapter)
>> {
>> int ret = _SUCCESS;
>> u8 write_fw_retry = 0;
>> + u8 reg;
>> unsigned long fwdl_timeout;
>> struct dvobj_priv *dvobj = adapter_to_dvobj(padapter);
>> struct device *device = dvobj_to_dev(dvobj);
>> struct rt_firmware_hdr *fwhdr = NULL;
>> u8 *fw_data;
>> u32 fw_size;
>> + int res;
>>
>> if (!dvobj->firmware.data)
>> ret = load_firmware(&dvobj->firmware, device);
>> @@ -269,7 +290,11 @@ int rtl8188e_firmware_download(struct adapter *padapter)
>>
>> /* Suggested by Filen. If 8051 is running in RAM code, driver should inform Fw to reset by itself, */
>> /* or it will cause download Fw fail. 2010.02.01. by tynli. */
>> - if (rtw_read8(padapter, REG_MCUFWDL) & RAM_DL_SEL) { /* 8051 RAM code */
>> + res = rtw_read8(padapter, REG_MCUFWDL, ®);
>> + if (res)
>> + goto exit;
>
> You didn't introduce this bug, but this path needs to have an error code
> set. Also we really need to get rid of the _FAIL garbage. When I saw
> this, I got "ret" and "res" mixed up so I thought we were returning
> negative error codes instead of _FAIL. That would But then I saw we
> are returning success.
>
I see now, that 'res' and 'ret' got mixed up in my mind too. Will fix up
>> +
>> + if (reg & RAM_DL_SEL) { /* 8051 RAM code */
>> rtw_write8(padapter, REG_MCUFWDL, 0x00);
>> rtw_reset_8051(padapter);
>> }
>> @@ -278,7 +303,14 @@ int rtl8188e_firmware_download(struct adapter *padapter)
>> fwdl_timeout = jiffies + msecs_to_jiffies(500);
>> while (1) {
>> /* reset the FWDL chksum */
>> - rtw_write8(padapter, REG_MCUFWDL, rtw_read8(padapter, REG_MCUFWDL) | FWDL_CHKSUM_RPT);
>> + res = rtw_read8(padapter, REG_MCUFWDL, ®);
>> + if (res == -ENODEV)
>> + break;
>> +
>> + if (res)
>> + continue;
>
> This continue is wrong. If res = -EPERM then it's a forever loop.
> Let's just break for every error.
>
I was trying to avoid strict breaking the loop on any error, since I am
afraid this might break the driver.
What about:
do {
/* reset the FWDL chksum */
ret = rtw_read8(padapter, REG_MCUFWDL, ®);
if (ret == -ENODEV || ret == -EPERM)
break;
if (ret) {
ret == _FAIL;
continue;
}
rtw_write8(padapter, REG_MCUFWDL, reg | FWDL_CHKSUM_RPT);
ret = write_fw(padapter, fw_data, fw_size);
} while (!(ret == _SUCCESS ||
(time_after(jiffies, fwdl_timeout) && write_fw_retry++ >= 3)))
The idea is to break only on fatal errors to make things less strict
With regards,
Pavel Skripkin
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2022-05-19 5:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-18 22:11 [PATCH 0/4] staging: r8188eu: add error handling of usb read errors Pavel Skripkin
2022-05-18 22:11 ` [PATCH 1/4] staging: r8188eu: add error handling of rtw_read8 Pavel Skripkin
2022-05-19 1:34 ` kernel test robot
2022-05-19 4:33 ` Dan Carpenter
2022-05-19 5:43 ` Pavel Skripkin [this message]
2022-05-19 5:49 ` Dan Carpenter
2022-05-18 22:11 ` [PATCH 2/4] staging: r8188eu: add error handling of rtw_read16 Pavel Skripkin
2022-05-19 4:47 ` Dan Carpenter
2022-05-18 22:12 ` [PATCH 3/4] staging: r8188eu: add error handling of rtw_read32 Pavel Skripkin
2022-05-19 5:43 ` Dan Carpenter
2022-05-19 5:48 ` Pavel Skripkin
2022-05-18 22:12 ` [PATCH 4/4] MAINTAINERS: add myself as r8188eu reviewer Pavel Skripkin
2022-05-19 5:46 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ff322920-6ddd-159d-b2f2-c0e4fc2e518f@gmail.com \
--to=paskripkin@gmail.com \
--cc=Larry.Finger@lwfinger.net \
--cc=dan.carpenter@oracle.com \
--cc=fmdefrancesco@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=phil@philpotter.co.uk \
--cc=straube.linux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.