Re: [PATCH 11/12] staging: media: cedrus: Fix misuse of GENMASK macro
Hi, On Tue 09 Jul 19, 22:04, Joe Perches wrote: > Arguments are supposed to be ordered high then low. > > Signed-off-by: Joe Perches Good catch, thanks! Acked-by: Paul Kocialkowski Cheers, Paul > --- > drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > index 3e9931416e45..ddd29788d685 100644 > --- a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > @@ -110,7 +110,7 @@ > #define VE_DEC_MPEG_MBADDR (VE_ENGINE_DEC_MPEG + 0x10) > > #define VE_DEC_MPEG_MBADDR_X(w) (((w) << 8) & > GENMASK(15, 8)) > -#define VE_DEC_MPEG_MBADDR_Y(h) (((h) << 0) & > GENMASK(0, 7)) > +#define VE_DEC_MPEG_MBADDR_Y(h) (((h) << 0) & > GENMASK(7, 0)) > > #define VE_DEC_MPEG_CTRL (VE_ENGINE_DEC_MPEG + 0x14) > > -- > 2.15.0 > -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
BUG: Staging: fbtft: Switch to the gpio descriptor interface
G'day Nishad,
I'm just wondering if the commit
c440eee1a7a1d0f "Staging: fbtft: Switch to the gpio descriptor interface"
was tested on anything.
I've had to apply the following patch to get my display functioning again.
in particular the devm_gpiod_get_index using dev->driver->name for the gpio
lookup seems
wrong.
Also I've had to invert the polarity of the reset-gpios in the DT file for the
display to function.
this code:
gpiod_set_value_cansleep(par->gpio.reset, 0);
usleep_range(20, 40);
gpiod_set_value_cansleep(par->gpio.reset, 1);
could be read as deasserting the reset line and then asserting it.
So I've had to specify and active high reset line in the DT.
Regards
Phil
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 9b07bad..6fe7cb5 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -79,18 +79,16 @@ static int fbtft_request_one_gpio(struct fbtft_par *par,
struct device_node *node = dev->of_node;
int ret = 0;
- if (of_find_property(node, name, NULL)) {
- *gpiop = devm_gpiod_get_index(dev, dev->driver->name, index,
- GPIOD_OUT_HIGH);
- if (IS_ERR(*gpiop)) {
- ret = PTR_ERR(*gpiop);
- dev_err(dev,
- "Failed to request %s GPIO:%d\n", name, ret);
- return ret;
- }
- fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
- __func__, name);
+ *gpiop = devm_gpiod_get_index_optional(dev, name, index,
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(*gpiop)) {
+ ret = PTR_ERR(*gpiop);
+ dev_err(dev,
+ "Failed to request %s GPIO: (%d)\n", name, ret);
+ return ret;
}
+ fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
+ __func__, name);
return ret;
}
@@ -103,34 +101,34 @@ static int fbtft_request_gpios_dt(struct fbtft_par *par)
if (!par->info->device->of_node)
return -EINVAL;
- ret = fbtft_request_one_gpio(par, "reset-gpios", 0, &par->gpio.reset);
+ ret = fbtft_request_one_gpio(par, "reset", 0, &par->gpio.reset);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "dc-gpios", 0, &par->gpio.dc);
+ ret = fbtft_request_one_gpio(par, "dc", 0, &par->gpio.dc);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "rd-gpios", 0, &par->gpio.rd);
+ ret = fbtft_request_one_gpio(par, "rd", 0, &par->gpio.rd);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "wr-gpios", 0, &par->gpio.wr);
+ ret = fbtft_request_one_gpio(par, "wr", 0, &par->gpio.wr);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "cs-gpios", 0, &par->gpio.cs);
+ ret = fbtft_request_one_gpio(par, "cs", 0, &par->gpio.cs);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "latch-gpios", 0, &par->gpio.latch);
+ ret = fbtft_request_one_gpio(par, "latch", 0, &par->gpio.latch);
if (ret)
return ret;
for (i = 0; i < 16; i++) {
- ret = fbtft_request_one_gpio(par, "db-gpios", i,
+ ret = fbtft_request_one_gpio(par, "db", i,
&par->gpio.db[i]);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "led-gpios", i,
+ ret = fbtft_request_one_gpio(par, "led", i,
&par->gpio.led[i]);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "aux-gpios", i,
+ ret = fbtft_request_one_gpio(par, "aux", i,
&par->gpio.aux[i]);
if (ret)
return ret;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: BUG: Staging: fbtft: Switch to the gpio descriptor interface
On Wed, 2019-07-10 at 16:31 +0800, Phil Reid wrote:
> G'day Nishad,
>
> I'm just wondering if the commit
> c440eee1a7a1d0f "Staging: fbtft: Switch to the gpio descriptor interface"
> was tested on anything.
>
> I've had to apply the following patch to get my display functioning again.
>
> in particular the devm_gpiod_get_index using dev->driver->name for the gpio
> lookup seems
> wrong.
FYI We've seen the same issue this week in opensuse's bugzilla and was testing
something very similar to the patch below. Phil do you plan on submitting your
fix?
Regards,
Nicolas
> Also I've had to invert the polarity of the reset-gpios in the DT file for the
> display to function.
>
> this code:
> gpiod_set_value_cansleep(par->gpio.reset, 0);
> usleep_range(20, 40);
> gpiod_set_value_cansleep(par->gpio.reset, 1);
>
> could be read as deasserting the reset line and then asserting it.
> So I've had to specify and active high reset line in the DT.
>
> Regards
> Phil
>
>
>
>
>
> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-
> core.c
> index 9b07bad..6fe7cb5 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -79,18 +79,16 @@ static int fbtft_request_one_gpio(struct fbtft_par *par,
> struct device_node *node = dev->of_node;
> int ret = 0;
>
> - if (of_find_property(node, name, NULL)) {
> - *gpiop = devm_gpiod_get_index(dev, dev->driver->name, index,
> - GPIOD_OUT_HIGH);
> - if (IS_ERR(*gpiop)) {
> - ret = PTR_ERR(*gpiop);
> - dev_err(dev,
> - "Failed to request %s GPIO:%d\n", name, ret);
> - return ret;
> - }
> - fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
> - __func__, name);
> + *gpiop = devm_gpiod_get_index_optional(dev, name, index,
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(*gpiop)) {
> + ret = PTR_ERR(*gpiop);
> + dev_err(dev,
> + "Failed to request %s GPIO: (%d)\n", name, ret);
> + return ret;
> }
> + fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
> + __func__, name);
>
> return ret;
> }
> @@ -103,34 +101,34 @@ static int fbtft_request_gpios_dt(struct fbtft_par *par)
> if (!par->info->device->of_node)
> return -EINVAL;
>
> - ret = fbtft_request_one_gpio(par, "reset-gpios", 0, &par->gpio.reset);
> + ret = fbtft_request_one_gpio(par, "reset", 0, &par->gpio.reset);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "dc-gpios", 0, &par->gpio.dc);
> + ret = fbtft_request_one_gpio(par, "dc", 0, &par->gpio.dc);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "rd-gpios", 0, &par->gpio.rd);
> + ret = fbtft_request_one_gpio(par, "rd", 0, &par->gpio.rd);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "wr-gpios", 0, &par->gpio.wr);
> + ret = fbtft_request_one_gpio(par, "wr", 0, &par->gpio.wr);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "cs-gpios", 0, &par->gpio.cs);
> + ret = fbtft_request_one_gpio(par, "cs", 0, &par->gpio.cs);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "latch-gpios", 0, &par->gpio.latch);
> + ret = fbtft_request_one_gpio(par, "latch", 0, &par->gpio.latch);
> if (ret)
> return ret;
> for (i = 0; i < 16; i++) {
> - ret = fbtft_request_one_gpio(par, "db-gpios", i,
> + ret = fbtft_request_one_gpio(par, "db", i,
>&par->gpio.db[i]);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "led-gpios", i,
> + ret = fbtft_request_one_gpio(par, "led", i,
>&par->gpio.led[i]);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "aux-gpios", i,
> + ret = fbtft_request_one_gpio(par, "aux", i,
>&par->gpio.aux[i]);
> if (ret)
> return ret;
>
>
>
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/12] treewide: Fix GENMASK misuses
On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote: > These GENMASK uses are inverted argument order and the > actual masks produced are incorrect. Fix them. > > Add checkpatch tests to help avoid more misuses too. > > Joe Perches (12): > checkpatch: Add GENMASK tests IMHO this doesn't make a lot of sense as a checkpatch test - just throw in a BUILD_BUG_ON()? johannes ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: BUG: Staging: fbtft: Switch to the gpio descriptor interface
On 10/07/2019 17:05, Nicolas Saenz Julienne wrote:
On Wed, 2019-07-10 at 16:31 +0800, Phil Reid wrote:
G'day Nishad,
I'm just wondering if the commit
c440eee1a7a1d0f "Staging: fbtft: Switch to the gpio descriptor interface"
was tested on anything.
I've had to apply the following patch to get my display functioning again.
in particular the devm_gpiod_get_index using dev->driver->name for the gpio
lookup seems
wrong.
FYI We've seen the same issue this week in opensuse's bugzilla and was testing
something very similar to the patch below. Phil do you plan on submitting your
fix?
Yes I can submit a patch tomorrow.
I just wasn't sure if it was working for anyone.
Also I've had to invert the polarity of the reset-gpios in the DT file for the
display to function.
this code:
gpiod_set_value_cansleep(par->gpio.reset, 0);
usleep_range(20, 40);
gpiod_set_value_cansleep(par->gpio.reset, 1);
could be read as deasserting the reset line and then asserting it.
So I've had to specify and active high reset line in the DT.
Regards
Phil
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-
core.c
index 9b07bad..6fe7cb5 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -79,18 +79,16 @@ static int fbtft_request_one_gpio(struct fbtft_par *par,
struct device_node *node = dev->of_node;
int ret = 0;
- if (of_find_property(node, name, NULL)) {
- *gpiop = devm_gpiod_get_index(dev, dev->driver->name, index,
- GPIOD_OUT_HIGH);
- if (IS_ERR(*gpiop)) {
- ret = PTR_ERR(*gpiop);
- dev_err(dev,
- "Failed to request %s GPIO:%d\n", name, ret);
- return ret;
- }
- fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
- __func__, name);
+ *gpiop = devm_gpiod_get_index_optional(dev, name, index,
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(*gpiop)) {
+ ret = PTR_ERR(*gpiop);
+ dev_err(dev,
+ "Failed to request %s GPIO: (%d)\n", name, ret);
+ return ret;
}
+ fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
+ __func__, name);
return ret;
}
@@ -103,34 +101,34 @@ static int fbtft_request_gpios_dt(struct fbtft_par *par)
if (!par->info->device->of_node)
return -EINVAL;
- ret = fbtft_request_one_gpio(par, "reset-gpios", 0, &par->gpio.reset);
+ ret = fbtft_request_one_gpio(par, "reset", 0, &par->gpio.reset);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "dc-gpios", 0, &par->gpio.dc);
+ ret = fbtft_request_one_gpio(par, "dc", 0, &par->gpio.dc);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "rd-gpios", 0, &par->gpio.rd);
+ ret = fbtft_request_one_gpio(par, "rd", 0, &par->gpio.rd);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "wr-gpios", 0, &par->gpio.wr);
+ ret = fbtft_request_one_gpio(par, "wr", 0, &par->gpio.wr);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "cs-gpios", 0, &par->gpio.cs);
+ ret = fbtft_request_one_gpio(par, "cs", 0, &par->gpio.cs);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "latch-gpios", 0, &par->gpio.latch);
+ ret = fbtft_request_one_gpio(par, "latch", 0, &par->gpio.latch);
if (ret)
return ret;
for (i = 0; i < 16; i++) {
- ret = fbtft_request_one_gpio(par, "db-gpios", i,
+ ret = fbtft_request_one_gpio(par, "db", i,
&par->gpio.db[i]);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "led-gpios", i,
+ ret = fbtft_request_one_gpio(par, "led", i,
&par->gpio.led[i]);
if (ret)
return ret;
- ret = fbtft_request_one_gpio(par, "aux-gpios", i,
+ ret = fbtft_request_one_gpio(par, "aux", i,
&par->gpio.aux[i]);
if (ret)
return ret;
--
Regards
Phil Reid
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: BUG: Staging: fbtft: Switch to the gpio descriptor interface
On Wed, 2019-07-10 at 17:27 +0800, Phil Reid wrote:
> On 10/07/2019 17:05, Nicolas Saenz Julienne wrote:
> > On Wed, 2019-07-10 at 16:31 +0800, Phil Reid wrote:
> > > G'day Nishad,
> > >
> > > I'm just wondering if the commit
> > > c440eee1a7a1d0f "Staging: fbtft: Switch to the gpio descriptor interface"
> > > was tested on anything.
> > >
> > > I've had to apply the following patch to get my display functioning again.
> > >
> > > in particular the devm_gpiod_get_index using dev->driver->name for the
> > > gpio
> > > lookup seems
> > > wrong.
> >
> > FYI We've seen the same issue this week in opensuse's bugzilla and was
> > testing
> > something very similar to the patch below. Phil do you plan on submitting
> > your
> > fix?
> >
>
> Yes I can submit a patch tomorrow.
>
> I just wasn't sure if it was working for anyone.
Please CC me and I'll give it a test :).
>
>
>
> > > Also I've had to invert the polarity of the reset-gpios in the DT file for
> > > the
> > > display to function.
> > >
> > > this code:
> > > gpiod_set_value_cansleep(par->gpio.reset, 0);
> > > usleep_range(20, 40);
> > > gpiod_set_value_cansleep(par->gpio.reset, 1);
> > >
> > > could be read as deasserting the reset line and then asserting it.
> > > So I've had to specify and active high reset line in the DT.
> > >
> > > Regards
> > > Phil
> > >
> > >
> > >
> > >
> > >
> > > diff --git a/drivers/staging/fbtft/fbtft-core.c
> > > b/drivers/staging/fbtft/fbtft-
> > > core.c
> > > index 9b07bad..6fe7cb5 100644
> > > --- a/drivers/staging/fbtft/fbtft-core.c
> > > +++ b/drivers/staging/fbtft/fbtft-core.c
> > > @@ -79,18 +79,16 @@ static int fbtft_request_one_gpio(struct fbtft_par
> > > *par,
> > > struct device_node *node = dev->of_node;
> > > int ret = 0;
> > >
> > > - if (of_find_property(node, name, NULL)) {
> > > - *gpiop = devm_gpiod_get_index(dev, dev->driver->name, index,
> > > - GPIOD_OUT_HIGH);
> > > - if (IS_ERR(*gpiop)) {
> > > - ret = PTR_ERR(*gpiop);
> > > - dev_err(dev,
> > > - "Failed to request %s GPIO:%d\n", name, ret);
> > > - return ret;
> > > - }
> > > - fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
> > > - __func__, name);
> > > + *gpiop = devm_gpiod_get_index_optional(dev, name, index,
> > > + GPIOD_OUT_HIGH);
> > > + if (IS_ERR(*gpiop)) {
> > > + ret = PTR_ERR(*gpiop);
> > > + dev_err(dev,
> > > + "Failed to request %s GPIO: (%d)\n", name, ret);
> > > + return ret;
> > > }
> > > + fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
> > > + __func__, name);
> > >
> > > return ret;
> > >}
> > > @@ -103,34 +101,34 @@ static int fbtft_request_gpios_dt(struct fbtft_par
> > > *par)
> > > if (!par->info->device->of_node)
> > > return -EINVAL;
> > >
> > > - ret = fbtft_request_one_gpio(par, "reset-gpios", 0, &par->gpio.reset);
> > > + ret = fbtft_request_one_gpio(par, "reset", 0, &par->gpio.reset);
> > > if (ret)
> > > return ret;
> > > - ret = fbtft_request_one_gpio(par, "dc-gpios", 0, &par->gpio.dc);
> > > + ret = fbtft_request_one_gpio(par, "dc", 0, &par->gpio.dc);
> > > if (ret)
> > > return ret;
> > > - ret = fbtft_request_one_gpio(par, "rd-gpios", 0, &par->gpio.rd);
> > > + ret = fbtft_request_one_gpio(par, "rd", 0, &par->gpio.rd);
> > > if (ret)
> > > return ret;
> > > - ret = fbtft_request_one_gpio(par, "wr-gpios", 0, &par->gpio.wr);
> > > + ret = fbtft_request_one_gpio(par, "wr", 0, &par->gpio.wr);
> > > if (ret)
> > > return ret;
> > > - ret = fbtft_request_one_gpio(par, "cs-gpios", 0, &par->gpio.cs);
> > > + ret = fbtft_request_one_gpio(par, "cs", 0, &par->gpio.cs);
> > > if (ret)
> > > return ret;
> > > - ret = fbtft_request_one_gpio(par, "latch-gpios", 0, &par->gpio.latch);
> > > + ret = fbtft_request_one_gpio(par, "latch", 0, &par->gpio.latch);
> > > if (ret)
> > > return ret;
> > > for (i = 0; i < 16; i++) {
> > > - ret = fbtft_request_one_gpio(par, "db-gpios", i,
> > > + ret = fbtft_request_one_gpio(par, "db", i,
> > >&par->gpio.db[i]);
> > > if (ret)
> > > return ret;
> > > - ret = fbtft_request_one_gpio(par, "led-gpios", i,
> > > + ret = fbtft_request_one_gpio(par, "led", i,
> > >&par->gpio.led[i]);
> > > if (ret)
> > > return ret;
> > > - ret = fbtft_request_one_gpio(par, "aux-gpios", i,
> > > + ret = fbtft_request_one_gpio(par, "aux", i,
> > >
Re: [PATCH 00/12] treewide: Fix GENMASK misuses
On Wed, Jul 10, 2019 at 11:17:31AM +0200, Johannes Berg wrote: > On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote: > > These GENMASK uses are inverted argument order and the > > actual masks produced are incorrect. Fix them. > > > > Add checkpatch tests to help avoid more misuses too. > > > > Joe Perches (12): > > checkpatch: Add GENMASK tests > > IMHO this doesn't make a lot of sense as a checkpatch test - just throw > in a BUILD_BUG_ON()? My personal take on this is that GENMASK() is really not useful, it's just pure obfuscation and leads to exactly these kinds of mistakes. Yes, I fully understand the argument that you can just specify the start and end bits, and it _in theory_ makes the code more readable. However, the problem is when writing code. GENMASK(a, b). Is a the starting bit or ending bit? Is b the number of bits? It's confusing and causes mistakes resulting in incorrect code. A BUILD_BUG_ON() can catch some of the cases, but not all of them. For example: GENMASK(6, 2) would satisify the requirement that a > b, so a BUILD_BUG_ON() will not trigger, but was the author meaning 0x3c or 0xc0? Personally, I've decided I am _not_ going to use GENMASK() in my code because I struggle to get the macro arguments correct - I'm _much_ happier, and it is way more reliable for me to write the mask in hex notation. I think this is where use of a ternary operator would come in use. The normal way of writing a number of bits tends to be "a:b", so if GENMASK took something like GENMASK(6:2), then I'd have less issue with it, because it's argument is then in a familiar notation. Yes, I'm sure that someone will point out that the GENMASK arguments are just in the same order, but that doesn't prevent _me_ frequently getting it wrong - and that's the point. The macro seems to me to cause more problems than it solves. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging/IIO driver patches for 5.3-rc1
The following changes since commit 4b972a01a7da614b4796475f933094751a295a2f:
Linux 5.2-rc6 (2019-06-22 16:01:36 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-5.3-rc1
for you to fetch changes up to 5d1532482943403eb11911898565628fa45863d7:
staging: kpc2000: simplify comparison to NULL in fileops.c (2019-07-04
10:40:44 +0200)
Staging / IIO driver update for 5.3-rc1
Here is the big Staging and IIO driver update for 5.3-rc1.
Lots of new IIO drivers are in here, along with loads of tiny staging
driver cleanups and fixes. Overall we almost break even with the same
lines added as removed.
Full details are in the shortlog, they are too large to list here.
All of these changes have been in linux-next for a while with no
reported issues.
Signed-off-by: Greg Kroah-Hartman
Adham Abozaeid (1):
staging: wilc1000: add passive scan support
Ajay Singh (8):
staging: wilc1000: handle p2p operations in caller context
staging: wilc1000: fix error path cleanup in wilc_wlan_initialize()
staging: wilc1000: added support to dynamically add/remove interfaces
staging: wilc1000: remove use of driver_handler_id & ifc_id
staging: wilc1000: remove unnecessary loop to traverse vif interfaces
staging: wilc1000: remove use of 'src_addr' element in 'wilc_vif' struct
staging: wilc1000: remove extra argument passing to wilc_send_config_pkt()
staging: wilc1000: rename 'host_interface' source and header
Alexander Dahl (1):
staging: rtl8188eu: Add 'rtl8188eufw.bin' to MODULE_FIRMWARE list
Alexandru Ardelean (11):
dt-bindings: iio: accel: adxl345: switch to YAML bindings
staging: iio: ad2s1210: Remove platform data NULL check in probe
iio: adxl372: fix iio_triggered_buffer_{pre,post}enable positions
iio: amplifiers: update license information
iio: amplifiers: ad8366: use own lock to guard state
iio: amplifiers: ad8366: rework driver to allow other chips
iio: amplifiers: ad8366: Add support for ADL5240 VGA
iio: ad_sigma_delta: return directly in ad_sd_buffer_postenable()
iio: st_accel: fix iio_triggered_buffer_{pre,post}enable positions
iio: adis162xx: fix low-power docs & reports
MAINTAINERS: add ADIS IMU driver library entry
Arnd Bergmann (1):
staging: rtl8712: reduce stack usage, again
Bastien Nocera (2):
staging: rtl8723bs: Remove myself from CC:
iio: iio-utils: Fix possible incorrect mask calculation
Beniamin Bia (2):
iio: adc: ad7606: Move oversampling and scale options to chip info
iio: adc: ad7606: Add software configuration
Benjamin Sherman (1):
staging: mt7621-dma: sizeof via pointer dereference
Brian Masney (3):
dt-bindings: iio: tsl2583: convert bindings to YAML format
dt-bindings: iio: tsl2772: convert bindings to YAML format
dt-bindings: iio: isl29018: convert bindings to YAML format
Bárbara Fernandes (2):
staging: iio: cdc: ad7150: create macro for capacitance channels
staging: iio: adt7316: create of_device_id array
Christian Gromm (3):
staging: most: register net and video config subsystems with configFS
staging: most: deregister net and video config subsystems with configFS
staging: most: remove data sanity check
Christian Müller (2):
drivers/staging/rtl8192u: drop first comment line
drivers/staging/rtl8192u: style nonstyled comments
Christopher Bostic (1):
iio: dps310: Temperature measurement errata
Chun-Hung Wu (2):
dt-bindings: iio: adc: mediatek: Add document for mt6765
iio: adc: mediatek: mt6577-auxadc, add mt6765 support
Colin Ian King (11):
staging: vc04_services: bcm2835-camera: remove redundant assignment to
variable ret
staging: wilc1000: remove redundant masking of pkt_offset
staging: vc04_services: remove redundant assignment to pointer service
staging: fsl-dpaa2/ethsw: fix memory leak of switchdev_work
staging: comedi: usbdux: remove redundant initialization of fx2delay
staging: erofs: clean up initialization of pointer de
staging: vt6656: fix indentation on break statement
staging: kpc2000: fix integer overflow with left shifts
staging: rtl8723bs: os_dep: fix indentation on break statement
staging: rtl8192e: remove redundant initialization of rtstatus
staging: rtl8723bs: hal: remove redundant assignment to packetType
Dan Carpenter (1):
iio: sca3000: Potential endian bug in sca3000_read_event_value()
Daniel Gomez (4):
iio: temperature: maxim_thermocouple: declare missing of table
iio: accel: kxsd9: declare missing of table
iio: adxl372: declare missing of table
iio: dac: ad5758: declare missing of table
Dave Stevenson (29):
staging: bcm2
Re: [PATCH 00/12] treewide: Fix GENMASK misuses
On Wed, 2019-07-10 at 10:43 +0100, Russell King - ARM Linux admin wrote: > On Wed, Jul 10, 2019 at 11:17:31AM +0200, Johannes Berg wrote: > > On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote: > > > These GENMASK uses are inverted argument order and the > > > actual masks produced are incorrect. Fix them. > > > > > > Add checkpatch tests to help avoid more misuses too. > > > > > > Joe Perches (12): > > > checkpatch: Add GENMASK tests > > > > IMHO this doesn't make a lot of sense as a checkpatch test - just throw > > in a BUILD_BUG_ON()? I tried that. It'd can't be done as it's used in declarations and included in asm files and it uses the UL() macro. I also tried just making it do the right thing whatever the argument order. Oh well. > My personal take on this is that GENMASK() is really not useful, it's > just pure obfuscation and leads to exactly these kinds of mistakes. > > Yes, I fully understand the argument that you can just specify the > start and end bits, and it _in theory_ makes the code more readable. > > However, the problem is when writing code. GENMASK(a, b). Is a the > starting bit or ending bit? Is b the number of bits? It's confusing > and causes mistakes resulting in incorrect code. A BUILD_BUG_ON() > can catch some of the cases, but not all of them. It's a horrid little macro and I agree with Russell. I also think if it existed at all it should have been GENMASK(low, high) not GENMASK(high, low). I ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: greybus: add logging statement when kfifo_alloc fails
Added missing logging statement when kfifo_alloc fails, to improve
debugging.
Signed-off-by: Keyur Patel
---
drivers/staging/greybus/uart.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
index b3bffe91ae99..86a395ae177d 100644
--- a/drivers/staging/greybus/uart.c
+++ b/drivers/staging/greybus/uart.c
@@ -856,8 +856,10 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
retval = kfifo_alloc(&gb_tty->write_fifo, GB_UART_WRITE_FIFO_SIZE,
GFP_KERNEL);
- if (retval)
+ if (retval) {
+ pr_err("kfifo_alloc failed\n");
goto exit_buf_free;
+ }
gb_tty->credits = GB_UART_FIRMWARE_CREDITS;
init_completion(&gb_tty->credits_complete);
--
2.22.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: add logging statement when kfifo_alloc fails
On Wed, Jul 10, 2019 at 08:20:17AM -0400, Keyur Patel wrote:
> Added missing logging statement when kfifo_alloc fails, to improve
> debugging.
>
> Signed-off-by: Keyur Patel
> ---
> drivers/staging/greybus/uart.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
> index b3bffe91ae99..86a395ae177d 100644
> --- a/drivers/staging/greybus/uart.c
> +++ b/drivers/staging/greybus/uart.c
> @@ -856,8 +856,10 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev,
>
> retval = kfifo_alloc(&gb_tty->write_fifo, GB_UART_WRITE_FIFO_SIZE,
>GFP_KERNEL);
> - if (retval)
> + if (retval) {
> + pr_err("kfifo_alloc failed\n");
> goto exit_buf_free;
> + }
You should have already gotten an error message from the log if this
fails, from the kmalloc_array() call failing, right?
So why is this needed? We have been trying to remove these types of
messages and keep them in the "root" place where the failure happens.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/12] treewide: Fix GENMASK misuses
On Wed, 2019-07-10 at 08:45 -0700, Joe Perches wrote: > On Wed, 2019-07-10 at 10:43 +0100, Russell King - ARM Linux admin wrote: > > On Wed, Jul 10, 2019 at 11:17:31AM +0200, Johannes Berg wrote: > > > On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote: > > > > These GENMASK uses are inverted argument order and the > > > > actual masks produced are incorrect. Fix them. > > > > > > > > Add checkpatch tests to help avoid more misuses too. > > > > > > > > Joe Perches (12): > > > > checkpatch: Add GENMASK tests > > > > > > IMHO this doesn't make a lot of sense as a checkpatch test - just throw > > > in a BUILD_BUG_ON()? > > I tried that. > > It'd can't be done as it's used in declarations > and included in asm files and it uses the UL() > macro. > > I also tried just making it do the right thing > whatever the argument order. I forgot. I also made all those arguments when it was introduced in 2013. https://lore.kernel.org/patchwork/patch/414248/ > Oh well. yeah. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: add logging statement when kfifo_alloc fails
On Wed, Jul 10, 2019 at 06:35:38PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 10, 2019 at 08:20:17AM -0400, Keyur Patel wrote:
> > Added missing logging statement when kfifo_alloc fails, to improve
> > debugging.
> >
> > Signed-off-by: Keyur Patel
> > ---
> > drivers/staging/greybus/uart.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
> > index b3bffe91ae99..86a395ae177d 100644
> > --- a/drivers/staging/greybus/uart.c
> > +++ b/drivers/staging/greybus/uart.c
> > @@ -856,8 +856,10 @@ static int gb_uart_probe(struct gbphy_device
> > *gbphy_dev,
> >
> > retval = kfifo_alloc(&gb_tty->write_fifo, GB_UART_WRITE_FIFO_SIZE,
> > GFP_KERNEL);
> > - if (retval)
> > + if (retval) {
> > + pr_err("kfifo_alloc failed\n");
> > goto exit_buf_free;
> > + }
>
> You should have already gotten an error message from the log if this
> fails, from the kmalloc_array() call failing, right?
>
> So why is this needed? We have been trying to remove these types of
> messages and keep them in the "root" place where the failure happens.
>
> thanks,
>
> greg k-h
Didn't notice that. I agree that this will result only into redundancy.
Quick look over files reveal that there are multiple places
where people are using print statements after memory allocation fails.
Should I go ahead and send patches to remove those
redundant print statements?
Sorry, if you're receiving this message again.
Thnaks.
Keyur Patel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: gasket: apex: fix copy-paste typo
In sysfs_show() case-branches ATTR_KERNEL_HIB_PAGE_TABLE_SIZE and ATTR_KERNEL_HIB_SIMPLE_PAGE_TABLE_SIZE do the same. It looks like copy-paste mistake. Signed-off-by: Ivan Bornyakov --- drivers/staging/gasket/apex_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/gasket/apex_driver.c b/drivers/staging/gasket/apex_driver.c index 2be45ee9d061..464648ee2036 100644 --- a/drivers/staging/gasket/apex_driver.c +++ b/drivers/staging/gasket/apex_driver.c @@ -532,7 +532,7 @@ static ssize_t sysfs_show(struct device *device, struct device_attribute *attr, break; case ATTR_KERNEL_HIB_SIMPLE_PAGE_TABLE_SIZE: ret = scnprintf(buf, PAGE_SIZE, "%u\n", - gasket_page_table_num_entries( + gasket_page_table_num_simple_entries( gasket_dev->page_table[0])); break; case ATTR_KERNEL_HIB_NUM_ACTIVE_PAGES: -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8723bs: hal: rtl8723bs_recv.c: Fix code style
On Mon, 2019-07-08 at 12:56 +0300, Fatih ALTINPINAR wrote:
> Fixed a coding stlye issue. Removed braces from a single statement if
> block.
>
> Signed-off-by: Fatih ALTINPINAR
> ---
> drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
> b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
> index e23b39ab16c5..71a4bcbeada9 100644
> --- a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
> +++ b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
> @@ -449,9 +449,8 @@ s32 rtl8723bs_init_recv_priv(struct adapter *padapter)
> skb_reserve(precvbuf->pskb, (RECVBUFF_ALIGN_SZ
> - alignment));
> }
>
> - if (!precvbuf->pskb) {
> + if (!precvbuf->pskb)
> DBG_871X("%s: alloc_skb fail!\n", __func__);
> - }
You could delete the block instead.
alloc_skb failures already do a dump_stack()
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] rtl8192*: display ESSIDs using %pE
From: "J. Bruce Fields" Everywhere else in the kernel ESSIDs are printed using %pE, and I can't see why there should be an exception here. Signed-off-by: J. Bruce Fields --- drivers/staging/rtl8192e/rtllib.h | 2 +- drivers/staging/rtl8192u/ieee80211/ieee80211.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8192e/rtllib.h b/drivers/staging/rtl8192e/rtllib.h index 2dd57e88276e..096254e422b3 100644 --- a/drivers/staging/rtl8192e/rtllib.h +++ b/drivers/staging/rtl8192e/rtllib.h @@ -2132,7 +2132,7 @@ static inline const char *escape_essid(const char *essid, u8 essid_len) return escaped; } - snprintf(escaped, sizeof(escaped), "%*pEn", essid_len, essid); + snprintf(escaped, sizeof(escaped), "%*pE", essid_len, essid); return escaped; } diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h index d36963469015..3963a08b9eb2 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h @@ -2426,7 +2426,7 @@ static inline const char *escape_essid(const char *essid, u8 essid_len) return escaped; } - snprintf(escaped, sizeof(escaped), "%*pEn", essid_len, essid); + snprintf(escaped, sizeof(escaped), "%*pE", essid_len, essid); return escaped; } -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wlan-ng: use "%*pE" for serial number
From: "J. Bruce Fields"
Almost every user of "%*pE" in the kernel uses just bare "%*pE". This
is the only user of "%pEhp". I can't see why it's needed.
Signed-off-by: J. Bruce Fields
---
drivers/staging/wlan-ng/prism2sta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/prism2sta.c
b/drivers/staging/wlan-ng/prism2sta.c
index fb5441399131..8f25496188aa 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -846,7 +846,7 @@ static int prism2sta_getcardinfo(struct wlandevice *wlandev)
result = hfa384x_drvr_getconfig(hw, HFA384x_RID_NICSERIALNUMBER,
snum, HFA384x_RID_NICSERIALNUMBER_LEN);
if (!result) {
- netdev_info(wlandev->netdev, "Prism2 card SN: %*pEhp\n",
+ netdev_info(wlandev->netdev, "Prism2 card SN: %*pE\n",
HFA384x_RID_NICSERIALNUMBER_LEN, snum);
} else {
netdev_err(wlandev->netdev, "Failed to retrieve Prism2 Card
SN\n");
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: BUG: Staging: fbtft: Switch to the gpio descriptor interface
On Wed, Jul 10, 2019 at 04:31:09PM +0800, Phil Reid wrote:
> G'day Nishad,
>
> I'm just wondering if the commit
> c440eee1a7a1d0f "Staging: fbtft: Switch to the gpio descriptor interface"
> was tested on anything.
>
> I've had to apply the following patch to get my display functioning again.
>
> in particular the devm_gpiod_get_index using dev->driver->name for the gpio
> lookup seems
> wrong.
>
> Also I've had to invert the polarity of the reset-gpios in the DT file for
> the display to function.
>
> this code:
> gpiod_set_value_cansleep(par->gpio.reset, 0);
> usleep_range(20, 40);
> gpiod_set_value_cansleep(par->gpio.reset, 1);
>
> could be read as deasserting the reset line and then asserting it.
> So I've had to specify and active high reset line in the DT.
>
> Regards
> Phil
>
Hello Phil,
This patch was only compiled successfully.
It hasn't been tested on any hardware.
Sorry for the mistake.
Thanks and regards,
Nishad
>
>
>
> diff --git a/drivers/staging/fbtft/fbtft-core.c
> b/drivers/staging/fbtft/fbtft-core.c
> index 9b07bad..6fe7cb5 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -79,18 +79,16 @@ static int fbtft_request_one_gpio(struct fbtft_par *par,
> struct device_node *node = dev->of_node;
> int ret = 0;
>
> - if (of_find_property(node, name, NULL)) {
> - *gpiop = devm_gpiod_get_index(dev, dev->driver->name, index,
> - GPIOD_OUT_HIGH);
> - if (IS_ERR(*gpiop)) {
> - ret = PTR_ERR(*gpiop);
> - dev_err(dev,
> - "Failed to request %s GPIO:%d\n", name, ret);
> - return ret;
> - }
> - fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
> - __func__, name);
> + *gpiop = devm_gpiod_get_index_optional(dev, name, index,
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(*gpiop)) {
> + ret = PTR_ERR(*gpiop);
> + dev_err(dev,
> + "Failed to request %s GPIO: (%d)\n", name, ret);
> + return ret;
> }
> + fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n",
> + __func__, name);
>
> return ret;
> }
> @@ -103,34 +101,34 @@ static int fbtft_request_gpios_dt(struct fbtft_par *par)
> if (!par->info->device->of_node)
> return -EINVAL;
>
> - ret = fbtft_request_one_gpio(par, "reset-gpios", 0, &par->gpio.reset);
> + ret = fbtft_request_one_gpio(par, "reset", 0, &par->gpio.reset);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "dc-gpios", 0, &par->gpio.dc);
> + ret = fbtft_request_one_gpio(par, "dc", 0, &par->gpio.dc);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "rd-gpios", 0, &par->gpio.rd);
> + ret = fbtft_request_one_gpio(par, "rd", 0, &par->gpio.rd);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "wr-gpios", 0, &par->gpio.wr);
> + ret = fbtft_request_one_gpio(par, "wr", 0, &par->gpio.wr);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "cs-gpios", 0, &par->gpio.cs);
> + ret = fbtft_request_one_gpio(par, "cs", 0, &par->gpio.cs);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "latch-gpios", 0, &par->gpio.latch);
> + ret = fbtft_request_one_gpio(par, "latch", 0, &par->gpio.latch);
> if (ret)
> return ret;
> for (i = 0; i < 16; i++) {
> - ret = fbtft_request_one_gpio(par, "db-gpios", i,
> + ret = fbtft_request_one_gpio(par, "db", i,
>&par->gpio.db[i]);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "led-gpios", i,
> + ret = fbtft_request_one_gpio(par, "led", i,
>&par->gpio.led[i]);
> if (ret)
> return ret;
> - ret = fbtft_request_one_gpio(par, "aux-gpios", i,
> + ret = fbtft_request_one_gpio(par, "aux", i,
>&par->gpio.aux[i]);
> if (ret)
> return ret;
>
>
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
