Re: [Outreachy kernel] Re: [PATCH 1/2] staging: vt6656: remove unneeded variable: ret

[Stefano Brivio <sbrivio@redhat.com>]

Hi John,

On Thu, 26 Mar 2020 16:26:13 -0700
John Wyatt <jbwyatt4@gmail.com> wrote:

> On Wed, 2020-03-25 at 09:15 +0000, Quentin Deslandes wrote:
> > On 03/24/20 17:32:01, John Wyatt wrote:  
> > > I do not know what these functions do.
> > > 
> > > There is no function documentation for:
> > > vnt_exit_deep_sleep
> > > vnt_mac_reg_bits_on
> > > vnt_mac_reg_bits_off  
> > 
> > I understand, however discarding the return value of functions that
> > could
> > fail is not the best thing to do. Whatever those 3 functions are
> > doing,
> > you should rely on their return code, and if one of those fail,
> > vnt_radio_power_on() should fail too.
> >   
> > > I am a new kernel developer intern with the Outreachy program. I am
> > > trying to fix a style issue reported by Coccinelle. I do not have
> > > that
> > > much experience with writing drivers yet.  
> > 
> > Don't worry, I'm not that experienced either. If my request is out of
> > scope for an Outreachy mentee, a more experienced contributor will
> > pop
> > in the discussion.  
> 
> To any of the Outreachy mentors please advise on what to do.
> 
> I was asked by Greg Kroah-Hartman to make this patch set, but Quentin
> Deslandes asked to return undocumented return codes for this patch to
> solve this coccinelle issue.

Strictly speaking, those are documented: C code (especially in kernel)
is supposed to be self-documenting, and if you follow the call path
(example for vnt_mac_reg_bits_off()) you'll find out that, eventually,
you might get -EINVAL (not going to actually happen), -ENOMEM, -EIO
(the only likely one, on communication error).

If you forward those return codes as Quentin suggested, those are
handled properly by the callers, so I would say that's the way to go.

-- 
Stefano