[PATCH] staging: rtl8723bs: Fix the return value in case of error in 'rtw_wx_read32()'

2018-10-17 Thread Christophe JAILLET 
We return 0 unconditionally in 'rtw_wx_read32()'.
However, 'ret' is set to some error codes in several error handling paths.

Return 'ret' instead to propagate the error code.

Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver")
Signed-off-by: Christophe JAILLET 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index 28bfdbdc6e76..b8631baf128d 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -2289,7 +2289,7 @@ static int rtw_wx_read32(struct net_device *dev,
 exit:
kfree(ptmp);
 
-   return 0;
+   return ret;
 }
 
 static int rtw_wx_write32(struct net_device *dev,
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3] staging: nrf24: add new driver for 2.4GHz radio transceiver

2018-10-17 Thread Marcin Ciupak 
This patch adds driver for Nordic Semiconductor nRF24L01+ radio
transceiver.

Signed-off-by: Marcin Ciupak 
---
Changes in v2:
  - add terminating newlines to all logging formats
Changes in v3:
  - patch subject
  - comments cleanup
  - goto labels cleanup
  - scnprintf bugfix
  - ida_simple_remove bugfix

 drivers/staging/Kconfig   |   2 +
 drivers/staging/Makefile  |   1 +
 drivers/staging/nrf24/Kconfig |  16 +
 drivers/staging/nrf24/Makefile|   3 +
 drivers/staging/nrf24/TODO|   7 +
 .../nrf24/devicetree/nrf24-spi0-overlay.dts   |  54 ++
 .../nrf24/devicetree/nrf24-spi1-overlay.dts   |  54 ++
 drivers/staging/nrf24/devicetree/nrf24.txt|   1 +
 drivers/staging/nrf24/nRF24L01.h  |  82 ++
 drivers/staging/nrf24/nrf24_enums.h   |  60 ++
 drivers/staging/nrf24/nrf24_hal.c | 764 +++
 drivers/staging/nrf24/nrf24_hal.h |  54 ++
 drivers/staging/nrf24/nrf24_if.c  | 893 ++
 drivers/staging/nrf24/nrf24_if.h  |  63 ++
 drivers/staging/nrf24/nrf24_sysfs.c   | 707 ++
 drivers/staging/nrf24/nrf24_sysfs.h   |  14 +
 16 files changed, 2775 insertions(+)
 create mode 100644 drivers/staging/nrf24/Kconfig
 create mode 100644 drivers/staging/nrf24/Makefile
 create mode 100644 drivers/staging/nrf24/TODO
 create mode 100644 drivers/staging/nrf24/devicetree/nrf24-spi0-overlay.dts
 create mode 100644 drivers/staging/nrf24/devicetree/nrf24-spi1-overlay.dts
 create mode 100644 drivers/staging/nrf24/devicetree/nrf24.txt
 create mode 100644 drivers/staging/nrf24/nRF24L01.h
 create mode 100644 drivers/staging/nrf24/nrf24_enums.h
 create mode 100644 drivers/staging/nrf24/nrf24_hal.c
 create mode 100644 drivers/staging/nrf24/nrf24_hal.h
 create mode 100644 drivers/staging/nrf24/nrf24_if.c
 create mode 100644 drivers/staging/nrf24/nrf24_if.h
 create mode 100644 drivers/staging/nrf24/nrf24_sysfs.c
 create mode 100644 drivers/staging/nrf24/nrf24_sysfs.h

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 1abf76be2aa8..55d688f3112e 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -126,4 +126,6 @@ source "drivers/staging/axis-fifo/Kconfig"
 
 source "drivers/staging/erofs/Kconfig"
 
+source "drivers/staging/nrf24/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index ab0cbe8815b1..c18e74df03af 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_SOC_MT7621)  += mt7621-dts/
 obj-$(CONFIG_STAGING_GASKET_FRAMEWORK) += gasket/
 obj-$(CONFIG_XIL_AXIS_FIFO)+= axis-fifo/
 obj-$(CONFIG_EROFS_FS) += erofs/
+obj-$(CONFIG_NRF24)+= nrf24/
diff --git a/drivers/staging/nrf24/Kconfig b/drivers/staging/nrf24/Kconfig
new file mode 100644
index ..67ebf14dd982
--- /dev/null
+++ b/drivers/staging/nrf24/Kconfig
@@ -0,0 +1,16 @@
+config NRF24
+tristate "nRF24L01+ 2.4GHz radio module support"
+depends on SPI
+help
+  This enables support for Nordic Semiconductor nRF24L01+ radio module,
+  with the following features:
+- multiple radio module instances via nrfX
+- dedicated /dev/nrfX.Y device per pipe per instance
+- dynamic and static payload lengths
+- configuration via sysfs (/sys/class/nrfX)
+- poll mechanism
+- 64kB RX FIFO per pipe
+- 64kB TX FIFO
+
+  To compile this driver as a module, choose M here: the module will be
+  called nrf24.
diff --git a/drivers/staging/nrf24/Makefile b/drivers/staging/nrf24/Makefile
new file mode 100644
index ..f5222567c632
--- /dev/null
+++ b/drivers/staging/nrf24/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_NRF24) += nrf24.o
+
+nrf24-objs := nrf24_if.o nrf24_hal.o nrf24_sysfs.o
diff --git a/drivers/staging/nrf24/TODO b/drivers/staging/nrf24/TODO
new file mode 100644
index ..a089e43faac5
--- /dev/null
+++ b/drivers/staging/nrf24/TODO
@@ -0,0 +1,7 @@
+Todo:
+- opening and closing pipes via sysfs
+- improve switching in between RX and TX
+- improve handling of MAX_RT interrupt
+- find and fix bugs
+- code cleanup
+
diff --git a/drivers/staging/nrf24/devicetree/nrf24-spi0-overlay.dts 
b/drivers/staging/nrf24/devicetree/nrf24-spi0-overlay.dts
new file mode 100644
index ..130e6787b76d
--- /dev/null
+++ b/drivers/staging/nrf24/devicetree/nrf24-spi0-overlay.dts
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//
+// Copyright (C) 2017 Marcin Ciupak 
+//
+
+// Definitions for NRF24
+/dts-v1/;
+/plugin/;
+
+/ {
+   compatible = "bcm,bcm2835", "bcm,bcm2708", "bcm,bcm2709";
+
+   fragment@0 {
+   target = <&spi0>;
+   __overlay__ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   statu

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

2018-10-17 Thread Dave Stevenson 
On Mon, 15 Oct 2018 at 17:27, Eric Anholt  wrote:
>
> Stefan Wahren  writes:
>
> > Hi Tuomas,
> >
> >> Tuomas Tynkkynen  hat am 4. Oktober 2018 um 11:37 
> >> geschrieben:
> >>
> >>
> >> Drop various pieces of dead code from here and there to get rid of
> >> the remaining users of VCHI_CONNECTION_T. After that we get to drop
> >> entire header files worth of unused code.
> >>
> >> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
> >> snd-bcm2835 can still play analog audio just fine.
> >>
> >
> > thanks and i'm fine with your patch series:
> >
> > Acked-by: Stefan Wahren 
> >
> > Unfortunately this would break compilation of the downstream vchi
> > drivers like vcsm [1]. Personally i don't want to maintain another
> > one, because i cannot see the gain of the resulting effort.
> >
> > [1] - 
> > https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm

I'm happy enough to work around these changes. Once the change is in a
released kernel we can merge a modified version of vc_sm into the
downstream kernel branch. It's not as if it requires big changes.

> I think the main concern would be if we removed things necessary for
> 6by9's new vcsm (the one that will let us do dma-buf sharing between
> media decode and DRM).

The new vcsm uses the same VCHI service as the existing downstream vc_sm driver.
The video codec driver don't use any VCHI functionality over and above
the camera. It goes via a slightly extended version of the
mmal-vchiq.c, which I have split out into a shared module.

> On the other hand, git revert is a thing, so it's not like we actually
> lose anything.

:-)

  Dave
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

2018-10-17 Thread Dan Carpenter 
On Sat, Oct 06, 2018 at 12:18:38PM +0200, Stefan Wahren wrote:
> Hi Tuomas,
> 
> > Tuomas Tynkkynen  hat am 4. Oktober 2018 um 11:37 
> > geschrieben:
> > 
> > 
> > Drop various pieces of dead code from here and there to get rid of
> > the remaining users of VCHI_CONNECTION_T. After that we get to drop
> > entire header files worth of unused code.
> > 
> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
> > snd-bcm2835 can still play analog audio just fine.
> > 
> 
> thanks and i'm fine with your patch series:
> 
> Acked-by: Stefan Wahren 
> 
> Unfortunately this would break compilation of the downstream vchi
> drivers like vcsm [1]. Personally i don't want to maintain another
> one, because i cannot see the gain of the resulting effort.
> 
> [1] - 
> https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm


I feel like everyone else already knows the answer but why don't we just
merge that code into staging?

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

2018-10-17 Thread Stefan Wahren 
Hi,

Am 17.10.2018 um 11:55 schrieb Dave Stevenson:
> On Mon, 15 Oct 2018 at 17:27, Eric Anholt  wrote:
>> Stefan Wahren  writes:
>>
>>> Hi Tuomas,
>>>
 Tuomas Tynkkynen  hat am 4. Oktober 2018 um 11:37 
 geschrieben:


 Drop various pieces of dead code from here and there to get rid of
 the remaining users of VCHI_CONNECTION_T. After that we get to drop
 entire header files worth of unused code.

 I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
 snd-bcm2835 can still play analog audio just fine.

>>> thanks and i'm fine with your patch series:
>>>
>>> Acked-by: Stefan Wahren 
>>>
>>> Unfortunately this would break compilation of the downstream vchi
>>> drivers like vcsm [1]. Personally i don't want to maintain another
>>> one, because i cannot see the gain of the resulting effort.
>>>
>>> [1] - 
>>> https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm
> I'm happy enough to work around these changes. Once the change is in a
> released kernel we can merge a modified version of vc_sm into the
> downstream kernel branch. It's not as if it requires big changes.
>
>> I think the main concern would be if we removed things necessary for
>> 6by9's new vcsm (the one that will let us do dma-buf sharing between
>> media decode and DRM).
> The new vcsm uses the same VCHI service as the existing downstream vc_sm 
> driver.
> The video codec driver don't use any VCHI functionality over and above
> the camera. It goes via a slightly extended version of the
> mmal-vchiq.c, which I have split out into a shared module.

