Re: [PATCH] staging: pi433: #define shift constants in rf69.c
On Wed, Nov 08, 2017 at 02:52:30PM +0300, Dan Carpenter wrote:
> On Wed, Nov 08, 2017 at 06:25:06AM -0500, Joshua Abraham wrote:
> > This patch completes TODO improvements in rf69.c to change shift
> > constants to a define.
> >
> > Signed-off-by: Joshua Abraham
> > ---
> > drivers/staging/pi433/rf69.c | 4 ++--
> > drivers/staging/pi433/rf69_registers.h | 4
> > 2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> > index e69a2153c999..cfcace195be9 100644
> > --- a/drivers/staging/pi433/rf69.c
> > +++ b/drivers/staging/pi433/rf69.c
> > @@ -102,7 +102,7 @@ enum modulation rf69_get_modulation(struct spi_device
> > *spi)
> >
> > currentValue = READ_REG(REG_DATAMODUL);
> >
> > - switch (currentValue & MASK_DATAMODUL_MODULATION_TYPE >> 3) { // TODO
> > improvement: change 3 to define
> > + switch (currentValue & MASK_DATAMODUL_MODULATION_TYPE >>
> > SHIFT_DATAMODUL_MODE) {
>
> You've send a few of mechanical patches without waiting for feedback and
> you should probably slow down...
>
Understood. I am just excited about submitting patches.
> The first thing to notice is that the original code is probably buggy
> and needs parenthesis.
>
> switch ((currentValue & MASK_DATAMODUL_MODULATION_TYPE) >> 3) {
>
> But that still doesn't fix the problem that x18 >> 3 is never going to
> equal to DATAMODUL_MODULATION_TYPE_OOK which is 0x8... So there are a
> couple bugs here.
>
> The line is over 80 characters, so checkpatch will complain about your
> patch. Please run checkpatch.pl on all your patches. Really, I hate
> all the naming here... Surely we can think of a better name than
> MASK_DATAMODUL_MODULATION_TYPE? Normally the "MASK" and "SHIFT" part of
> the name go at the end instead of the start.
>
I named the define to be consistent with the extant code, but I agree
that the names could be better.
> > /* RegDataModul */
> > +#define SHIFT_DATAMODUL_MODE 0x03
> > +
> > #define MASK_DATAMODUL_MODE 0x06
>
> Why did you add a blank line? Don't use hex values for shifting, use
> normal numbers. The 0x3 is indented too far.
>
I added the blank line to separate shifts from masks, but since the shift
will only be performed on the mask I supposed it isn't needed.
> Anyway, take your time and really think about patches before you send
> them. Normally, I write a patch, then wait overnight, then review it
> and again in the morning before I send it.
>
> regards,
> dan carpenter
>
Thanks for the criticism. I will be better.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: fsl-dpaa2: Fix multiple assignments should be avoided
On Wed, Nov 08, 2017 at 10:20:48AM +0100, Greg KH wrote: > On Tue, Nov 07, 2017 at 07:45:03PM -0500, Joshua Abraham wrote: > > This patch fixes the checkpatch.pl warning: > > "CHECK: multiple assignments should be avoided" > > > > Signed-off-by: Joshua Abraham > > --- > > drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c > > b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c > > index 0d8ed002adcb..384218946108 100644 > > --- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c > > +++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c > > @@ -1661,7 +1661,8 @@ static void set_fq_affinity(struct dpaa2_eth_priv > > *priv) > > * This may well change at runtime, either through irqbalance or > > * through direct user intervention. > > */ > > - rx_cpu = txc_cpu = cpumask_first(&priv->dpio_cpumask); > > + rx_cpu = cpumask_first(&priv->dpio_cpumask); > > + txc_cpu = rx_cpu; > > The original code here makes much more sense, doesn't it? > > Sometimes checkpatch is wrong :) > > thanks, > > greg k-h It does make a lot more sense. I will trust checkpatch less, and my eyes more :) -Josh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: nvec: Fix usleep_range is preferred over udelay
On Wed, Nov 29, 2017 at 06:07:53PM +0200, Mikko Perttunen wrote:
> On 11/29/2017 06:00 PM, Joshua Abraham wrote:
> > Signed-off-by: Joshua Abraham
> >
> > This patch fixes the issue:
> >
> > CHECK: usleep_range is preferred over udelay; see
> > Documentation/timers/timers-howto.txt
> >
> > ---
> > drivers/staging/nvec/nvec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
> > index 4ff8f47385da..2a01ef4b54ff 100644
> > --- a/drivers/staging/nvec/nvec.c
> > +++ b/drivers/staging/nvec/nvec.c
> > @@ -631,7 +631,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
> > break;
> > case 2: /* first byte after command */
> > if (status == (I2C_SL_IRQ | RNW | RCVD)) {
> > - udelay(33);
> > + usleep_range(30, 35);
> > if (nvec->rx->data[0] != 0x01) {
> > dev_err(nvec->dev,
> > "Read without prior read command\n");
> >
>
> This is incorrect, as this function is an interrupt handler and we cannot
> sleep in interrupt context.
>
> Cheers,
> Mikko
My mistake. Thank you for the feedback!
-Josh
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: xgifb: remove unused macro XGIPART3
On Thu, Nov 30, 2017 at 08:55:44AM +0300, Dan Carpenter wrote: > On Wed, Nov 29, 2017 at 09:53:48PM -0500, Joshua Abraham wrote: > > Signed-off-by: Joshua Abraham > > > > This patch removes the unused macro XGIPART3. > > > > The Signed-off-by line goes after the changelog. > > > --- > > drivers/staging/xgifb/XGI_main.h | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/staging/xgifb/XGI_main.h > > b/drivers/staging/xgifb/XGI_main.h > > index a3af1cbbf8ee..5f55d0a39bc1 100644 > > --- a/drivers/staging/xgifb/XGI_main.h > > +++ b/drivers/staging/xgifb/XGI_main.h > > @@ -25,7 +25,6 @@ MODULE_DEVICE_TABLE(pci, xgifb_pci_table); > > #define XGIDACD (xgifb_info->dev_info.P3c9) > > #define XGIPART1 (xgifb_info->dev_info.Part1Port) > > #define XGIPART2 (xgifb_info->dev_info.Part2Port) > > -#define XGIPART3 (xgifb_info->dev_info.Part3Port) > > That define isn't hurting anyone. > > > #define XGIPART4 (xgifb_info->dev_info.Part4Port) > > #define XGIPART5 (xgifb_info->dev_info.Part5Port) > > Actually these should all be deleted because they mean you have to have > a xgifb_info variable and they hurt readability by hiding stuff behind a > define. It would be better to remove them all than to just remove one > from the middle. That's a more complicated patch, but it's a useful > patch. > > regards, > dan carpenter > Great point. I will work on that and get the patch out! -Josh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: xgifb: remove macros with hidden variable
On Fri, Dec 01, 2017 at 10:12:30AM +0300, Dan Carpenter wrote:
> On Thu, Nov 30, 2017 at 10:39:48AM -0500, Joshua Abraham wrote:
> > diff --git a/drivers/staging/xgifb/XGI_main_26.c
> > b/drivers/staging/xgifb/XGI_main_26.c
> > index 6feecc55d2bc..6de66eaad96b 100644
> > --- a/drivers/staging/xgifb/XGI_main_26.c
> > +++ b/drivers/staging/xgifb/XGI_main_26.c
> > @@ -34,16 +34,16 @@ static void dumpVGAReg(struct xgifb_video_info
> > *xgifb_info)
> > {
> > u8 i, reg;
> >
> > - xgifb_reg_set(XGISR, 0x05, 0x86);
> > + xgifb_reg_set(xgifb_info->dev_info.P3c4, 0x05, 0x86);
>
> This patch is OK, but it might be nicer to create a temporary variable
> so the lines are not so long:
>
> struct vb_device_info *vb = &xgifb_info->dev_info;
> u8 i, reg;
>
> xgifb_reg_set(vb->P3c4, 0x05, 0x86);
>
> I chose "vb" based on the struct name... "dev" and "info" aren't very
> useful in a name because there are a lot of devices and lots of types
> of info.
>
> regards,
> dan carpneter
>
That is indeed MUCH more readable. Thanks, I'll work on this today.
-Josh
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
