RE: [PATCH] vmbus: fix missed ring events on boot

[Dexuan Cui]

> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> Behalf Of Stephen Hemminger
> @@ -609,7 +609,15 @@ static int vmbus_close_internal(struct
> @@ -480,20 +492,12 @@ static void vmbus_process_offer(struct

Hi Stephen,
Thanks for the patch!

hv_event_tasklet_enable() is called in 4 places in 4.10:

vmbus_close_internal, hv_process_channel_removal and 
vmbus_process_offer (twice).

The patch only fixes 2 of the 4 ones.
Should we fix all of them?

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

[PATCH] staging: vchiq_arm: Fix MODULE_LICENSE

[Stefan Wahren]

Regarding to the header the driver is licensed under BSD and GPL.

Signed-off-by: Stefan Wahren 
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index e6f8aeb..e823f1d 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -3490,6 +3490,6 @@ static struct platform_driver vchiq_driver = {
 };
 module_platform_driver(vchiq_driver);
 
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("Dual BSD/GPL");
 MODULE_DESCRIPTION("Videocore VCHIQ driver");
 MODULE_AUTHOR("Broadcom Corporation");
-- 
2.7.4

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

[PATCH] This patch fixes three minor checkpatch warning:

[Ding-Chi Wang]

"WARNING: Avoid multiple line dereference - prefer 
'poid_par_priv->information_buf_len'"
"WARNING: Avoid multiple line dereference - prefer 
'padapter->registrypriv.dev_network.Configuration'"
"WARNING: Avoid multiple line dereference - prefer 
'Adapter->mppriv.workparam.io_value'"

Signed-off-by: Ding-Chi Wang 
---
 drivers/staging/rtl8712/rtl871x_ioctl_rtl.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_rtl.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_rtl.c
index c7f2e51..ca769f7 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_rtl.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_rtl.c
@@ -282,8 +282,7 @@ uint oid_rt_get_total_rx_bytes_hdl(struct oid_par_priv
if (poid_par_priv->information_buf_len >= sizeof(u32)) {
*(u32 *)poid_par_priv->information_buf =
   padapter->recvpriv.rx_bytes;
-   *poid_par_priv->bytes_rw = poid_par_priv->
-  information_buf_len;
+   *poid_par_priv->bytes_rw = poid_par_priv->information_buf_len;
} else {
return RNDIS_STATUS_INVALID_LENGTH;
}
@@ -325,8 +324,7 @@ uint oid_rt_get_channel_hdl(struct oid_par_priv 
*poid_par_priv)
check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))
pnic_Config = &pmlmepriv->cur_network.network.Configuration;
else
-   pnic_Config = &padapter->registrypriv.dev_network.
- Configuration;
+   pnic_Config = &padapter->registrypriv.dev_network.Configuration;
channelnum = pnic_Config->DSConfig;
*(u32 *)poid_par_priv->information_buf = channelnum;
*poid_par_priv->bytes_rw = poid_par_priv->information_buf_len;
@@ -483,8 +481,8 @@ uint oid_rt_pro_rf_read_registry_hdl(struct oid_par_priv 
*poid_par_priv)
 */
if (!r8712_getrfreg_cmd(Adapter,
*(unsigned char *)poid_par_priv->information_buf,
-   (unsigned char *)&Adapter->mppriv.workparam.
-   io_value))
+   (unsigned char *)&Adapter->mppriv.workparam.io_value
+   ))
status = RNDIS_STATUS_NOT_ACCEPTED;
}
} else {
-- 
1.9.1


---
Avast 防毒軟體已檢查此封電子郵件的病毒。
https://www.avast.com/antivirus

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

[PATCH] staging: rtl8712: checkpatch: Avoid multiple line dereferences

[Ding-Chi Wang]

"WARNING: Avoid multiple line dereference - prefer 
'poid_par_priv->information_buf_len'"
"WARNING: Avoid multiple line dereference - prefer 
'padapter->registrypriv.dev_network.Configuration'"
"WARNING: Avoid multiple line dereference - prefer 
'Adapter->mppriv.workparam.io_value'"

Signed-off-by: Ding-Chi Wang 
---
 drivers/staging/rtl8712/rtl871x_ioctl_rtl.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_rtl.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_rtl.c
index c7f2e51..ca769f7 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_rtl.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_rtl.c
@@ -282,8 +282,7 @@ uint oid_rt_get_total_rx_bytes_hdl(struct oid_par_priv
if (poid_par_priv->information_buf_len >= sizeof(u32)) {
*(u32 *)poid_par_priv->information_buf =
   padapter->recvpriv.rx_bytes;
-   *poid_par_priv->bytes_rw = poid_par_priv->
-  information_buf_len;
+   *poid_par_priv->bytes_rw = poid_par_priv->information_buf_len;
} else {
return RNDIS_STATUS_INVALID_LENGTH;
}
@@ -325,8 +324,7 @@ uint oid_rt_get_channel_hdl(struct oid_par_priv 
*poid_par_priv)
check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))
pnic_Config = &pmlmepriv->cur_network.network.Configuration;
else
-   pnic_Config = &padapter->registrypriv.dev_network.
- Configuration;
+   pnic_Config = &padapter->registrypriv.dev_network.Configuration;
channelnum = pnic_Config->DSConfig;
*(u32 *)poid_par_priv->information_buf = channelnum;
*poid_par_priv->bytes_rw = poid_par_priv->information_buf_len;
@@ -483,8 +481,8 @@ uint oid_rt_pro_rf_read_registry_hdl(struct oid_par_priv 
*poid_par_priv)
 */