my statement about the old vc_sm based on assumption there wont be a
user of this driver.

In case the camera driver would use the new vc_sm driver, i would be
happier to see this merged in staging than in downstream.

Stefan

>
>> On the other hand, git revert is a thing, so it's not like we actually
>> lose anything.
> :-)
>
>   Dave

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: iio: ad7816: Switch to the gpio descriptor interface

2018-10-17 Thread Nishad Kamdar 
On Tue, Oct 16, 2018 at 05:10:14PM +0200, Lars-Peter Clausen wrote:
> On 10/16/2018 04:46 PM, Nishad Kamdar wrote:
> > Use the gpiod interface for rdwr_pin, convert_pin and busy_pin
> > instead of the deprecated old non-descriptor interface.
> > 
> > Signed-off-by: Nishad Kamdar 
> 
> Hi,
> 
> Thanks for the patch, this looks good.
> 
> One thing about the error messages though.
> 
> > +   chip->rdwr_pin = devm_gpiod_get(&spi_dev->dev, "rdwr", GPIOD_IN);
> > +   if (IS_ERR(chip->rdwr_pin)) {
> > +   ret = PTR_ERR(chip->rdwr_pin);
> > dev_err(&spi_dev->dev, "Fail to request rdwr gpio PIN %d.\n",
> > -   chip->rdwr_pin);
> > +   ret);
> 
> This previously showed the pin number which has now been replaced with the
> error code. The message doesn't make that much sense semantically anymore.
> Maybe replace it with something like
> 
>   "Failed to request rdwr GPIO: %d\n", ret
> 
> > return ret;

Hello,

Ok, I'll do that.

Thanks for the review.

regards,
Nishad
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: iio: ad7816: Switch to the gpio descriptor interface

2018-10-17 Thread Nishad Kamdar 
Use the gpiod interface for rdwr_pin, convert_pin and busy_pin
instead of the deprecated old non-descriptor interface.

Signed-off-by: Nishad Kamdar 
---
Changes in v2:
 - Correct the error messages as pin number being showed
   has now been replaced by error code.
