[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220222054018.GD3943@kadam>
Date: Tue, 22 Feb 2022 08:40:19 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Pavel Skripkin <paskripkin@...il.com>
Cc: Michael Straube <straube.linux@...il.com>,
gregkh@...uxfoundation.org, Larry.Finger@...inger.net,
phil@...lpotter.co.uk, linux-staging@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] staging: r8188eu: refactor rtw_ch2freq()
On Mon, Feb 21, 2022 at 11:54:50PM +0300, Pavel Skripkin wrote:
> Hi Michael,
>
> On 2/21/22 22:20, Michael Straube wrote:
> > > I'm glad that Pavel noticed this change. This is a risky thing and
> > > should have been noted in the commit message.
> > >
> > > Just from a review stand point it would be best to leave the original
> > > behavior.
> > >
> >
> > Do you mean to leave the whole original code including the 5 GHz
> > frequencies? Or returning a default value if we have a channel value < 1
> > or > 14?
> >
>
> IMO, your version is much cleaner than previous one. This table walk seems
> really unreasonable, since 5 GHz support is really redundant (I saw it in
> other thread)
>
> I'd put just sanity check and return the default value from previous
> version. Maybe even wrapped with unlikely() if we sure, that in normal state
> we won't hit it ;)
Adding likely()/unlikely() annotations hurt readability. Do not do that
unless you have benchmark data to prove that it is worth it. (Hint: it
is not worth it here).
regards,
dan carpenter
Powered by blists - more mailing lists