if (!r8712_getrfreg_cmd(Adapter,
*(unsigned char *)poid_par_priv->information_buf,
-   (unsigned char *)&Adapter->mppriv.workparam.
-   io_value))
+   (unsigned char *)&Adapter->mppriv.workparam.io_value
+   ))
status = RNDIS_STATUS_NOT_ACCEPTED;
}
} else {
-- 
1.9.1


---
Avast 防毒軟體已檢查此封電子郵件的病毒。
https://www.avast.com/antivirus

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

Re: [PATCH/RFC] staging/lustre: Rework class_process_proc_param

[Greg Kroah-Hartman]

On Sat, Mar 18, 2017 at 02:24:08AM -0400, Oleg Drokin wrote:
> Ever since sysfs migration, class_process_proc_param stopped working
> correctly as all the useful params were no longer present as lvars.
> Replace all the nasty fake proc writes with hopefully less nasty
> kobject attribute search and then update the attributes as needed.
> 
> Signed-off-by: Oleg Drokin 
> Reported-by: Al Viro 
> ---
> Al has quite rightfully complained in the past that class_process_proc_param
> is a terrible piece of code and needs to go.
> This patch is an attempt at improving it somewhat and in process drop
> all the user/kernel address space games we needed to play to make it work
> in the past (and which I suspect attracted Al's attention in the first place).
> 
> Now I wonder if iterating kobject attributes like that would be ok with
> you Greg, or do you think there is a better way?
> class_find_write_attr could be turned into something generic since it's
> certainly convenient to reuse same table of name-write_method pairs,
> but I did some cursory research and nobody else seems to need anything
> of the sort in-tree.
> 
> I know ll_process_config is still awful and I will likely just
> replace the current hack with kset_find_obj, but I just wanted to make
> sure this new approach would be ok before spending too much time on it.

I'm not quite sure what exactly you are even trying to do here.  What is
this interface?  Who calls it, and how?  What does it want to do?

You can look up attributes for a kobject easily in the show/store
functions (and some drivers just have a generic one and then you look at
the string to see which attribute you are wanting to reference.)  But
you seem to be working backwards here, why do you have to look up a
kobject?

What is wrong with the "normal" way to interact with kobject attributes
from sysfs?

What does your "process proc" function do?  Where does it get called
from?

totally confused,

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

Re: [PATCH 1/6] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service

[Stefan Wahren]

> Michael Zoran  hat am 17. März 2017 um 16:22 geschrieben:
> 
> 
> From: Dave Stevenson 
> 
> Pi3 and Compute Module 3 have a GPIO expander that the
> VPU communicates with.
> There is a mailbox service that now allows control of this
> expander, so add a kernel driver that can make use of it.
> 
> Pwr_led node added to device-tree for Pi3.

Looks like debris

> 
> Signed-off-by: Dave Stevenson 
> 
> Stripped off changes to Makefile and Kconfig
> Also stripped off changes to raspberrypi-firmware.h
> Moved to drivers/staging/vc04_services/bcm2835-firmware-gpio
> 
> Signed-off-by: Michael Zoran 
> ---
>  .../bcm2835-firmware-gpio/gpio-bcm-exp.c   | 256 
> +
>  1 file changed, 256 insertions(+)
>  create mode 100644 
> drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
> 
> diff --git 
> a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c 
> b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
> new file mode 100644
> index ..681a91492d4c
> --- /dev/null
> +++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
> @@ -0,0 +1,256 @@
> +/*
> + *  Broadcom expander GPIO driver
> + *
> + *  Uses the firmware mailbox service to communicate with the
> + *  GPIO expander on the VPU.
> + *
> + *  Copyright (C) 2017 Raspberry Pi Trading Ltd.
> + *
> + *  Author: Dave Stevenson 
> + *  Based on gpio-bcm-virt.c by Dom Cobley 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MODULE_NAME "brcmexp-gpio"
> +#define NUM_GPIO 8
> +
> +struct brcmexp_gpio {
> + struct gpio_chip gc;
> + struct device *dev;
> + struct rpi_firmware *fw;
> +};
> +
> +struct gpio_set_config {
> + u32 gpio, direction, polarity, term_en, term_pull_up, state;

Please one line per member

> +};
> +
> +struct gpio_get_config {
> + u32 gpio, direction, polarity, term_en, term_pull_up;

ditto

> +};
> +
> +struct gpio_get_set_state {
> + u32 gpio, state;

ditto

> +};
> +
> +static int brcmexp_gpio_get_polarity(struct gpio_chip *gc, unsigned int off)
> +{
> + struct brcmexp_gpio *gpio;
> + struct gpio_get_config get;
> + int ret;
> +
> + gpio = container_of(gc, struct brcmexp_gpio, gc);
> +
> + get.gpio = off + gpio->gc.base; /* GPIO to update */
> +
> + ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_CONFIG,
> + &get, sizeof(get));

This define comes from patch 2 which should breaks the build after apply only 
this patch :-(

> + if (ret) {
> + dev_err(gpio->dev,
> + "Failed to get GPIO %u config (%d)\n", off, ret);
> + return ret;
> + }
> + return get.polarity;
> +}
> +
> +static int brcmexp_gpio_dir_in(struct gpio_chip *gc, unsigned int off)
> +{
> + struct brcmexp_gpio *gpio;
> + struct gpio_set_config set_in;
> + int ret;
> +
> + gpio = container_of(gc, struct brcmexp_gpio, gc);
> +
> + set_in.gpio = off + gpio->gc.base;  /* GPIO to update */
> + set_in.direction = 0;   /* Input */

I think a self explaining define would be better.

> + set_in.polarity = brcmexp_gpio_get_polarity(gc, off);
> + /* Retain existing setting */
> + set_in.term_en = 0; /* termination disabled */
> + set_in.term_pull_up = 0;/* n/a as termination disabled */
> + set_in.state = 0;   /* n/a as configured as an input */
> +
> + ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_SET_GPIO_CONFIG,
> + &set_in, sizeof(set_in));
> + if (ret) {
> + dev_err(gpio->dev,
> + "Failed to set GPIO %u to input (%d)\n",
> + off, ret);
> + return ret;
> + }
> + return 0;
> +}
> +
> +static int brcmexp_gpio_dir_out(struct gpio_chip *gc, unsigned int off, int 
> val)
> +{
> + struct brcmexp_gpio *gpio;
> + struct gpio_set_config set_out;
> + int ret;
> +
> + gpio = container_of(gc, struct brcmexp_gpio, gc);
> +
> + set_out.gpio = off + gpio->gc.base; /* GPIO to update */
> + set_out.direction = 1;  /* Output */
> + set_out.polarity = brcmexp_gpio_get_polarity(gc, off);
> + /* Retain existing setting */
> + set_out.term_en = 0;/* n/a as an output */
> + set_out.term_pull_up = 0;   /* n/a as termination disabled */
> + set_out.state = val;/* Output state */
> +
> + ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_SET_GPIO_CONFIG,
> + &set_out, sizeof

Re: [PATCH 2/6] staging: bcm2835-firmware-gpio: Add needed mailbox defines to driver

[Stefan Wahren]

> Michael Zoran  hat am 17. März 2017 um 16:22 geschrieben:
> 
> 
> The original change this driver is based on adds the needed mailbox
> defines to include/soc/bcm2835/raspberrypi-firmware.h. That is not
> appropriate at this time, so add the defines directly into the
> driver source.
> 
> This change is based on:
> https://github.com/raspberrypi/linux
> 
> Branch: rpi-4.11.y(commit efad03c3c86642dafccc03fcdd3ab84dd11e2ab7)
> 
> Signed-off-by: Michael Zoran 
> ---
>  drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c | 7 
> +++
>  1 file changed, 7 insertions(+)
> 
> diff --git 
> a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c 
> b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
> index 681a91492d4c..ba9750107957 100644
> --- a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
> +++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
> @@ -43,6 +43,13 @@ struct gpio_get_set_state {
>   u32 gpio, state;
>  };
>  
> +enum rpi_firmware_gpio_property_tag {
> + RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
> + RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
> + RPI_FIRMWARE_GET_GPIO_CONFIG =0x00030043,
> + RPI_FIRMWARE_SET_GPIO_CONFIG =0x00038043,
> +};
> +

As i point out before, please fold into the first patch so we don't break the 
build. Btw a TODO comment to move this into 
include/soc/bcm2835/raspberrypi-firmware.h later would be nice.

>  static int brcmexp_gpio_get_polarity(struct gpio_chip *gc, unsigned int off)
>  {
>   struct brcmexp_gpio *gpio;
> -- 
> 2.11.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/6] staging: bcm2835-firmware-gpio: Expand DT options for driver

[Stefan Wahren]

> Michael Zoran  hat am 17. März 2017 um 16:22 geschrieben:
> 
> 
> This change adds the following optional DT properties:
> 
> number-gpios: Number of GPIOs the device should expose
> gpio-base: GPIO base that is registered with the kernel

Please don't reinvent existing properties. Take a look at the gpio-range from 
the general gpio binding.

> firmware-gpio-base: GPIO bases as viewed by the firmware
> 

Since this isn't a general DT property this needs a vendor prefix.

Please also look at Eric's version [1] and the comments.

[1] - https://www.spinics.net/lists/arm-kernel/msg532889.html

> The purpose of these DT nodes is to make the driver more
> general.
> 
> Signed-off-by: Michael Zoran 
> ---
>  .../bcm2835-firmware-gpio/gpio-bcm-exp.c   | 40 
> --
>  1 file changed, 29 insertions(+), 11 deletions(-)
> 
> diff --git 
> a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c 
> b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
> index ba9750107957..f6719c84ed8b 100644
> --- a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
> +++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
> @@ -23,12 +23,15 @@
>  #include 
>  
>  #define MODULE_NAME "brcmexp-gpio"
> -#define NUM_GPIO 8
> +#define DEFAULT_NUM_GPIO 8
> +#define DEFAULT_GPIO_BASE 128
> +#define DEFAULT_FIRMWARE_GPIO_BASE 128
>  
>  struct brcmexp_gpio {
>   struct gpio_chip gc;
>   struct device *dev;
>   struct rpi_firmware *fw;
> + u32 firmware_gpio_base;
>  };
>  
>  struct gpio_set_config {
> @@ -58,7 +61,7 @@ static int brcmexp_gpio_get_polarity(struct gpio_chip *gc, 
> unsigned int off)
>  
>   gpio = container_of(gc, struct brcmexp_gpio, gc);
>  
> - get.gpio = off + gpio->gc.base; /* GPIO to update */
> + get.gpio = off + gpio->firmware_gpio_base;
>  
>   ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_CONFIG,
>   &get, sizeof(get));
> @@ -78,7 +81,7 @@ static int brcmexp_gpio_dir_in(struct gpio_chip *gc, 
> unsigned int off)
>  
>   gpio = container_of(gc, struct brcmexp_gpio, gc);
>  
> - set_in.gpio = off + gpio->gc.base;  /* GPIO to update */
> + set_in.gpio = off + gpio->firmware_gpio_base;
>   set_in.direction = 0;   /* Input */
>   set_in.polarity = brcmexp_gpio_get_polarity(gc, off);
>   /* Retain existing setting */
> @@ -105,7 +108,7 @@ static int brcmexp_gpio_dir_out(struct gpio_chip *gc, 
> unsigned int off, int val)
>  
>   gpio = container_of(gc, struct brcmexp_gpio, gc);
>  
> - set_out.gpio = off + gpio->gc.base; /* GPIO to update */
> + set_out.gpio = off + gpio->firmware_gpio_base;
>   set_out.direction = 1;  /* Output */
>   set_out.polarity = brcmexp_gpio_get_polarity(gc, off);
>   /* Retain existing setting */
> @@ -131,7 +134,7 @@ static int brcmexp_gpio_get_direction(struct gpio_chip 
> *gc, unsigned int off)
>  
>   gpio = container_of(gc, struct brcmexp_gpio, gc);
>  
> - get.gpio = off + gpio->gc.base; /* GPIO to update */
> + get.gpio = off + gpio->firmware_gpio_base;
>  
>   ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_CONFIG,
>   &get, sizeof(get));
> @@ -151,7 +154,7 @@ static int brcmexp_gpio_get(struct gpio_chip *gc, 
> unsigned int off)
>  
>   gpio = container_of(gc, struct brcmexp_gpio, gc);
>  
> - get.gpio = off + gpio->gc.base; /* GPIO to update */
> + get.gpio = off + gpio->firmware_gpio_base;
>   get.state = 0;  /* storage for returned value */
>  
>   ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_STATE,
> @@ -172,9 +175,7 @@ static void brcmexp_gpio_set(struct gpio_chip *gc, 
> unsigned int off, int val)
>  
>   gpio = container_of(gc, struct brcmexp_gpio, gc);
>  
> - off += gpio->gc.base;
> -
> - set.gpio = off + gpio->gc.base; /* GPIO to update */
> + set.gpio = off + gpio->firmware_gpio_base;
>   set.state = val;/* Output state */
>  
>   ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_SET_GPIO_STATE,
> @@ -212,8 +213,8 @@ static int brcmexp_gpio_probe(struct platform_device 
> *pdev)
>   ucb->gc.label = MODULE_NAME;
>   ucb->gc.owner = THIS_MODULE;
>   ucb->gc.of_node = np;
> - ucb->gc.base = 128;
> - ucb->gc.ngpio = NUM_GPIO;
> + ucb->gc.base = DEFAULT_GPIO_BASE;
> + ucb->gc.ngpio = DEFAULT_NUM_GPIO;
>  
>   ucb->gc.direction_input = brcmexp_gpio_dir_in;
>   ucb->gc.direction_output = brcmexp_gpio_dir_out;
> @@ -222,6 +223,23 @@ static int brcmexp_gpio_probe(struct platform_device 
> *pdev)
>   ucb->gc.set = brcmexp_gpio_set;
>   ucb->gc.can_sleep = true;
>  
> + ucb->firmware_gpio_base = DEFAULT_FIRMWARE_GPIO_BASE;
> +
> + err = of_property_read_u16(dev->of_node, "number-gpios",
> +   

Re: [PATCH 5/6] staging: bcm2835-firmware-gpio: Add a build system for the driver

[Stefan Wahren]

> Michael Zoran  hat am 17. März 2017 um 16:22 geschrieben:
> 
> 
> This change adds the driver to the standard kernel build system.
> 
> Signed-off-by: Michael Zoran 
> ---
>  drivers/staging/vc04_services/Kconfig| 2 ++
>  drivers/staging/vc04_services/Makefile   | 1 +
>  drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig  | 6 ++
>  drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile | 5 +
>  4 files changed, 14 insertions(+)
>  create mode 100644 
> drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig
>  create mode 100644 
> drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile
> 
> diff --git a/drivers/staging/vc04_services/Kconfig 
> b/drivers/staging/vc04_services/Kconfig
> index b9f316603308..aebb622cff4a 100644
> --- a/drivers/staging/vc04_services/Kconfig
> +++ b/drivers/staging/vc04_services/Kconfig
> @@ -34,5 +34,7 @@ source "drivers/staging/vc04_services/bcm2835-audio/Kconfig"
>  
>  source "drivers/staging/vc04_services/bcm2835-camera/Kconfig"
>  
> +source "drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig"
> +
>  endif
>  
> diff --git a/drivers/staging/vc04_services/Makefile 
> b/drivers/staging/vc04_services/Makefile
> index e9a8e1343cbb..54c75b732094 100644
> --- a/drivers/staging/vc04_services/Makefile
> +++ b/drivers/staging/vc04_services/Makefile
> @@ -12,6 +12,7 @@ vchiq-objs := \
>  
>  obj-$(CONFIG_SND_BCM2835)+= bcm2835-audio/
>  obj-$(CONFIG_VIDEO_BCM2835)  += bcm2835-camera/
> +obj-$(CONFIG_FIRMWARE_GPIO_BCM2835) += bcm2835-firmware-gpio/
>  
>  ccflags-y += -DVCOS_VERIFY_BKPTS=1 -Idrivers/staging/vc04_services 
> -DUSE_VCHIQ_ARM -D__VCCOREVER__=0x0400
>  
> diff --git a/drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig 
> b/drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig
> new file mode 100644
> index ..1c8cb579fad9
> --- /dev/null
> +++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig
> @@ -0,0 +1,6 @@
> +config FIRMWARE_GPIO_BCM2835
> + tristate "BCM2835 Firmware GPIO"
> + depends on OF_GPIO && (ARCH_BCM2835 || COMPILE_TEST)

depends on RASPBERRYPI_FIRMWARE ?

> + help
> +   Turn on GPIO support for Broadcom chips using the firmware mailbox
> +   to communicate with VideoCore on BCM283x chips.
> diff --git a/drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile 
> b/drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile
> new file mode 100644
> index ..afa642ab26f4
> --- /dev/null
> +++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile
> @@ -0,0 +1,5 @@
> +obj-$(CONFIG_FIRMWARE_GPIO_BCM2835)  += gpio-bcm-exp.o
> +
> +
> +
> +

Please avoid those many empty lines.

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

Re: [PATCH/RFC] staging/lustre: Rework class_process_proc_param

[Oleg Drokin]

On Mar 18, 2017, at 6:34 AM, Greg Kroah-Hartman wrote:

> On Sat, Mar 18, 2017 at 02:24:08AM -0400, Oleg Drokin wrote:
>> Ever since sysfs migration, class_process_proc_param stopped working
>> correctly as all the useful params were no longer present as lvars.
>> Replace all the nasty fake proc writes with hopefully less nasty
>> kobject attribute search and then update the attributes as needed.
>> 
>> Signed-off-by: Oleg Drokin 
>> Reported-by: Al Viro 
>> ---
>> Al has quite rightfully complained in the past that class_process_proc_param
>> is a terrible piece of code and needs to go.
>> This patch is an attempt at improving it somewhat and in process drop
>> all the user/kernel address space games we needed to play to make it work
>> in the past (and which I suspect attracted Al's attention in the first 
>> place).
>> 
>> Now I wonder if iterating kobject attributes like that would be ok with
>> you Greg, or do you think there is a better way?
>> class_find_write_attr could be turned into something generic since it's
>> certainly convenient to reuse same table of name-write_method pairs,
>> but I did some cursory research and nobody else seems to need anything
>> of the sort in-tree.
>> 
>> I know ll_process_config is still awful and I will likely just
>> replace the current hack with kset_find_obj, but I just wanted to make
>> sure this new approach would be ok before spending too much time on it.
> 
> I'm not quite sure what exactly you are even trying to do here.  What is
> this interface?  Who calls it, and how?  What does it want to do?

This is a configuration client code.
Management server has ability to pass down config information in the form of:
fsname.subsystem.attribute=value to clients and other servers
(subsystem determines if it's something of interest of clients or servers or
both).
This could be changed in the real time - i.e. you update it on the server and
that gets propagated to all the clients/servers, so no need to ssh into
every node to manually apply those changes and worry about client restarts
(the config is remembered at the management server and would be applied to any
new nodes connecting/across server restarts and such).

So the way it then works then is once the string 
fsname.subsystem.attribute=value is delivered to the client, we find all 
instances of filesystem with fsname and then
all subsystems within it (one kobject per subsystem instance) and then update 
the
attributes to the value supplied.

The same filesystem might be mounted more than once and then some layers might 
have
multiple instances inside a single filesystems.

In the end it would turn something like lustre.osc.max_dirty_mb=128 into
writes to
/sys/fs/lustre/osc/lustre-OST-osc-8800d75ca000/max_dirty_mb and
/sys/fs/lustre/osc/lustre-OST0001-osc-8800d75ca000/max_dirty_mb
without actually iterating in sysfs namespace.

The alternative we considered is we can probably just do an upcall and have
a userspace tool called with the parameter verbatim and try to figure it out,
but that seems a lot less ideal, and also we'll get a bunch of complications 
from
containers and such too, I imagine.

The function pre-this patch is assuming that all these values are part of
a list of procfs values (no longer true after sysfs migration) so just iterates
that list and calls the write for matched names (but also needs to supply a 
userspace
buffer so looks much uglier too).

Hopefully this makes at least some sense.

> You can look up attributes for a kobject easily in the show/store
> functions (and some drivers just have a generic one and then you look at
> the string to see which attribute you are wanting to reference.)  But
> you seem to be working backwards here, why do you have to look up a
> kobject?

But that leads to the need to list attribute names essentially twice:
once for the attributes list, once in the show/set function to figure
out how to deal with that name.

> What is wrong with the "normal" way to interact with kobject attributes
> from sysfs?
> 
> What does your "process proc" function do?  Where does it get called
> from?
> 
> totally confused,
> 
> greg k-h

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

Re: [PATCH] vmbus: fix missed ring events on boot

[Stephen Hemminger]

On Sat, 18 Mar 2017 07:46:21 +
Dexuan Cui  wrote:

> > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> > Behalf Of Stephen Hemminger
> > @@ -609,7 +609,15 @@ static int vmbus_close_internal(struct
> > @@ -480,20 +492,12 @@ static void vmbus_process_offer(struct  
> 
> Hi Stephen,
> Thanks for the patch!
> 
> hv_event_tasklet_enable() is called in 4 places in 4.10:
> 
> vmbus_close_internal, hv_process_channel_removal and 
> vmbus_process_offer (twice).
> 
> The patch only fixes 2 of the 4 ones.
> Should we fix all of them?
> 
> Thanks,
> -- Dexuan

I am testing a simpler patch that just fixes hv_event_tasklet_enable
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

[Borislav Petkov]

On Fri, Mar 17, 2017 at 03:45:26PM +0100, Paolo Bonzini wrote:
> Yes, and I'd like that to be done with a new data section rather than a
> special KVM hook.

Can you give more details about how pls? Or is there already an example for that
somewhere in the kvm code?

> I have no idea.  SEV-ES seems to be very hard to set up at the beginning
> of the kernel bootstrap.  There's all sorts of chicken and egg problems,
> as well as complicated handshakes between the firmware and the guest,
> and the way to do it also depends on the trust and threat models.
> 
> A much simpler way is to just boot under a trusted hypervisor, do
> "modprobe sev-es" and save a snapshot of the guest.  Then you sign the
> snapshot and pass it to your cloud provider.

Right, especially the early trapping could be a pain. I don't think this
is cast in stone yet, though...

We'll see.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH v2] staging: iio: ade7753: replace mlock with driver private lock

[SIMRAN SINGHAL]

On Thu, Mar 16, 2017 at 3:23 AM, Jonathan Cameron  wrote:
> On 13/03/17 19:53, Alison Schofield wrote:
>> On Mon, Mar 13, 2017 at 10:01:07PM +0530, simran singhal wrote:
>>> The IIO subsystem is redefining iio_dev->mlock to be used by
>>> the IIO core only for protecting device operating mode changes.
>>> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
>>>
>>> In this driver, mlock was being used to protect hardware state
>>> changes.  Replace it with a lock in the devices global data.
>>>
>>> Fix some coding style issues related to white space also.
>>>
>>> Signed-off-by: simran singhal 
>>> ---
>>>
>>>  v2:
>>>-Removed new lock to reuse the existing lock
>> Simran,
>>
>> The good news is that you have 2 patches that have similar
>> challenges!  I'll suggest picking one, drive it to completion,
>> then do the other.
>>
>> This has the nested locking issue that Lars warned about.
>> Need to refactor to avoid.  Check back on his review comments.
>>
>> I suggest dropping those whitespace changes - they appear
>> out of place in this patch since you are no longer actually
>> touching those lines of code.
>>
>> alisons
> Also missing a mutex_init, though that may well become irrelevant
> with refactoring as suggested.

Jonathon, what I found by looking at the codes of other drivers is that
we have to use mutex_init in probe function only.

Is this correct?

And this patch also suggest the same:-
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=testing&id=388c8f18ff29fe95dbf72cb0a1bd8fbcd6f52f8f

>>
>>
>>>
>>>  drivers/staging/iio/meter/ade7753.c | 12 ++--
>>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/staging/iio/meter/ade7753.c 
>>> b/drivers/staging/iio/meter/ade7753.c
>>> index dfd8b71..d88eaa3 100644
>>> --- a/drivers/staging/iio/meter/ade7753.c
>>> +++ b/drivers/staging/iio/meter/ade7753.c
>>> @@ -83,10 +83,10 @@
>>>   * @buf_lock:   mutex to protect tx and rx
>>>   **/
>>>  struct ade7753_state {
>>> -struct spi_device   *us;
>>> -struct mutexbuf_lock;
>>> -u8  tx[ADE7753_MAX_TX] 
>>> cacheline_aligned;
>>> -u8  rx[ADE7753_MAX_RX];
>>> +struct spi_device   *us;
>>> +struct mutexbuf_lock;
>>> +u8  tx[ADE7753_MAX_TX] cacheline_aligned;
>>> +u8  rx[ADE7753_MAX_RX];
>>>  };
>>>
>>>  static int ade7753_spi_write_reg_8(struct device *dev,
>>> @@ -484,7 +484,7 @@ static ssize_t ade7753_write_frequency(struct device 
>>> *dev,
>>>  if (!val)
>>>  return -EINVAL;
>>>
>>> -mutex_lock(&indio_dev->mlock);
>>> +mutex_lock(&st->buf_lock);
>>>
>>>  t = 27900 / val;
>>>  if (t > 0)
>>> @@ -505,7 +505,7 @@ static ssize_t ade7753_write_frequency(struct device 
>>> *dev,
>>>  ret = ade7753_spi_write_reg_16(dev, ADE7753_MODE, reg);
>>>
>>>  out:
>>> -mutex_unlock(&indio_dev->mlock);
>>> +mutex_unlock(&st->buf_lock);
>>>
>>>  return ret ? ret : len;
>>>  }
>>> --
>>> 2.7.4
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "outreachy-kernel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/outreachy-kernel/20170313163107.GA31496%40singhal-Inspiron-5558.
>>> For more options, visit https://groups.google.com/d/optout.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH v2] staging: iio: ade7753: replace mlock with driver private lock

[Jonathan Cameron]

On 18/03/17 17:34, SIMRAN SINGHAL wrote:
> On Thu, Mar 16, 2017 at 3:23 AM, Jonathan Cameron  wrote:
>> On 13/03/17 19:53, Alison Schofield wrote:
>>> On Mon, Mar 13, 2017 at 10:01:07PM +0530, simran singhal wrote:
 The IIO subsystem is redefining iio_dev->mlock to be used by
 the IIO core only for protecting device operating mode changes.
 ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.

 In this driver, mlock was being used to protect hardware state
 changes.  Replace it with a lock in the devices global data.

 Fix some coding style issues related to white space also.

 Signed-off-by: simran singhal 
 ---

  v2:
-Removed new lock to reuse the existing lock
>>> Simran,
>>>
>>> The good news is that you have 2 patches that have similar
>>> challenges!  I'll suggest picking one, drive it to completion,
>>> then do the other.
>>>
>>> This has the nested locking issue that Lars warned about.
>>> Need to refactor to avoid.  Check back on his review comments.
>>>
>>> I suggest dropping those whitespace changes - they appear
>>> out of place in this patch since you are no longer actually
>>> touching those lines of code.
>>>
>>> alisons
>> Also missing a mutex_init, though that may well become irrelevant
>> with refactoring as suggested.
> 
> Jonathon, what I found by looking at the codes of other drivers is that
> we have to use mutex_init in probe function only.
> 
> Is this correct?
Yes, it only needs initializing once.
> 
> And this patch also suggest the same:-
> https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=testing&id=388c8f18ff29fe95dbf72cb0a1bd8fbcd6f52f8f
> 
>>>
>>>

  drivers/staging/iio/meter/ade7753.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

 diff --git a/drivers/staging/iio/meter/ade7753.c 
 b/drivers/staging/iio/meter/ade7753.c
 index dfd8b71..d88eaa3 100644
 --- a/drivers/staging/iio/meter/ade7753.c
 +++ b/drivers/staging/iio/meter/ade7753.c
 @@ -83,10 +83,10 @@
   * @buf_lock:   mutex to protect tx and rx
   **/
  struct ade7753_state {
 -struct spi_device   *us;
 -struct mutexbuf_lock;
 -u8  tx[ADE7753_MAX_TX] 
 cacheline_aligned;
 -u8  rx[ADE7753_MAX_RX];
 +struct spi_device   *us;
 +struct mutexbuf_lock;
 +u8  tx[ADE7753_MAX_TX] cacheline_aligned;
 +u8  rx[ADE7753_MAX_RX];
  };

  static int ade7753_spi_write_reg_8(struct device *dev,
 @@ -484,7 +484,7 @@ static ssize_t ade7753_write_frequency(struct device 
 *dev,
  if (!val)
  return -EINVAL;

 -mutex_lock(&indio_dev->mlock);
 +mutex_lock(&st->buf_lock);

  t = 27900 / val;
  if (t > 0)
 @@ -505,7 +505,7 @@ static ssize_t ade7753_write_frequency(struct device 
 *dev,
  ret = ade7753_spi_write_reg_16(dev, ADE7753_MODE, reg);

  out:
 -mutex_unlock(&indio_dev->mlock);
 +mutex_unlock(&st->buf_lock);

  return ret ? ret : len;
  }
 --
 2.7.4

 --
 You received this message because you are subscribed to the Google Groups 
 "outreachy-kernel" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to outreachy-kernel+unsubscr...@googlegroups.com.
 To post to this group, send email to outreachy-ker...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/outreachy-kernel/20170313163107.GA31496%40singhal-Inspiron-5558.
 For more options, visit https://groups.google.com/d/optout.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>

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

[PATCH v4] staging: Use buf_lock instead of mlock and Refactor code

[simran singhal]

The IIO subsystem is redefining iio_dev->mlock to be used by
the IIO core only for protecting device operating mode changes.
ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.

In this driver, mlock was being used to protect hardware state
changes. Replace it with buf_lock in the devices global data.

As buf_lock protects both the adis16060_spi_write() and
adis16060_spi_read() functions and both are always called in
pair. First write, then read. Thus, refactor the code to have
one single function adis16060_spi_write_than_read() which is
protected by the existing buf_lock.

Signed-off-by: simran singhal 
---

 v4:
   -Refactored code 
   -change commit subject
   -change commit message

 drivers/staging/iio/gyro/adis16060_core.c | 37 ---
 1 file changed, 14 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
b/drivers/staging/iio/gyro/adis16060_core.c
index c9d46e7..39ddd55 100644
--- a/drivers/staging/iio/gyro/adis16060_core.c
+++ b/drivers/staging/iio/gyro/adis16060_core.c
@@ -40,7 +40,7 @@ struct adis16060_state {
 
 static struct iio_dev *adis16060_iio_dev;
 
-static int adis16060_spi_write(struct iio_dev *indio_dev, u8 val)
+static int adis16060_spi_write_than_read(struct iio_dev *indio_dev, u8 val, 
u16 *val2)
 {
int ret;
struct adis16060_state *st = iio_priv(indio_dev);
@@ -48,17 +48,11 @@ static int adis16060_spi_write(struct iio_dev *indio_dev, 
u8 val)
mutex_lock(&st->buf_lock);
st->buf[2] = val; /* The last 8 bits clocked in are latched */
ret = spi_write(st->us_w, st->buf, 3);
-   mutex_unlock(&st->buf_lock);
 
-   return ret;
-}
-
-static int adis16060_spi_read(struct iio_dev *indio_dev, u16 *val)
-{
-   int ret;
-   struct adis16060_state *st = iio_priv(indio_dev);
-
-   mutex_lock(&st->buf_lock);
+   if (ret < 0) {
+   mutex_unlock(&st->buf_lock);
+   return ret;
+   }
 
ret = spi_read(st->us_r, st->buf, 3);
 
@@ -67,10 +61,10 @@ static int adis16060_spi_read(struct iio_dev *indio_dev, 
u16 *val)
 * starts to place data MSB first on the DOUT line at
 * the 6th falling edge of SCLK
 */
-   if (!ret)
-   *val = ((st->buf[0] & 0x3) << 12) |
-   (st->buf[1] << 4) |
-   ((st->buf[2] >> 4) & 0xF);
+if (!ret)
+   *val2 = ((st->buf[0] & 0x3) << 12) |
+(st->buf[1] << 4) |
+((st->buf[2] >> 4) & 0xF);
mutex_unlock(&st->buf_lock);
 
return ret;
@@ -83,20 +77,17 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
 {
u16 tval = 0;
int ret;
+   struct adis16060_state *st = iio_priv(indio_dev);
 
switch (mask) {
case IIO_CHAN_INFO_RAW:
/* Take the iio_dev status lock */
-   mutex_lock(&indio_dev->mlock);
-   ret = adis16060_spi_write(indio_dev, chan->address);
+   mutex_lock(&st->buf_lock);
+   ret = adis16060_spi_write_than_read(indio_dev, chan->address, 
&tval);
if (ret < 0)
goto out_unlock;
 
-   ret = adis16060_spi_read(indio_dev, &tval);
-   if (ret < 0)
-   goto out_unlock;
-
-   mutex_unlock(&indio_dev->mlock);
+   mutex_unlock(&st->buf_lock);
*val = tval;
return IIO_VAL_INT;
case IIO_CHAN_INFO_OFFSET:
@@ -112,7 +103,7 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
 
 out_unlock:
-   mutex_unlock(&indio_dev->mlock);
+   mutex_unlock(&st->buf_lock);
return ret;
 }
 
-- 
2.7.4

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

Re: [Outreachy kernel] [PATCH v2] staging: iio: ade7753: replace mlock with driver private lock

[SIMRAN SINGHAL]

On Sat, Mar 18, 2017 at 11:51 PM, Jonathan Cameron  wrote:
> On 18/03/17 17:34, SIMRAN SINGHAL wrote:
>> On Thu, Mar 16, 2017 at 3:23 AM, Jonathan Cameron  wrote:
>>> On 13/03/17 19:53, Alison Schofield wrote:
 On Mon, Mar 13, 2017 at 10:01:07PM +0530, simran singhal wrote:
> The IIO subsystem is redefining iio_dev->mlock to be used by
> the IIO core only for protecting device operating mode changes.
> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
>
> In this driver, mlock was being used to protect hardware state
> changes.  Replace it with a lock in the devices global data.
>
> Fix some coding style issues related to white space also.
>
> Signed-off-by: simran singhal 
> ---
>
>  v2:
>-Removed new lock to reuse the existing lock
 Simran,

 The good news is that you have 2 patches that have similar
 challenges!  I'll suggest picking one, drive it to completion,
 then do the other.

 This has the nested locking issue that Lars warned about.
 Need to refactor to avoid.  Check back on his review comments.

 I suggest dropping those whitespace changes - they appear
 out of place in this patch since you are no longer actually
 touching those lines of code.

 alisons
>>> Also missing a mutex_init, though that may well become irrelevant
>>> with refactoring as suggested.
>>
>> Jonathon, what I found by looking at the codes of other drivers is that
>> we have to use mutex_init in probe function only.
>>
>> Is this correct?
> Yes, it only needs initializing once.
>>
So, no need of using mutex_init here as the function is not a
probe function.

Thanks
Simran

>> And this patch also suggest the same:-
>> https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=testing&id=388c8f18ff29fe95dbf72cb0a1bd8fbcd6f52f8f
>>


>
>  drivers/staging/iio/meter/ade7753.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/iio/meter/ade7753.c 
> b/drivers/staging/iio/meter/ade7753.c
> index dfd8b71..d88eaa3 100644
> --- a/drivers/staging/iio/meter/ade7753.c
> +++ b/drivers/staging/iio/meter/ade7753.c
> @@ -83,10 +83,10 @@
>   * @buf_lock:   mutex to protect tx and rx
>   **/
>  struct ade7753_state {
> -struct spi_device   *us;
> -struct mutexbuf_lock;
> -u8  tx[ADE7753_MAX_TX] 
> cacheline_aligned;
> -u8  rx[ADE7753_MAX_RX];
> +struct spi_device   *us;
> +struct mutexbuf_lock;
> +u8  tx[ADE7753_MAX_TX] cacheline_aligned;
> +u8  rx[ADE7753_MAX_RX];
>  };
>
>  static int ade7753_spi_write_reg_8(struct device *dev,
> @@ -484,7 +484,7 @@ static ssize_t ade7753_write_frequency(struct device 
> *dev,
>  if (!val)
>  return -EINVAL;
>
> -mutex_lock(&indio_dev->mlock);
> +mutex_lock(&st->buf_lock);
>
>  t = 27900 / val;
>  if (t > 0)
> @@ -505,7 +505,7 @@ static ssize_t ade7753_write_frequency(struct device 
> *dev,
>  ret = ade7753_spi_write_reg_16(dev, ADE7753_MODE, reg);
>
>  out:
> -mutex_unlock(&indio_dev->mlock);
> +mutex_unlock(&st->buf_lock);
>
>  return ret ? ret : len;
>  }
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170313163107.GA31496%40singhal-Inspiron-5558.
> For more options, visit https://groups.google.com/d/optout.
 --
 To unsubscribe from this list: send the line "unsubscribe linux-iio" in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH v5 00/39] i.MX Media Driver

[Russell King - ARM Linux]

Hi Steve,

I've just been trying to get gstreamer to capture and h264 encode
video from my camera at various frame rates, and what I've discovered
does not look good.

1) when setting frame rates, media-ctl _always_ calls
   VIDIOC_SUBDEV_S_FRAME_INTERVAL with pad=0.

2) media-ctl never retrieves the frame interval information, so there's
   no way to read it back with standard tools, and no indication that
   this is going on...

3) gstreamer v4l2src is getting upset, because it can't enumerate the
   frame sizes (VIDIOC_ENUM_FRAMESIZES fails), which causes it to
   fallback to using the "tvnorms" to decide about frame rates.  This
   makes it impossible to use frame rates higher than 3/1001, and
   causes the pipeline validation to fail.

0:00:01.937465845 20954  0x15ffe90 DEBUG   v4l2 
gstv4l2object.c:2474:gst_v4l2_object_probe_caps_for_format: 
Enumerating frame sizes for RGGB
0:00:01.937588518 20954  0x15ffe90 DEBUG   v4l2 
gstv4l2object.c:2601:gst_v4l2_object_probe_caps_for_format: Failed to 
enumerate frame sizes for pixelformat RGGB (Inappropriate ioctl for device)
0:00:01.937879535 20954  0x15ffe90 LOG v4l2 
gstv4l2object.c:2708:gst_v4l2_object_get_nearest_size: getting 
nearest size to 1x1 with format RGGB
0:00:01.937990874 20954  0x15ffe90 LOG v4l2 
gstv4l2object.c:2724:gst_v4l2_object_get_nearest_size: got nearest 
size 816x616
0:00:01.938250889 20954  0x15ffe90 ERROR   v4l2 
gstv4l2object.c:1873:gst_v4l2_object_get_interlace_mode: Driver bug detected - 
check driver with v4l2-compliance from http://git.linuxtv.org/v4l-utils.git
0:00:01.938326893 20954  0x15ffe90 LOG v4l2 
gstv4l2object.c:2708:gst_v4l2_object_get_nearest_size: getting 
nearest size to 32768x32768 with format RGGB
0:00:01.938431566 20954  0x15ffe90 LOG v4l2 
gstv4l2object.c:2724:gst_v4l2_object_get_nearest_size: got nearest 
size 816x616
0:00:01.939776641 20954  0x15ffe90 ERROR   v4l2 
gstv4l2object.c:1873:gst_v4l2_object_get_interlace_mode: Driver bug detected - 
check driver with v4l2-compliance from http://git.linuxtv.org/v4l-utils.git
0:00:01.940110660 20954  0x15ffe90 DEBUG   v4l2 
gstv4l2object.c:1955:gst_v4l2_object_get_colorspace: Unknown enum 
v4l2_colorspace 0

   This triggers the "/* Since we can't get framerate directly, try to
   use the current norm */" code in v4l2object.c, which causes it to
   select one of the 3/1001 norms:

0:00:01.955927879 20954  0x15ffe90 INFOv4l2 
gstv4l2object.c:3811:gst_v4l2_object_get_caps: probed caps: 
video/x-bayer, format=(string)rggb, framerate=(fraction)3/1001, 
width=(int)816, height=(int)616, pixel-aspect-ratio=(fraction)1/1; video/x-raw, 
format=(string)I420, framerate=(fraction)3/1001, width=(int)816, 
height=(int)616, interlace-mode=(string)progressive, 
pixel-aspect-ratio=(fraction)1/1; video/x-raw, format=(string)YV12, 
framerate=(fraction)3/1001, width=(int)816, height=(int)616, 
interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1; 
video/x-raw, format=(string)BGR, framerate=(fraction)3/1001, 
width=(int)816, height=(int)616, interlace-mode=(string)progressive, 
pixel-aspect-ratio=(fraction)1/1; video/x-raw, format=(string)RGB, 
framerate=(fraction)3/1001, width=(int)816, height=(int)616, 
interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1

   despite the media pipeline actually being configured for 60fps.

   Forcing it by adjusting the pipeline only results in gstreamer
   failing, because it believes that v4l2 is unable to operate at
   60fps.

   Also note the complaints from v4l2src about the non-compliance...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 00/39] i.MX Media Driver

[Steve Longerbeam]

On 03/18/2017 12:22 PM, Russell King - ARM Linux wrote:

Hi Steve,

I've just been trying to get gstreamer to capture and h264 encode
video from my camera at various frame rates, and what I've discovered
does not look good.

1) when setting frame rates, media-ctl _always_ calls
VIDIOC_SUBDEV_S_FRAME_INTERVAL with pad=0.

2) media-ctl never retrieves the frame interval information, so there's
no way to read it back with standard tools, and no indication that
this is going on...


I think Philipp Zabel submitted a patch which addresses these
in media-ctl. Check with him.



3) gstreamer v4l2src is getting upset, because it can't enumerate the
frame sizes (VIDIOC_ENUM_FRAMESIZES fails),


Right, imx-media-capture.c (the "standard" v4l2 user interface module)
is not implementing VIDIOC_ENUM_FRAMESIZES. It should, but it can only
return the single frame size that the pipeline has configured (the mbus
format of the attached source pad).


  which causes it to
fallback to using the "tvnorms" to decide about frame rates.  This
makes it impossible to use frame rates higher than 3/1001, and
causes the pipeline validation to fail.


In v5 I added validation of frame intervals between pads,
but due to negative feedback I've pulled that. So next
version will not attempt to validate frame intervals between
source->sink pads.

Can you share your gstreamer pipeline? For now, until
VIDIOC_ENUM_FRAMESIZES is implemented, try a pipeline that
does not attempt to specify a frame rate. I use the attached
script for testing, which works for me.





0:00:01.937465845 20954  0x15ffe90 DEBUG   v4l2 
gstv4l2object.c:2474:gst_v4l2_object_probe_caps_for_format: 
Enumerating frame sizes for RGGB
0:00:01.937588518 20954  0x15ffe90 DEBUG   v4l2 
gstv4l2object.c:2601:gst_v4l2_object_probe_caps_for_format: Failed to 
enumerate frame sizes for pixelformat RGGB (Inappropriate ioctl for device)
0:00:01.937879535 20954  0x15ffe90 LOG v4l2 
gstv4l2object.c:2708:gst_v4l2_object_get_nearest_size: getting 
nearest size to 1x1 with format RGGB
0:00:01.937990874 20954  0x15ffe90 LOG v4l2 
gstv4l2object.c:2724:gst_v4l2_object_get_nearest_size: got nearest 
size 816x616
0:00:01.938250889 20954  0x15ffe90 ERROR   v4l2 
gstv4l2object.c:1873:gst_v4l2_object_get_interlace_mode: Driver bug detected - 
check driver with v4l2-compliance from http://git.linuxtv.org/v4l-utils.git
0:00:01.938326893 20954  0x15ffe90 LOG v4l2 
gstv4l2object.c:2708:gst_v4l2_object_get_nearest_size: getting 
nearest size to 32768x32768 with format RGGB
0:00:01.938431566 20954  0x15ffe90 LOG v4l2 
gstv4l2object.c:2724:gst_v4l2_object_get_nearest_size: got nearest 
size 816x616
0:00:01.939776641 20954  0x15ffe90 ERROR   v4l2 
gstv4l2object.c:1873:gst_v4l2_object_get_interlace_mode: Driver bug detected - 
check driver with v4l2-compliance from http://git.linuxtv.org/v4l-utils.git
0:00:01.940110660 20954  0x15ffe90 DEBUG   v4l2 
gstv4l2object.c:1955:gst_v4l2_object_get_colorspace: Unknown enum 
v4l2_colorspace 0

This triggers the "/* Since we can't get framerate directly, try to
use the current norm */" code in v4l2object.c, which causes it to
select one of the 3/1001 norms:

0:00:01.955927879 20954  0x15ffe90 INFOv4l2 
gstv4l2object.c:3811:gst_v4l2_object_get_caps: probed caps: 
video/x-bayer, format=(string)rggb, framerate=(fraction)3/1001, width=(int)816, 
height=(int)616, pixel-aspect-ratio=(fraction)1/1; video/x-raw, format=(string)I420, 
framerate=(fraction)3/1001, width=(int)816, height=(int)616, 
interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1; video/x-raw, 
format=(string)YV12, framerate=(fraction)3/1001, width=(int)816, height=(int)616, 
interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1; video/x-raw, 
format=(string)BGR, framerate=(fraction)3/1001, width=(int)816, height=(int)616, 
interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1; video/x-raw, 
format=(string)RGB, framerate=(fraction)3/1001, width=(int)816, height=(int)616, 
interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1

despite the media pipeline actually being configured for 60fps.

Forcing it by adjusting the pipeline only results in gstreamer
failing, because it believes that v4l2 is unable to operate at
60fps.

Also note the complaints from v4l2src about the non-compliance...


Thanks, I've fixed most of v4l2-compliance issues, but this is not
done yet. Is that something you can help with?

Steve



udpstream.sh
Description: application/shellscript
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 00/39] i.MX Media Driver

[Steve Longerbeam]

Hi Russell,


On 03/14/2017 10:29 AM, Steve Longerbeam wrote:



On 03/12/2017 02:09 PM, Russell King - ARM Linux wrote:
On Sun, Mar 12, 2017 at 08:40:37PM +, Russell King - ARM Linux 
wrote:

On Sun, Mar 12, 2017 at 01:36:32PM -0700, Steve Longerbeam wrote:

But hold on, if my logic is correct, then why did the CSI power-off
get reached in your case, multiple times? Yes I think there is a bug,
link_notify() is not checking if the link has already been disabled.
I will fix this. But I'm surprised media core's link_notify handling
doesn't do this.

Well, I think there's something incredibly fishy going on here.  I
turned that dev_dbg() at the top of the function into a dev_info(),
and I get:

root@hbi2ex:~# dmesg |grep -A2 imx-ipuv3-csi
[   53.370949] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF
[   53.371015] [ cut here ]
[   53.371075] WARNING: CPU: 0 PID: 1515 at 
drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 
[imx_media_csi]

--
[   53.372624] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF
[   53.372637] [ cut here ]
[   53.372663] WARNING: CPU: 0 PID: 1515 at 
drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 
[imx_media_csi]


There isn't a power on event being generated before these two power
off events.  I don't see a power on event even when I attempt to
start streaming either (which fails due to the lack of bayer
support.)

Found it - my imx219 driver returns '1' from its s_power function when
powering up, which triggers a bug in your code - when 
imx_media_set_power()

fails to power up, you call imx_media_set_power() telling it to power
everything off - including devices that are already powered off.


Yep, there's a bug in the error cleanup in 
imx_media_pipeline_set_power().
On error, it needs to backout by calling s_power(off) as it is doing, 
but not

through the whole pipeline, but needs to stop at the subdev encountered
just before the subdev that failed. This was causing the s_power() 
imbalance.

I will fix.



Due to some fixes to ov5640 from version 4, v4l2_pipeline_pm APIs are 
working

now, so I've removed imx_media_pipeline_set_power() and switched to
v4l2_pipeline_pm_use() in capture device open/release and 
v4l2_pipeline_link_notify()

in imx_media_link_notify(), for the pipeline power management.

Steve

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

[PATCH 0/3] staging: speakup: Multiple checkpatch issues

[Arushi Singhal]

Improve readability by fixing multiple checkpatch.pl
issues in speakup driver.

Arushi Singhal (3):
  staging: speakup: Moved logical to previous line.
  staging: speakup: Remove multiple assignments
  staging: speakup: Simplify "NULL" comparisons

 drivers/staging/speakup/main.c| 30 ++
 drivers/staging/speakup/selection.c   |  2 +-
 drivers/staging/speakup/varhandlers.c |  6 +++---
 3 files changed, 22 insertions(+), 16 deletions(-)

-- 
2.11.0

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

[PATCH 3/3] staging: speakup: Simplify "NULL" comparisons

[Arushi Singhal]

Fixed coding style for null comparisons in speakup driver to be more
consistant with the rest of the kernel coding style.
Replaced 'x != NULL' with 'x' and 'x = NULL' with '!x'.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/selection.c   | 2 +-
 drivers/staging/speakup/varhandlers.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/selection.c 
b/drivers/staging/speakup/selection.c
index afd9a446a06f..4417c00e68a7 100644
--- a/drivers/staging/speakup/selection.c
+++ b/drivers/staging/speakup/selection.c
@@ -175,7 +175,7 @@ static struct speakup_paste_work speakup_paste_work = {
 
 int speakup_paste_selection(struct tty_struct *tty)
 {
-   if (cmpxchg(&speakup_paste_work.tty, NULL, tty) != NULL)
+   if (cmpxchg(&speakup_paste_work.tty, NULL, tty))
return -EBUSY;
 
tty_kref_get(tty);
diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index cc984196020f..5910fe0b1365 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -98,7 +98,7 @@ void speakup_register_var(struct var_t *var)
}
}
p_header = var_ptrs[var->var_id];
-   if (p_header->data != NULL)
+   if (p_header->data)
return;
p_header->data = var;
switch (p_header->var_type) {
@@ -210,11 +210,11 @@ int spk_set_num_var(int input, struct st_var_header *var, 
int how)
return -ERANGE;
 
var_data->u.n.value = val;
-   if (var->var_type == VAR_TIME && p_val != NULL) {
+   if (var->var_type == VAR_TIME && p_val) {
*p_val = msecs_to_jiffies(val);
return 0;
}
-   if (p_val != NULL)
+   if (p_val)
*p_val = val;
if (var->var_id == PUNC_LEVEL) {
spk_punc_mask = spk_punc_masks[val];
-- 
2.11.0

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

[PATCH 1/3] staging: speakup: Moved logical to previous line.

[Arushi Singhal]

Moved logical OR operator to previous line to fix the following
checkpatch issue:

CHECK: Logical continuations should be on the previous line.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index f280e22d7e15..f71206878363 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -905,8 +905,8 @@ static int get_sentence_buf(struct vc_data *vc, int 
read_punc)
while (start < end) {
sentbuf[bn][i] = get_char(vc, (u_short *)start, &tmp);
if (i > 0) {
-   if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == '.'
-   && numsentences[bn] < 9) {
+   if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == 
'.' &&
+   numsentences[bn] < 9) {
/* Sentence Marker */
numsentences[bn]++;
sentmarks[bn][numsentences[bn]] =
@@ -1292,8 +1292,8 @@ void spk_reset_default_chars(void)
 
/* First, free any non-default */
for (i = 0; i < 256; i++) {
-   if ((spk_characters[i] != NULL)
-   && (spk_characters[i] != spk_default_chars[i]))
+   if (spk_characters[i] &&
+   (spk_characters[i] != spk_default_chars[i]))
kfree(spk_characters[i]);
}
 
@@ -2088,8 +2088,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
tty = vc->port.tty;
if (type >= 0xf0)
type -= 0xf0;
-   if (type == KT_PAD
-   && (vt_get_leds(fg_console, VC_NUMLOCK))) {
+   if (type == KT_PAD &&
+   (vt_get_leds(fg_console, VC_NUMLOCK))) {
if (up_flag) {
spk_keydown = 0;
goto out;
-- 
2.11.0

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

[PATCH 2/3] staging: speakup: Remove multiple assignments

[Arushi Singhal]

This patch fixes the checkpatch.pl warning "multiple assignments
should be avoided."

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index f71206878363..f8fccc8bf6b2 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -270,9 +270,12 @@ static unsigned char get_attributes(struct vc_data *vc, 
u16 *pos)
 
 static void speakup_date(struct vc_data *vc)
 {
-   spk_x = spk_cx = vc->vc_x;
-   spk_y = spk_cy = vc->vc_y;
-   spk_pos = spk_cp = vc->vc_pos;
+   spk_x = vc->vc_x;
+   spk_cx = spk_x;
+   spk_y = vc->vc_y;
+   spk_cy = spk_y;
+   spk_pos = vc->vc_pos;
+   spk_cp = spk_pos;
spk_old_attr = spk_attr;
spk_attr = get_attributes(vc, (u_short *)spk_pos);
 }
@@ -1655,9 +1658,12 @@ static int speak_highlight(struct vc_data *vc)
spk_do_flush();
spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
speakup_console[vc_num]->ht.highsize[hc]);
-   spk_pos = spk_cp = speakup_console[vc_num]->ht.rpos[hc];
-   spk_x = spk_cx = speakup_console[vc_num]->ht.rx[hc];
-   spk_y = spk_cy = speakup_console[vc_num]->ht.ry[hc];
+   spk_pos = speakup_console[vc_num]->ht.rpos[hc];
+   spk_cp = spk_pos;
+   spk_x = speakup_console[vc_num]->ht.rx[hc];
+   spk_cx = spk_x;
+   spk_y = speakup_console[vc_num]->ht.ry[hc];
+   spk_cy = spk_y;
return 1;
}
return 0;
-- 
2.11.0

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

Re: [Outreachy kernel] [PATCH 1/3] staging: speakup: Moved logical to previous line.

[Julia Lawall]

The subject appears to be missing some words.  logical what?

On Sun, 19 Mar 2017, Arushi Singhal wrote:

> Moved logical OR operator to previous line to fix the following
> checkpatch issue:

All the instances appear to be && not ||

julia

> CHECK: Logical continuations should be on the previous line.
>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/main.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index f280e22d7e15..f71206878363 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -905,8 +905,8 @@ static int get_sentence_buf(struct vc_data *vc, int 
> read_punc)
>   while (start < end) {
>   sentbuf[bn][i] = get_char(vc, (u_short *)start, &tmp);
>   if (i > 0) {
> - if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == '.'
> - && numsentences[bn] < 9) {
> + if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == 
> '.' &&
> + numsentences[bn] < 9) {
>   /* Sentence Marker */
>   numsentences[bn]++;
>   sentmarks[bn][numsentences[bn]] =
> @@ -1292,8 +1292,8 @@ void spk_reset_default_chars(void)
>
>   /* First, free any non-default */
>   for (i = 0; i < 256; i++) {
> - if ((spk_characters[i] != NULL)
> - && (spk_characters[i] != spk_default_chars[i]))
> + if (spk_characters[i] &&
> + (spk_characters[i] != spk_default_chars[i]))
>   kfree(spk_characters[i]);
>   }
>
> @@ -2088,8 +2088,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
> keycode, u_short keysym,
>   tty = vc->port.tty;
>   if (type >= 0xf0)
>   type -= 0xf0;
> - if (type == KT_PAD
> - && (vt_get_leds(fg_console, VC_NUMLOCK))) {
> + if (type == KT_PAD &&
> + (vt_get_leds(fg_console, VC_NUMLOCK))) {
>   if (up_flag) {
>   spk_keydown = 0;
>   goto out;
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170318202559.10886-2-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 00/39] i.MX Media Driver

[Russell King - ARM Linux]

On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote:
> Can you share your gstreamer pipeline? For now, until
> VIDIOC_ENUM_FRAMESIZES is implemented, try a pipeline that
> does not attempt to specify a frame rate. I use the attached
> script for testing, which works for me.

It's nothing more than

  gst-launch-1.0 -v v4l2src !  ! xvimagesink

in my case, the conversions are bayer2rgbneon.  However, this only shows
you the frame rate negotiated on the pads (which is actually good enough
to show the issue.)

How I stumbled across though this was when I was trying to encode:

 gst-launch-1.0 v4l2src device=/dev/video9 ! bayer2rgbneon ! \
videoconvert ! x264enc speed-preset=1 ! avimux ! \
filesink location=test.avi

I noticed that vlc would always say it was playing the resulting AVI
at 30fps.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: speakup: fixes braces {} used on all arms of this statement

[Arushi Singhal]

This patch fixes the checks reported by checkpatch.pl
for braces {} should be used on all arms of this statement.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c   | 35 +++-
 drivers/staging/speakup/speakup_decext.c |  6 +++---
 drivers/staging/speakup/speakup_decpc.c  |  6 +++---
 drivers/staging/speakup/speakup_dectlk.c |  6 +++---
 drivers/staging/speakup/varhandlers.c| 12 ++-
 5 files changed, 37 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index f8fccc8bf6b2..21e76b031449 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -409,8 +409,9 @@ static void say_attributes(struct vc_data *vc)
if (bg > 7) {
synth_printf(" %s ", spk_msg_get(MSG_ON_BLINKING));
bg -= 8;
-   } else
+   } else {
synth_printf(" %s ", spk_msg_get(MSG_ON));
+   }
synth_printf("%s\n", spk_msg_get(MSG_COLORS_START + bg));
 }
 
@@ -643,8 +644,9 @@ static void say_prev_word(struct vc_data *vc)
break;
spk_y--;
spk_x = vc->vc_cols - 1;
-   } else
+   } else {
spk_x--;
+   }
spk_pos -= 2;
ch = get_char(vc, (u_short *)spk_pos, &temp);
if (ch == SPACE || ch == 0)
@@ -697,8 +699,9 @@ static void say_next_word(struct vc_data *vc)
spk_y++;
spk_x = 0;
edge_said = edge_right;
-   } else
+   } else {
spk_x++;
+   }
spk_pos += 2;
last_state = state;
}
@@ -729,8 +732,9 @@ static void spell_word(struct vc_data *vc)
spk_pitch_shift++;
else/* synth has no pitch */
last_cap = spk_str_caps_stop;
-   } else
+   } else {
str_cap = spk_str_caps_stop;
+   }
if (str_cap != last_cap) {
synth_printf("%s", str_cap);
last_cap = str_cap;
@@ -1343,8 +1347,9 @@ static int speakup_allocate(struct vc_data *vc)
if (!speakup_console[vc_num])
return -ENOMEM;
speakup_date(vc);
-   } else if (!spk_parked)
+   } else if (!spk_parked) {
speakup_date(vc);
+   }
 
return 0;
 }
@@ -1397,9 +1402,9 @@ static void read_all_doc(struct vc_data *vc)
prev_cursor_track = cursor_track;
cursor_track = read_all_mode;
spk_reset_index_count(0);
-   if (get_sentence_buf(vc, 0) == -1)
+   if (get_sentence_buf(vc, 0) == -1) {
kbd_fakekey2(vc, RA_DOWN_ARROW);
-   else {
+   } else {
say_sentence_num(0, 0);
synth_insert_next_index(0);
start_read_all_timer(vc, RA_TIMER);
@@ -1446,8 +1451,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
int command)
if (!say_sentence_num(sentcount + 1, 1)) {
sn = 1;
spk_reset_index_count(sn);
-   } else
+   } else {
synth_insert_next_index(0);
+   }
if (!say_sentence_num(sn, 0)) {
kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
return;
@@ -1476,9 +1482,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
int command)
rv = get_sentence_buf(vc, 0);
if (rv == -1)
read_all_doc(vc);
-   if (rv == 0)
+   if (rv == 0) {
kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
-   else {
+   } else {
say_sentence_num(1, 0);
synth_insert_next_index(0);
start_read_all_timer(vc, RA_TIMER);
@@ -2177,10 +2183,11 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
if (type == KT_SPEC && value == 1) {
value = '\n';
type = KT_LATIN;
-   } else if (type == KT_LETTER)
+   } else if (type == KT_LETTER) {
type = KT_LATIN;
-   else if (value == 0x7f)
+   } else if (value == 0x7f) {
value = 8;  /* make del = backspace */
+   }
ret = (*spk_special_handler) (vc, type, value, keycode);
spk_close_press = 0;
if (ret < 0)
@@ -2274,9 +2281,9 @@ static int vt_notifier_call(struct notifier_block *n

[PATCH v2 3/6] staging: media: atomisp: select REGMAP_I2C needed by ap1302.c

[Jérémy Lefaure]

REGMAP_I2C should be enabled to build the driver ap1302 because it uses
regmap functions.

Signed-off-by: Jérémy Lefaure 
---
v2: rebase on staging-testing

 drivers/staging/media/atomisp/i2c/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/i2c/Kconfig 
b/drivers/staging/media/atomisp/i2c/Kconfig
index 30b0bb94f20d..b80d29d53e65 100644
--- a/drivers/staging/media/atomisp/i2c/Kconfig
+++ b/drivers/staging/media/atomisp/i2c/Kconfig
@@ -62,6 +62,7 @@ config VIDEO_MT9M114
 config VIDEO_AP1302
tristate "AP1302 external ISP support"
depends on I2C && VIDEO_V4L2
+   select REGMAP_I2C
---help---
  This is a Video4Linux2 sensor-level driver for the external
  ISP AP1302.
-- 
2.12.0

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

[PATCH v2 2/6] staging: media: atomisp: add missing dependencies in Kconfig

[Jérémy Lefaure]

Two dependencies were missing to build atomisp drivers:

_ MEDIA_CONTROLLER: to use the entity field of v4l2_subdev structure. Since
every atomisp driver needs MEDIA_CONTROLLER has a dependency, let's add it
to INTEL_ATOMISP

_ EFI: to use efivar_entry_get:
drivers/built-in.o: In function `gmin_get_config_var':
(.text+0xe062b): undefined reference to `efivar_entry_get'

Signed-off-by: Jérémy Lefaure 
---
v2:
* rebased on staging-testing
* removed ACPI and VIDEO_V4L2_SUBDEV_API dependencies as I am not sure that
it's the best solution to fix the building issue.

 drivers/staging/media/atomisp/Kconfig| 2 +-
 drivers/staging/media/atomisp/i2c/ov5693/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/Kconfig 
b/drivers/staging/media/atomisp/Kconfig
index f7d8a841c629..28615aaa2a5d 100644
--- a/drivers/staging/media/atomisp/Kconfig
+++ b/drivers/staging/media/atomisp/Kconfig
@@ -1,6 +1,6 @@
 menuconfig INTEL_ATOMISP
 bool "Enable support to Intel MIPI camera drivers"
-depends on X86
+depends on X86 && EFI && MEDIA_CONTROLLER
 help
   Enable support for the Intel ISP2 camera interfaces and MIPI
   sensor drivers.
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/Kconfig 
b/drivers/staging/media/atomisp/i2c/ov5693/Kconfig
index 3954b8c65fd1..9fb1bffbe9b3 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/Kconfig
+++ b/drivers/staging/media/atomisp/i2c/ov5693/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_OV5693
tristate "Omnivision ov5693 sensor support"
-   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on I2C && VIDEO_V4L2
---help---
  This is a Video4Linux2 sensor-level driver for the Micron
  ov5693 5 Mpixel camera.
-- 
2.12.0

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

[PATCH] Staging: ks7010 - fixed style block comments

[Derek Robson]

Fixed style of all block comments across whole driver
Found by checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/ks7010/ks7010_sdio.c |  3 ++-
 drivers/staging/ks7010/ks_hostif.h   | 35 +-
 drivers/staging/ks7010/ks_wlan.h |  3 ++-
 drivers/staging/ks7010/ks_wlan_net.c | 41 +++-
 4 files changed, 55 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
b/drivers/staging/ks7010/ks7010_sdio.c
index 6f9f746a3a61..1311e83b99d8 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -496,7 +496,8 @@ static void ks7010_rw_function(struct work_struct *work)
while (time_after(priv->last_wakeup + ((30 * HZ) / 1000), jiffies)) {
DPRINTK(4, "wait after WAKEUP\n");
 /* 
queue_delayed_work(priv->ks_wlan_hw.ks7010sdio_wq,&priv->ks_wlan_hw.rw_wq,
-   (priv->last_wakeup + ((30*HZ)/1000) - jiffies));*/
+ * (priv->last_wakeup + ((30*HZ)/1000) - jiffies));
+ */
dev_info(&priv->ks_wlan_hw.sdio_card->func->dev,
 "wake: %lu %lu\n",
 priv->last_wakeup + (30 * HZ) / 1000,
diff --git a/drivers/staging/ks7010/ks_hostif.h 
b/drivers/staging/ks7010/ks_hostif.h
index 30c49b699d62..c7636e829c40 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -360,8 +360,11 @@ struct hostif_ps_adhoc_set_request_t {
 #define CTS_MODE_TRUE  1
uint16_t channel;
struct rate_set16_t rate_set;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
-* bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
+   uint16_t capability;/* bit5:preamble
+* bit6:pbcc pbcc not supported always 0
+* bit10:ShortSlotTime
+* bit13:DSSS-OFDM DSSS-OFDM not supported 
always 0
+*/
uint16_t scan_type;
 } __packed;
 
@@ -376,8 +379,11 @@ struct hostif_infrastructure_set_request_t {
uint16_t cts_mode;
struct rate_set16_t rate_set;
struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
-* bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
+   uint16_t capability;/* bit5:preamble
+* bit6:pbcc pbcc not supported always 0
+* bit10:ShortSlotTime
+* bit13:DSSS-OFDM DSSS-OFDM not supported 
always 0
+*/
uint16_t beacon_lost_count;
uint16_t auth_type;
 #define AUTH_TYPE_OPEN_SYSTEM 0
@@ -392,8 +398,11 @@ struct hostif_infrastructure_set2_request_t {
uint16_t cts_mode;
struct rate_set16_t rate_set;
struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
-* bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
+   uint16_t capability;/* bit5:preamble
+* bit6:pbcc pbcc not supported always 0
+* bit10:ShortSlotTime
+* bit13:DSSS-OFDM DSSS-OFDM not supported 
always 0
+*/
uint16_t beacon_lost_count;
uint16_t auth_type;
 #define AUTH_TYPE_OPEN_SYSTEM 0
@@ -415,8 +424,11 @@ struct hostif_adhoc_set_request_t {
uint16_t channel;
struct rate_set16_t rate_set;
struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
-* bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
+   uint16_t capability;/* bit5:preamble
+* bit6:pbcc pbcc not supported always 0
+* bit10:ShortSlotTime
+* bit13:DSSS-OFDM DSSS-OFDM not supported 
always 0
+*/
uint16_t scan_type;
 } __packed;
 
@@ -427,8 +439,11 @@ struct hostif_adhoc_set2_request_t {
uint16_t reserved;
struct rate_set16_t rate_set;
struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
-* bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
+   uint16_t capability;/* bit5:preamble
+* bit6:pbcc pbcc not supported always 0
+* bit10:ShortSlotTime
+* bit13:DSSS-OFDM DSSS-OFDM not supported 
always 0
+*/
uint16_t scan_type;
   

Re: [PATCH v5 00/39] i.MX Media Driver

[Nicolas Dufresne]

Le samedi 18 mars 2017 à 20:43 +, Russell King - ARM Linux a
écrit :
> On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote:
> > Can you share your gstreamer pipeline? For now, until
> > VIDIOC_ENUM_FRAMESIZES is implemented, try a pipeline that
> > does not attempt to specify a frame rate. I use the attached
> > script for testing, which works for me.
> 
> It's nothing more than
> 
>   gst-launch-1.0 -v v4l2src !  ! xvimagesink
> 
> in my case, the conversions are bayer2rgbneon.  However, this only
> shows
> you the frame rate negotiated on the pads (which is actually good
> enough
> to show the issue.)
> 
> How I stumbled across though this was when I was trying to encode:
> 
>  gst-launch-1.0 v4l2src device=/dev/video9 ! bayer2rgbneon ! \
> videoconvert ! x264enc speed-preset=1 ! avimux ! \
> filesink location=test.avi
> 
> I noticed that vlc would always say it was playing the resulting AVI
> at 30fps.

In practice, I have the impression there is a fair reason why framerate
enumeration isn't implemented (considering there is only 1 valid rate).
Along with the norm fallback, GStreamer could could also consider the
currently set framerate as returned by VIDIOC_G_PARM. At the same time,
implementing that enumeration shall be straightforward, and will make a
large amount of existing userspace work.

regards,
Nicolas

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 v5 00/39] i.MX Media Driver

[Russell King - ARM Linux]

On Sat, Mar 18, 2017 at 08:41:14PM -0400, Nicolas Dufresne wrote:
> Le samedi 18 mars 2017 à 20:43 +, Russell King - ARM Linux a
> écrit :
> > On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote:
> > > Can you share your gstreamer pipeline? For now, until
> > > VIDIOC_ENUM_FRAMESIZES is implemented, try a pipeline that
> > > does not attempt to specify a frame rate. I use the attached
> > > script for testing, which works for me.
> > 
> > It's nothing more than
> > 
> >   gst-launch-1.0 -v v4l2src !  ! xvimagesink
> > 
> > in my case, the conversions are bayer2rgbneon.  However, this only
> > shows
> > you the frame rate negotiated on the pads (which is actually good
> > enough
> > to show the issue.)
> > 
> > How I stumbled across though this was when I was trying to encode:
> > 
> >  gst-launch-1.0 v4l2src device=/dev/video9 ! bayer2rgbneon ! \
> > videoconvert ! x264enc speed-preset=1 ! avimux ! \
> > filesink location=test.avi
> > 
> > I noticed that vlc would always say it was playing the resulting AVI
> > at 30fps.
> 
> In practice, I have the impression there is a fair reason why framerate
> enumeration isn't implemented (considering there is only 1 valid rate).

That's actually completely incorrect.

With the capture device interfacing directly with CSI, it's possible
_today_ to select:

* the CSI sink pad's resolution
* the CSI sink pad's resolution with the width and/or height halved
* the CSI sink pad's frame rate
* the CSI sink pad's frame rate divided by the frame drop factor

To put it another way, these are possible:

# v4l2-ctl -d /dev/video10 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Index   : 0
Type: Video Capture
Pixel Format: 'RGGB'
Name: 8-bit Bayer RGRG/GBGB
Size: Discrete 816x616
Interval: Discrete 0.040s (25.000 fps)
Interval: Discrete 0.048s (20.833 fps)
Interval: Discrete 0.050s (20.000 fps)
Interval: Discrete 0.053s (18.750 fps)
Interval: Discrete 0.060s (16.667 fps)
Interval: Discrete 0.067s (15.000 fps)
Interval: Discrete 0.080s (12.500 fps)
Interval: Discrete 0.100s (10.000 fps)
Interval: Discrete 0.120s (8.333 fps)
Interval: Discrete 0.160s (6.250 fps)
Interval: Discrete 0.200s (5.000 fps)
Interval: Discrete 0.240s (4.167 fps)
Size: Discrete 408x616

Size: Discrete 816x308

Size: Discrete 408x308


These don't become possible as a result of implementing the enums,
they're all already requestable through /dev/video10.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: rtl8192e - fixed style of block comments

[Derek Robson]

Fixed style of block comment across whole driver
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192e/rtl8192e/r8190P_def.h |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.c |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.h |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c  |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.h  |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_dev.h |  2 +-
 .../staging/rtl8192e/rtl8192e/r8192E_firmware.c|  2 +-
 .../staging/rtl8192e/rtl8192e/r8192E_firmware.h|  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_hw.h  |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_hwimg.h   |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_phy.h |  2 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_phyreg.h  |  4 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_cam.c|  2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_cam.h|  2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c   | 30 ++---
 drivers/staging/rtl8192e/rtl8192e/rtl_core.h   |  2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c |  4 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_dm.h |  2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_eeprom.c |  2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_eeprom.h |  2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_pm.c |  2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_pm.h |  2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_wx.c |  2 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_wx.h |  2 +-
 drivers/staging/rtl8192e/rtl819x_BA.h  |  2 +-
 drivers/staging/rtl8192e/rtl819x_HT.h  |  2 +-
 drivers/staging/rtl8192e/rtl819x_Qos.h |  2 +-
 drivers/staging/rtl8192e/rtl819x_TS.h  |  2 +-
 drivers/staging/rtl8192e/rtllib.h  |  6 ++-
 drivers/staging/rtl8192e/rtllib_debug.h|  2 +-
 drivers/staging/rtl8192e/rtllib_module.c   | 52 +++---
 drivers/staging/rtl8192e/rtllib_wx.c   | 52 +++---
 34 files changed, 103 insertions(+), 101 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/r8190P_def.h 
b/drivers/staging/rtl8192e/rtl8192e/r8190P_def.h
index 34453e38ba93..03421033d14a 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8190P_def.h
+++ b/drivers/staging/rtl8192e/rtl8192e/r8190P_def.h
@@ -11,7 +11,7 @@
  *
  * Contact Information:
  * wlanfae 
-**/
+ */
 
 
 #ifndef R8190P_DEF_H
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.c 
b/drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.c
index 81b3cf6588d4..85f93056d28b 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.c
@@ -11,7 +11,7 @@
  *
  * Contact Information:
  * wlanfae 
-**/
+ */
 
 #include "rtl_core.h"
 #include "r8192E_phyreg.h"
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.h 
b/drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.h
index 7873a73a2f76..bbea13b452b2 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.h
+++ b/drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.h
@@ -11,7 +11,7 @@
  *
  * Contact Information:
  * wlanfae 
-**/
+ */
 
 #ifndef RTL8225H
 #define RTL8225H
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c
index 757ffd4f2f89..467287ae6c1c 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c
@@ -11,7 +11,7 @@
  *
  * Contact Information:
  * wlanfae 
-**/
+ */
 
 #include "rtl_core.h"
 #include "r8192E_hw.h"
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.h 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.h
index 7dd15d993481..a8c63ad2ac2e 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.h
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.h
@@ -11,7 +11,7 @@
  *
  * Contact Information:
  * wlanfae 
-**/
+ */
 #ifndef R819XUSB_CMDPKT_H
 #define R819XUSB_CMDPKT_H
 
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c 
b/drivers/stagin

Re: [PATCH/RFC] staging/lustre: Rework class_process_proc_param

[Greg Kroah-Hartman]

On Sat, Mar 18, 2017 at 11:17:55AM -0400, Oleg Drokin wrote:
> 
> On Mar 18, 2017, at 6:34 AM, Greg Kroah-Hartman wrote:
> 
> > On Sat, Mar 18, 2017 at 02:24:08AM -0400, Oleg Drokin wrote:
> >> Ever since sysfs migration, class_process_proc_param stopped working
> >> correctly as all the useful params were no longer present as lvars.
> >> Replace all the nasty fake proc writes with hopefully less nasty
> >> kobject attribute search and then update the attributes as needed.
> >> 
> >> Signed-off-by: Oleg Drokin 
> >> Reported-by: Al Viro 
> >> ---
> >> Al has quite rightfully complained in the past that 
> >> class_process_proc_param
> >> is a terrible piece of code and needs to go.
> >> This patch is an attempt at improving it somewhat and in process drop
> >> all the user/kernel address space games we needed to play to make it work
> >> in the past (and which I suspect attracted Al's attention in the first 
> >> place).
> >> 
> >> Now I wonder if iterating kobject attributes like that would be ok with
> >> you Greg, or do you think there is a better way?
> >> class_find_write_attr could be turned into something generic since it's
> >> certainly convenient to reuse same table of name-write_method pairs,
> >> but I did some cursory research and nobody else seems to need anything
> >> of the sort in-tree.
> >> 
> >> I know ll_process_config is still awful and I will likely just
> >> replace the current hack with kset_find_obj, but I just wanted to make
> >> sure this new approach would be ok before spending too much time on it.
> > 
> > I'm not quite sure what exactly you are even trying to do here.  What is
> > this interface?  Who calls it, and how?  What does it want to do?
> 
> This is a configuration client code.
> Management server has ability to pass down config information in the form of:
> fsname.subsystem.attribute=value to clients and other servers
> (subsystem determines if it's something of interest of clients or servers or
> both).
> This could be changed in the real time - i.e. you update it on the server and
> that gets propagated to all the clients/servers, so no need to ssh into
> every node to manually apply those changes and worry about client restarts
> (the config is remembered at the management server and would be applied to any
> new nodes connecting/across server restarts and such).
> 
> So the way it then works then is once the string 
> fsname.subsystem.attribute=value is delivered to the client, we find all 
> instances of filesystem with fsname and then
> all subsystems within it (one kobject per subsystem instance) and then update 
> the
> attributes to the value supplied.
> 
> The same filesystem might be mounted more than once and then some layers 
> might have
> multiple instances inside a single filesystems.
> 
> In the end it would turn something like lustre.osc.max_dirty_mb=128 into
> writes to
> /sys/fs/lustre/osc/lustre-OST-osc-8800d75ca000/max_dirty_mb and
> /sys/fs/lustre/osc/lustre-OST0001-osc-8800d75ca000/max_dirty_mb
> without actually iterating in sysfs namespace.

Wait, who is doing the "write"?  From within the kernel?  Or some
userspace app?  I'm guessing from within the kernel, you are receiving
the data from some other transport within the filesystem and then need
to apply the settings?

> The alternative we considered is we can probably just do an upcall and have
> a userspace tool called with the parameter verbatim and try to figure it out,
> but that seems a lot less ideal, and also we'll get a bunch of complications 
> from
> containers and such too, I imagine.

Yeah, no, don't do an upcall, that's a mess.

> The function pre-this patch is assuming that all these values are part of
> a list of procfs values (no longer true after sysfs migration) so just 
> iterates
> that list and calls the write for matched names (but also needs to supply a 
> userspace
> buffer so looks much uglier too).

For kobjects, you don't need userspace buffers, so this should be
easier.

> Hopefully this makes at least some sense.

Yes, a bit more, but ugh, what a mess :)

> > You can look up attributes for a kobject easily in the show/store
> > functions (and some drivers just have a generic one and then you look at
> > the string to see which attribute you are wanting to reference.)  But
> > you seem to be working backwards here, why do you have to look up a
> > kobject?
> 
> But that leads to the need to list attribute names essentially twice:
> once for the attributes list, once in the show/set function to figure
> out how to deal with that name.

Yes, you don't need/want to do that.

Let me go review the code now with that info, thanks, it makes more
sense.

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

Re: [PATCH/RFC] staging/lustre: Rework class_process_proc_param

[Oleg Drokin]

On Mar 19, 2017, at 12:29 AM, Greg Kroah-Hartman wrote:

> On Sat, Mar 18, 2017 at 11:17:55AM -0400, Oleg Drokin wrote:
>> 
>> On Mar 18, 2017, at 6:34 AM, Greg Kroah-Hartman wrote:
>> 
>>> On Sat, Mar 18, 2017 at 02:24:08AM -0400, Oleg Drokin wrote:
 Ever since sysfs migration, class_process_proc_param stopped working
 correctly as all the useful params were no longer present as lvars.
 Replace all the nasty fake proc writes with hopefully less nasty
 kobject attribute search and then update the attributes as needed.
 
 Signed-off-by: Oleg Drokin 
 Reported-by: Al Viro 
 ---
 Al has quite rightfully complained in the past that 
 class_process_proc_param
 is a terrible piece of code and needs to go.
 This patch is an attempt at improving it somewhat and in process drop
 all the user/kernel address space games we needed to play to make it work
 in the past (and which I suspect attracted Al's attention in the first 
 place).
 
 Now I wonder if iterating kobject attributes like that would be ok with
 you Greg, or do you think there is a better way?
 class_find_write_attr could be turned into something generic since it's
 certainly convenient to reuse same table of name-write_method pairs,
 but I did some cursory research and nobody else seems to need anything
 of the sort in-tree.
 
 I know ll_process_config is still awful and I will likely just
 replace the current hack with kset_find_obj, but I just wanted to make
 sure this new approach would be ok before spending too much time on it.
>>> 
>>> I'm not quite sure what exactly you are even trying to do here.  What is
>>> this interface?  Who calls it, and how?  What does it want to do?
>> 
>> This is a configuration client code.
>> Management server has ability to pass down config information in the form of:
>> fsname.subsystem.attribute=value to clients and other servers
>> (subsystem determines if it's something of interest of clients or servers or
>> both).
>> This could be changed in the real time - i.e. you update it on the server and
>> that gets propagated to all the clients/servers, so no need to ssh into
>> every node to manually apply those changes and worry about client restarts
>> (the config is remembered at the management server and would be applied to 
>> any
>> new nodes connecting/across server restarts and such).
>> 
>> So the way it then works then is once the string 
>> fsname.subsystem.attribute=value is delivered to the client, we find all 
>> instances of filesystem with fsname and then
>> all subsystems within it (one kobject per subsystem instance) and then 
>> update the
>> attributes to the value supplied.
>> 
>> The same filesystem might be mounted more than once and then some layers 
>> might have
>> multiple instances inside a single filesystems.
>> 
>> In the end it would turn something like lustre.osc.max_dirty_mb=128 into
>> writes to
>> /sys/fs/lustre/osc/lustre-OST-osc-8800d75ca000/max_dirty_mb and
>> /sys/fs/lustre/osc/lustre-OST0001-osc-8800d75ca000/max_dirty_mb
>> without actually iterating in sysfs namespace.
> 
> Wait, who is doing the "write"?  From within the kernel?  Or some
> userspace app?  I'm guessing from within the kernel, you are receiving
> the data from some other transport within the filesystem and then need
> to apply the settings?

Yes, kernel code gets the notification "hey, there's a config change, come get 
it",
then it requests the diff in the config and does the "write' by updating the
attributes.

>> The alternative we considered is we can probably just do an upcall and have
>> a userspace tool called with the parameter verbatim and try to figure it out,
>> but that seems a lot less ideal, and also we'll get a bunch of complications 
>> from
>> containers and such too, I imagine.
> 
> Yeah, no, don't do an upcall, that's a mess.
> 
>> The function pre-this patch is assuming that all these values are part of
>> a list of procfs values (no longer true after sysfs migration) so just 
>> iterates
>> that list and calls the write for matched names (but also needs to supply a 
>> userspace
>> buffer so looks much uglier too).
> 
> For kobjects, you don't need userspace buffers, so this should be
> easier.

Right, it's less of a mess due to that.

>> Hopefully this makes at least some sense.
> 
> Yes, a bit more, but ugh, what a mess :)

Overall big systems are quite messy in many ways no matter what you do,
so it's always a case of pick your poison.

>>> You can look up attributes for a kobject easily in the show/store
>>> functions (and some drivers just have a generic one and then you look at
>>> the string to see which attribute you are wanting to reference.)  But
>>> you seem to be working backwards here, why do you have to look up a
>>> kobject?
>> 
>> But that leads to the need to list attribute names essentially twice:
>> once for the attributes list, once in the show/set function t

Re: [PATCH/RFC] staging/lustre: Rework class_process_proc_param

[Greg Kroah-Hartman]

On Sat, Mar 18, 2017 at 02:24:08AM -0400, Oleg Drokin wrote:
> Ever since sysfs migration, class_process_proc_param stopped working
> correctly as all the useful params were no longer present as lvars.
> Replace all the nasty fake proc writes with hopefully less nasty
> kobject attribute search and then update the attributes as needed.
> 
> Signed-off-by: Oleg Drokin 
> Reported-by: Al Viro 
> ---
> Al has quite rightfully complained in the past that class_process_proc_param
> is a terrible piece of code and needs to go.
> This patch is an attempt at improving it somewhat and in process drop
> all the user/kernel address space games we needed to play to make it work
> in the past (and which I suspect attracted Al's attention in the first place).
> 
> Now I wonder if iterating kobject attributes like that would be ok with
> you Greg, or do you think there is a better way?
> class_find_write_attr could be turned into something generic since it's
> certainly convenient to reuse same table of name-write_method pairs,
> but I did some cursory research and nobody else seems to need anything
> of the sort in-tree.
> 
> I know ll_process_config is still awful and I will likely just
> replace the current hack with kset_find_obj, but I just wanted to make
> sure this new approach would be ok before spending too much time on it.
> 
> Thanks!
> 
>  drivers/staging/lustre/lustre/include/obd_class.h  |  4 +-
>  drivers/staging/lustre/lustre/llite/llite_lib.c| 10 +--
>  drivers/staging/lustre/lustre/lov/lov_obd.c|  3 +-
>  drivers/staging/lustre/lustre/mdc/mdc_request.c|  3 +-
>  .../staging/lustre/lustre/obdclass/obd_config.c| 78 
> ++
>  drivers/staging/lustre/lustre/osc/osc_request.c|  3 +-
>  6 files changed, 44 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/obd_class.h 
> b/drivers/staging/lustre/lustre/include/obd_class.h
> index 083a6ff..badafb8 100644
> --- a/drivers/staging/lustre/lustre/include/obd_class.h
> +++ b/drivers/staging/lustre/lustre/include/obd_class.h
> @@ -114,8 +114,8 @@ typedef int (*llog_cb_t)(const struct lu_env *, struct 
> llog_handle *,
>struct llog_rec_hdr *, void *);
>  /* obd_config.c */
>  int class_process_config(struct lustre_cfg *lcfg);
> -int class_process_proc_param(char *prefix, struct lprocfs_vars *lvars,
> -  struct lustre_cfg *lcfg, void *data);
> +int class_process_attr_param(char *prefix, struct kobject *kobj,
> +  struct lustre_cfg *lcfg);

As you are exporting these functions, they will need to end up with a
lustre_* prefix eventually :)

>  struct obd_device *class_incref(struct obd_device *obd,
>   const char *scope, const void *source);
>  void class_decref(struct obd_device *obd,
> diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
> b/drivers/staging/lustre/lustre/llite/llite_lib.c
> index 7b80040..192b877 100644
> --- a/drivers/staging/lustre/lustre/llite/llite_lib.c
> +++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
> @@ -2259,7 +2259,7 @@ int ll_obd_statfs(struct inode *inode, void __user *arg)
>  int ll_process_config(struct lustre_cfg *lcfg)
>  {
>   char *ptr;
> - void *sb;
> + struct super_block *sb;
>   struct lprocfs_static_vars lvars;
>   unsigned long x;
>   int rc = 0;
> @@ -2273,15 +2273,15 @@ int ll_process_config(struct lustre_cfg *lcfg)
>   rc = kstrtoul(ptr, 16, &x);
>   if (rc != 0)
>   return -EINVAL;
> - sb = (void *)x;
> + sb = (struct super_block *)x;
>   /* This better be a real Lustre superblock! */
> - LASSERT(s2lsi((struct super_block *)sb)->lsi_lmd->lmd_magic == 
> LMD_MAGIC);
> + LASSERT(s2lsi(sb)->lsi_lmd->lmd_magic == LMD_MAGIC);
>  
>   /* Note we have not called client_common_fill_super yet, so
>* proc fns must be able to handle that!
>*/
> - rc = class_process_proc_param(PARAM_LLITE, lvars.obd_vars,
> -   lcfg, sb);
> + rc = class_process_attr_param(PARAM_LLITE, &ll_s2sbi(sb)->ll_kobj,
> +   lcfg);
>   if (rc > 0)
>   rc = 0;
>   return rc;
> diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c 
> b/drivers/staging/lustre/lustre/lov/lov_obd.c
> index b3161fb..c33a327 100644
> --- a/drivers/staging/lustre/lustre/lov/lov_obd.c
> +++ b/drivers/staging/lustre/lustre/lov/lov_obd.c
> @@ -926,8 +926,7 @@ int lov_process_config_base(struct obd_device *obd, 
> struct lustre_cfg *lcfg,
>  
>   lprocfs_lov_init_vars(&lvars);
>  
> - rc = class_process_proc_param(PARAM_LOV, lvars.obd_vars,
> -   lcfg, obd);
> + rc = class_process_attr_param(PARAM_LOV, &obd->obd_kobj, lcfg);
>   if (rc > 0)
>   rc = 0;
>   goto out;
> diff --git a/drivers/staging/lustre/lustre

Re: [PATCH 1/6] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service

[Michael Zoran]

On Sat, 2017-03-18 at 14:23 +0100, Stefan Wahren wrote:
> > Michael Zoran  hat am 17. März 2017 um 16:22
> > geschrieben:
> > 
> > 
> > From: Dave Stevenson 
> > 
> > Pi3 and Compute Module 3 have a GPIO expander that the
> > VPU communicates with.
> > There is a mailbox service that now allows control of this
> > expander, so add a kernel driver that can make use of it.
> > 
> > Pwr_led node added to device-tree for Pi3.
> 
> Looks like debris
> 
> > 
> > Signed-off-by: Dave Stevenson 
> > 
> > Stripped off changes to Makefile and Kconfig
> > Also stripped off changes to raspberrypi-firmware.h
> > Moved to drivers/staging/vc04_services/bcm2835-firmware-gpio
> > 
> > Signed-off-by: Michael Zoran 
> > ---
> > 

Hi Stefan,

For this particular patch, I simply cherry-picked the orignal version
of the driver in the github directory.  It's a 100% original copy of
the initial version.

So any grips/complaints should be sent to dave.steven...@raspberrypi.or
g.

Or better yet, if the driver is accepted then you can contribute to
making it better.


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

[PATCH] staging: speakup: Remove multiple assignments

[Arushi Singhal]

This patch fixes the checkpatch.pl warning "multiple assignments
should be avoided."

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 21e76b031449..c10445624e92 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2106,7 +2106,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
spk_keydown = 0;
goto out;
}
-   value = spk_lastkey = pad_chars[value];
+   value = pad_chars[value];
+   spk_lastkey = value;
spk_keydown++;
spk_parked &= 0xfe;
goto no_map;
-- 
2.11.0

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

Re: [PATCH 5/6] staging: bcm2835-firmware-gpio: Add a build system for the driver

[Michael Zoran]

On Sat, 2017-03-18 at 14:25 +0100, Stefan Wahren wrote:
> > Michael Zoran  hat am 17. März 2017 um 16:22
> > geschrieben:
> > 
> > 
> > This change adds the driver to the standard kernel build system.
> > 
> > Signed-off-by: Michael Zoran 
> > ---
> >  drivers/staging/vc04_services/Kconfig| 2
> > ++
> >  drivers/staging/vc04_services/Makefile   | 1 +
> >  drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig  | 6
> > ++
> >  drivers/staging/vc04_services/bcm2835-firmware-gpio/Makefile | 5
> > +
> >  4 files changed, 14 insertions(+)
> >  create mode 100644 drivers/staging/vc04_services/bcm2835-firmware-
> > gpio/Kconfig
> >  create mode 100644 drivers/staging/vc04_services/bcm2835-firmware-
> > gpio/Makefile
> > 
> > diff --git a/drivers/staging/vc04_services/Kconfig
> > b/drivers/staging/vc04_services/Kconfig
> > index b9f316603308..aebb622cff4a 100644
> > --- a/drivers/staging/vc04_services/Kconfig
> > +++ b/drivers/staging/vc04_services/Kconfig
> > @@ -34,5 +34,7 @@ source "drivers/staging/vc04_services/bcm2835-
> > audio/Kconfig"
> >  
> >  source "drivers/staging/vc04_services/bcm2835-camera/Kconfig"
> >  
> > +source "drivers/staging/vc04_services/bcm2835-firmware-
> > gpio/Kconfig"
> > +
> >  endif
> >  
> > diff --git a/drivers/staging/vc04_services/Makefile
> > b/drivers/staging/vc04_services/Makefile
> > index e9a8e1343cbb..54c75b732094 100644
> > --- a/drivers/staging/vc04_services/Makefile
> > +++ b/drivers/staging/vc04_services/Makefile
> > @@ -12,6 +12,7 @@ vchiq-objs := \
> >  
> >  obj-$(CONFIG_SND_BCM2835)  += bcm2835-audio/
> >  obj-$(CONFIG_VIDEO_BCM2835)+= bcm2835-camera/
> > +obj-$(CONFIG_FIRMWARE_GPIO_BCM2835) += bcm2835-firmware-gpio/
> >  
> >  ccflags-y += -DVCOS_VERIFY_BKPTS=1 -Idrivers/staging/vc04_services
> > -DUSE_VCHIQ_ARM -D__VCCOREVER__=0x0400
> >  
> > diff --git a/drivers/staging/vc04_services/bcm2835-firmware-
> > gpio/Kconfig b/drivers/staging/vc04_services/bcm2835-firmware-
> > gpio/Kconfig
> > new file mode 100644
> > index ..1c8cb579fad9
> > --- /dev/null
> > +++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/Kconfig
> > @@ -0,0 +1,6 @@
> > +config FIRMWARE_GPIO_BCM2835
> > +   tristate "BCM2835 Firmware GPIO"
> > +   depends on OF_GPIO && (ARCH_BCM2835 || COMPILE_TEST)
> 
> depends on RASPBERRYPI_FIRMWARE ?
> 

That's in the top level BCM_VIDEOCORE.  But perhaps it should be added
here to make things clear.


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

Re: [PATCH/RFC] staging/lustre: Rework class_process_proc_param

[Greg Kroah-Hartman]

On Sun, Mar 19, 2017 at 12:41:20AM -0400, Oleg Drokin wrote:
> 
> On Mar 19, 2017, at 12:29 AM, Greg Kroah-Hartman wrote:
> 
> > On Sat, Mar 18, 2017 at 11:17:55AM -0400, Oleg Drokin wrote:
> >> 
> >> On Mar 18, 2017, at 6:34 AM, Greg Kroah-Hartman wrote:
> >> 
> >>> On Sat, Mar 18, 2017 at 02:24:08AM -0400, Oleg Drokin wrote:
>  Ever since sysfs migration, class_process_proc_param stopped working
>  correctly as all the useful params were no longer present as lvars.
>  Replace all the nasty fake proc writes with hopefully less nasty
>  kobject attribute search and then update the attributes as needed.
>  
>  Signed-off-by: Oleg Drokin 
>  Reported-by: Al Viro 
>  ---
>  Al has quite rightfully complained in the past that 
>  class_process_proc_param
>  is a terrible piece of code and needs to go.
>  This patch is an attempt at improving it somewhat and in process drop
>  all the user/kernel address space games we needed to play to make it work
>  in the past (and which I suspect attracted Al's attention in the first 
>  place).
>  
>  Now I wonder if iterating kobject attributes like that would be ok with
>  you Greg, or do you think there is a better way?
>  class_find_write_attr could be turned into something generic since it's
>  certainly convenient to reuse same table of name-write_method pairs,
>  but I did some cursory research and nobody else seems to need anything
>  of the sort in-tree.
>  
>  I know ll_process_config is still awful and I will likely just
>  replace the current hack with kset_find_obj, but I just wanted to make
>  sure this new approach would be ok before spending too much time on it.
> >>> 
> >>> I'm not quite sure what exactly you are even trying to do here.  What is
> >>> this interface?  Who calls it, and how?  What does it want to do?
> >> 
> >> This is a configuration client code.
> >> Management server has ability to pass down config information in the form 
> >> of:
> >> fsname.subsystem.attribute=value to clients and other servers
> >> (subsystem determines if it's something of interest of clients or servers 
> >> or
> >> both).
> >> This could be changed in the real time - i.e. you update it on the server 
> >> and
> >> that gets propagated to all the clients/servers, so no need to ssh into
> >> every node to manually apply those changes and worry about client restarts
> >> (the config is remembered at the management server and would be applied to 
> >> any
> >> new nodes connecting/across server restarts and such).
> >> 
> >> So the way it then works then is once the string 
> >> fsname.subsystem.attribute=value is delivered to the client, we find all 
> >> instances of filesystem with fsname and then
> >> all subsystems within it (one kobject per subsystem instance) and then 
> >> update the
> >> attributes to the value supplied.
> >> 
> >> The same filesystem might be mounted more than once and then some layers 
> >> might have
> >> multiple instances inside a single filesystems.
> >> 
> >> In the end it would turn something like lustre.osc.max_dirty_mb=128 into
> >> writes to
> >> /sys/fs/lustre/osc/lustre-OST-osc-8800d75ca000/max_dirty_mb and
> >> /sys/fs/lustre/osc/lustre-OST0001-osc-8800d75ca000/max_dirty_mb
> >> without actually iterating in sysfs namespace.
> > 
> > Wait, who is doing the "write"?  From within the kernel?  Or some
> > userspace app?  I'm guessing from within the kernel, you are receiving
> > the data from some other transport within the filesystem and then need
> > to apply the settings?
> 
> Yes, kernel code gets the notification "hey, there's a config change, come 
> get it",
> then it requests the diff in the config and does the "write' by updating the
> attributes.
> 
> >> The alternative we considered is we can probably just do an upcall and have
> >> a userspace tool called with the parameter verbatim and try to figure it 
> >> out,
> >> but that seems a lot less ideal, and also we'll get a bunch of 
> >> complications from
> >> containers and such too, I imagine.
> > 
> > Yeah, no, don't do an upcall, that's a mess.
> > 
> >> The function pre-this patch is assuming that all these values are part of
> >> a list of procfs values (no longer true after sysfs migration) so just 
> >> iterates
> >> that list and calls the write for matched names (but also needs to supply 
> >> a userspace
> >> buffer so looks much uglier too).
> > 
> > For kobjects, you don't need userspace buffers, so this should be
> > easier.
> 
> Right, it's less of a mess due to that.
> 
> >> Hopefully this makes at least some sense.
> > 
> > Yes, a bit more, but ugh, what a mess :)
> 
> Overall big systems are quite messy in many ways no matter what you do,
> so it's always a case of pick your poison.

Oh I know, I wasn't complaining, it's just a fact of life :)

> >>> You can look up attributes for a kobject easily in the show/store
> >>> functions (and s

[PATCH] staging: speakup: fix: braces {} should used on all arms of statement

[Arushi Singhal]

This patch fixes the checks reported by checkpatch.pl
for braces {} should be used on all arms of this statement.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c   | 35 +++-
 drivers/staging/speakup/speakup_decext.c |  6 +++---
 drivers/staging/speakup/speakup_decpc.c  |  6 +++---
 drivers/staging/speakup/speakup_dectlk.c |  6 +++---
 drivers/staging/speakup/varhandlers.c| 12 ++-
 5 files changed, 37 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index f8fccc8bf6b2..21e76b031449 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -409,8 +409,9 @@ static void say_attributes(struct vc_data *vc)
if (bg > 7) {
synth_printf(" %s ", spk_msg_get(MSG_ON_BLINKING));
bg -= 8;
-   } else
+   } else {
synth_printf(" %s ", spk_msg_get(MSG_ON));
+   }
synth_printf("%s\n", spk_msg_get(MSG_COLORS_START + bg));
 }
 
@@ -643,8 +644,9 @@ static void say_prev_word(struct vc_data *vc)
break;
spk_y--;
spk_x = vc->vc_cols - 1;
-   } else
+   } else {
spk_x--;
+   }
spk_pos -= 2;
ch = get_char(vc, (u_short *)spk_pos, &temp);
if (ch == SPACE || ch == 0)
@@ -697,8 +699,9 @@ static void say_next_word(struct vc_data *vc)
spk_y++;
spk_x = 0;
edge_said = edge_right;
-   } else
+   } else {
spk_x++;
+   }
spk_pos += 2;
last_state = state;
}
@@ -729,8 +732,9 @@ static void spell_word(struct vc_data *vc)
spk_pitch_shift++;
else/* synth has no pitch */
last_cap = spk_str_caps_stop;
-   } else
+   } else {
str_cap = spk_str_caps_stop;
+   }
if (str_cap != last_cap) {
synth_printf("%s", str_cap);
last_cap = str_cap;
@@ -1343,8 +1347,9 @@ static int speakup_allocate(struct vc_data *vc)
if (!speakup_console[vc_num])
return -ENOMEM;
speakup_date(vc);
-   } else if (!spk_parked)
+   } else if (!spk_parked) {
speakup_date(vc);
+   }
 