---
 drivers/staging/iio/adc/ad7816.c | 80 ++--
 1 file changed, 34 insertions(+), 46 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index bf76a8620bdb..12c4e0ab4713 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -7,7 +7,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -44,9 +44,9 @@
 
 struct ad7816_chip_info {
struct spi_device *spi_dev;
-   u16 rdwr_pin;
-   u16 convert_pin;
-   u16 busy_pin;
+   struct gpio_desc *rdwr_pin;
+   struct gpio_desc *convert_pin;
+   struct gpio_desc *busy_pin;
u8  oti_data[AD7816_CS_MAX + 1];
u8  channel_id; /* 0 always be temperature */
u8  mode;
@@ -61,28 +61,28 @@ static int ad7816_spi_read(struct ad7816_chip_info *chip, 
u16 *data)
int ret = 0;
__be16 buf;
 
-   gpio_set_value(chip->rdwr_pin, 1);
-   gpio_set_value(chip->rdwr_pin, 0);
+   gpiod_set_value(chip->rdwr_pin, 1);
+   gpiod_set_value(chip->rdwr_pin, 0);
ret = spi_write(spi_dev, &chip->channel_id, sizeof(chip->channel_id));
if (ret < 0) {
dev_err(&spi_dev->dev, "SPI channel setting error\n");
return ret;
}
-   gpio_set_value(chip->rdwr_pin, 1);
+   gpiod_set_value(chip->rdwr_pin, 1);
 
if (chip->mode == AD7816_PD) { /* operating mode 2 */
-   gpio_set_value(chip->convert_pin, 1);
-   gpio_set_value(chip->convert_pin, 0);
+   gpiod_set_value(chip->convert_pin, 1);
+   gpiod_set_value(chip->convert_pin, 0);
} else { /* operating mode 1 */
-   gpio_set_value(chip->convert_pin, 0);
-   gpio_set_value(chip->convert_pin, 1);
+   gpiod_set_value(chip->convert_pin, 0);
+   gpiod_set_value(chip->convert_pin, 1);
}
 
-   while (gpio_get_value(chip->busy_pin))
+   while (gpiod_get_value(chip->busy_pin))
cpu_relax();
 
-   gpio_set_value(chip->rdwr_pin, 0);
-   gpio_set_value(chip->rdwr_pin, 1);
+   gpiod_set_value(chip->rdwr_pin, 0);
+   gpiod_set_value(chip->rdwr_pin, 1);
ret = spi_read(spi_dev, &buf, sizeof(*data));
if (ret < 0) {
dev_err(&spi_dev->dev, "SPI data read error\n");
@@ -99,8 +99,8 @@ static int ad7816_spi_write(struct ad7816_chip_info *chip, u8 
data)
struct spi_device *spi_dev = chip->spi_dev;
int ret = 0;
 
-   gpio_set_value(chip->rdwr_pin, 1);
-   gpio_set_value(chip->rdwr_pin, 0);
+   gpiod_set_value(chip->rdwr_pin, 1);
+   gpiod_set_value(chip->rdwr_pin, 0);
ret = spi_write(spi_dev, &data, sizeof(data));
if (ret < 0)
dev_err(&spi_dev->dev, "SPI oti data write error\n");
@@ -129,10 +129,10 @@ static ssize_t ad7816_store_mode(struct device *dev,
struct ad7816_chip_info *chip = iio_priv(indio_dev);
 
if (strcmp(buf, "full")) {
-   gpio_set_value(chip->rdwr_pin, 1);
+   gpiod_set_value(chip->rdwr_pin, 1);
chip->mode = AD7816_FULL;
} else {
-   gpio_set_value(chip->rdwr_pin, 0);
+   gpiod_set_value(chip->rdwr_pin, 0);
chip->mode = AD7816_PD;
}
 
@@ -345,15 +345,9 @@ static int ad7816_probe(struct spi_device *spi_dev)
 {
struct ad7816_chip_info *chip;
struct iio_dev *indio_dev;
-   unsigned short *pins = dev_get_platdata(&spi_dev->dev);
int ret = 0;
int i;
 
-   if (!pins) {
-   dev_err(&spi_dev->dev, "No necessary GPIO platform data.\n");
-   return -EINVAL;
-   }
-
indio_dev = devm_iio_device_alloc(&spi_dev->dev, sizeof(*chip));
if (!indio_dev)
return -ENOMEM;
@@ -364,34 +358,28 @@ static int ad7816_probe(struct spi_device *spi_dev)
chip->spi_dev = spi_dev;
for (i = 0; i <= AD7816_CS_MAX; i++)
chip->oti_data[i] = 203;
-   chip->rdwr_pin = pins[0];
-   chip->convert_pin = pins[1];
-   chip->busy_pin = pins[2];
-
-   ret = devm_gpio_request(&spi_dev->dev, chip->rdwr_pin,
-   spi_get_device_id(spi_dev)->name);
-   if (ret) {
-   dev_err(&spi_dev->dev, "Fail to request rdwr gpio PIN %d.\n",
-   chip->rdwr_pin);
+
+   chip->rdwr_pin = devm_gpiod_get(&spi_dev->dev, "rdwr", GPIOD_IN);
+   if (IS_ERR(chip->rdwr_pin)) {
+   ret = PTR_ERR(chip->rdwr_pin);
+   dev_err(&spi_dev->dev, "Failed to request rdwr GPIO: %d\n",
+   ret);

Re: [PATCH v2] staging: iio: ad7816: Switch to the gpio descriptor interface

2018-10-17 Thread Lars-Peter Clausen 
On 10/17/2018 04:47 PM, Nishad Kamdar wrote:
> Use the gpiod interface for rdwr_pin, convert_pin and busy_pin
> instead of the deprecated old non-descriptor interface.
> 
> Signed-off-by: Nishad Kamdar 

Acked-by: Lars-Peter Clausen 

Thanks.

> ---
> Changes in v2:
>  - Correct the error messages as pin number being showed
>has now been replaced by error code.
> ---
>  drivers/staging/iio/adc/ad7816.c | 80 ++--
>  1 file changed, 34 insertions(+), 46 deletions(-)
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

For your photos 29

2018-10-17 Thread Jenny 

We provide photoshop services to some of the companies from around the
world.

Some online stores use our services for retouching portraits, jewelry,
apparels, furnitures etc.

Here are the details of what we provide:
Clipping path for photos
Deep etching  for photos
Image masking  for photos
Portrait retouching  for photos
Jewelry retouching  for photos
Fashion retouching  for photos

Please reply back for further info.
We can provide testing for your photos if needed.

Thanks,
Jenny

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: iio: ad7816: Switch to the gpio descriptor interface

2018-10-17 Thread Sasha Levin 

On Wed, Oct 17, 2018 at 08:17:20PM +0530, Nishad Kamdar wrote:

+   chip->rdwr_pin = devm_gpiod_get(&spi_dev->dev, "rdwr", GPIOD_IN);
+   if (IS_ERR(chip->rdwr_pin)) {
+   ret = PTR_ERR(chip->rdwr_pin);
+   dev_err(&spi_dev->dev, "Failed to request rdwr GPIO: %d\n",
+   ret);
return ret;
}
-   gpio_direction_input(chip->rdwr_pin);
-   ret = devm_gpio_request(&spi_dev->dev, chip->convert_pin,
-   spi_get_device_id(spi_dev)->name);
-   if (ret) {
-   dev_err(&spi_dev->dev, "Fail to request convert gpio PIN %d.\n",
-   chip->convert_pin);
+   chip->convert_pin = devm_gpiod_get(&spi_dev->dev, "convert", GPIOD_IN);
+   if (IS_ERR(chip->convert_pin)) {
+   ret = PTR_ERR(chip->convert_pin);
+   dev_err(&spi_dev->dev, "Failed to request convert GPIO: %d\n",
+   ret);
return ret;
}
-   gpio_direction_input(chip->convert_pin);
-   ret = devm_gpio_request(&spi_dev->dev, chip->busy_pin,
-   spi_get_device_id(spi_dev)->name);
-   if (ret) {
-   dev_err(&spi_dev->dev, "Fail to request busy gpio PIN %d.\n",
-   chip->busy_pin);
+   chip->busy_pin = devm_gpiod_get(&spi_dev->dev, "busy", GPIOD_IN);
+   if (IS_ERR(chip->busy_pin)) {
+   ret = PTR_ERR(chip->busy_pin);
+   dev_err(&spi_dev->dev, "Failed to request busy GPIO: %d\n",
+   ret);
return ret;
}


Hm, from what I can tell devm_gpio_request() is allocating some memory,
which makes this a series of 4 allocations.

What happens if the fourth allocation fails? Do we leak the first three?

--
Thanks,
Sasha
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

2018-10-17 Thread Eric Anholt 
Dan Carpenter  writes:

> On Sat, Oct 06, 2018 at 12:18:38PM +0200, Stefan Wahren wrote:
>> Hi Tuomas,
>> 
>> > Tuomas Tynkkynen  hat am 4. Oktober 2018 um 11:37 
>> > geschrieben:
>> > 
>> > 
>> > Drop various pieces of dead code from here and there to get rid of
>> > the remaining users of VCHI_CONNECTION_T. After that we get to drop
>> > entire header files worth of unused code.
>> > 
>> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
>> > snd-bcm2835 can still play analog audio just fine.
>> > 
>> 
>> thanks and i'm fine with your patch series:
>> 
>> Acked-by: Stefan Wahren 
>> 
>> Unfortunately this would break compilation of the downstream vchi
>> drivers like vcsm [1]. Personally i don't want to maintain another
>> one, because i cannot see the gain of the resulting effort.
>> 
>> [1] - 
>> https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm
>
>
> I feel like everyone else already knows the answer but why don't we just
> merge that code into staging?

Dave's been working on a new VCSM service where the firmware can call
back into Linux to allocate (instead of just having a permanent carveout
of system memory that the firmware allocates from), and lets us make
dma-bufs out of those buffers.  That driver makes a no-copies v4l2 media
decode driver possible, which would then let Kodi and similar projects
switch from downstream kernels with closed graphics to upstream kernels
with open graphics.

Given that the new VCSM service is a rewrite, it's not clear to me that
importing the old VCSM driver is a win.  But maybe we should go raid
https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab
the new drivers.  Upstreaming the VCHI audio driver to staging has
clearly been a win for it, so maybe other eyes on the new v4l2 codec
could help Dave along in stabilizing it.


signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging iio/adc: fixes parenthesis alignment

2018-10-17 Thread Shreeya Patel 
On Tue, 2018-10-16 at 13:01 -0300, Marcelo Schmitt wrote:
> Fixes close parenthesis alignment to match open parenthesis at
> iio/drivers/staging/iio/adc/ad7606.c line 379.
> 
> Signed-of-by: Marcelo Schmitt 

Hi Marcelo,

Some suggestions from my side

1) Your subject line should look like "Staging: iio: adc:" instead of
"Staging iio/adc:"
This is the pattern that everyone in the Linux Kernel community has to
follow for having consistency around.

2) Your subject line and commit message should be in the imperative
form.

For example :-
Staging: iio: adc: Match alignment with open parenthesis

Similar should be the case for commit message.

3) Try to avoid the word 'fix' as it becomes an easy way for
people to avoid explanation for the patch.
Try giving more information about what you are doing and why are you
doing that.

You can have a look here
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/comm
it/?id=efd44cf468fe7e7ff9150dc52879426e0d0801eb

Bdw, good try if it's your first patch :)

Thanks

> ---
>  drivers/staging/iio/adc/ad7606.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/adc/ad7606.c
> b/drivers/staging/iio/adc/ad7606.c
> index 0b728b6ea135..230faae38c12 100644
> --- a/drivers/staging/iio/adc/ad7606.c
> +++ b/drivers/staging/iio/adc/ad7606.c
> @@ -376,7 +376,7 @@ static int ad7606_request_gpios(struct
> ad7606_state *st)
>   return 0;
>  
>   st->gpio_os = devm_gpiod_get_array_optional(dev,
> "oversampling-ratio",
> - GPIOD_OUT_LOW);
> + GPIOD_OUT_LOW);
>   return PTR_ERR_OR_ZERO(st->gpio_os);
>  }
>  
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] ANDROID: binder: Add BINDER_GET_NODE_INFO_FOR_REF ioctl.

2018-10-17 Thread Todd Kjos 
On Fri, Sep 7, 2018 at 6:38 AM Martijn Coenen  wrote:
>
> This allows the context manager to retrieve information about nodes
> that it holds a reference to, such as the current number of
> references to those nodes.
>
> Such information can for example be used to determine whether the
> servicemanager is the only process holding a reference to a node.
> This information can then be passed on to the process holding the
> node, which can in turn decide whether it wants to shut down to
> reduce resource usage.
>
> Signed-off-by: Martijn Coenen 
> ---
> v2: made sure reserved fields are aligned, and enforce caller zeroes
> all fields except handle, as suggested by Dan Carpenter.
>
>  drivers/android/binder.c| 55 +
>  include/uapi/linux/android/binder.h | 10 ++
>  2 files changed, 65 insertions(+)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index d58763b6b0090..5b25412e15ccf 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -4544,6 +4544,42 @@ static int binder_ioctl_set_ctx_mgr(struct file *filp)
> return ret;
>  }
>
> +static int binder_ioctl_get_node_info_for_ref(struct binder_proc *proc,
> +   struct binder_node_info_for_ref *info)
> +{
> +   struct binder_node *node;
> +   struct binder_context *context = proc->context;
> +   __u32 handle = info->handle;
> +
> +   if (info->strong_count || info->weak_count || info->reserved1 ||
> +   info->reserved2 || info->reserved3) {
> +   binder_user_error("%d BINDER_GET_NODE_INFO_FOR_REF: only 
> handle may be non-zero.",
> + proc->pid);
> +   return -EINVAL;
> +   }
> +
> +   /* This ioctl may only be used by the context manager */
> +   mutex_lock(&context->context_mgr_node_lock);
> +   if (!context->binder_context_mgr_node ||
> +   context->binder_context_mgr_node->proc != proc) {
> +   mutex_unlock(&context->context_mgr_node_lock);
> +   return -EPERM;
> +   }
> +   mutex_unlock(&context->context_mgr_node_lock);
> +
> +   node = binder_get_node_from_ref(proc, handle, true, NULL);
> +   if (!node)
> +   return -EINVAL;
> +
> +   info->strong_count = node->local_strong_refs +
> +   node->internal_strong_refs;
> +   info->weak_count = node->local_weak_refs;

Aren't we under-reporting the weak refs here? The "internal weak" refs
are the count of elements in node->refs, so we need to add something
like:

hlist_for_each_entry(ref, &node->refs, node_entry)
info->weak_count++;

> +
> +   binder_put_node(node);
> +
> +   return 0;
> +}
> +
>  static int binder_ioctl_get_node_debug_info(struct binder_proc *proc,
> struct binder_node_debug_info *info)
>  {
> @@ -4638,6 +4674,25 @@ static long binder_ioctl(struct file *filp, unsigned 
> int cmd, unsigned long arg)
> }
> break;
> }
> +   case BINDER_GET_NODE_INFO_FOR_REF: {
> +   struct binder_node_info_for_ref info;
> +
> +   if (copy_from_user(&info, ubuf, sizeof(info))) {
> +   ret = -EFAULT;
> +   goto err;
> +   }
> +
> +   ret = binder_ioctl_get_node_info_for_ref(proc, &info);
> +   if (ret < 0)
> +   goto err;
> +
> +   if (copy_to_user(ubuf, &info, sizeof(info))) {
> +   ret = -EFAULT;
> +   goto err;
> +   }
> +
> +   break;
> +   }
> case BINDER_GET_NODE_DEBUG_INFO: {
> struct binder_node_debug_info info;
>
> diff --git a/include/uapi/linux/android/binder.h 
> b/include/uapi/linux/android/binder.h
> index bfaec6903b8bc..b9ba520f7e4bb 100644
> --- a/include/uapi/linux/android/binder.h
> +++ b/include/uapi/linux/android/binder.h
> @@ -200,6 +200,15 @@ struct binder_node_debug_info {
> __u32has_weak_ref;
>  };
>
> +struct binder_node_info_for_ref {
> +   __u32handle;
> +   __u32strong_count;
> +   __u32weak_count;
> +   __u32reserved1;
> +   __u32reserved2;
> +   __u32reserved3;
> +};
> +
>  #define BINDER_WRITE_READ  _IOWR('b', 1, struct 
> binder_write_read)
>  #define BINDER_SET_IDLE_TIMEOUT_IOW('b', 3, __s64)
>  #define BINDER_SET_MAX_THREADS _IOW('b', 5, __u32)
> @@ -208,6 +217,7 @@ struct binder_node_debug_info {
>  #define BINDER_THREAD_EXIT _IOW('b', 8, __s32)
>  #define BINDER_VERSION _IOWR('b', 9, struct binder_version)
>  #define BINDER_GET_NODE_DEBUG_INFO _IOWR('b', 11, struct 
> binder_node_debug_info)
> +#define BINDER_GET_NODE_INFO_FOR_REF   _IOWR('b', 12, struct 
> binder_node_info_for_ref)
>
>  /*
>   * NOTE: Two

Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

2018-10-17 Thread Peter Robinson 
> >> > Drop various pieces of dead code from here and there to get rid of
> >> > the remaining users of VCHI_CONNECTION_T. After that we get to drop
> >> > entire header files worth of unused code.
> >> >
> >> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that
> >> > snd-bcm2835 can still play analog audio just fine.
> >> >
> >>
> >> thanks and i'm fine with your patch series:
> >>
> >> Acked-by: Stefan Wahren 
> >>
> >> Unfortunately this would break compilation of the downstream vchi
> >> drivers like vcsm [1]. Personally i don't want to maintain another
> >> one, because i cannot see the gain of the resulting effort.
> >>
> >> [1] - 
> >> https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm
> >
> >
> > I feel like everyone else already knows the answer but why don't we just
> > merge that code into staging?
>
> Dave's been working on a new VCSM service where the firmware can call
> back into Linux to allocate (instead of just having a permanent carveout
> of system memory that the firmware allocates from), and lets us make
> dma-bufs out of those buffers.  That driver makes a no-copies v4l2 media
> decode driver possible, which would then let Kodi and similar projects
> switch from downstream kernels with closed graphics to upstream kernels
> with open graphics.
>
> Given that the new VCSM service is a rewrite, it's not clear to me that
> importing the old VCSM driver is a win.  But maybe we should go raid
> https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab
> the new drivers.  Upstreaming the VCHI audio driver to staging has
> clearly been a win for it, so maybe other eyes on the new v4l2 codec
> could help Dave along in stabilizing it.

I think that makes sense as long as the firmware side changes are in
place so it can actually be used.

Peter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-10-17 Thread Dexuan Cui 
> From: devel  On Behalf Of
> KY Srinivasan
> Sent: Tuesday, October 16, 2018 23:02
> > > --- a/drivers/hv/hv_kvp.c
> > > +++ b/drivers/hv/hv_kvp.c
> > > @@ -353,6 +353,9 @@ static void process_ib_ipinfo(void *in_msg, void
> > *out_msg, int op)
> > >
> > >   out->body.kvp_ip_val.dhcp_enabled = in-
> > >kvp_ip_val.dhcp_enabled;
> > >
> > > + __attribute__ ((fallthrough));
> >
> > The comment should be sufficient for this, right?  I haven't seen many
> > uses of this attribute before, how common is it?
> 
> Yes; a common should be sufficient.

You all are right. 
Right now, I realized the gcc warning can also be suppressed by a simple line
of comment:

/* fallthrough */

It looks gcc treats this comment specially. 

If I add something more in the comment, like
/* add fallthrough */
, the warning can not be suppressed. :-)

I'll do a new version for KY.

Thank you all!

-- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-10-17 Thread Dexuan Cui 
> From: devel  On Behalf Of
> Greg KH
> Sent: Tuesday, October 16, 2018 22:07
> > ...
> > +   case KVP_OP_GET:
> > +   message->body.kvp_get.data.key_size =
> > +   utf16s_to_utf8s(
> > +   (wchar_t *)in_msg->body.kvp_get.data.key,
> > +   in_msg->body.kvp_get.data.key_size,
> > +   UTF16_LITTLE_ENDIAN,
> > +   message->body.kvp_get.data.key,
> > +   HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1;
> 
> Worst indentation ever :(
> 
> Yeah, I know it follows the others above it, but you should reconsider
> it in the future...
> greg k-h

Agreed. We should consider improving this in future.

-- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 2/7] staging: bcm2835-audio: don't initialize memory twice

2018-10-17 Thread Nicolas Saenz Julienne 
The memory is being allocated with devres_alloc(), wich ultimately uses
__GFP_ZERO to call kmalloc. We don't need to zero the memory area again
in bcm2835-audio.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Takashi Iwai 
Acked-by: Stefan Wahren 
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
index 87d56ab1ffa0..0efae7068fef 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
@@ -39,8 +39,6 @@ static int bcm2835_devm_add_vchi_ctx(struct device *dev)
if (!vchi_ctx)
return -ENOMEM;
 
-   memset(vchi_ctx, 0, sizeof(*vchi_ctx));
-
ret = bcm2835_new_vchi_ctx(dev, vchi_ctx);
if (ret) {
devres_free(vchi_ctx);
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 1/7] staging: bcm2835-audio: unify FOURCC command definitions

2018-10-17 Thread Nicolas Saenz Julienne 
The device communicates with the audio core using FOURCC codes. The
driver was generating them using different macros/expressions. We now
use the same macro to create them and centralize all the definitions.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Takashi Iwai 
Acked-by: Stefan Wahren 
---
 .../vc04_services/bcm2835-audio/bcm2835-vchiq.c | 13 -
 .../bcm2835-audio/vc_vchi_audioserv_defs.h  |  4 +++-
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
index 781754f36da7..aca7008e1921 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
@@ -89,11 +89,6 @@ static int bcm2835_audio_send_simple(struct 
bcm2835_audio_instance *instance,
return bcm2835_audio_send_msg(instance, &m, wait);
 }
 
-static const u32 BCM2835_AUDIO_WRITE_COOKIE1 = ('B' << 24 | 'C' << 16 |
-   'M' << 8  | 'A');
-static const u32 BCM2835_AUDIO_WRITE_COOKIE2 = ('D' << 24 | 'A' << 16 |
-   'T' << 8  | 'A');
-
 static void audio_vchi_callback(void *param,
const VCHI_CALLBACK_REASON_T reason,
void *msg_handle)
@@ -112,8 +107,8 @@ static void audio_vchi_callback(void *param,
instance->result = m.u.result.success;
complete(&instance->msg_avail_comp);
} else if (m.type == VC_AUDIO_MSG_TYPE_COMPLETE) {
-   if (m.u.complete.cookie1 != BCM2835_AUDIO_WRITE_COOKIE1 ||
-   m.u.complete.cookie2 != BCM2835_AUDIO_WRITE_COOKIE2)
+   if (m.u.complete.cookie1 != VC_AUDIO_WRITE_COOKIE1 ||
+   m.u.complete.cookie2 != VC_AUDIO_WRITE_COOKIE2)
dev_err(instance->dev, "invalid cookie\n");
else
bcm2835_playback_fifo(instance->alsa_stream,
@@ -329,8 +324,8 @@ int bcm2835_audio_write(struct bcm2835_alsa_stream 
*alsa_stream,
.type = VC_AUDIO_MSG_TYPE_WRITE,
.u.write.count = size,
.u.write.max_packet = instance->max_packet,
-   .u.write.cookie1 = BCM2835_AUDIO_WRITE_COOKIE1,
-   .u.write.cookie2 = BCM2835_AUDIO_WRITE_COOKIE2,
+   .u.write.cookie1 = VC_AUDIO_WRITE_COOKIE1,
+   .u.write.cookie2 = VC_AUDIO_WRITE_COOKIE2,
};
unsigned int count;
int err, status;
diff --git 
a/drivers/staging/vc04_services/bcm2835-audio/vc_vchi_audioserv_defs.h 
b/drivers/staging/vc04_services/bcm2835-audio/vc_vchi_audioserv_defs.h
index 1a7f0884ac9c..dc62875cfdca 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/vc_vchi_audioserv_defs.h
+++ b/drivers/staging/vc04_services/bcm2835-audio/vc_vchi_audioserv_defs.h
@@ -7,8 +7,10 @@
 #define VC_AUDIOSERV_MIN_VER 1
 #define VC_AUDIOSERV_VER 2
 
-/* FourCC code used for VCHI connection */
+/* FourCC codes used for VCHI communication */
 #define VC_AUDIO_SERVER_NAME  MAKE_FOURCC("AUDS")
+#define VC_AUDIO_WRITE_COOKIE1 MAKE_FOURCC("BCMA")
+#define VC_AUDIO_WRITE_COOKIE2 MAKE_FOURCC("DATA")
 
 /*
  *  List of screens that are currently supported
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 3/7] staging: bcm2835-audio: reorder variable declarations & remove trivial comments

2018-10-17 Thread Nicolas Saenz Julienne 
When it comes to declaring variables it's preferred, when possible, to
use an inverted tree organization scheme.

Also, removes some comments that were useless.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Takashi Iwai 
Acked-by: Stefan Wahren 
---
 .../vc04_services/bcm2835-audio/bcm2835-pcm.c  | 10 ++
 .../vc04_services/bcm2835-audio/bcm2835-vchiq.c|  4 ++--
 .../staging/vc04_services/bcm2835-audio/bcm2835.c  | 14 +++---
 3 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
index e66da11af5cf..98b6977bdce7 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
@@ -164,14 +164,11 @@ static int snd_bcm2835_playback_spdif_open(struct 
snd_pcm_substream *substream)
return snd_bcm2835_playback_open_generic(substream, 1);
 }
 
-/* close callback */
 static int snd_bcm2835_playback_close(struct snd_pcm_substream *substream)
 {
-   /* the hardware-specific codes will be here */
-
-   struct bcm2835_chip *chip;
-   struct snd_pcm_runtime *runtime;
struct bcm2835_alsa_stream *alsa_stream;
+   struct snd_pcm_runtime *runtime;
+   struct bcm2835_chip *chip;
 
chip = snd_pcm_substream_chip(substream);
mutex_lock(&chip->audio_mutex);
@@ -195,20 +192,17 @@ static int snd_bcm2835_playback_close(struct 
snd_pcm_substream *substream)
return 0;
 }
 
-/* hw_params callback */
 static int snd_bcm2835_pcm_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
 {
return snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params));
 }
 
-/* hw_free callback */
 static int snd_bcm2835_pcm_hw_free(struct snd_pcm_substream *substream)
 {
return snd_pcm_lib_free_pages(substream);
 }
 
-/* prepare callback */
 static int snd_bcm2835_pcm_prepare(struct snd_pcm_substream *substream)
 {
struct bcm2835_chip *chip = snd_pcm_substream_chip(substream);
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
index aca7008e1921..932ef12ac5d2 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
@@ -94,9 +94,9 @@ static void audio_vchi_callback(void *param,
void *msg_handle)
 {
struct bcm2835_audio_instance *instance = param;
-   int status;
-   int msg_len;
struct vc_audio_msg m;
+   int msg_len;
+   int status;
 
if (reason != VCHI_CALLBACK_MSG_AVAILABLE)
return;
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
index 0efae7068fef..6ee8334dfc81 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
@@ -161,8 +161,8 @@ static int snd_add_child_device(struct device *dev,
struct bcm2835_audio_driver *audio_driver,
u32 numchans)
 {
-   struct snd_card *card;
struct bcm2835_chip *chip;
+   struct snd_card *card;
int err;
 
err = snd_card_new(dev, -1, NULL, THIS_MODULE, sizeof(*chip), &card);
@@ -225,12 +225,12 @@ static int snd_add_child_device(struct device *dev,
 
 static int snd_add_child_devices(struct device *device, u32 numchans)
 {
-   int i;
-   int count_devices = 0;
-   int minchannels = 0;
-   int extrachannels = 0;
int extrachannels_per_driver = 0;
int extrachannels_remainder = 0;
+   int count_devices = 0;
+   int extrachannels = 0;
+   int minchannels = 0;
+   int i;
 
for (i = 0; i < ARRAY_SIZE(children_devices); i++)
if (*children_devices[i].is_enabled)
@@ -258,9 +258,9 @@ static int snd_add_child_devices(struct device *device, u32 
numchans)
extrachannels_remainder);
 
for (i = 0; i < ARRAY_SIZE(children_devices); i++) {
-   int err;
-   int numchannels_this_device;
struct bcm2835_audio_driver *audio_driver;
+   int numchannels_this_device;
+   int err;
 
if (!*children_devices[i].is_enabled)
continue;
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 4/7] staging: bcm2835-audio: use anonymous union in struct vc_audio_msg

2018-10-17 Thread Nicolas Saenz Julienne 
In this case explicitly naming the union doesn't help overall code
comprehension and clutters it.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Takashi Iwai 
Acked-by: Stefan Wahren 
---
 .../bcm2835-audio/bcm2835-vchiq.c | 30 +--
 .../bcm2835-audio/vc_vchi_audioserv_defs.h|  2 +-
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
index 932ef12ac5d2..0db412fd7c55 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
@@ -104,15 +104,15 @@ static void audio_vchi_callback(void *param,
status = vchi_msg_dequeue(instance->vchi_handle,
  &m, sizeof(m), &msg_len, VCHI_FLAGS_NONE);
if (m.type == VC_AUDIO_MSG_TYPE_RESULT) {
-   instance->result = m.u.result.success;
+   instance->result = m.result.success;
complete(&instance->msg_avail_comp);
} else if (m.type == VC_AUDIO_MSG_TYPE_COMPLETE) {
-   if (m.u.complete.cookie1 != VC_AUDIO_WRITE_COOKIE1 ||
-   m.u.complete.cookie2 != VC_AUDIO_WRITE_COOKIE2)
+   if (m.complete.cookie1 != VC_AUDIO_WRITE_COOKIE1 ||
+   m.complete.cookie2 != VC_AUDIO_WRITE_COOKIE2)
dev_err(instance->dev, "invalid cookie\n");
else
bcm2835_playback_fifo(instance->alsa_stream,
- m.u.complete.count);
+ m.complete.count);
} else {
dev_err(instance->dev, "unexpected callback type=%d\n", m.type);
}
@@ -249,11 +249,11 @@ int bcm2835_audio_set_ctls(struct bcm2835_alsa_stream 
*alsa_stream)
struct vc_audio_msg m = {};
 
m.type = VC_AUDIO_MSG_TYPE_CONTROL;
-   m.u.control.dest = chip->dest;
+   m.control.dest = chip->dest;
if (!chip->mute)
-   m.u.control.volume = CHIP_MIN_VOLUME;
+   m.control.volume = CHIP_MIN_VOLUME;
else
-   m.u.control.volume = alsa2chip(chip->volume);
+   m.control.volume = alsa2chip(chip->volume);
 
return bcm2835_audio_send_msg(alsa_stream->instance, &m, true);
 }
@@ -264,9 +264,9 @@ int bcm2835_audio_set_params(struct bcm2835_alsa_stream 
*alsa_stream,
 {
struct vc_audio_msg m = {
 .type = VC_AUDIO_MSG_TYPE_CONFIG,
-.u.config.channels = channels,
-.u.config.samplerate = samplerate,
-.u.config.bps = bps,
+.config.channels = channels,
+.config.samplerate = samplerate,
+.config.bps = bps,
};
int err;
 
@@ -294,7 +294,7 @@ int bcm2835_audio_drain(struct bcm2835_alsa_stream 
*alsa_stream)
 {
struct vc_audio_msg m = {
.type = VC_AUDIO_MSG_TYPE_STOP,
-   .u.stop.draining = 1,
+   .stop.draining = 1,
};
 
return bcm2835_audio_send_msg(alsa_stream->instance, &m, false);
@@ -322,10 +322,10 @@ int bcm2835_audio_write(struct bcm2835_alsa_stream 
*alsa_stream,
struct bcm2835_audio_instance *instance = alsa_stream->instance;
struct vc_audio_msg m = {
.type = VC_AUDIO_MSG_TYPE_WRITE,
-   .u.write.count = size,
-   .u.write.max_packet = instance->max_packet,
-   .u.write.cookie1 = VC_AUDIO_WRITE_COOKIE1,
-   .u.write.cookie2 = VC_AUDIO_WRITE_COOKIE2,
+   .write.count = size,
+   .write.max_packet = instance->max_packet,
+   .write.cookie1 = VC_AUDIO_WRITE_COOKIE1,
+   .write.cookie2 = VC_AUDIO_WRITE_COOKIE2,
};
unsigned int count;
int err, status;
diff --git 
a/drivers/staging/vc04_services/bcm2835-audio/vc_vchi_audioserv_defs.h 
b/drivers/staging/vc04_services/bcm2835-audio/vc_vchi_audioserv_defs.h
index dc62875cfdca..d6401e914ac9 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/vc_vchi_audioserv_defs.h
+++ b/drivers/staging/vc04_services/bcm2835-audio/vc_vchi_audioserv_defs.h
@@ -93,7 +93,7 @@ struct vc_audio_msg {
struct vc_audio_write write;
struct vc_audio_result result;
struct vc_audio_complete complete;
-   } u;
+   };
 };
 
 #endif /* _VC_AUDIO_DEFS_H_ */
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 7/7] staging: bcm2835-audio: update TODO

2018-10-17 Thread Nicolas Saenz Julienne 
The following tasks were completed or not the right solution:

1/2- Not the proper solution, we should register a platform device in
vchiq the same way it's done with bcm2835-camera as commented here:
https://lkml.org/lkml/2018/10/16/1131

2/3- Fixed by Takashi Iwai here: https://lkml.org/lkml/2018/9/4/587

Also, adds a new task as per mailing list conversation.

Signed-off-by: Nicolas Saenz Julienne 
---
 .../staging/vc04_services/bcm2835-audio/TODO  | 25 +++
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/TODO 
b/drivers/staging/vc04_services/bcm2835-audio/TODO
index 73d41fa631ac..cb8ead3e9108 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/TODO
+++ b/drivers/staging/vc04_services/bcm2835-audio/TODO
@@ -4,26 +4,7 @@
 *   *
 *
 
+1) Revisit multi-cards options and PCM route mixer control (as per comment
+https://lkml.org/lkml/2018/9/8/200)
 
-1) Document the device tree node
-
-The downstream tree(the tree that the driver was imported from) at
-http://www.github.com/raspberrypi/linux uses this node:
-
-audio: audio {
-   compatible = "brcm,bcm2835-audio";
-   brcm,pwm-channels = <8>;
-};
-
-Since the driver requires the use of VCHIQ, it may be useful to have a link
-in the device tree to the VCHIQ driver.
-
-2) Gracefully handle the case where VCHIQ is missing from the device tree or
-it has not been initialized yet.
-
-3) Review error handling and remove duplicate code.
-
-4) Cleanup the logging mechanism.  The driver should probably be using the
-standard kernel logging mechanisms such as dev_info, dev_dbg, and friends.
-
-5) Fix the remaining checkpatch.pl errors and warnings.
+2) Fix the remaining checkpatch.pl errors and warnings.
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 0/7] staging: bcm2835-audio: Cleanups and upgrades

