All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Skripkin <paskripkin@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Larry.Finger@lwfinger.net, phil@philpotter.co.uk,
	straube.linux@gmail.com, dan.carpenter@oracle.com,
	fmdefrancesco@gmail.com, linux-kernel@vger.kernel.org,
	linux-staging@lists.linux.dev
Subject: Re: [PATCH v2 1/4] staging: r8188eu: add error handling of rtw_read8
Date: Mon, 6 Jun 2022 21:57:32 +0300	[thread overview]
Message-ID: <5d57d0f5-06bd-5e3a-2cb9-d8ae531e453e@gmail.com> (raw)
In-Reply-To: <Yp2VMecmrET9Mu3P@kroah.com>

Hi Greg,

On 6/6/22 08:48, Greg KH wrote:
>> -	rtw_read8(padapter, REG_FMETHR);
>> +	/* FIXME: should this read be removed? */
>> +	res = rtw_read8(padapter, REG_FMETHR, &reg);
>> +	(void)res;
> 
> What is that?  We don't do "empty" lines like this in the kernel for no
> good reason.  If the return value must be checked, then that's fine, but
> don't do it this way.  Shouldn't the function itself return an error?
> 
> And reading a value is sometimes required by hardware in order to have
> the write call go through.  But that's for PCI devices, not normally USB
> devices, but we could be wrong.  I wouldn't put a FIXME in here unless
> you have some plan for how to eventually solve it, otherwise someone
> might just drop it without knowing why the FIXME was ever added.
> 
> 

Ok, I will just make this function return an error. Thanks

[snip]

>>  
>> diff --git a/drivers/staging/r8188eu/hal/HalPhyRf_8188e.c b/drivers/staging/r8188eu/hal/HalPhyRf_8188e.c
>> index b944c8071a3b..a5b7980dfcee 100644
>> --- a/drivers/staging/r8188eu/hal/HalPhyRf_8188e.c
>> +++ b/drivers/staging/r8188eu/hal/HalPhyRf_8188e.c
>> @@ -463,6 +463,7 @@ void _PHY_SaveADDARegisters(struct adapter *adapt, u32 *ADDAReg, u32 *ADDABackup
>>  	}
>>  }
>>  
>> +/* FIXME: return an error to caller */
> 
> When are these FIXME going to be resolved?  I don't like adding them for
> no good reason.
> 

After this series will go in. I really don't want to make this series 
huge, since ideally read errors should be passed up to callers. This 
driver has a lot of very deep call-chains, so fixing them in one series 
is just unreal

I have a plan to address these FIXMEs, that's why I've planted them.


thanks for review,


With regards,
Pavel Skripkin

  reply	other threads:[~2022-06-06 18:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19 21:09 [PATCH v2 0/4] staging: r8188eu: add error handling of usb read errors Pavel Skripkin
2022-05-19 21:09 ` [PATCH v2 1/4] staging: r8188eu: add error handling of rtw_read8 Pavel Skripkin
2022-06-06  5:48   ` Greg KH
2022-06-06 18:57     ` Pavel Skripkin [this message]
2022-05-19 21:09 ` [PATCH v2 2/4] staging: r8188eu: add error handling of rtw_read16 Pavel Skripkin
2022-06-06  5:48   ` Greg KH
2022-06-06 19:00     ` Pavel Skripkin
2022-05-19 21:10 ` [PATCH v2 3/4] staging: r8188eu: add error handling of rtw_read32 Pavel Skripkin
2022-05-20  7:43 ` [PATCH v2 0/4] staging: r8188eu: add error handling of usb read errors 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=5d57d0f5-06bd-5e3a-2cb9-d8ae531e453e@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.