return 0;
 }
@@ -1397,9 +1402,9 @@ static void read_all_doc(struct vc_data *vc)
prev_cursor_track = cursor_track;
cursor_track = read_all_mode;
spk_reset_index_count(0);
-   if (get_sentence_buf(vc, 0) == -1)
+   if (get_sentence_buf(vc, 0) == -1) {
kbd_fakekey2(vc, RA_DOWN_ARROW);
-   else {
+   } else {
say_sentence_num(0, 0);
synth_insert_next_index(0);
start_read_all_timer(vc, RA_TIMER);
@@ -1446,8 +1451,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
int command)
if (!say_sentence_num(sentcount + 1, 1)) {
sn = 1;
spk_reset_index_count(sn);
-   } else
+   } else {
synth_insert_next_index(0);
+   }
if (!say_sentence_num(sn, 0)) {
kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
return;
@@ -1476,9 +1482,9 @@ static void handle_cursor_read_all(struct vc_data *vc, 
int command)
rv = get_sentence_buf(vc, 0);
if (rv == -1)
read_all_doc(vc);
-   if (rv == 0)
+   if (rv == 0) {
kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
-   else {
+   } else {
say_sentence_num(1, 0);
synth_insert_next_index(0);
start_read_all_timer(vc, RA_TIMER);
@@ -2177,10 +2183,11 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
if (type == KT_SPEC && value == 1) {
value = '\n';
type = KT_LATIN;
-   } else if (type == KT_LETTER)
+   } else if (type == KT_LETTER) {
type = KT_LATIN;
-   else if (value == 0x7f)
+   } else if (value == 0x7f) {
value = 8;  /* make del = backspace */
+   }
ret = (*spk_special_handler) (vc, type, value, keycode);
spk_close_press = 0;
if (ret < 0)
@@ -2274,9 +2281,9 @@ static int vt_notifier_call(struct notifier_block *n

Re: [PATCH/RFC] staging/lustre: Rework class_process_proc_param

[Oleg Drokin]

On Mar 19, 2017, at 12:41 AM, Greg Kroah-Hartman wrote:

> On Sat, Mar 18, 2017 at 02:24:08AM -0400, Oleg Drokin wrote:
>> Ever since sysfs migration, class_process_proc_param stopped working
>> correctly as all the useful params were no longer present as lvars.
>> Replace all the nasty fake proc writes with hopefully less nasty
>> kobject attribute search and then update the attributes as needed.
>> 
>> Signed-off-by: Oleg Drokin 
>> Reported-by: Al Viro 
>> ---
>> Al has quite rightfully complained in the past that class_process_proc_param
>> is a terrible piece of code and needs to go.
>> This patch is an attempt at improving it somewhat and in process drop
>> all the user/kernel address space games we needed to play to make it work
>> in the past (and which I suspect attracted Al's attention in the first 
>> place).
>> 
>> Now I wonder if iterating kobject attributes like that would be ok with
>> you Greg, or do you think there is a better way?
>> class_find_write_attr could be turned into something generic since it's
>> certainly convenient to reuse same table of name-write_method pairs,
>> but I did some cursory research and nobody else seems to need anything
>> of the sort in-tree.
>> 
>> I know ll_process_config is still awful and I will likely just
>> replace the current hack with kset_find_obj, but I just wanted to make
>> sure this new approach would be ok before spending too much time on it.
>> 
>> Thanks!
>> 
>> drivers/staging/lustre/lustre/include/obd_class.h  |  4 +-
>> drivers/staging/lustre/lustre/llite/llite_lib.c| 10 +--
>> drivers/staging/lustre/lustre/lov/lov_obd.c|  3 +-
>> drivers/staging/lustre/lustre/mdc/mdc_request.c|  3 +-
>> .../staging/lustre/lustre/obdclass/obd_config.c| 78 
>> ++
>> drivers/staging/lustre/lustre/osc/osc_request.c|  3 +-
>> 6 files changed, 44 insertions(+), 57 deletions(-)
>> 
>> diff --git a/drivers/staging/lustre/lustre/include/obd_class.h 
>> b/drivers/staging/lustre/lustre/include/obd_class.h
>> index 083a6ff..badafb8 100644
>> --- a/drivers/staging/lustre/lustre/include/obd_class.h
>> +++ b/drivers/staging/lustre/lustre/include/obd_class.h
>> @@ -114,8 +114,8 @@ typedef int (*llog_cb_t)(const struct lu_env *, struct 
>> llog_handle *,
>>   struct llog_rec_hdr *, void *);
>> /* obd_config.c */
>> int class_process_config(struct lustre_cfg *lcfg);
>> -int class_process_proc_param(char *prefix, struct lprocfs_vars *lvars,
>> - struct lustre_cfg *lcfg, void *data);
>> +int class_process_attr_param(char *prefix, struct kobject *kobj,
>> + struct lustre_cfg *lcfg);
> 
> As you are exporting these functions, they will need to end up with a
> lustre_* prefix eventually :)

ok.

> 
>> struct obd_device *class_incref(struct obd_device *obd,
>>  const char *scope, const void *source);
>> void class_decref(struct obd_device *obd,
>> diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
>> b/drivers/staging/lustre/lustre/llite/llite_lib.c
>> index 7b80040..192b877 100644
>> --- a/drivers/staging/lustre/lustre/llite/llite_lib.c
>> +++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
>> @@ -2259,7 +2259,7 @@ int ll_obd_statfs(struct inode *inode, void __user 
>> *arg)
>> int ll_process_config(struct lustre_cfg *lcfg)
>> {
>>  char *ptr;
>> -void *sb;
>> +struct super_block *sb;
>>  struct lprocfs_static_vars lvars;
>>  unsigned long x;
>>  int rc = 0;
>> @@ -2273,15 +2273,15 @@ int ll_process_config(struct lustre_cfg *lcfg)
>>  rc = kstrtoul(ptr, 16, &x);
>>  if (rc != 0)
>>  return -EINVAL;
>> -sb = (void *)x;
>> +sb = (struct super_block *)x;
>>  /* This better be a real Lustre superblock! */
>> -LASSERT(s2lsi((struct super_block *)sb)->lsi_lmd->lmd_magic == 
>> LMD_MAGIC);
>> +LASSERT(s2lsi(sb)->lsi_lmd->lmd_magic == LMD_MAGIC);
>> 
>>  /* Note we have not called client_common_fill_super yet, so
>>   * proc fns must be able to handle that!
>>   */
>> -rc = class_process_proc_param(PARAM_LLITE, lvars.obd_vars,
>> -  lcfg, sb);
>> +rc = class_process_attr_param(PARAM_LLITE, &ll_s2sbi(sb)->ll_kobj,
>> +  lcfg);
>>  if (rc > 0)
>>  rc = 0;
>>  return rc;
>> diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c 
>> b/drivers/staging/lustre/lustre/lov/lov_obd.c
>> index b3161fb..c33a327 100644
>> --- a/drivers/staging/lustre/lustre/lov/lov_obd.c
>> +++ b/drivers/staging/lustre/lustre/lov/lov_obd.c
>> @@ -926,8 +926,7 @@ int lov_process_config_base(struct obd_device *obd, 
>> struct lustre_cfg *lcfg,
>> 
>>  lprocfs_lov_init_vars(&lvars);
>> 
>> -rc = class_process_proc_param(PARAM_LOV, lvars.obd_vars,
>> -  lcfg, obd);
>> +rc = class_process_attr_param(PARAM_LOV, &obd->obd_kobj, lc

[PATCH v2] vmbus: fix missed ring events on boot

[Stephen Hemminger]

During initialization, the channel initialization code schedules the
tasklet to scan the VMBUS receive event page (i.e. simulates an
interrupt). The problem was that it invokes the tasklet on a different
CPU from where it normally runs and therefore if an event is present,
it will clear the bit but not find the associated channel.

This can lead to missed events, typically stuck tasks, during bootup
when sub channels are being initialized. Typically seen as stuck
boot with 8 or more CPU's.

This patch is not necessary for upstream (4.11 and later) since
commit 631e63a9f346 ("vmbus: change to per channel tasklet").
This changed vmbus code to get rid of common tasklet which
caused the problem.

Cc: sta...@vger.kernel.org
Fixes: 638fea33aee8 ("Drivers: hv: vmbus: fix the race when querying & updating 
the percpu list")
Signed-off-by: Stephen Hemminger 
---
v2 - simplified version (only need to change one function).
 also don't need to wait for tasklet to be scheduled on other CPU
 add Fixes tag.

 drivers/hv/channel_mgmt.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 0af7e39006c8..63c903b00a58 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -361,8 +361,19 @@ void hv_event_tasklet_enable(struct vmbus_channel *channel)
tasklet = hv_context.event_dpc[channel->target_cpu];
tasklet_enable(tasklet);
 
-   /* In case there is any pending event */
-   tasklet_schedule(tasklet);
+   /*
+* In case there is any pending event schedule a rescan
+* but must be on the correct CPU for the channel.
+*/
+   if (channel->target_cpu == get_cpu()) {
+   put_cpu();
+   tasklet_schedule(tasklet);
+   } else {
+   smp_call_function_single(channel->target_cpu,
+(smp_call_func_t)tasklet_schedule,
+tasklet, false);
+   put_cpu();
+   }
 }
 
 void hv_process_channel_removal(struct vmbus_channel *channel, u32 relid)
-- 
2.11.0

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

[PATCH v2 0/3] staging: speakup: Multiple checkpatch issues

[Arushi Singhal]

Improve readability by fixing multiple checkpatch.pl
issues in speakup driver.

Arushi Singhal (3):
  staging: speakup: Moved logical to previous line.
  staging: speakup: Remove multiple assignments
  staging: speakup: Simplify "NULL" comparisons

 drivers/staging/speakup/main.c| 30 ++
 drivers/staging/speakup/selection.c   |  2 +-
 drivers/staging/speakup/varhandlers.c |  6 +++---
 3 files changed, 22 insertions(+), 16 deletions(-)

-- 
changes in v2
 -change the commit message of [patch 1/3] as was wrong
2.11.0

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

[PATCH v2 1/3] staging: speakup: Moved logical to previous line.

[Arushi Singhal]

Moved logical AND operator to previous line to fix the following
checkpatch issue:

CHECK: Logical continuations should be on the previous line.

Signed-off-by: Arushi Singhal 
---
changes in v2
 - Change the commit message.

 drivers/staging/speakup/main.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index f280e22d7e15..f71206878363 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -905,8 +905,8 @@ static int get_sentence_buf(struct vc_data *vc, int 
read_punc)
while (start < end) {
sentbuf[bn][i] = get_char(vc, (u_short *)start, &tmp);
if (i > 0) {
-   if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == '.'
-   && numsentences[bn] < 9) {
+   if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == 
'.' &&
+   numsentences[bn] < 9) {
/* Sentence Marker */
numsentences[bn]++;
sentmarks[bn][numsentences[bn]] =
@@ -1292,8 +1292,8 @@ void spk_reset_default_chars(void)
 
/* First, free any non-default */
for (i = 0; i < 256; i++) {
-   if ((spk_characters[i] != NULL)
-   && (spk_characters[i] != spk_default_chars[i]))
+   if (spk_characters[i] &&
+   (spk_characters[i] != spk_default_chars[i]))
kfree(spk_characters[i]);
}
 
@@ -2088,8 +2088,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
tty = vc->port.tty;
if (type >= 0xf0)
type -= 0xf0;
-   if (type == KT_PAD
-   && (vt_get_leds(fg_console, VC_NUMLOCK))) {
+   if (type == KT_PAD &&
+   (vt_get_leds(fg_console, VC_NUMLOCK))) {
if (up_flag) {
spk_keydown = 0;
goto out;
-- 
2.11.0

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

[PATCH v2 2/3] staging: speakup: Remove multiple assignments

[Arushi Singhal]

This patch fixes the checkpatch.pl warning "multiple assignments
should be avoided."

Signed-off-by: Arushi Singhal 
---
changes in v2
 - no change.

 drivers/staging/speakup/main.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index f71206878363..f8fccc8bf6b2 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -270,9 +270,12 @@ static unsigned char get_attributes(struct vc_data *vc, 
u16 *pos)
 
 static void speakup_date(struct vc_data *vc)
 {
-   spk_x = spk_cx = vc->vc_x;
-   spk_y = spk_cy = vc->vc_y;
-   spk_pos = spk_cp = vc->vc_pos;
+   spk_x = vc->vc_x;
+   spk_cx = spk_x;
+   spk_y = vc->vc_y;
+   spk_cy = spk_y;
+   spk_pos = vc->vc_pos;
+   spk_cp = spk_pos;
spk_old_attr = spk_attr;
spk_attr = get_attributes(vc, (u_short *)spk_pos);
 }
@@ -1655,9 +1658,12 @@ static int speak_highlight(struct vc_data *vc)
spk_do_flush();
spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
speakup_console[vc_num]->ht.highsize[hc]);
-   spk_pos = spk_cp = speakup_console[vc_num]->ht.rpos[hc];
-   spk_x = spk_cx = speakup_console[vc_num]->ht.rx[hc];
-   spk_y = spk_cy = speakup_console[vc_num]->ht.ry[hc];
+   spk_pos = speakup_console[vc_num]->ht.rpos[hc];
+   spk_cp = spk_pos;
+   spk_x = speakup_console[vc_num]->ht.rx[hc];
+   spk_cx = spk_x;
+   spk_y = speakup_console[vc_num]->ht.ry[hc];
+   spk_cy = spk_y;
return 1;
}
return 0;
-- 
2.11.0

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

[PATCH v2 3/3] staging: speakup: Simplify "NULL" comparisons

[Arushi Singhal]

Fixed coding style for null comparisons in speakup driver to be more
consistant with the rest of the kernel coding style.
Replaced 'x != NULL' with 'x' and 'x = NULL' with '!x'.

Signed-off-by: Arushi Singhal 
---
changes in v2
 - no change

 drivers/staging/speakup/selection.c   | 2 +-
 drivers/staging/speakup/varhandlers.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/selection.c 
b/drivers/staging/speakup/selection.c
index afd9a446a06f..4417c00e68a7 100644
--- a/drivers/staging/speakup/selection.c
+++ b/drivers/staging/speakup/selection.c
@@ -175,7 +175,7 @@ static struct speakup_paste_work speakup_paste_work = {
 
 int speakup_paste_selection(struct tty_struct *tty)
 {
-   if (cmpxchg(&speakup_paste_work.tty, NULL, tty) != NULL)
+   if (cmpxchg(&speakup_paste_work.tty, NULL, tty))
return -EBUSY;
 
tty_kref_get(tty);
diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index cc984196020f..5910fe0b1365 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -98,7 +98,7 @@ void speakup_register_var(struct var_t *var)
}
}
p_header = var_ptrs[var->var_id];
-   if (p_header->data != NULL)
+   if (p_header->data)
return;
p_header->data = var;
switch (p_header->var_type) {
@@ -210,11 +210,11 @@ int spk_set_num_var(int input, struct st_var_header *var, 
int how)
return -ERANGE;
 
var_data->u.n.value = val;
-   if (var->var_type == VAR_TIME && p_val != NULL) {
+   if (var->var_type == VAR_TIME && p_val) {
*p_val = msecs_to_jiffies(val);
return 0;
}
-   if (p_val != NULL)
+   if (p_val)
*p_val = val;
if (var->var_id == PUNC_LEVEL) {
spk_punc_mask = spk_punc_masks[val];
-- 
2.11.0

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

[PATCH] staging: bcm2835-firmware-gpio: fix platform_no_drv_owner.cocci warnings

[kbuild test robot]

drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c:271:3-8: No 
need to set .owner here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Michael Zoran 
Signed-off-by: Fengguang Wu 
---

 gpio-bcm-exp.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
+++ b/drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c
@@ -268,7 +268,6 @@ MODULE_DEVICE_TABLE(of, brcmexp_gpio_ids
 static struct platform_driver brcmexp_gpio_driver = {
.driver = {
.name   = MODULE_NAME,
-   .owner  = THIS_MODULE,
.of_match_table = of_match_ptr(brcmexp_gpio_ids),
},
.probe  = brcmexp_gpio_probe,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 5/6] staging: bcm2835-firmware-gpio: Add a build system for the driver

[kbuild test robot]

Hi Michael,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on next-20170310]
[cannot apply to linux-rpi/for-rpi-next v4.11-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Michael-Zoran/staging-bcm2835-firmware-gpio-Initial-staging-commit/20170319-14


coccinelle warnings: (new ones prefixed by >>)

>> drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-exp.c:271:3-8: 
>> No need to set .owner here. The core will do it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 5/6] staging: bcm2835-firmware-gpio: Add a build system for the driver

[Michael Zoran]

On Sun, 2017-03-19 at 13:27 +0800, kbuild test robot wrote:
> Hi Michael,
> 
> [auto build test WARNING on staging/staging-testing]
> [also build test WARNING on next-20170310]
> [cannot apply to linux-rpi/for-rpi-next v4.11-rc2]
> [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Michael-Zoran/stagin
> g-bcm2835-firmware-gpio-Initial-staging-commit/20170319-14
> 
> 
> coccinelle warnings: (new ones prefixed by >>)
> 
> > > drivers/staging/vc04_services/bcm2835-firmware-gpio/gpio-bcm-
> > > exp.c:271:3-8: No need to set .owner here. The core will do it.
> 

> Please review and possibly fold the followup patch.
> 
> ---
> 0-DAY kernel test infrastructure    Open Source
> Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel
> Corporation

OK, Some I'm completely confused here.  Has this patch been applied,
and through which tree has it been applied to?

I think I need to send a V2.  So who should I be sending V2 to?

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