2018-10-17 Thread Nicolas Saenz Julienne 
Hi,

I just received a RPi3B+ and decided to have a go at fixing stuff in the
audio driver. The changes are mostly cosmetic. I also took the liberty
to update the TODO file.

The series was developed on top of linux-next and tested on a RPi2B and
RPi3B+. Sadly I don't have an HDMI monitor with sound so I only tested
the mini jack output.

Thanks,
Nicolas

v2: Removes the device tree related patches, updates TODO accordingly
and adds suggestions from Takashi.



Nicolas Saenz Julienne (7):
  staging: bcm2835-audio: unify FOURCC command definitions
  staging: bcm2835-audio: don't initialize memory twice
  staging: bcm2835-audio: reorder variable declarations & remove trivial
comments
  staging: bcm2835-audio: use anonymous union in struct vc_audio_msg
  staging: bcm2835-audio: more generic probe function name
  staging: bcm2835-audio: rename platform_driver structure
  staging: bcm2835-audio: update TODO

 .../staging/vc04_services/bcm2835-audio/TODO  | 25 ++--
 .../vc04_services/bcm2835-audio/bcm2835-pcm.c | 10 +
 .../bcm2835-audio/bcm2835-vchiq.c | 39 ---
 .../vc04_services/bcm2835-audio/bcm2835.c | 26 ++---
 .../bcm2835-audio/vc_vchi_audioserv_defs.h|  6 ++-
 5 files changed, 38 insertions(+), 68 deletions(-)

-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 5/7] staging: bcm2835-audio: more generic probe function name

2018-10-17 Thread Nicolas Saenz Julienne 
There will only be one probe function, there is no use for appendig
"_dt" the end of the name.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Takashi Iwai 
Acked-by: Stefan Wahren 
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
index 6ee8334dfc81..039565311d10 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
@@ -291,7 +291,7 @@ static int snd_add_child_devices(struct device *device, u32 
numchans)
return 0;
 }
 
