From: Joe Perches <joe@perches.com>
To: Marcus Wolf <marcus.wolf@smarthome-wolf.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
dan.carpenter@oracle.com
Subject: Re: staging: pi433: Possible bug in rf69.c
Date: Sat, 11 Nov 2017 08:02:07 -0800 [thread overview]
Message-ID: <1510416127.10883.30.camel@perches.com> (raw)
In-Reply-To: <709d3e3f-be3b-aa98-1cf6-6a048ef14d7b@smarthome-wolf.de>
On Fri, 2017-11-10 at 18:23 +0100, Marcus Wolf wrote:
> Hi everybody!
>
> Just comparing the master of Gregs statging of pi433 with my local SVN
> to review all changes, that were done the last monthes.
>
> I am not sure, but maybe we imported a bug in rf69.c lines 378 and
> following:
>
> Gregs repo:
> case automatic: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) & LNA_GAIN_AUTO) );
> case max: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) & LNA_GAIN_MAX) );
> case maxMinus6: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_6) );
> case maxMinus12: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_12) );
> case maxMinus24: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_24) );
> case maxMinus36: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_36) );
> case maxMinus48: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_48) );
>
> my repo:
> case automatic: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) | LNA_GAIN_AUTO) );
> case max: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) | LNA_GAIN_MAX) );
> case maxMinus6: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_6) );
> case maxMinus12: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_12) );
> case maxMinus24: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_24) );
> case maxMinus36: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_36) );
> case maxMinus48: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_48) );
>
> Up to my opinion, my (old) version is better then Gregs (new) version.
> If you agree, I'll prepare a patch, to revert the modification.
There seems to be a lot of enum/#define duplication in this driver.
For instance:
drivers/staging/pi433/rf69_registers.h
#define LNA_GAIN_AUTO 0x00 /* default */
#define LNA_GAIN_MAX 0x01
#define LNA_GA
IN_MAX_MINUS_6 0x02
#define LNA_GAIN_MAX_MINUS_12
0x03
#define LNA_GAIN_MAX_MINUS_24
0x04
#define LNA_GAIN_MAX_MINUS_36 0x05
#d
efine LNA_GAIN_MAX_MINUS_48 0x06
vs
drivers/staging/pi433/rf69_enum.h
enum lnaGain
{
automatic,
max,
maxMinus6,
maxMinus12,
maxM
inus24,
maxMinus36,
maxMinus48,
undefined
};
My suggestion would be to remove drivers/staging/pi433/rf69_enum.h
where possible and convert all these switch/case entries into
macros like
#define GAIN_CASE(type) \
case type: return WRITE_REG(REG_LNA, \
(READ_REG(REG_LNA) & ~MASK_LNA_GAIN) | (type));
so for example this switch becomes
switch (lnaGain) {
GAIN_CASE(LNA_GAIN_AUTO);
...
}
next prev parent reply other threads:[~2017-11-11 16:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 17:23 staging: pi433: Possible bug in rf69.c Marcus Wolf
2017-11-10 19:32 ` Dan Carpenter
2017-11-11 7:55 ` Marcus Wolf
2017-11-11 8:40 ` Dan Carpenter
2017-11-11 8:45 ` Dan Carpenter
2017-11-11 9:42 ` Marcus Wolf
2017-11-11 11:18 ` Greg Kroah-Hartman
2017-11-11 11:42 ` Marcus Wolf
2017-11-11 11:49 ` Greg Kroah-Hartman
2017-11-11 11:51 ` Marcus Wolf
2017-11-11 12:33 ` Greg Kroah-Hartman
2017-11-11 12:10 ` Dan Carpenter
2017-11-11 16:02 ` Joe Perches [this message]
2017-11-11 16:40 ` Marcus Wolf
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=1510416127.10883.30.camel@perches.com \
--to=joe@perches.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcus.wolf@smarthome-wolf.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox