Re: [PATCH] staging: vt6656: add error code handling to unused variable
On Sat, 28 Mar 2020, John B. Wyatt IV wrote:
> Add error code handling to unused 'ret' variable that was never used.
> Return an error code from functions called within vnt_radio_power_on.
>
> Issue reported by coccinelle (coccicheck).
>
> Suggested-by: Quentin Deslandes
> Suggested-by: Stefano Brivio
> Signed-off-by: John B. Wyatt IV
> ---
> drivers/staging/vt6656/card.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c
> index dc3ab10eb630..9d23c3ec1e60 100644
> --- a/drivers/staging/vt6656/card.c
> +++ b/drivers/staging/vt6656/card.c
> @@ -723,9 +723,13 @@ int vnt_radio_power_on(struct vnt_private *priv)
> {
> int ret = 0;
>
> - vnt_exit_deep_sleep(priv);
> + ret = vnt_exit_deep_sleep(priv);
> + if (ret)
> + goto end;
Normally, if there is nothing to clean up, one can just say return ret.
>
> - vnt_mac_reg_bits_on(priv, MAC_REG_HOSTCR, HOSTCR_RXON);
> + ret = vnt_mac_reg_bits_on(priv, MAC_REG_HOSTCR, HOSTCR_RXON);
> + if (ret)
> + goto end;
>
> switch (priv->rf_type) {
> case RF_AL2230:
> @@ -734,13 +738,18 @@ int vnt_radio_power_on(struct vnt_private *priv)
> case RF_VT3226:
> case RF_VT3226D0:
> case RF_VT3342A0:
> - vnt_mac_reg_bits_on(priv, MAC_REG_SOFTPWRCTL,
> - (SOFTPWRCTL_SWPE2 | SOFTPWRCTL_SWPE3));
> + ret = vnt_mac_reg_bits_on(priv, MAC_REG_SOFTPWRCTL,
> + (SOFTPWRCTL_SWPE2 | SOFTPWRCTL_SWPE3));
> break;
> }
> + if (ret)
> + goto end;
>
> - vnt_mac_reg_bits_off(priv, MAC_REG_GPIOCTL1, GPIO3_INTMD);
> + ret = vnt_mac_reg_bits_off(priv, MAC_REG_GPIOCTL1, GPIO3_INTMD);
> + if (ret)
> + goto end;
There is no need for the above if, because whether ret is nonzero or not,
you will just end up at the next line.
julia
>
> +end:
> return ret;
> }
>
> --
> 2.25.1
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: vt6656: add error code handling to unused variable
Add error code handling to unused 'ret' variable that was never used.
Return an error code from functions called within vnt_radio_power_on.
Issue reported by coccinelle (coccicheck).
Suggested-by: Quentin Deslandes
Suggested-by: Stefano Brivio
Signed-off-by: John B. Wyatt IV
---
v2: Replace goto statements with return.
Remove last if check because it was unneeded.
Suggested-by: Julia Lawall
drivers/staging/vt6656/card.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c
index dc3ab10eb630..9d23c3ec1e60 100644
--- a/drivers/staging/vt6656/card.c
+++ b/drivers/staging/vt6656/card.c
@@ -723,9 +723,13 @@ int vnt_radio_power_on(struct vnt_private *priv)
{
int ret = 0;
- vnt_exit_deep_sleep(priv);
+ ret = vnt_exit_deep_sleep(priv);
+ if (ret)
+ goto end;
- vnt_mac_reg_bits_on(priv, MAC_REG_HOSTCR, HOSTCR_RXON);
+ ret = vnt_mac_reg_bits_on(priv, MAC_REG_HOSTCR, HOSTCR_RXON);
+ if (ret)
+ goto end;
switch (priv->rf_type) {
case RF_AL2230:
@@ -734,13 +738,18 @@ int vnt_radio_power_on(struct vnt_private *priv)
case RF_VT3226:
case RF_VT3226D0:
case RF_VT3342A0:
- vnt_mac_reg_bits_on(priv, MAC_REG_SOFTPWRCTL,
- (SOFTPWRCTL_SWPE2 | SOFTPWRCTL_SWPE3));
+ ret = vnt_mac_reg_bits_on(priv, MAC_REG_SOFTPWRCTL,
+(SOFTPWRCTL_SWPE2 | SOFTPWRCTL_SWPE3));
break;
}
+ if (ret)
+ goto end;
- vnt_mac_reg_bits_off(priv, MAC_REG_GPIOCTL1, GPIO3_INTMD);
+ ret = vnt_mac_reg_bits_off(priv, MAC_REG_GPIOCTL1, GPIO3_INTMD);
+ if (ret)
+ goto end;
+end:
return ret;
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: vt6656: add error code handling to unused variable
Add error code handling to unused 'ret' variable that was never used.
Return an error code from functions called within vnt_radio_power_on.
Issue reported by coccinelle (coccicheck).
Suggested-by: Quentin Deslandes
Suggested-by: Stefano Brivio
Signed-off-by: John B. Wyatt IV
---
v3: Forgot to add v2 code changes to commit.
v2: Replace goto statements with return.
Remove last if check because it was unneeded.
Suggested-by: Julia Lawall
drivers/staging/vt6656/card.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c
index dc3ab10eb630..239012539e73 100644
--- a/drivers/staging/vt6656/card.c
+++ b/drivers/staging/vt6656/card.c
@@ -723,9 +723,13 @@ int vnt_radio_power_on(struct vnt_private *priv)
{
int ret = 0;
- vnt_exit_deep_sleep(priv);
+ ret = vnt_exit_deep_sleep(priv);
+ if (ret)
+ return ret;
- vnt_mac_reg_bits_on(priv, MAC_REG_HOSTCR, HOSTCR_RXON);
+ ret = vnt_mac_reg_bits_on(priv, MAC_REG_HOSTCR, HOSTCR_RXON);
+ if (ret)
+ return ret;
switch (priv->rf_type) {
case RF_AL2230:
@@ -734,14 +738,14 @@ int vnt_radio_power_on(struct vnt_private *priv)
case RF_VT3226:
case RF_VT3226D0:
case RF_VT3342A0:
- vnt_mac_reg_bits_on(priv, MAC_REG_SOFTPWRCTL,
- (SOFTPWRCTL_SWPE2 | SOFTPWRCTL_SWPE3));
+ ret = vnt_mac_reg_bits_on(priv, MAC_REG_SOFTPWRCTL,
+(SOFTPWRCTL_SWPE2 | SOFTPWRCTL_SWPE3));
break;
}
+ if (ret)
+ return ret;
- vnt_mac_reg_bits_off(priv, MAC_REG_GPIOCTL1, GPIO3_INTMD);
-
- return ret;
+ return vnt_mac_reg_bits_off(priv, MAC_REG_GPIOCTL1, GPIO3_INTMD);
}
void vnt_set_bss_mode(struct vnt_private *priv)
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fbtft: Replace udelay with preferred usleep_range
Fix style issue with usleep_range being reported as preferred over udelay. Issue reported by checkpatch. Please review. As written in Documentation/timers/timers-howto.rst udelay is the generally preferred API. hrtimers, as noted in the docs, may be too expensive for this short timer. Are the docs out of date, or, is this a checkpatch issue? Signed-off-by: John B. Wyatt IV --- drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c index ec97ad27..019c8cce6bab 100644 --- a/drivers/staging/fbtft/fb_agm1264k-fl.c +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) dev_dbg(par->info->device, "%s()\n", __func__); gpiod_set_value(par->gpio.reset, 0); - udelay(20); + usleep_range(20, 20); gpiod_set_value(par->gpio.reset, 1); mdelay(120); } -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range
On Sun, 29 Mar 2020, John B. Wyatt IV wrote: > Fix style issue with usleep_range being reported as preferred over > udelay. > > Issue reported by checkpatch. > > Please review. > > As written in Documentation/timers/timers-howto.rst udelay is the > generally preferred API. hrtimers, as noted in the docs, may be too > expensive for this short timer. > > Are the docs out of date, or, is this a checkpatch issue? > > Signed-off-by: John B. Wyatt IV > --- > drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c > b/drivers/staging/fbtft/fb_agm1264k-fl.c > index ec97ad27..019c8cce6bab 100644 > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) > dev_dbg(par->info->device, "%s()\n", __func__); > > gpiod_set_value(par->gpio.reset, 0); > - udelay(20); > + usleep_range(20, 20); usleep_range should have a range, eg usleep_range(50, 100);. But it is hard to know a priori what the range should be. So it is probably better to leave the code alone. julia > gpiod_set_value(par->gpio.reset, 1); > mdelay(120); > } > -- > 2.25.1 > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-jbwyatt4%40gmail.com. > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range
On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote: > > On Sun, 29 Mar 2020, John B. Wyatt IV wrote: > > > Fix style issue with usleep_range being reported as preferred over > > udelay. > > > > Issue reported by checkpatch. > > > > Please review. > > > > As written in Documentation/timers/timers-howto.rst udelay is the > > generally preferred API. hrtimers, as noted in the docs, may be too > > expensive for this short timer. > > > > Are the docs out of date, or, is this a checkpatch issue? > > > > Signed-off-by: John B. Wyatt IV > > --- > > drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c > > b/drivers/staging/fbtft/fb_agm1264k-fl.c > > index ec97ad27..019c8cce6bab 100644 > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) > > dev_dbg(par->info->device, "%s()\n", __func__); > > > > gpiod_set_value(par->gpio.reset, 0); > > - udelay(20); > > + usleep_range(20, 20); > > usleep_range should have a range, eg usleep_range(50, 100);. But it > is > hard to know a priori what the range should be. So it is probably > better > to leave the code alone. Understood. With the question I wrote in the commit message: "As written in Documentation/timers/timers-howto.rst udelay is the generally preferred API. hrtimers, as noted in the docs, may be too expensive for this short timer. Are the docs out of date, or, is this a checkpatch issue?" Is usleep_range too expensive for this operation? Why does checkpatch favor usleep_range while the docs favor udelay? > > julia > > > gpiod_set_value(par->gpio.reset, 1); > > mdelay(120); > > } > > -- > > 2.25.1 > > > > -- > > You received this message because you are subscribed to the Google > > Groups "outreachy-kernel" group. > > To unsubscribe from this group and stop receiving emails from it, > > send an email to outreachy-kernel+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-jbwyatt4%40gmail.com > > . > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range
On Sun, 29 Mar 2020, John Wyatt wrote: > On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote: > > > > On Sun, 29 Mar 2020, John B. Wyatt IV wrote: > > > > > Fix style issue with usleep_range being reported as preferred over > > > udelay. > > > > > > Issue reported by checkpatch. > > > > > > Please review. > > > > > > As written in Documentation/timers/timers-howto.rst udelay is the > > > generally preferred API. hrtimers, as noted in the docs, may be too > > > expensive for this short timer. > > > > > > Are the docs out of date, or, is this a checkpatch issue? > > > > > > Signed-off-by: John B. Wyatt IV > > > --- > > > drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > index ec97ad27..019c8cce6bab 100644 > > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) > > > dev_dbg(par->info->device, "%s()\n", __func__); > > > > > > gpiod_set_value(par->gpio.reset, 0); > > > - udelay(20); > > > + usleep_range(20, 20); > > > > usleep_range should have a range, eg usleep_range(50, 100);. But it > > is > > hard to know a priori what the range should be. So it is probably > > better > > to leave the code alone. > > Understood. > > With the question I wrote in the commit message: > > "As written in Documentation/timers/timers-howto.rst udelay is the > generally preferred API. hrtimers, as noted in the docs, may be too > expensive for this short timer. > > Are the docs out of date, or, is this a checkpatch issue?" > > Is usleep_range too expensive for this operation? > > Why does checkpatch favor usleep_range while the docs favor udelay? I don't know the answer in detail, but it is quite possible that checkpatch doesn't pay any attention to the delay argument. Checkpatch is a perl script that highlights things that may be of concern. It is not a precise static analsis tool. As a matter of form, all of your Please review comments should have been put below the ---. Currently, if someone had wanted to apply the patch, you would make them do extra work to remove this information. julia > > > > > julia > > > > > gpiod_set_value(par->gpio.reset, 1); > > > mdelay(120); > > > } > > > -- > > > 2.25.1 > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "outreachy-kernel" group. > > > To unsubscribe from this group and stop receiving emails from it, > > > send an email to outreachy-kernel+unsubscr...@googlegroups.com. > > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-jbwyatt4%40gmail.com > > > . > > > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range
On Sun, 29 Mar 2020, Soumyajit Deb wrote: > I had the same doubt the other day about the replacement of udelay() with > usleep_range(). The corresponding range for the single argument value of > udelay() is quite confusing as I couldn't decide the range. But as much as I > noticed checkpatch.pl gives warning for replacing udelay() with > usleep_range() by checking the argument value of udelay(). In the > documentation, it is written udelay() should be used for a sleep time of at > most 10 microseconds but between 10 microseconds and 20 milliseconds, > usleep_range() should be used. > I think the range is code specific and will depend on what range is > acceptable and doesn't break the code. > Please correct me if I am wrong. The range depends on the associated hardware. Just because checkpatch suggests something doesn't mean that it is easy to address the problem. julia > > More clarification on this issue will be helpful. > > On Sun, 29 Mar 2020, 15:17 Julia Lawall, wrote: > > > On Sun, 29 Mar 2020, John Wyatt wrote: > > > On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote: > > > > > > On Sun, 29 Mar 2020, John B. Wyatt IV wrote: > > > > > > > Fix style issue with usleep_range being reported as > preferred over > > > > udelay. > > > > > > > > Issue reported by checkpatch. > > > > > > > > Please review. > > > > > > > > As written in Documentation/timers/timers-howto.rst udelay > is the > > > > generally preferred API. hrtimers, as noted in the docs, > may be too > > > > expensive for this short timer. > > > > > > > > Are the docs out of date, or, is this a checkpatch issue? > > > > > > > > Signed-off-by: John B. Wyatt IV > > > > --- > > > > drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > index ec97ad27..019c8cce6bab 100644 > > > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) > > > > dev_dbg(par->info->device, "%s()\n", __func__); > > > > > > > > gpiod_set_value(par->gpio.reset, 0); > > > > - udelay(20); > > > > + usleep_range(20, 20); > > > > > > usleep_range should have a range, eg usleep_range(50, > 100);. But it > > > is > > > hard to know a priori what the range should be. So it is > probably > > > better > > > to leave the code alone. > > > > Understood. > > > > With the question I wrote in the commit message: > > > > "As written in Documentation/timers/timers-howto.rst udelay is > the > > generally preferred API. hrtimers, as noted in the docs, may > be too > > expensive for this short timer. > > > > Are the docs out of date, or, is this a checkpatch issue?" > > > > Is usleep_range too expensive for this operation? > > > > Why does checkpatch favor usleep_range while the docs favor > udelay? > > I don't know the answer in detail, but it is quite possible that > checkpatch doesn't pay any attention to the delay argument. > Checkpatch is > a perl script that highlights things that may be of concern. It > is not a > precise static analsis tool. > > As a matter of form, all of your Please review comments should > have been > put below the ---. Currently, if someone had wanted to apply > the patch, > you would make them do extra work to remove this information. > > julia > > > > > > > > > julia > > > > > > > gpiod_set_value(par->gpio.reset, 1); > > > > mdelay(120); > > > > } > > > > -- > > > > 2.25.1 > > > > > > > > -- > > > > You received this message because you are subscribed to > the Google > > > > Groups "outreachy-kernel" group. > > > > To unsubscribe from this group and stop receiving emails > from it, > > > > send an email to > outreachy-kernel+unsubscr...@googlegroups.com. > > > > To view this discussion on the web visit > > > > >https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1- > jbwyatt4%40gmail.com > > > > . > > > > > > > > > > -- > You received this message because you are subscribed to the > Google Groups "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from > it, send an email to > outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web > visithttps://
Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range
On Sun, 2020-03-29 at 12:37 +0200, Julia Lawall wrote: > > On Sun, 29 Mar 2020, Soumyajit Deb wrote: > > > I had the same doubt the other day about the replacement of udelay() with > > usleep_range(). The corresponding range for the single argument value of > > udelay() is quite confusing as I couldn't decide the range. But as much as I > > noticed checkpatch.pl gives warning for replacing udelay() with > > usleep_range() by checking the argument value of udelay(). In the > > documentation, it is written udelay() should be used for a sleep time of at > > most 10 microseconds but between 10 microseconds and 20 milliseconds, > > usleep_range() should be used. > > I think the range is code specific and will depend on what range is > > acceptable and doesn't break the code. > > Please correct me if I am wrong. > > The range depends on the associated hardware. Just because checkpatch > suggests something doesn't mean that it is easy to address the problem. > > julia > Hi all, i think when it comes to a significant change in the code, we should at least be familiar with the driver or be able to test the change. In the very beginning of the Documentation/timers/timers-howto.rst there is the question: "Is my code in an atomic context?" It's not just about the range, it's more of at which context this code runs, for atomic-context -> udelay must be used. for non-atomic context -> usleep-range is better for power-management. unless we are familiar with the driver we wouldn't really know in what context this code is run at. This thread though had the same conversation about this change, for the same driver. https://patchwork.kernel.org/patch/11137125/ Sam > > > > More clarification on this issue will be helpful. > > > > On Sun, 29 Mar 2020, 15:17 Julia Lawall, wrote: > > > > > > On Sun, 29 Mar 2020, John Wyatt wrote: > > > > > On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote: > > > > > > > > On Sun, 29 Mar 2020, John B. Wyatt IV wrote: > > > > > > > > > Fix style issue with usleep_range being reported as > > preferred over > > > > > udelay. > > > > > > > > > > Issue reported by checkpatch. > > > > > > > > > > Please review. > > > > > > > > > > As written in Documentation/timers/timers-howto.rst udelay > > is the > > > > > generally preferred API. hrtimers, as noted in the docs, > > may be too > > > > > expensive for this short timer. > > > > > > > > > > Are the docs out of date, or, is this a checkpatch issue? > > > > > > > > > > Signed-off-by: John B. Wyatt IV > > > > > --- > > > > > drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > > b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > > index ec97ad27..019c8cce6bab 100644 > > > > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) > > > > > dev_dbg(par->info->device, "%s()\n", __func__); > > > > > > > > > > gpiod_set_value(par->gpio.reset, 0); > > > > > - udelay(20); > > > > > + usleep_range(20, 20); > > > > > > > > usleep_range should have a range, eg usleep_range(50, > > 100);. But it > > > > is > > > > hard to know a priori what the range should be. So it is > > probably > > > > better > > > > to leave the code alone. > > > > > > Understood. > > > > > > With the question I wrote in the commit message: > > > > > > "As written in Documentation/timers/timers-howto.rst udelay is > > the > > > generally preferred API. hrtimers, as noted in the docs, may > > be too > > > expensive for this short timer. > > > > > > Are the docs out of date, or, is this a checkpatch issue?" > > > > > > Is usleep_range too expensive for this operation? > > > > > > Why does checkpatch favor usleep_range while the docs favor > > udelay? > > > > I don't know the answer in detail, but it is quite possible that > > checkpatch doesn't pay any attention to the delay argument. > > Checkpatch is > > a perl script that highlights things that may be of concern. It > > is not a > > precise static analsis tool. > > > > As a matter of form, all of your Please review comments should > > have been > > put below the ---. Currently, if someone had wanted to apply > > the patch, > > you would make them do extra work to remove this information. > > > > julia > > > > > > > > > > > > > julia > > > > > > > > > gpiod_set_value(par->gpio.reset, 1); > > > > >
[PATCH] staging: rtl8188eu: refactor Efuse_GetCurrentSize()
Refactor while loop in Efuse_GetCurrentSize() to reduce indentation
level and clear line over 80 characters checkpatch warnings.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_efuse.c | 33 +++---
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c
b/drivers/staging/rtl8188eu/core/rtw_efuse.c
index c525682d0edf..9bb3ec0cd62f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
+++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
@@ -370,28 +370,27 @@ static u16 Efuse_GetCurrentSize(struct adapter *pAdapter)
while (efuse_OneByteRead(pAdapter, efuse_addr, &efuse_data) &&
AVAILABLE_EFUSE_ADDR(efuse_addr)) {
- if (efuse_data != 0xFF) {
- if ((efuse_data & 0x1F) == 0x0F) { /*
extended header */
- hoffset = efuse_data;
+ if (efuse_data == 0xFF)
+ break;
+ if ((efuse_data & 0x1F) == 0x0F) { /* extended header */
+ hoffset = efuse_data;
+ efuse_addr++;
+ efuse_OneByteRead(pAdapter, efuse_addr, &efuse_data);
+ if ((efuse_data & 0x0F) == 0x0F) {
efuse_addr++;
- efuse_OneByteRead(pAdapter, efuse_addr,
&efuse_data);
- if ((efuse_data & 0x0F) == 0x0F) {
- efuse_addr++;
- continue;
- } else {
- hoffset = ((hoffset & 0xE0) >> 5) |
((efuse_data & 0xF0) >> 1);
- hworden = efuse_data & 0x0F;
- }
+ continue;
} else {
- hoffset = (efuse_data >> 4) & 0x0F;
- hworden = efuse_data & 0x0F;
+ hoffset = ((hoffset & 0xE0) >> 5) |
+ ((efuse_data & 0xF0) >> 1);
+ hworden = efuse_data & 0x0F;
}
- word_cnts = Efuse_CalculateWordCnts(hworden);
- /* read next header */
- efuse_addr = efuse_addr + (word_cnts * 2) + 1;
} else {
- break;
+ hoffset = (efuse_data >> 4) & 0x0F;
+ hworden = efuse_data & 0x0F;
}
+ word_cnts = Efuse_CalculateWordCnts(hworden);
+ /* read next header */
+ efuse_addr = efuse_addr + (word_cnts * 2) + 1;
}
rtw_hal_set_hwreg(pAdapter, HW_VAR_EFUSE_BYTES, (u8 *)&efuse_addr);
--
2.26.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range
On Sun, Mar 29, 2020 at 2:23 PM Sam Muhammed wrote: > On Sun, 2020-03-29 at 12:37 +0200, Julia Lawall wrote: > > On Sun, 29 Mar 2020, Soumyajit Deb wrote: > > First of all, let's stop topposting. > > > I had the same doubt the other day about the replacement of udelay() with > > > usleep_range(). The corresponding range for the single argument value of > > > udelay() is quite confusing as I couldn't decide the range. But as much > > > as I > > > noticed checkpatch.pl gives warning for replacing udelay() with > > > usleep_range() by checking the argument value of udelay(). In the > > > documentation, it is written udelay() should be used for a sleep time of > > > at > > > most 10 microseconds but between 10 microseconds and 20 milliseconds, > > > usleep_range() should be used. > > > I think the range is code specific and will depend on what range is > > > acceptable and doesn't break the code. > > > Please correct me if I am wrong. > > > > The range depends on the associated hardware. Just because checkpatch > > suggests something doesn't mean that it is easy to address the problem. > Hi all, i think when it comes to a significant change in the code, we > should at least be familiar with the driver or be able to test the > change. > > In the very beginning of the Documentation/timers/timers-howto.rst > there is the question: > "Is my code in an atomic context?" > It's not just about the range, it's more of at which context this code > runs, for atomic-context -> udelay must be used. > for non-atomic context -> usleep-range is better for power-management. > > unless we are familiar with the driver we wouldn't really know in what > context this code is run at. > > This thread though had the same conversation about this change, for the > same driver. > https://patchwork.kernel.org/patch/11137125/ While it's a good discussion it reminds me that this entire function, i.e. reset(), repeats the on provided by fbtft core. Yes, the only question if it's atomic or not. IIRC ->reset() is being called only in non-atomic contexts and keeping reset signal longer is fine (but better to check with datasheet). So, I would rather to drop the function completely in order to use fbtft's core one. -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/9] staging: bcm2835-camera: Activate V4L2_EXPOSURE_METERING_MATRIX handling
I don't see any reason to keep this TODO, so activate the
V4L2_EXPOSURE_METERING_MATRIX handling.
Signed-off-by: Stefan Wahren
---
drivers/staging/vc04_services/bcm2835-camera/controls.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
b/drivers/staging/vc04_services/bcm2835-camera/controls.c
index 5137fcf..1d0caf4 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
@@ -377,11 +377,9 @@ static int ctrl_set_metering_mode(struct bm2835_mmal_dev
*dev,
dev->metering_mode = MMAL_PARAM_EXPOSUREMETERINGMODE_SPOT;
break;
- /* todo matrix weighting not added to Linux API till 3.9
-* case V4L2_EXPOSURE_METERING_MATRIX:
-* dev->metering_mode = MMAL_PARAM_EXPOSUREMETERINGMODE_MATRIX;
-* break;
-*/
+ case V4L2_EXPOSURE_METERING_MATRIX:
+ dev->metering_mode = MMAL_PARAM_EXPOSUREMETERINGMODE_MATRIX;
+ break;
}
if (dev->scene_mode == V4L2_SCENE_MODE_NONE) {
@@ -1045,8 +1043,8 @@ static const struct bm2835_mmal_v4l2_ctrl
v4l2_ctrls[V4L2_CTRL_COUNT] = {
{
.id = V4L2_CID_EXPOSURE_METERING,
.type = MMAL_CONTROL_TYPE_STD_MENU,
- .min = ~0x7,
- .max = V4L2_EXPOSURE_METERING_SPOT,
+ .min = ~0xf,
+ .max = V4L2_EXPOSURE_METERING_MATRIX,
.def = V4L2_EXPOSURE_METERING_AVERAGE,
.step = 0,
.imenu = NULL,
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/9] staging: bcm2835-camera: return early in mmal_setup_components
We can reduce the indentation in mmal_setup_components further by
returning early in error case.
Signed-off-by: Stefan Wahren
---
.../vc04_services/bcm2835-camera/bcm2835-camera.c | 60 +++---
1 file changed, 31 insertions(+), 29 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index f11f186..91f767f 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -1241,38 +1241,40 @@ static int mmal_setup_components(struct bm2835_mmal_dev
*dev,
f->fmt.pix.pixelformat);
/* ensure capture is not going to be tried */
dev->capture.port = NULL;
- } else {
- if (encode_component) {
- ret = mmal_setup_encode_component(dev, f, port,
- camera_port,
- encode_component);
- } else {
- /* configure buffering */
- camera_port->current_buffer.num = 1;
- camera_port->current_buffer.size = f->fmt.pix.sizeimage;
- camera_port->current_buffer.alignment = 0;
- }
+ return ret;
+ }
- if (!ret) {
- dev->capture.fmt = mfmt;
- dev->capture.stride = f->fmt.pix.bytesperline;
- dev->capture.width = camera_port->es.video.crop.width;
- dev->capture.height = camera_port->es.video.crop.height;
- dev->capture.buffersize = port->current_buffer.size;
-
- /* select port for capture */
- dev->capture.port = port;
- dev->capture.camera_port = camera_port;
- dev->capture.encode_component = encode_component;
- v4l2_dbg(1, bcm2835_v4l2_debug,
-&dev->v4l2_dev,
- "Set dev->capture.fmt %08X, %dx%d, stride %d,
size %d",
- port->format.encoding,
- dev->capture.width, dev->capture.height,
- dev->capture.stride, dev->capture.buffersize);
- }
+ if (encode_component) {
+ ret = mmal_setup_encode_component(dev, f, port,
+ camera_port,
+ encode_component);
+
+ if (ret)
+ return ret;
+ } else {
+ /* configure buffering */
+ camera_port->current_buffer.num = 1;
+ camera_port->current_buffer.size = f->fmt.pix.sizeimage;
+ camera_port->current_buffer.alignment = 0;
}
+ dev->capture.fmt = mfmt;
+ dev->capture.stride = f->fmt.pix.bytesperline;
+ dev->capture.width = camera_port->es.video.crop.width;
+ dev->capture.height = camera_port->es.video.crop.height;
+ dev->capture.buffersize = port->current_buffer.size;
+
+ /* select port for capture */
+ dev->capture.port = port;
+ dev->capture.camera_port = camera_port;
+ dev->capture.encode_component = encode_component;
+ v4l2_dbg(1, bcm2835_v4l2_debug,
+&dev->v4l2_dev,
+ "Set dev->capture.fmt %08X, %dx%d, stride %d, size %d",
+ port->format.encoding,
+ dev->capture.width, dev->capture.height,
+ dev->capture.stride, dev->capture.buffersize);
+
/* todo: Need to convert the vchiq/mmal error into a v4l2 error. */
return ret;
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 9/9] staging: bcm2835-camera: reduce indentation in ctrl_set_image_effect
We can reduce the indentation in the loop by using continue in case the
effect doesn't match.
Signed-off-by: Stefan Wahren
---
.../vc04_services/bcm2835-camera/controls.c| 63 +++---
1 file changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
b/drivers/staging/vc04_services/bcm2835-camera/controls.c
index 8e10a66..b096a12 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
@@ -514,42 +514,41 @@ static int ctrl_set_image_effect(struct bm2835_mmal_dev
*dev,
struct mmal_parameter_imagefx_parameters imagefx;
for (i = 0; i < ARRAY_SIZE(v4l2_to_mmal_effects_values); i++) {
- if (ctrl->val == v4l2_to_mmal_effects_values[i].v4l2_effect) {
- imagefx.effect =
- v4l2_to_mmal_effects_values[i].mmal_effect;
- imagefx.num_effect_params =
-
v4l2_to_mmal_effects_values[i].num_effect_params;
-
- if (imagefx.num_effect_params >
MMAL_MAX_IMAGEFX_PARAMETERS)
- imagefx.num_effect_params =
MMAL_MAX_IMAGEFX_PARAMETERS;
-
- for (j = 0; j < imagefx.num_effect_params; j++)
- imagefx.effect_parameter[j] =
-
v4l2_to_mmal_effects_values[i].effect_params[j];
-
- dev->colourfx.enable =
- v4l2_to_mmal_effects_values[i].col_fx_enable;
- if (!v4l2_to_mmal_effects_values[i].col_fx_fixed_cbcr) {
- dev->colourfx.u =
- v4l2_to_mmal_effects_values[i].u;
- dev->colourfx.v =
- v4l2_to_mmal_effects_values[i].v;
- }
+ if (ctrl->val != v4l2_to_mmal_effects_values[i].v4l2_effect)
+ continue;
+
+ imagefx.effect =
+ v4l2_to_mmal_effects_values[i].mmal_effect;
+ imagefx.num_effect_params =
+ v4l2_to_mmal_effects_values[i].num_effect_params;
- control = &dev->component[COMP_CAMERA]->control;
+ if (imagefx.num_effect_params > MMAL_MAX_IMAGEFX_PARAMETERS)
+ imagefx.num_effect_params = MMAL_MAX_IMAGEFX_PARAMETERS;
- ret = vchiq_mmal_port_parameter_set(
- dev->instance, control,
- MMAL_PARAMETER_IMAGE_EFFECT_PARAMETERS,
- &imagefx, sizeof(imagefx));
- if (ret)
- goto exit;
+ for (j = 0; j < imagefx.num_effect_params; j++)
+ imagefx.effect_parameter[j] =
+ v4l2_to_mmal_effects_values[i].effect_params[j];
- ret = vchiq_mmal_port_parameter_set(
- dev->instance, control,
- MMAL_PARAMETER_COLOUR_EFFECT,
- &dev->colourfx, sizeof(dev->colourfx));
+ dev->colourfx.enable =
+ v4l2_to_mmal_effects_values[i].col_fx_enable;
+ if (!v4l2_to_mmal_effects_values[i].col_fx_fixed_cbcr) {
+ dev->colourfx.u = v4l2_to_mmal_effects_values[i].u;
+ dev->colourfx.v = v4l2_to_mmal_effects_values[i].v;
}
+
+ control = &dev->component[COMP_CAMERA]->control;
+
+ ret = vchiq_mmal_port_parameter_set(
+ dev->instance, control,
+ MMAL_PARAMETER_IMAGE_EFFECT_PARAMETERS,
+ &imagefx, sizeof(imagefx));
+ if (ret)
+ goto exit;
+
+ ret = vchiq_mmal_port_parameter_set(
+ dev->instance, control,
+ MMAL_PARAMETER_COLOUR_EFFECT,
+ &dev->colourfx, sizeof(dev->colourfx));
}
exit:
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/9] staging: bcm2835-camera: Drop PREVIEW_LAYER
This define is used only once. So drop the define and init the layer
directly.
Signed-off-by: Stefan Wahren
---
drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c | 2 +-
drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index 597acef..ff2ba23 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -668,7 +668,7 @@ static int set_overlay_params(struct bm2835_mmal_dev *dev,
MMAL_DISPLAY_SET_ALPHA |
MMAL_DISPLAY_SET_DEST_RECT |
MMAL_DISPLAY_SET_FULLSCREEN,
- .layer = PREVIEW_LAYER,
+ .layer = 2,
.alpha = dev->overlay.global_alpha,
.fullscreen = 0,
.dest_rect = {
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
index b5fce38..c426a5c 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
@@ -30,8 +30,6 @@ enum {
CAM_PORT_COUNT
};
-#define PREVIEW_LAYER 2
-
extern int bcm2835_v4l2_debug;
struct bm2835_mmal_dev {
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/9] staging: bcm2835-camera: Clean up driver
Except of patch 2 all these patches tries to clean up the bcm2835-camera driver. Stefan Wahren (9): staging: bcm2835-camera: Drop PREVIEW_LAYER staging: bcm2835-camera: Activate V4L2_EXPOSURE_METERING_MATRIX handling staging: bcm2835-camera: Make struct indentation consistent staging: bcm2835-camera: Simplify set_framerate_params staging: bcm2835-camera: Move encode component setup in its own function staging: bcm2835-camera: Move video component setup in its own function staging: bcm2835-camera: return early in mmal_setup_components staging: bcm2835-camera: reduce multiline statements staging: bcm2835-camera: reduce indentation in ctrl_set_image_effect .../vc04_services/bcm2835-camera/bcm2835-camera.c | 382 ++--- .../vc04_services/bcm2835-camera/bcm2835-camera.h | 62 ++-- .../vc04_services/bcm2835-camera/controls.c| 97 +++--- .../vc04_services/bcm2835-camera/mmal-common.h | 18 +- .../vc04_services/bcm2835-camera/mmal-parameters.h | 14 +- 5 files changed, 279 insertions(+), 294 deletions(-) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/9] staging: bcm2835-camera: Simplify set_framerate_params
This simplifies set_framerate_params and avoids the multiple assignment
in one line by moving the fps_high handling out of the if statement.
Signed-off-by: Stefan Wahren
---
drivers/staging/vc04_services/bcm2835-camera/controls.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
b/drivers/staging/vc04_services/bcm2835-camera/controls.c
index 275ff21..e46f150 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
@@ -1280,21 +1280,18 @@ int set_framerate_params(struct bm2835_mmal_dev *dev)
struct mmal_parameter_fps_range fps_range;
int ret;
+ fps_range.fps_high.num = dev->capture.timeperframe.denominator;
+ fps_range.fps_high.den = dev->capture.timeperframe.numerator;
+
if ((dev->exposure_mode_active != MMAL_PARAM_EXPOSUREMODE_OFF) &&
(dev->exp_auto_priority)) {
- /* Variable FPS. Define min FPS as 1fps.
-* Max as max defined FPS.
-*/
+ /* Variable FPS. Define min FPS as 1fps. */
fps_range.fps_low.num = 1;
fps_range.fps_low.den = 1;
- fps_range.fps_high.num = dev->capture.timeperframe.denominator;
- fps_range.fps_high.den = dev->capture.timeperframe.numerator;
} else {
/* Fixed FPS - set min and max to be the same */
- fps_range.fps_low.num = fps_range.fps_high.num =
- dev->capture.timeperframe.denominator;
- fps_range.fps_low.den = fps_range.fps_high.den =
- dev->capture.timeperframe.numerator;
+ fps_range.fps_low.num = fps_range.fps_high.num;
+ fps_range.fps_low.den = fps_range.fps_high.den;
}
v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 8/9] staging: bcm2835-camera: reduce multiline statements
There are a lot of multiline statements which can be reduced.
Signed-off-by: Stefan Wahren
---
.../vc04_services/bcm2835-camera/bcm2835-camera.c | 57 +-
.../vc04_services/bcm2835-camera/controls.c| 3 +-
2 files changed, 23 insertions(+), 37 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index 91f767f..6d554d4 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -369,8 +369,7 @@ static void buffer_cb(struct vchiq_mmal_instance *instance,
if (dev->capture.vc_start_timestamp != -1 && pts) {
ktime_t timestamp;
- s64 runtime_us = pts -
- dev->capture.vc_start_timestamp;
+ s64 runtime_us = pts - dev->capture.vc_start_timestamp;
timestamp = ktime_add_us(dev->capture.kernel_start_ts,
runtime_us);
v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
@@ -420,9 +419,8 @@ static int enable_camera(struct bm2835_mmal_dev *dev)
return -EINVAL;
}
- ret = vchiq_mmal_component_enable(
- dev->instance,
- dev->component[COMP_CAMERA]);
+ ret = vchiq_mmal_component_enable(dev->instance,
+ dev->component[COMP_CAMERA]);
if (ret < 0) {
v4l2_err(&dev->v4l2_dev,
"Failed enabling camera, ret %d\n", ret);
@@ -451,10 +449,8 @@ static int disable_camera(struct bm2835_mmal_dev *dev)
v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
"Disabling camera\n");
- ret =
- vchiq_mmal_component_disable(
- dev->instance,
- dev->component[COMP_CAMERA]);
+ ret = vchiq_mmal_component_disable(dev->instance,
+ dev->component[COMP_CAMERA]);
if (ret < 0) {
v4l2_err(&dev->v4l2_dev,
"Failed disabling camera, ret %d\n", ret);
@@ -555,8 +551,8 @@ static int start_streaming(struct vb2_queue *vq, unsigned
int count)
/* enable the camera port */
dev->capture.port->cb_ctx = dev;
- ret =
- vchiq_mmal_port_enable(dev->instance, dev->capture.port, buffer_cb);
+ ret = vchiq_mmal_port_enable(dev->instance, dev->capture.port,
+buffer_cb);
if (ret) {
v4l2_err(&dev->v4l2_dev,
"Failed to enable capture port - error %d. Disabling
camera port again\n",
@@ -767,16 +763,14 @@ static int vidioc_overlay(struct file *file, void *f,
unsigned int on)
(!on && !dev->component[COMP_PREVIEW]->enabled))
return 0; /* already in requested state */
- src =
- &dev->component[COMP_CAMERA]->output[CAM_PORT_PREVIEW];
+ src = &dev->component[COMP_CAMERA]->output[CAM_PORT_PREVIEW];
if (!on) {
/* disconnect preview ports and disable component */
ret = vchiq_mmal_port_disable(dev->instance, src);
if (!ret)
- ret =
- vchiq_mmal_port_connect_tunnel(dev->instance, src,
- NULL);
+ ret = vchiq_mmal_port_connect_tunnel(dev->instance, src,
+NULL);
if (ret >= 0)
ret = vchiq_mmal_component_disable(
dev->instance,
@@ -800,9 +794,8 @@ static int vidioc_overlay(struct file *file, void *f,
unsigned int on)
if (enable_camera(dev) < 0)
return -EINVAL;
- ret = vchiq_mmal_component_enable(
- dev->instance,
- dev->component[COMP_PREVIEW]);
+ ret = vchiq_mmal_component_enable(dev->instance,
+ dev->component[COMP_PREVIEW]);
if (ret < 0)
return ret;
@@ -1210,8 +1203,7 @@ static int mmal_setup_components(struct bm2835_mmal_dev
*dev,
}
remove_padding = mfmt->remove_padding;
- vchiq_mmal_port_parameter_set(dev->instance,
- camera_port,
+ vchiq_mmal_port_parameter_set(dev->instance, camera_port,
MMAL_PARAMETER_NO_IMAGE_PADDING,
&remove_padding, sizeof(remove_padding));
@@ -1665,9 +1657,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
dev->c
[PATCH 3/9] staging: bcm2835-camera: Make struct indentation consistent
The indentation of struct members wasn't consistent over the whole driver.
Signed-off-by: Stefan Wahren
---
.../vc04_services/bcm2835-camera/bcm2835-camera.h | 60 +++---
.../vc04_services/bcm2835-camera/controls.c| 4 +-
.../vc04_services/bcm2835-camera/mmal-common.h | 18 +++
.../vc04_services/bcm2835-camera/mmal-parameters.h | 14 ++---
4 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
index c426a5c..75524ad 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
@@ -34,73 +34,73 @@ extern int bcm2835_v4l2_debug;
struct bm2835_mmal_dev {
/* v4l2 devices */
- struct v4l2_device v4l2_dev;
- struct video_devicevdev;
- struct mutex mutex;
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct mutex mutex;
/* controls */
- struct v4l2_ctrl_handler ctrl_handler;
- struct v4l2_ctrl *ctrls[V4L2_CTRL_COUNT];
- enum v4l2_scene_mode scene_mode;
- struct mmal_colourfx colourfx;
- int hflip;
- int vflip;
- int red_gain;
- int blue_gain;
+ struct v4l2_ctrl_handler ctrl_handler;
+ struct v4l2_ctrl *ctrls[V4L2_CTRL_COUNT];
+ enum v4l2_scene_mode scene_mode;
+ struct mmal_colourfx colourfx;
+ int hflip;
+ int vflip;
+ int red_gain;
+ int blue_gain;
enum mmal_parameter_exposuremode exposure_mode_user;
enum v4l2_exposure_auto_type exposure_mode_v4l2_user;
/* active exposure mode may differ if selected via a scene mode */
enum mmal_parameter_exposuremode exposure_mode_active;
enum mmal_parameter_exposuremeteringmode metering_mode;
- unsigned int manual_shutter_speed;
- bool exp_auto_priority;
+ unsigned int manual_shutter_speed;
+ bool exp_auto_priority;
bool manual_iso_enabled;
u32 iso;
/* allocated mmal instance and components */
- struct vchiq_mmal_instance *instance;
- struct vchiq_mmal_component *component[COMP_COUNT];
+ struct vchiq_mmal_instance *instance;
+ struct vchiq_mmal_component *component[COMP_COUNT];
int camera_use_count;
struct v4l2_window overlay;
struct {
- unsigned int width; /* width */
- unsigned int height; /* height */
- unsigned int stride; /* stride */
- unsigned int buffersize; /* buffer size with padding */
- struct mmal_fmt *fmt;
+ unsigned int width; /* width */
+ unsigned int height; /* height */
+ unsigned int stride; /* stride */
+ unsigned int buffersize; /* buffer size with padding */
+ struct mmal_fmt *fmt;
struct v4l2_fract timeperframe;
/* H264 encode bitrate */
- int encode_bitrate;
+ int encode_bitrate;
/* H264 bitrate mode. CBR/VBR */
- int encode_bitrate_mode;
+ int encode_bitrate_mode;
/* H264 profile */
enum v4l2_mpeg_video_h264_profile enc_profile;
/* H264 level */
enum v4l2_mpeg_video_h264_level enc_level;
/* JPEG Q-factor */
- int q_factor;
+ int q_factor;
- struct vb2_queuevb_vidq;
+ struct vb2_queue vb_vidq;
/* VC start timestamp for streaming */
- s64 vc_start_timestamp;
+ s64 vc_start_timestamp;
/* Kernel start timestamp for streaming */
ktime_t kernel_start_ts;
/* Sequence number of last buffer */
- u32 sequence;
+ u32 sequence;
- struct vchiq_mmal_port *port; /* port being used for capture */
+ struct vchiq_mmal_port *port; /* port being used for capture */
/* camera port being used for capture */
- struct vchiq_mmal_port *camera_port;
+ struct vchiq_mmal_port *camera_port;
/* component being used for encode */
struct vchiq_mmal_component *encode_component;
/* number of frames remaining which driver should capture */
- unsigned int frame_count;
+ unsigned int frame_count;
/* last frame completion */
- struct completion frame_cmplt;
+ struct completion frame_cmplt;
} capture;
[PATCH 6/9] staging: bcm2835-camera: Move video component setup in its own function
The function mmal_setup_components has to many indention levels. So move
the setup code for video component in its own function.
Signed-off-by: Stefan Wahren
---
.../vc04_services/bcm2835-camera/bcm2835-camera.c | 88 --
1 file changed, 48 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index f101918..f11f186 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -1001,6 +1001,53 @@ static int vidioc_try_fmt_vid_cap(struct file *file,
void *priv,
return 0;
}
+
+static int mmal_setup_video_component(struct bm2835_mmal_dev *dev,
+ struct v4l2_format *f)
+{
+ bool overlay_enabled = !!dev->component[COMP_PREVIEW]->enabled;
+ struct vchiq_mmal_port *preview_port;
+ int ret;
+
+ preview_port = &dev->component[COMP_CAMERA]->output[CAM_PORT_PREVIEW];
+
+ /* Preview and encode ports need to match on resolution */
+ if (overlay_enabled) {
+ /* Need to disable the overlay before we can update
+* the resolution
+*/
+ ret = vchiq_mmal_port_disable(dev->instance, preview_port);
+ if (!ret) {
+ ret = vchiq_mmal_port_connect_tunnel(dev->instance,
+preview_port,
+NULL);
+ }
+ }
+ preview_port->es.video.width = f->fmt.pix.width;
+ preview_port->es.video.height = f->fmt.pix.height;
+ preview_port->es.video.crop.x = 0;
+ preview_port->es.video.crop.y = 0;
+ preview_port->es.video.crop.width = f->fmt.pix.width;
+ preview_port->es.video.crop.height = f->fmt.pix.height;
+ preview_port->es.video.frame_rate.num =
+ dev->capture.timeperframe.denominator;
+ preview_port->es.video.frame_rate.den =
+ dev->capture.timeperframe.numerator;
+ ret = vchiq_mmal_port_set_format(dev->instance, preview_port);
+
+ if (overlay_enabled) {
+ ret = vchiq_mmal_port_connect_tunnel(dev->instance,
+ preview_port,
+ &dev->component[COMP_PREVIEW]->input[0]);
+ if (ret)
+ return ret;
+
+ ret = vchiq_mmal_port_enable(dev->instance, preview_port, NULL);
+ }
+
+ return ret;
+}
+
static int mmal_setup_encode_component(struct bm2835_mmal_dev *dev,
struct v4l2_format *f,
struct vchiq_mmal_port *port,
@@ -1184,46 +1231,7 @@ static int mmal_setup_components(struct bm2835_mmal_dev
*dev,
if (!ret &&
camera_port ==
&dev->component[COMP_CAMERA]->output[CAM_PORT_VIDEO]) {
- bool overlay_enabled =
- !!dev->component[COMP_PREVIEW]->enabled;
- struct vchiq_mmal_port *preview_port =
- &dev->component[COMP_CAMERA]->output[CAM_PORT_PREVIEW];
- /* Preview and encode ports need to match on resolution */
- if (overlay_enabled) {
- /* Need to disable the overlay before we can update
-* the resolution
-*/
- ret =
- vchiq_mmal_port_disable(dev->instance,
- preview_port);
- if (!ret)
- ret =
- vchiq_mmal_port_connect_tunnel(
- dev->instance,
- preview_port,
- NULL);
- }
- preview_port->es.video.width = f->fmt.pix.width;
- preview_port->es.video.height = f->fmt.pix.height;
- preview_port->es.video.crop.x = 0;
- preview_port->es.video.crop.y = 0;
- preview_port->es.video.crop.width = f->fmt.pix.width;
- preview_port->es.video.crop.height = f->fmt.pix.height;
- preview_port->es.video.frame_rate.num =
- dev->capture.timeperframe.denominator;
- preview_port->es.video.frame_rate.den =
- dev->capture.timeperframe.numerator;
- ret = vchiq_mmal_port_set_format(dev->instance, preview_port);
- if (overlay_enabled) {
- ret = vchiq_mmal_port_connect_tunnel(
- dev->instance,
- preview_port,
-
[PATCH 5/9] staging: bcm2835-camera: Move encode component setup in its own function
The function mmal_setup_components has to many indention levels. So move
the setup code for encode component in its own function.
Signed-off-by: Stefan Wahren
---
.../vc04_services/bcm2835-camera/bcm2835-camera.c | 185 ++---
1 file changed, 91 insertions(+), 94 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index ff2ba23..f101918 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -1001,6 +1001,94 @@ static int vidioc_try_fmt_vid_cap(struct file *file,
void *priv,
return 0;
}
+static int mmal_setup_encode_component(struct bm2835_mmal_dev *dev,
+ struct v4l2_format *f,
+ struct vchiq_mmal_port *port,
+ struct vchiq_mmal_port *camera_port,
+ struct vchiq_mmal_component *component)
+{
+ struct mmal_fmt *mfmt = get_format(f);
+ int ret;
+
+ v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
+"vid_cap - set up encode comp\n");
+
+ /* configure buffering */
+ camera_port->current_buffer.size = camera_port->recommended_buffer.size;
+ camera_port->current_buffer.num = camera_port->recommended_buffer.num;
+
+ ret = vchiq_mmal_port_connect_tunnel(dev->instance, camera_port,
+&component->input[0]);
+ if (ret) {
+ v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
+"%s failed to create connection\n", __func__);
+ /* ensure capture is not going to be tried */
+ dev->capture.port = NULL;
+ return ret;
+ }
+
+ port->es.video.width = f->fmt.pix.width;
+ port->es.video.height = f->fmt.pix.height;
+ port->es.video.crop.x = 0;
+ port->es.video.crop.y = 0;
+ port->es.video.crop.width = f->fmt.pix.width;
+ port->es.video.crop.height = f->fmt.pix.height;
+ port->es.video.frame_rate.num =
+ dev->capture.timeperframe.denominator;
+ port->es.video.frame_rate.den =
+ dev->capture.timeperframe.numerator;
+
+ port->format.encoding = mfmt->mmal;
+ port->format.encoding_variant = 0;
+ /* Set any encoding specific parameters */
+ switch (mfmt->mmal_component) {
+ case COMP_VIDEO_ENCODE:
+ port->format.bitrate = dev->capture.encode_bitrate;
+ break;
+ case COMP_IMAGE_ENCODE:
+ /* Could set EXIF parameters here */
+ break;
+ default:
+ break;
+ }
+
+ ret = vchiq_mmal_port_set_format(dev->instance, port);
+ if (ret) {
+ v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
+"%s failed to set format %dx%d fmt %08X\n",
+__func__,
+f->fmt.pix.width,
+f->fmt.pix.height,
+f->fmt.pix.pixelformat);
+ return ret;
+ }
+
+ ret = vchiq_mmal_component_enable(dev->instance, component);
+ if (ret) {
+ v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
+"%s Failed to enable encode components\n", __func__);
+ return ret;
+ }
+
+ /* configure buffering */
+ port->current_buffer.num = 1;
+ port->current_buffer.size = f->fmt.pix.sizeimage;
+ if (port->format.encoding == MMAL_ENCODING_JPEG) {
+ v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
+"JPG - buf size now %d was %d\n",
+f->fmt.pix.sizeimage,
+port->current_buffer.size);
+ port->current_buffer.size =
+ (f->fmt.pix.sizeimage < (100 << 10)) ?
+ (100 << 10) : f->fmt.pix.sizeimage;
+ }
+ v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
+"vid_cap - cur_buf.size set to %d\n", f->fmt.pix.sizeimage);
+ port->current_buffer.alignment = 0;
+
+ return 0;
+}
+
static int mmal_setup_components(struct bm2835_mmal_dev *dev,
struct v4l2_format *f)
{
@@ -1147,100 +1235,9 @@ static int mmal_setup_components(struct bm2835_mmal_dev
*dev,
dev->capture.port = NULL;
} else {
if (encode_component) {
- v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
-"vid_cap - set up encode comp\n");
-
- /* configure buffering */
- camera_port->current_buffer.size =
- camera_port->recommended_buffer.size;
- camera_port->current_buffer.num =
-
Re: [PATCH] staging: android: ashmem: Declared file operation with const keyword
Hi SandeshKenjanaAshok,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v5.6-rc7 next-20200327]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/SandeshKenjanaAshok/staging-android-ashmem-Declared-file-operation-with-const-keyword/20200329-014353
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
e681bb287f40e7a9dbcb04cef80fd87a2511ab86
config: um-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=um
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/staging/android/ashmem.c: In function 'ashmem_mmap':
>> drivers/staging/android/ashmem.c:418:16: error: assignment of read-only
>> variable 'vmfile_fops'
vmfile_fops = *vmfile->f_op;
^
>> drivers/staging/android/ashmem.c:419:21: error: assignment of member 'mmap'
>> in read-only object
vmfile_fops.mmap = ashmem_vmfile_mmap;
^
>> drivers/staging/android/ashmem.c:420:34: error: assignment of member
>> 'get_unmapped_area' in read-only object
vmfile_fops.get_unmapped_area =
^
vim +/vmfile_fops +418 drivers/staging/android/ashmem.c
6d67b0290b4b84 Suren Baghdasaryan 2020-01-27 367
11980c2ac4ccfa Robert Love 2011-12-20 368 static int
ashmem_mmap(struct file *file, struct vm_area_struct *vma)
11980c2ac4ccfa Robert Love 2011-12-20 369 {
3e4e9953cadce9 SandeshKenjanaAshok 2020-03-28 370 static const struct
file_operations vmfile_fops;
11980c2ac4ccfa Robert Love 2011-12-20 371 struct ashmem_area
*asma = file->private_data;
11980c2ac4ccfa Robert Love 2011-12-20 372 int ret = 0;
11980c2ac4ccfa Robert Love 2011-12-20 373
11980c2ac4ccfa Robert Love 2011-12-20 374
mutex_lock(&ashmem_mutex);
11980c2ac4ccfa Robert Love 2011-12-20 375
11980c2ac4ccfa Robert Love 2011-12-20 376 /* user needs to
SET_SIZE before mapping */
59848d6aded59a Alistair Strachan 2018-06-19 377 if (!asma->size) {
11980c2ac4ccfa Robert Love 2011-12-20 378 ret = -EINVAL;
11980c2ac4ccfa Robert Love 2011-12-20 379 goto out;
11980c2ac4ccfa Robert Love 2011-12-20 380 }
11980c2ac4ccfa Robert Love 2011-12-20 381
8632c614565d0c Alistair Strachan 2018-06-19 382 /* requested mapping
size larger than object size */
8632c614565d0c Alistair Strachan 2018-06-19 383 if (vma->vm_end -
vma->vm_start > PAGE_ALIGN(asma->size)) {
11980c2ac4ccfa Robert Love 2011-12-20 384 ret = -EINVAL;
11980c2ac4ccfa Robert Love 2011-12-20 385 goto out;
11980c2ac4ccfa Robert Love 2011-12-20 386 }
11980c2ac4ccfa Robert Love 2011-12-20 387
11980c2ac4ccfa Robert Love 2011-12-20 388 /* requested protection
bits must match our allowed protection mask */
59848d6aded59a Alistair Strachan 2018-06-19 389 if ((vma->vm_flags &
~calc_vm_prot_bits(asma->prot_mask, 0)) &
59848d6aded59a Alistair Strachan 2018-06-19 390
calc_vm_prot_bits(PROT_MASK, 0)) {
11980c2ac4ccfa Robert Love 2011-12-20 391 ret = -EPERM;
11980c2ac4ccfa Robert Love 2011-12-20 392 goto out;
11980c2ac4ccfa Robert Love 2011-12-20 393 }
56f76fc68492af Arve Hjønnevåg 2011-12-20 394 vma->vm_flags &=
~calc_vm_may_flags(~asma->prot_mask);
11980c2ac4ccfa Robert Love 2011-12-20 395
11980c2ac4ccfa Robert Love 2011-12-20 396 if (!asma->file) {
11980c2ac4ccfa Robert Love 2011-12-20 397 char *name =
ASHMEM_NAME_DEF;
11980c2ac4ccfa Robert Love 2011-12-20 398 struct file
*vmfile;
11980c2ac4ccfa Robert Love 2011-12-20 399
11980c2ac4ccfa Robert Love 2011-12-20 400 if
(asma->name[ASHMEM_NAME_PREFIX_LEN] != '\0')
11980c2ac4ccfa Robert Love 2011-12-20 401 name =
asma->name;
11980c2ac4ccfa Robert Love 2011-12-20 402
11980c2ac4ccfa Robert Love 2011-12-20 403 /* ... and
allocate the backing shmem file */
11980c2ac4ccfa Robert Love 2011-12-20 404 vmfile =
shmem_file_setup(name, asma->size, vma->vm_flags);
7f44cb0ba88b40 Viresh Kumar2015-07-
Re: mmotm 2020-03-28-22-17 uploaded (staging/octeon/)
On 3/28/20 10:18 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2020-03-28-22-17 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > > You will need quilt to apply these patches to the latest Linus release (5.x > or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > http://ozlabs.org/~akpm/mmotm/series on i386 or x86_64: ../drivers/staging/octeon/ethernet-tx.c: In function ‘cvm_oct_xmit’: ../drivers/staging/octeon/ethernet-tx.c:358:2: error: implicit declaration of function ‘skb_reset_tc’; did you mean ‘skb_reserve’? [-Werror=implicit-function-declaration] skb_reset_tc(skb); ^~~~ It looks like this inline function has been removed from . Looks like it should be this change: - skb_reset_tc(skb); + skb_reset_redirect(skb); -- ~Randy Reported-by: Randy Dunlap ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/5] staging: rtl8712: fix checkpatch long-line warning
This patch fixes these two long-line checkpatch warnings
in rtl871x_xmit.c:
WARNING: line over 80 characters
\#74: FILE: drivers/staging//rtl8712/rtl871x_xmit.c:74:
+ * Please allocate memory with the sz = (struct xmit_frame) *
NR_XMITFRAME,
WARNING: line over 80 characters
\#79: FILE: drivers/staging//rtl8712/rtl871x_xmit.c:79:
+ kmalloc(NR_XMITFRAME * sizeof(struct xmit_frame) + 4,
GFP_ATOMIC);
Signed-off-by: Aiman Najjar
---
drivers/staging/rtl8712/rtl871x_xmit.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c
b/drivers/staging/rtl8712/rtl871x_xmit.c
index f0b85338b567..628e4bad1547 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -71,12 +71,13 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv,
_init_queue(&pxmitpriv->apsd_queue);
_init_queue(&pxmitpriv->free_xmit_queue);
/*
-* Please allocate memory with the sz = (struct xmit_frame) *
NR_XMITFRAME,
+* Please allocate memory with sz = (struct xmit_frame) * NR_XMITFRAME,
* and initialize free_xmit_frame below.
* Please also apply free_txobj to link_up all the xmit_frames...
*/
pxmitpriv->pallocated_frame_buf =
- kmalloc(NR_XMITFRAME * sizeof(struct xmit_frame) + 4,
GFP_ATOMIC);
+ kmalloc(NR_XMITFRAME * sizeof(struct xmit_frame) + 4,
+ GFP_ATOMIC);
if (!pxmitpriv->pallocated_frame_buf) {
pxmitpriv->pxmit_frame_buf = NULL;
return -ENOMEM;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 0/5] staging: rtl8712: rtl871x_xmit.{c, h} code style improvements
Make several improvements to code style of rtl871x_xmit.c and rtl871x_xmit.h. v1 -> v2: changes * Break up single pach into patchset of small patches v2 -> v3 changes: * [PATCH 4/5]: Applied suggestions by Joe to improve overall code quality (thanks Joe!) Aiman Najjar (5): staging: rtl8712: fix checkpatch long-line warning staging: rtl8712: fix long-line checkpatch warning staging: rtl8712: fix checkpatch warnings staging:rtl8712: code improvements to make_wlanhdr staging: rtl8712:fix multiline derefernce warnings drivers/staging/rtl8712/rtl871x_xmit.c | 158 - drivers/staging/rtl8712/rtl871x_xmit.h | 2 +- 2 files changed, 77 insertions(+), 83 deletions(-) -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 3/5] staging: rtl8712: fix checkpatch warnings
This patch fixes multiline dereference warnings in
rtl871x_xmit.c:
WARNING: Avoid multiple line dereference - prefer 'psecuritypriv->XGrptxmickey'
379: FILE: drivers/staging//rtl8712/rtl871x_xmit.c:379:
+ psecuritypriv->
+ XGrptxmickey[psecuritypriv->
WARNING: Avoid multiple line dereference - prefer 'psecuritypriv->XGrpKeyid'
380: FILE: drivers/staging//rtl8712/rtl871x_xmit.c:380:
+ XGrptxmickey[psecuritypriv->
+ XGrpKeyid].skey);
Signed-off-by: Aiman Najjar
---
drivers/staging/rtl8712/rtl871x_xmit.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c
b/drivers/staging/rtl8712/rtl871x_xmit.c
index 454c26f83406..0f789c821552 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -351,7 +351,7 @@ static int xmitframe_addmic(struct _adapter *padapter,
struct sta_info *stainfo;
struct qos_priv *pqospriv = &(padapter->mlmepriv.qospriv);
struct pkt_attrib *pattrib = &pxmitframe->attrib;
- struct security_priv *psecuritypriv = &padapter->securitypriv;
+ struct security_priv *psecpriv = &padapter->securitypriv;
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
u8 priority[4] = {0x0, 0x0, 0x0, 0x0};
bool bmcst = is_multicast_ether_addr(pattrib->ra);
@@ -369,15 +369,14 @@ static int xmitframe_addmic(struct _adapter *padapter,
0x0, 0x0};
pframe = pxmitframe->buf_addr + TXDESC_OFFSET;
if (bmcst) {
- if (!memcmp(psecuritypriv->XGrptxmickey
- [psecuritypriv->XGrpKeyid].skey,
+ if (!memcmp(psecpriv->XGrptxmickey
+ [psecpriv->XGrpKeyid].skey,
null_key, 16))
return -ENOMEM;
/*start to calculate the mic code*/
r8712_secmicsetkey(&micdata,
-psecuritypriv->
-XGrptxmickey[psecuritypriv->
- XGrpKeyid].skey);
+ psecpriv->XGrptxmickey
+ [psecpriv->XGrpKeyid].skey);
} else {
if (!memcmp(&stainfo->tkiptxmickey.skey[0],
null_key, 16))
@@ -417,7 +416,7 @@ static int xmitframe_addmic(struct _adapter *padapter,
length = pattrib->last_txcmdsz -
pattrib->hdrlen -
pattrib->iv_len -
- ((psecuritypriv->sw_encrypt)
+ ((psecpriv->sw_encrypt)
? pattrib->icv_len : 0);
r8712_secmicappend(&micdata, payload,
length);
@@ -425,7 +424,7 @@ static int xmitframe_addmic(struct _adapter *padapter,
} else {
length = pxmitpriv->frag_len -
pattrib->hdrlen - pattrib->iv_len -
- ((psecuritypriv->sw_encrypt) ?
+ ((psecpriv->sw_encrypt) ?
pattrib->icv_len : 0);
r8712_secmicappend(&micdata, payload,
length);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 4/5] staging:rtl8712: code improvements to make_wlanhdr
1. Refactor make_wlanhdr to improve code style.
2. Use ether_addr_copy instead of memcpy to copy addresses.
Suggested-by: Joe Perches
Signed-off-by: Aiman Najjar
---
drivers/staging/rtl8712/rtl871x_xmit.c | 123 -
drivers/staging/rtl8712/rtl871x_xmit.h | 2 +-
2 files changed, 61 insertions(+), 64 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c
b/drivers/staging/rtl8712/rtl871x_xmit.c
index 0f789c821552..21026297413c 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -477,75 +477,72 @@ static int make_wlanhdr(struct _adapter *padapter, u8
*hdr,
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
struct qos_priv *pqospriv = &pmlmepriv->qospriv;
__le16 *fctrl = &pwlanhdr->frame_ctl;
+ u8 *bssid;
memset(hdr, 0, WLANHDR_OFFSET);
SetFrameSubType(fctrl, pattrib->subtype);
- if (pattrib->subtype & WIFI_DATA_TYPE) {
- if (check_fwstate(pmlmepriv, WIFI_STATION_STATE)) {
- /* to_ds = 1, fr_ds = 0; */
- SetToDs(fctrl);
- memcpy(pwlanhdr->addr1, get_bssid(pmlmepriv),
- ETH_ALEN);
- memcpy(pwlanhdr->addr2, pattrib->src, ETH_ALEN);
- memcpy(pwlanhdr->addr3, pattrib->dst, ETH_ALEN);
- } else if (check_fwstate(pmlmepriv, WIFI_AP_STATE)) {
- /* to_ds = 0, fr_ds = 1; */
- SetFrDs(fctrl);
- memcpy(pwlanhdr->addr1, pattrib->dst, ETH_ALEN);
- memcpy(pwlanhdr->addr2, get_bssid(pmlmepriv),
- ETH_ALEN);
- memcpy(pwlanhdr->addr3, pattrib->src, ETH_ALEN);
- } else if (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) ||
- check_fwstate(pmlmepriv,
-WIFI_ADHOC_MASTER_STATE)) {
- memcpy(pwlanhdr->addr1, pattrib->dst, ETH_ALEN);
- memcpy(pwlanhdr->addr2, pattrib->src, ETH_ALEN);
- memcpy(pwlanhdr->addr3, get_bssid(pmlmepriv),
- ETH_ALEN);
- } else if (check_fwstate(pmlmepriv, WIFI_MP_STATE)) {
- memcpy(pwlanhdr->addr1, pattrib->dst, ETH_ALEN);
- memcpy(pwlanhdr->addr2, pattrib->src, ETH_ALEN);
- memcpy(pwlanhdr->addr3, get_bssid(pmlmepriv),
- ETH_ALEN);
- } else {
- return -EINVAL;
- }
+ if (!(pattrib->subtype & WIFI_DATA_TYPE))
+ return 0;
- if (pattrib->encrypt)
- SetPrivacy(fctrl);
- if (pqospriv->qos_option) {
- qc = (unsigned short *)(hdr + pattrib->hdrlen - 2);
- if (pattrib->priority)
- SetPriority(qc, pattrib->priority);
- SetAckpolicy(qc, pattrib->ack_policy);
- }
- /* TODO: fill HT Control Field */
- /* Update Seq Num will be handled by f/w */
- {
- struct sta_info *psta;
- bool bmcst = is_multicast_ether_addr(pattrib->ra);
-
- if (pattrib->psta) {
- psta = pattrib->psta;
- } else {
- if (bmcst)
- psta = r8712_get_bcmc_stainfo(padapter);
- else
- psta =
-r8712_get_stainfo(&padapter->stapriv,
-pattrib->ra);
- }
- if (psta) {
- psta->sta_xmitpriv.txseq_tid
- [pattrib->priority]++;
- psta->sta_xmitpriv.txseq_tid[pattrib->priority]
- &= 0xFFF;
- pattrib->seqnum = psta->sta_xmitpriv.
- txseq_tid[pattrib->priority];
- SetSeqNum(hdr, pattrib->seqnum);
- }
+ bssid = get_bssid(pmlmepriv);
+
+ if (check_fwstate(pmlmepriv, WIFI_STATION_STATE)) {
+ /* to_ds = 1, fr_ds = 0; */
+ SetToDs(fctrl);
+ ether_addr_copy(pwlanhdr->addr1, bssid);
+ ether_addr_copy(pwlanhdr->addr2, pattrib->src);
+ ether_addr_copy(pwlanhdr->addr3, pattrib->dst);
+ } else if (check_fwstate(pmlmepriv, WIFI_AP_STATE)) {
+ /* to_ds = 0, fr_ds = 1; */
+ SetFrDs(fctrl);
+ ether_addr_copy(pwlanhdr->
[PATCH v3 2/5] staging: rtl8712: fix long-line checkpatch warning
This patch fixes the following warning in rtl871x_xmit.c:
WARNING: line over 80 characters
130: FILE: drivers/staging//rtl8712/rtl871x_xmit.c:130:
+ pxmitbuf->pallocated_buf = kmalloc(MAX_XMITBUF_SZ +
XMITBUF_ALIGN_SZ,
Signed-off-by: Aiman Najjar
---
drivers/staging/rtl8712/rtl871x_xmit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c
b/drivers/staging/rtl8712/rtl871x_xmit.c
index 628e4bad1547..454c26f83406 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -127,8 +127,8 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv,
pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmitbuf;
for (i = 0; i < NR_XMITBUFF; i++) {
INIT_LIST_HEAD(&pxmitbuf->list);
- pxmitbuf->pallocated_buf = kmalloc(MAX_XMITBUF_SZ +
XMITBUF_ALIGN_SZ,
- GFP_ATOMIC);
+ pxmitbuf->pallocated_buf =
+ kmalloc(MAX_XMITBUF_SZ + XMITBUF_ALIGN_SZ, GFP_ATOMIC);
if (!pxmitbuf->pallocated_buf)
return -ENOMEM;
pxmitbuf->pbuf = pxmitbuf->pallocated_buf + XMITBUF_ALIGN_SZ -
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 5/5] staging: rtl8712:fix multiline derefernce warnings
This patch fixes remaining checkpatch warnings in rtl871x_xmit.c: WARNING: Avoid multiple line dereference - prefer 'psecuritypriv->PrivacyKeyIndex' 636: FILE: drivers/staging//rtl8712/rtl871x_xmit.c:636: + (u8)psecuritypriv-> + PrivacyKeyIndex); WARNING: Avoid multiple line dereference - prefer 'psecuritypriv->XGrpKeyid' 643: FILE: drivers/staging//rtl8712/rtl871x_xmit.c:643: + (u8)psecuritypriv-> + XGrpKeyid); WARNING: Avoid multiple line dereference - prefer 'psecuritypriv->XGrpKeyid' 652: FILE: drivers/staging//rtl8712/rtl871x_xmit.c:652: + (u8)psecuritypriv-> + XGrpKeyid); Signed-off-by: Aiman Najjar --- drivers/staging/rtl8712/rtl871x_xmit.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c b/drivers/staging/rtl8712/rtl871x_xmit.c index 21026297413c..2f0d0ffa6fae 100644 --- a/drivers/staging/rtl8712/rtl871x_xmit.c +++ b/drivers/staging/rtl8712/rtl871x_xmit.c @@ -586,7 +586,7 @@ sint r8712_xmitframe_coalesce(struct _adapter *padapter, _pkt *pkt, addr_t addr; u8 *pframe, *mem_start, *ptxdesc; struct sta_info *psta; - struct security_priv*psecuritypriv = &padapter->securitypriv; + struct security_priv*psecpriv = &padapter->securitypriv; struct mlme_priv*pmlmepriv = &padapter->mlmepriv; struct xmit_priv*pxmitpriv = &padapter->xmitpriv; struct pkt_attrib *pattrib = &pxmitframe->attrib; @@ -629,15 +629,13 @@ sint r8712_xmitframe_coalesce(struct _adapter *padapter, _pkt *pkt, case _WEP40_: case _WEP104_: WEP_IV(pattrib->iv, psta->txpn, - (u8)psecuritypriv-> - PrivacyKeyIndex); + (u8)psecpriv->PrivacyKeyIndex); break; case _TKIP_: if (bmcst) TKIP_IV(pattrib->iv, psta->txpn, - (u8)psecuritypriv-> - XGrpKeyid); + (u8)psecpriv->XGrpKeyid); else TKIP_IV(pattrib->iv, psta->txpn, 0); @@ -645,8 +643,7 @@ sint r8712_xmitframe_coalesce(struct _adapter *padapter, _pkt *pkt, case _AES_: if (bmcst) AES_IV(pattrib->iv, psta->txpn, - (u8)psecuritypriv-> - XGrpKeyid); + (u8)psecpriv->XGrpKeyid); else AES_IV(pattrib->iv, psta->txpn, 0); -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 01/01] staging: gasket: Fix incongruency in handling of sysfs entries creation
Fix incongruency in handling of sysfs entries creation.
This issue could cause invalid memory accesses, by not properly
detecting the end of the sysfs attributes array.
Signed-off-by: Luis Mendes
---
gasket_sysfs.c |3 +--
gasket_sysfs.h |4
2 files changed, 1 insertion(+), 6 deletions(-)
diff -uprN -X linux-5.6-rc7-vanilla/Documentation/dontdiff
linux-5.6-rc7-vanilla/drivers/staging/gasket/gasket_sysfs.c
linux-5.6-rc7/drivers/staging/gasket/gasket_sysfs.c
--- linux-5.6-rc7-vanilla/drivers/staging/gasket/gasket_sysfs.c
2020-03-23 01:31:56.0 +
+++ linux-5.6-rc7/drivers/staging/gasket/gasket_sysfs.c2020-03-29
18:52:39.399925886 +0100
@@ -228,8 +228,7 @@ int gasket_sysfs_create_entries(struct d
}
mutex_lock(&mapping->mutex);
-for (i = 0; strcmp(attrs[i].attr.attr.name, GASKET_ARRAY_END_MARKER);
-i++) {
+for (i = 0; attrs[i].attr.attr.name != NULL; i++) {
if (mapping->attribute_count == GASKET_SYSFS_MAX_NODES) {
dev_err(device,
"Maximum number of sysfs nodes reached for device\n");
diff -uprN -X linux-5.6-rc7-vanilla/Documentation/dontdiff
linux-5.6-rc7-vanilla/drivers/staging/gasket/gasket_sysfs.h
linux-5.6-rc7/drivers/staging/gasket/gasket_sysfs.h
--- linux-5.6-rc7-vanilla/drivers/staging/gasket/gasket_sysfs.h
2020-03-23 01:31:56.0 +
+++ linux-5.6-rc7/drivers/staging/gasket/gasket_sysfs.h2020-03-29
18:52:56.487839090 +0100
@@ -30,10 +30,6 @@
*/
#define GASKET_SYSFS_MAX_NODES 196
-/* End markers for sysfs struct arrays. */
-#define GASKET_ARRAY_END_TOKEN GASKET_RESERVED_ARRAY_END
-#define GASKET_ARRAY_END_MARKER __stringify(GASKET_ARRAY_END_TOKEN)
-
/*
* Terminator struct for a gasket_sysfs_attr array. Must be at the end of
* all gasket_sysfs_attribute arrays.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: uwb: Fix missing blank space coding style issue
This patch adds a blank space before the switch argument parenthesis to
silence checkpatch.pl errors.
Signed-off-by: Iulian Olaru
---
drivers/staging/uwb/drp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/uwb/drp.c b/drivers/staging/uwb/drp.c
index 869987bede7b..4449220f618a 100644
--- a/drivers/staging/uwb/drp.c
+++ b/drivers/staging/uwb/drp.c
@@ -249,7 +249,7 @@ static void handle_conflict_normal(struct uwb_ie_drp
*drp_ie,
action = evaluate_conflict_action(drp_ie, ext_beacon_slot, rsv,
uwb_rsv_status(rsv));
if (uwb_rsv_is_owner(rsv)) {
- switch(action) {
+ switch (action) {
case UWB_DRP_CONFLICT_ACT2:
/* try move */
uwb_rsv_set_state(rsv, UWB_RSV_STATE_O_TO_BE_MOVED);
@@ -267,7 +267,7 @@ static void handle_conflict_normal(struct uwb_ie_drp
*drp_ie,
break;
}
} else {
- switch(action) {
+ switch (action) {
case UWB_DRP_CONFLICT_ACT2:
case UWB_DRP_CONFLICT_ACT3:
uwb_rsv_set_state(rsv, UWB_RSV_STATE_T_CONFLICT);
@@ -292,7 +292,7 @@ static void handle_conflict_expanding(struct uwb_ie_drp
*drp_ie, int ext_beacon_
/* status of companion is 0 at this point */
action = evaluate_conflict_action(drp_ie, ext_beacon_slot, rsv,
0);
if (uwb_rsv_is_owner(rsv)) {
- switch(action) {
+ switch (action) {
case UWB_DRP_CONFLICT_ACT2:
case UWB_DRP_CONFLICT_ACT3:
uwb_rsv_set_state(rsv,
@@ -304,7 +304,7 @@ static void handle_conflict_expanding(struct uwb_ie_drp
*drp_ie, int ext_beacon_
&rsv->mv.companion_mas);
}
} else { /* rsv is target */
- switch(action) {
+ switch (action) {
case UWB_DRP_CONFLICT_ACT2:
case UWB_DRP_CONFLICT_ACT3:
uwb_rsv_set_state(rsv,
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: rtl8723bs: Remove unnecessary braces for single statements
On Wed, 25 Mar 2020 19:32:45 +0530
Simran Singhal wrote:
> Clean up unnecessary braces around single statement blocks.
> Issues reported by checkpatch.pl as:
> WARNING: braces {} are not necessary for single statement blocks
>
> Signed-off-by: Simran Singhal
> ---
> drivers/staging/rtl8723bs/core/rtw_efuse.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c
> b/drivers/staging/rtl8723bs/core/rtw_efuse.c
> index bdb6ff8aab7d..de7d15fdc936 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
> @@ -43,9 +43,8 @@ Efuse_Read1ByteFromFakeContent(
> u16 Offset,
> u8 *Value)
> {
> - if (Offset >= EFUSE_MAX_HW_SIZE) {
> + if (Offset >= EFUSE_MAX_HW_SIZE)
> return false;
> - }
> /* DbgPrint("Read fake content, offset = %d\n", Offset); */
I find the resulting version a bit confusing:
if (Offset >= EFUSE_MAX_HW_SIZE)
return false;
/* DbgPrint("Read fake content, offset = %d\n", Offset); */
if (fakeEfuseBank == 0)
*Value = fakeEfuseContent[Offset];
The check on "Offset" isn't separated in any way by the following
logic. I would suggest that you replace the closing brace by a newline,
also for the other cases you're fixing up here:
if (Offset >= EFUSE_MAX_HW_SIZE)
return false;
/* DbgPrint("Read fake content, offset = %d\n", Offset); */
...
--
Stefano
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: rtl8723bs: Remove multiple assignments
On Wed, 25 Mar 2020 19:52:26 +0530 Simran Singhal wrote: > Remove multiple assignments by factorizing them. > Problem found using checkpatch.pl:- > CHECK: multiple assignments should be avoided > > Signed-off-by: Simran Singhal > --- > drivers/staging/rtl8723bs/core/rtw_cmd.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c > b/drivers/staging/rtl8723bs/core/rtw_cmd.c > index 61a9bf61b976..744b40dd4cf0 100644 > --- a/drivers/staging/rtl8723bs/core/rtw_cmd.c > +++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c > @@ -194,7 +194,9 @@ int rtw_init_cmd_priv(struct cmd_priv *pcmdpriv) > > pcmdpriv->rsp_buf = pcmdpriv->rsp_allocated_buf + 4 - > ((SIZE_PTR)(pcmdpriv->rsp_allocated_buf) & 3); > > - pcmdpriv->cmd_issued_cnt = pcmdpriv->cmd_done_cnt = pcmdpriv->rsp_cnt = > 0; > + pcmdpriv->cmd_issued_cnt = 0; > + pcmdpriv->cmd_done_cnt = 0; > + pcmdpriv->rsp_cnt = 0; I think this is better than the original because the original exceeds 80 columns (and looks horrible in general). But the second hunk: > > mutex_init(&pcmdpriv->sctx_mutex); > exit: > @@ -2138,7 +2140,8 @@ void rtw_setassocsta_cmdrsp_callback(struct adapter > *padapter, struct cmd_obj * > goto exit; > } > > - psta->aid = psta->mac_id = passocsta_rsp->cam_id; > + psta->aid = passocsta_rsp->cam_id; > + psta->mac_id = passocsta_rsp->cam_id; I would leave this alone, because psta->aid is really the same thing here, it's not just a value that happens to be assigned to both by accident. -- Stefano ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: rtl8723bs: Add line after variable declarations
Hi Simran, On Wed, 25 Mar 2020 22:14:52 +0530 Simran Singhal wrote: > Add whiteline after variable declarations to remove the checkpatch.pl > warning: > WARNING: Missing a blank line after declarations > > Signed-off-by: Simran Singhal Sorry for the late review. This patch introduces similar changes to the other patches you posted to fix checkpatch warnings for rtl8723bs, so I think they should be posted as a patchset instead. -- Stefano ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH v2] Staging: rtl8188eu: hal: Add space around operators
On Wed, 25 Mar 2020 21:31:42 +0530 Shreeya Patel wrote: > Add space around operators for improving the code > readability. > Reported by checkpatch.pl > > git diff -w shows no difference. > diff of the .o files before and after the changes shows no difference. > > Signed-off-by: Shreeya Patel Reviewed-by: Stefano Brivio -- Stefano ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Reply For More Details.
-- My dear, I am Mrs Maryalice Williams, I want to send you donation of two million seven hundred thousand Dollars ($2.7M) for volunteer projects in your country due to my ill health that could not permit me. Kindly reply for more details, and also send me the following details, as per below, your full Name .., Address..., Age..., Occupation ... Remain blessed, Mrs. Maryalice Williams. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: mmotm 2020-03-28-22-17 uploaded (staging/octeon/)
Hi Randy, On Sun, 29 Mar 2020 09:12:31 -0700 Randy Dunlap wrote: > > On 3/28/20 10:18 PM, a...@linux-foundation.org wrote: > > The mm-of-the-moment snapshot 2020-03-28-22-17 has been uploaded to > > > >http://www.ozlabs.org/~akpm/mmotm/ > > > > mmotm-readme.txt says > > > > README for mm-of-the-moment: > > > > http://www.ozlabs.org/~akpm/mmotm/ > > > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > > more than once a week. > > > > You will need quilt to apply these patches to the latest Linus release (5.x > > or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > > http://ozlabs.org/~akpm/mmotm/series > > > on i386 or x86_64: > > ../drivers/staging/octeon/ethernet-tx.c: In function ‘cvm_oct_xmit’: > ../drivers/staging/octeon/ethernet-tx.c:358:2: error: implicit declaration of > function ‘skb_reset_tc’; did you mean ‘skb_reserve’? > [-Werror=implicit-function-declaration] > skb_reset_tc(skb); > ^~~~ > > It looks like this inline function has been removed from > . > > > Looks like it should be this change: > > - skb_reset_tc(skb); > + skb_reset_redirect(skb); I applied the above as a merge resolution patch for the staging tree merge today, as the inline removal was a late change to Linus' tree. -- Cheers, Stephen Rothwell pgp67jcLOmpjj.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: rtl8723bs: rtw_efuse: Compress lines for immediate return
On Thu, 26 Mar 2020 02:24:18 +0530 Simran Singhal wrote: > Compress two lines into a single line if immediate return statement is found. Same as your patches for issues reported by checkpatch, I think you should post these ones as a patchset. -- Stefano ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: rtl8723bs: rtw_cmd: Compress lines for immediate return
On Thu, 26 Mar 2020 02:52:53 +0530 Simran Singhal wrote: > Compress two lines into a single line if immediate return statement is found. > It also removes variable cmd_obj as it is no longer needed. > > It is done using script Coccinelle. This should be consistent. What does "it" refer to, now? If you start with an imperative mode, switching to indicative makes it hard to follow. By the way, Coccinelle is not exactly a script. Saying something is detected by Coccinelle is enough, you don't need to qualify that further. -- Stefano ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