-static int snd_bcm2835_alsa_probe_dt(struct platform_device *pdev)
+static int snd_bcm2835_alsa_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
u32 numchans;
@@ -344,7 +344,7 @@ static const struct of_device_id 
snd_bcm2835_of_match_table[] = {
 MODULE_DEVICE_TABLE(of, snd_bcm2835_of_match_table);
 
 static struct platform_driver bcm2835_alsa0_driver = {
-   .probe = snd_bcm2835_alsa_probe_dt,
+   .probe = snd_bcm2835_alsa_probe,
 #ifdef CONFIG_PM
.suspend = snd_bcm2835_alsa_suspend,
.resume = snd_bcm2835_alsa_resume,
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 6/7] staging: bcm2835-audio: rename platform_driver structure

2018-10-17 Thread Nicolas Saenz Julienne 
It was called bcm2835_alsa0_driver, that "0" didn't mean much.

Suggested-by: Takashi Iwai 
Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
index 039565311d10..e14b7c5aa07c 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
@@ -343,7 +343,7 @@ static const struct of_device_id 
snd_bcm2835_of_match_table[] = {
 };
 MODULE_DEVICE_TABLE(of, snd_bcm2835_of_match_table);
 
-static struct platform_driver bcm2835_alsa0_driver = {
+static struct platform_driver bcm2835_alsa_driver = {
.probe = snd_bcm2835_alsa_probe,
 #ifdef CONFIG_PM
.suspend = snd_bcm2835_alsa_suspend,
@@ -359,7 +359,7 @@ static int bcm2835_alsa_device_init(void)
 {
int retval;
 
-   retval = platform_driver_register(&bcm2835_alsa0_driver);
+   retval = platform_driver_register(&bcm2835_alsa_driver);
if (retval)
pr_err("Error registering bcm2835_audio driver %d .\n", retval);
 
@@ -368,7 +368,7 @@ static int bcm2835_alsa_device_init(void)
 
 static void bcm2835_alsa_device_exit(void)
 {
-   platform_driver_unregister(&bcm2835_alsa0_driver);
+   platform_driver_unregister(&bcm2835_alsa_driver);
 }
 
 late_initcall(bcm2835_alsa_device_init);
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 03/15] dt-bindings: olpc,xo1.75-ec: Add OLPC XO-1.75 EC bindings

2018-10-17 Thread Rob Herring 
On Wed, Oct 10, 2018 at 07:22:48PM +0200, Lubomir Rintel wrote:
> The OLPC XO-1.75 Embedded Controller is a SPI master that uses extra
> signals for handshaking. It needs to know when is the slave (Linux)
> side's TX FIFO ready for transfer (the ready-gpio signal on the SPI
> controller node) and when does it wish to respond with a command (the
> cmd-gpio property).
> 
> Signed-off-by: Lubomir Rintel 
> ---
>  .../bindings/misc/olpc,xo1.75-ec.txt  | 24 +++
>  1 file changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt 
> b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt
> new file mode 100644
> index ..14385fee65d2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt
> @@ -0,0 +1,24 @@
> +OLPC XO-1.75 Embedded Controller
> +
> +Required properties:
> +- compatible: Should be "olpc,xo1.75-ec".
> +- cmd-gpio: gpio specifier of the CMD pin

cmd-gpios

> +
> +The embedded controller requires the SPI controller driver to signal 
> readiness
> +to receive a transfer (that is, when TX FIFO contains the response data) by
> +strobing the ACK pin with the ready signal. See the "ready-gpio" property of 
> the

This will need updating based on the SPI binding.

> +SSP binding as documented in:
> +.
> +
> +Example:
> + &ssp3 {
> + spi-slave;
> + status = "okay";

Don't show status in examples.

> + ready-gpio = <&gpio 125 GPIO_ACTIVE_HIGH>;
> +
> + slave {
> + compatible = "olpc,xo1.75-ec";
> + spi-cpha;
> + cmd-gpio = <&gpio 155 GPIO_ACTIVE_HIGH>;
> + };
> + };
> -- 
> 2.19.0
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 10/15] dt-bindings: olpc_battery: Add XO-1.5 battery

2018-10-17 Thread Rob Herring 
On Wed, 10 Oct 2018 19:22:55 +0200, Lubomir Rintel wrote:
> The XO-1 and XO-1.5 batteries apparently differ in an ability to report
> ambient temperature.
> 
> Signed-off-by: Lubomir Rintel 
> ---
>  Documentation/devicetree/bindings/power/supply/olpc_battery.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: iio: ad7816: Switch to the gpio descriptor interface

2018-10-17 Thread Dan Carpenter 
On Wed, Oct 17, 2018 at 10:58:23AM -0400, Sasha Levin wrote:
> On Wed, Oct 17, 2018 at 08:17:20PM +0530, Nishad Kamdar wrote:
> > +   chip->rdwr_pin = devm_gpiod_get(&spi_dev->dev, "rdwr", GPIOD_IN);
> > +   if (IS_ERR(chip->rdwr_pin)) {
> > +   ret = PTR_ERR(chip->rdwr_pin);
> > +   dev_err(&spi_dev->dev, "Failed to request rdwr GPIO: %d\n",
> > +   ret);
> > return ret;
> > }
> > -   gpio_direction_input(chip->rdwr_pin);
> > -   ret = devm_gpio_request(&spi_dev->dev, chip->convert_pin,
> > -   spi_get_device_id(spi_dev)->name);
> > -   if (ret) {
> > -   dev_err(&spi_dev->dev, "Fail to request convert gpio PIN %d.\n",
> > -   chip->convert_pin);
> > +   chip->convert_pin = devm_gpiod_get(&spi_dev->dev, "convert", GPIOD_IN);
> > +   if (IS_ERR(chip->convert_pin)) {
> > +   ret = PTR_ERR(chip->convert_pin);
> > +   dev_err(&spi_dev->dev, "Failed to request convert GPIO: %d\n",
> > +   ret);
> > return ret;
> > }
> > -   gpio_direction_input(chip->convert_pin);
> > -   ret = devm_gpio_request(&spi_dev->dev, chip->busy_pin,
> > -   spi_get_device_id(spi_dev)->name);
> > -   if (ret) {
> > -   dev_err(&spi_dev->dev, "Fail to request busy gpio PIN %d.\n",
> > -   chip->busy_pin);
> > +   chip->busy_pin = devm_gpiod_get(&spi_dev->dev, "busy", GPIOD_IN);
> > +   if (IS_ERR(chip->busy_pin)) {
> > +   ret = PTR_ERR(chip->busy_pin);
> > +   dev_err(&spi_dev->dev, "Failed to request busy GPIO: %d\n",
> > +   ret);
> > return ret;
> > }
> 
> Hm, from what I can tell devm_gpio_request() is allocating some memory,
> which makes this a series of 4 allocations.
> 
> What happens if the fourth allocation fails? Do we leak the first three?

These are devm_ allocations.  They are freed when &spi_dev->dev is
released.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 5/5] Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1

2018-10-17 Thread Dexuan Cui 
> From: devel  On Behalf Of
> Greg KH
> Sent: Tuesday, October 16, 2018 22:07
> 
> On Wed, Oct 17, 2018 at 03:14:06AM +, k...@linuxonhyperv.com wrote:
> > From: Dexuan Cui 
> >
> > The patch fixes:
> >
> > hv_kvp_daemon.c: In function 'kvp_set_ip_info':
> > hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes
> > into a destination of size 4096
> > ...
> > --- a/tools/hv/hv_kvp_daemon.c
> > +++ b/tools/hv/hv_kvp_daemon.c
> > @@ -1176,7 +1176,7 @@ static int kvp_set_ip_info(char *if_name, struct
> hv_kvp_ipaddr_value *new_val)
> > int error = 0;
> > char if_file[PATH_MAX];
> > FILE *file;
> > -   char cmd[PATH_MAX];
> > +   char cmd[PATH_MAX * 2];
> 
> Overkill?

Well, I found the -Wformat-truncation warning can be suppressed by checking
the return value of snprintf, so I'm going to do a new patch for KY to resend 
like this:

@@ -1178,6 +1178,7 @@ static int kvp_set_ip_info(char *if_name, struct 
hv_kvp_ipaddr_value *new_val)
FILE *file;
char cmd[PATH_MAX];
char *mac_addr;
+   int str_len;

/*
 * Set the configuration for the specified interface with
@@ -1301,8 +1302,19 @@ static int kvp_set_ip_info(char *if_name, struct 
hv_kvp_ipaddr_value *new_val)
 * invoke the external script to do its magic.
 */

-   snprintf(cmd, sizeof(cmd), KVP_SCRIPTS_PATH "%s %s",
-"hv_set_ifconfig", if_file);
+   str_len = snprintf(cmd, sizeof(cmd), KVP_SCRIPTS_PATH "%s %s",
+"hv_set_ifconfig", if_file);
+
+   /*
+* This is a little overcautious, but it's necessary to suppress some
+* false warnings from gcc 8.0.1.
+*/
+   if (str_len <= 0 || (unsigned int)str_len >= sizeof(cmd)) {
+   syslog(LOG_ERR, "Cmd '%s' (len=%d) may be too long",
+  cmd, str_len);
+   return HV_E_FAIL;
+   }


Thanks,
-- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] staging: emxx_udc: Added static modifier to udc_controller

2018-10-17 Thread Carmeli Tamir 
Added static modifier to the udc_controller, since it's only
required within emxx_udc.c.

Signed-off-by: Carmeli Tamir 
---
 drivers/staging/emxx_udc/emxx_udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index 3e51476..94a4327 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -56,7 +56,7 @@ static void _nbu2ss_fifo_flush(struct nbu2ss_udc *, struct 
nbu2ss_ep *);
 
 /*===*/
 /* Global */
-struct nbu2ss_udc udc_controller;
+static struct nbu2ss_udc udc_controller;
 
 /*-*/
 /* Read */
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/3] staging: emxx_udc: Added missing le16_to_cpu conversions

2018-10-17 Thread Carmeli Tamir 
Fixed sparse tool warnings due to missing convesion from 
le16 to cpu endienness.

Signed-off-by: Carmeli Tamir 
---
 drivers/staging/emxx_udc/emxx_udc.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index 344fe80..03df1bc 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -135,6 +135,7 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct 
usb_request *_req)
 {
u8  recipient;
u16 selector;
+   u16 wIndex;
u32 test_mode;
struct usb_ctrlrequest  *p_ctrl;
struct nbu2ss_udc *udc;
@@ -149,10 +150,12 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, 
struct usb_request *_req)
/*-*/
/* SET_FEATURE */
recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
-   selector  = p_ctrl->wValue;
+   selector  = le16_to_cpu(p_ctrl->wValue);
if ((recipient == USB_RECIP_DEVICE) &&
(selector == USB_DEVICE_TEST_MODE)) {
test_mode = (u32)(p_ctrl->wIndex >> 8);
+   wIndex = le16_to_cpu(p_ctrl->wIndex);
+   test_mode = (u32)(wIndex >> 8);
_nbu2ss_set_test_mode(udc, test_mode);
}
}
@@ -1380,7 +1383,7 @@ static struct usb_device_descriptor device_desc = {
.bMaxPacketSize0  = 64,
.idVendor = cpu_to_le16(0x0409),
.idProduct= cpu_to_le16(0xfff0),
-   .bcdDevice= 0x,
+   .bcdDevice= cpu_to_le16(0x),
.iManufacturer= 0x00,
.iProduct = 0x00,
.iSerialNumber= 0x00,
@@ -1468,8 +1471,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc 
*udc, bool bset)
 {
u8  recipient = (u8)(udc->ctrl.bRequestType & USB_RECIP_MASK);
u8  direction = (u8)(udc->ctrl.bRequestType & USB_DIR_IN);
-   u16 selector  = udc->ctrl.wValue;
-   u16 wIndex= udc->ctrl.wIndex;
+   u16 selector  = le16_to_cpu(udc->ctrl.wValue);
+   u16 wIndex= le16_to_cpu(udc->ctrl.wIndex);
u8  ep_adrs;
int result = -EOPNOTSUPP;
 
@@ -1568,7 +1571,8 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
if ((udc->ctrl.wValue != 0x) || (direction != USB_DIR_IN))
return result;
 
-   length = min_t(u16, udc->ctrl.wLength, sizeof(status_data));
+   length =
+   min_t(u16, le16_to_cpu(udc->ctrl.wLength), sizeof(status_data));
 
switch (recipient) {
case USB_RECIP_DEVICE:
@@ -1584,8 +1588,8 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
break;
 
case USB_RECIP_ENDPOINT:
-   if (0x == (udc->ctrl.wIndex & 0xFF70)) {
-   ep_adrs = (u8)(udc->ctrl.wIndex & 0xFF);
+   if (0x == (le16_to_cpu(udc->ctrl.wIndex) & 0xFF70)) {
+   ep_adrs = (u8)(le16_to_cpu(udc->ctrl.wIndex) & 0xFF);
result = _nbu2ss_get_ep_stall(udc, ep_adrs);
 
if (result > 0)
@@ -1625,7 +1629,7 @@ static int std_req_set_feature(struct nbu2ss_udc *udc)
 static int std_req_set_address(struct nbu2ss_udc *udc)
 {
int result = 0;
-   u32 wValue = udc->ctrl.wValue;
+   u32 wValue = le16_to_cpu(udc->ctrl.wValue);
 
if ((udc->ctrl.bRequestType != 0x00)||
(udc->ctrl.wIndex != 0x)||
@@ -1647,7 +1651,7 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
 /*-*/
 static int std_req_set_configuration(struct nbu2ss_udc *udc)
 {
-   u32 config_value = (u32)(udc->ctrl.wValue & 0x00ff);
+   u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
 
if ((udc->ctrl.wIndex != 0x)||
(udc->ctrl.wLength != 0x)   ||
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/3] staging: emxx_udc: Added missing __iomem modifier to handle p_regs

2018-10-17 Thread Carmeli Tamir 
Since in nbu2ss_drv_probe() p_regs is assigned from mmio_base, which is 
marked as __iomem, p_regs also should be market with __iomem.

Signed-off-by: Carmeli Tamir 
---
 drivers/staging/emxx_udc/emxx_udc.c | 44 ++---
 drivers/staging/emxx_udc/emxx_udc.h |  2 +-
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index 94a4327..344fe80 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -60,21 +60,21 @@ static struct nbu2ss_udc udc_controller;
 
 /*-*/
 /* Read */
-static inline u32 _nbu2ss_readl(void *address)
+static inline u32 _nbu2ss_readl(void __iomem *address)
 {
return __raw_readl(address);
 }
 
 /*-*/
 /* Write */
-static inline void _nbu2ss_writel(void *address, u32 udata)
+static inline void _nbu2ss_writel(void __iomem *address, u32 udata)
 {
__raw_writel(udata, address);
 }
 
 /*-*/
 /* Set Bit */
-static inline void _nbu2ss_bitset(void *address, u32 udata)
+static inline void _nbu2ss_bitset(void __iomem *address, u32 udata)
 {
u32 reg_dt = __raw_readl(address) | (udata);
 
@@ -83,7 +83,7 @@ static inline void _nbu2ss_bitset(void *address, u32 udata)
 
 /*-*/
 /* Clear Bit */
-static inline void _nbu2ss_bitclr(void *address, u32 udata)
+static inline void _nbu2ss_bitclr(void __iomem *address, u32 udata)
 {
u32 reg_dt = __raw_readl(address) & ~(udata);
 
@@ -184,7 +184,7 @@ static u32 _nbu2ss_get_begin_ram_address(struct nbu2ss_udc 
*udc)
u32 num, buf_type;
u32 data, last_ram_adr, use_ram_size;
 
-   struct ep_regs *p_ep_regs;
+   struct ep_regs __iomem *p_ep_regs;
 
last_ram_adr = (D_RAM_SIZE_CTRL / sizeof(u32)) * 2;
use_ram_size = 0;
@@ -377,7 +377,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, 
struct nbu2ss_ep *ep)
 {
u32 num;
u32 data;
-   struct fc_regs  *preg = udc->p_regs;
+   struct fc_regs __iomem *preg = udc->p_regs;
 
if (udc->vbus_active == 0)
return; /* VBUS OFF */
@@ -408,7 +408,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, 
struct nbu2ss_ep *ep)
 /* Abort DMA */
 static void _nbu2ss_ep_dma_abort(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
 {
-   struct fc_regs  *preg = udc->p_regs;
+   struct fc_regs __iomem *preg = udc->p_regs;
 
_nbu2ss_bitclr(&preg->EP_DCR[ep->epnum - 1].EP_DCR1, DCR1_EPN_REQEN);
mdelay(DMA_DISABLE_TIME);   /* DCR1_EPN_REQEN Clear */
@@ -426,7 +426,7 @@ static void _nbu2ss_ep_in_end(
 {
u32 data;
u32 num;
-   struct fc_regs  *preg = udc->p_regs;
+   struct fc_regs __iomem *preg = udc->p_regs;
 
if (length >= sizeof(u32))
return;
@@ -817,7 +817,7 @@ static int _nbu2ss_out_dma(
u32 burst = 1;
u32 data;
int result = -EINVAL;
-   struct fc_regs  *preg = udc->p_regs;
+   struct fc_regs __iomem *preg = udc->p_regs;
 
if (req->dma_flag)
return 1;   /* DMA is forwarded */
@@ -880,7 +880,7 @@ static int _nbu2ss_epn_out_pio(
union usb_reg_accesstemp_32;
union usb_reg_access*p_buf_32;
int result = 0;
-   struct fc_regs  *preg = udc->p_regs;
+   struct fc_regs __iomem *preg = udc->p_regs;
 
if (req->dma_flag)
return 1;   /* DMA is forwarded */
@@ -964,7 +964,7 @@ static int _nbu2ss_epn_out_transfer(
u32 num;
u32 i_recv_length;
int result = 1;
-   struct fc_regs  *preg = udc->p_regs;
+   struct fc_regs __iomem *preg = udc->p_regs;
 
if (ep->epnum == 0)
return -EINVAL;
@@ -1026,7 +1026,7 @@ static int _nbu2ss_in_dma(
u32 i_write_length;
u32 data;
int result = -EINVAL;
-   struct fc_regs  *preg = udc->p_regs;
+   struct fc_regs __iomem *preg = udc->p_regs;
 
if (req->dma_flag)
return 1;   /* DMA is forwarded */
@@ -1101,7 +1101,7 @@ static int _nbu2ss_epn_in_pio(
union usb_reg_accesstemp_32;
union usb_reg_access*p_buf_32 = NULL;
int result = 0;
-   struct fc_regs  *preg = udc->p_regs;
+   struct fc_regs __iomem *preg = udc->p_regs;
 
if (req->dma_flag)
return 1;   /* DMA is forwarded */
@@ -1317,7 +1317,7 @@ static void _nbu2ss_set_endpoint_stall(
u8

[PATCH v2] Staging iio: adc: Match parenthesis alignment

2018-10-17 Thread Marcelo Schmitt 
Change close parenthesis alignment to match respective open parenthesis at
iio/drivers/staging/iio/adc/ad7606.c line 379.
This makes the file more compliant with the preferred coding style for the
linux kernel.

Signed-of-by: Marcelo Schmitt 
---
 drivers/staging/iio/adc/ad7606.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/adc/ad7606.c b/drivers/staging/iio/adc/ad7606.c
index 0b728b6ea135..230faae38c12 100644
--- a/drivers/staging/iio/adc/ad7606.c
+++ b/drivers/staging/iio/adc/ad7606.c
@@ -376,7 +376,7 @@ static int ad7606_request_gpios(struct ad7606_state *st)
return 0;
 
st->gpio_os = devm_gpiod_get_array_optional(dev, "oversampling-ratio",
-   GPIOD_OUT_LOW);
+   GPIOD_OUT_LOW);
return PTR_ERR_OR_ZERO(st->gpio_os);
 }
 
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH V2 0/5] Drivers: hv: Miscellaneous fixes

2018-10-17 Thread kys 
From: "K. Y. Srinivasan" 

Miscellaneous fixes.

V2: Addressed comments from Greg.

Dexuan Cui (3):
  Drivers: hv: kvp: Fix the recent regression caused by incorrect
clean-up
  Drivers: hv: kvp: Use %u to print U32
  Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1

Haiyang Zhang (1):
  hv_utils: update name in struct hv_driver util_drv

K. Y. Srinivasan (1):
  Drivers: hv: vmbus: Get rid of unnecessary state in hv_context

 drivers/hv/hv.c   | 10 +++---
 drivers/hv/hv_kvp.c   | 28 +++-
 drivers/hv/hv_util.c  |  2 +-
 drivers/hv/hyperv_vmbus.h |  2 --
 tools/hv/hv_kvp_daemon.c  | 15 +--
 5 files changed, 40 insertions(+), 17 deletions(-)

-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH V2 1/5] Drivers: hv: vmbus: Get rid of unnecessary state in hv_context

2018-10-17 Thread kys 
From: "K. Y. Srinivasan" 

Currently we are replicating state in struct hv_context that is unnecessary -
this state can be retrieved from the hypervisor. Furthermore, this is a per-cpu
state that is being maintained as a global state in struct hv_context.
Get rid of this state in struct hv_context.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv.c   | 10 +++---
 drivers/hv/hyperv_vmbus.h |  2 --
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 332d7c34be5c..166c2501de17 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -33,9 +33,7 @@
 #include "hyperv_vmbus.h"
 
 /* The one and only */
-struct hv_context hv_context = {
-   .synic_initialized  = false,
-};
+struct hv_context hv_context;
 
 /*
  * If false, we're using the old mechanism for stimer0 interrupts
@@ -326,8 +324,6 @@ int hv_synic_init(unsigned int cpu)
 
hv_set_synic_state(sctrl.as_uint64);
 
-   hv_context.synic_initialized = true;
-
/*
 * Register the per-cpu clockevent source.
 */
@@ -373,7 +369,8 @@ int hv_synic_cleanup(unsigned int cpu)
bool channel_found = false;
unsigned long flags;
 
-   if (!hv_context.synic_initialized)
+   hv_get_synic_state(sctrl.as_uint64);
+   if (sctrl.enable != 1)
return -EFAULT;
 
/*
@@ -435,7 +432,6 @@ int hv_synic_cleanup(unsigned int cpu)
hv_set_siefp(siefp.as_uint64);
 
/* Disable the global synic bit */
-   hv_get_synic_state(sctrl.as_uint64);
sctrl.enable = 0;
hv_set_synic_state(sctrl.as_uint64);
 
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 72eaba3d50fc..f17c06a5e74b 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -230,8 +230,6 @@ struct hv_context {
 
void *tsc_page;
 
-   bool synic_initialized;
-
struct hv_per_cpu_context __percpu *cpu_context;
 
/*
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH V2 2/5] hv_utils: update name in struct hv_driver util_drv

2018-10-17 Thread kys 
From: Haiyang Zhang 

The correct module name is hv_utils. This patch corrects
the name in struct hv_driver util_drv.

Signed-off-by: Haiyang Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 423205077bf6..f10eeb120c8b 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -483,7 +483,7 @@ MODULE_DEVICE_TABLE(vmbus, id_table);
 
 /* The one and only one */
 static  struct hv_driver util_drv = {
-   .name = "hv_util",
+   .name = "hv_utils",
.id_table = id_table,
.probe =  util_probe,
.remove =  util_remove,
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH V2 4/5] Drivers: hv: kvp: Use %u to print U32

2018-10-17 Thread kys 
From: Dexuan Cui 

I didn't find a real issue. Let's just make it consistent with the
next "case REG_U64:" where %llu is used.

Signed-off-by: Dexuan Cui 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_kvp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index d6106e1a0d4a..5054d1105236 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -437,7 +437,7 @@ kvp_send_key(struct work_struct *dummy)
val32 = in_msg->body.kvp_set.data.value_u32;
message->body.kvp_set.data.value_size =
sprintf(message->body.kvp_set.data.value,
-   "%d", val32) + 1;
+   "%u", val32) + 1;
break;
 
case REG_U64:
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-10-17 Thread kys 
From: Dexuan Cui 

In kvp_send_key(), we do need call process_ib_ipinfo() if
message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
the userland hv_kvp_daemon needs the info of operation, adapter_id and
addr_family. With the incorrect fc62c3b1977d, the host can't get the
VM's IP via KVP.

And, fc62c3b1977d added a "break;", but actually forgot to initialize
the key_size/value in the case of KVP_OP_SET, so the default key_size of
0 is passed to the kvp daemon, and the pool files
/var/lib/hyperv/.kvp_pool_* can't be updated.

This patch effectively rolls back the previous fc62c3b1977d, and
correctly fixes the "this statement may fall through" warnings.

This patch is tested on WS 2012 R2 and 2016.

Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may fall 
through" warnings")
Signed-off-by: Dexuan Cui 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_kvp.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index a7513a8a8e37..d6106e1a0d4a 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -353,6 +353,9 @@ static void process_ib_ipinfo(void *in_msg, void *out_msg, 
int op)
 
out->body.kvp_ip_val.dhcp_enabled = in->kvp_ip_val.dhcp_enabled;
 
+   /* fallthrough */
+
+   case KVP_OP_GET_IP_INFO:
utf16s_to_utf8s((wchar_t *)in->kvp_ip_val.adapter_id,
MAX_ADAPTER_ID_SIZE,
UTF16_LITTLE_ENDIAN,
@@ -405,7 +408,11 @@ kvp_send_key(struct work_struct *dummy)
process_ib_ipinfo(in_msg, message, KVP_OP_SET_IP_INFO);
break;
case KVP_OP_GET_IP_INFO:
-   /* We only need to pass on message->kvp_hdr.operation.  */
+   /*
+* We only need to pass on the info of operation, adapter_id
+* and addr_family to the userland kvp daemon.
+*/
+   process_ib_ipinfo(in_msg, message, KVP_OP_GET_IP_INFO);
break;
case KVP_OP_SET:
switch (in_msg->body.kvp_set.data.value_type) {
@@ -446,9 +453,9 @@ kvp_send_key(struct work_struct *dummy)
 
}
 
-   break;
-
-   case KVP_OP_GET:
+   /*
+* The key is always a string - utf16 encoding.
+*/
message->body.kvp_set.data.key_size =
utf16s_to_utf8s(
(wchar_t *)in_msg->body.kvp_set.data.key,
@@ -456,6 +463,17 @@ kvp_send_key(struct work_struct *dummy)
UTF16_LITTLE_ENDIAN,
message->body.kvp_set.data.key,
HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1;
+
+   break;
+
+   case KVP_OP_GET:
+   message->body.kvp_get.data.key_size =
+   utf16s_to_utf8s(
+   (wchar_t *)in_msg->body.kvp_get.data.key,
+   in_msg->body.kvp_get.data.key_size,
+   UTF16_LITTLE_ENDIAN,
+   message->body.kvp_get.data.key,
+   HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1;
break;
 
case KVP_OP_DELETE:
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH V2 5/5] Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1

2018-10-17 Thread kys 
From: Dexuan Cui 

The patch fixes:

hv_kvp_daemon.c: In function 'kvp_set_ip_info':
hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes
into a destination of size 4096

The "(unsigned int)str_len" is to avoid:

hv_kvp_daemon.c:1309:30: warning: comparison of integer expressions of
different signedness: 'int' and 'long unsigned int' [-Wsign-compare]

Signed-off-by: Dexuan Cui 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_kvp_daemon.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bbb2a8ef367c..d7e06fe0270e 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1178,6 +1178,7 @@ static int kvp_set_ip_info(char *if_name, struct 
hv_kvp_ipaddr_value *new_val)
FILE *file;
char cmd[PATH_MAX];
char *mac_addr;
+   int str_len;
 
/*
 * Set the configuration for the specified interface with
@@ -1301,8 +1302,18 @@ static int kvp_set_ip_info(char *if_name, struct 
hv_kvp_ipaddr_value *new_val)
 * invoke the external script to do its magic.
 */
 
-   snprintf(cmd, sizeof(cmd), KVP_SCRIPTS_PATH "%s %s",
-"hv_set_ifconfig", if_file);
+   str_len = snprintf(cmd, sizeof(cmd), KVP_SCRIPTS_PATH "%s %s",
+  "hv_set_ifconfig", if_file);
+   /*
+* This is a little overcautious, but it's necessary to suppress some
+* false warnings from gcc 8.0.1.
+*/
+   if (str_len <= 0 || (unsigned int)str_len >= sizeof(cmd)) {
+   syslog(LOG_ERR, "Cmd '%s' (len=%d) may be too long",
+  cmd, str_len);
+   return HV_E_FAIL;
+   }
+
if (system(cmd)) {
syslog(LOG_ERR, "Failed to execute cmd '%s'; error: %d %s",
cmd, errno, strerror(errno));
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging iio/adc: fixes parenthesis alignment

2018-10-17 Thread Dan Carpenter 
I feel like these are overly nit-picky...

I understand that everyone is picky about different things.  For
example, I have a prefered style for error handling.  So two days ago
there was a new staging driver and it used label name like
"goto kmalloc_failed;" and I looked until I found an error handling bug
and then I said, "Here is a bug, plus your label names are bad."  When
people have bad style but it doesn't lead to bugs then I let them get
away with it.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH V2 5/5] Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1

2018-10-17 Thread Dan Carpenter 
On Thu, Oct 18, 2018 at 05:09:32AM +, k...@linuxonhyperv.com wrote:
> From: Dexuan Cui 
> 
> The patch fixes:
> 
> hv_kvp_daemon.c: In function 'kvp_set_ip_info':
> hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes
> into a destination of size 4096
> 
> The "(unsigned int)str_len" is to avoid:
> 
> hv_kvp_daemon.c:1309:30: warning: comparison of integer expressions of
> different signedness: 'int' and 'long unsigned int' [-Wsign-compare]
> 

Ugh...  Any tool with the most basic flow analysis would realize this
was a false positive.  We use at least three static analyzers which
catch signedness bugs.  Can we turn off GCC's warning on this until they
improve it a bit?

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel