[PATCH] staging: pi433: Fix rf69_set_tx_cfg() logic

2019-03-27 Thread Sidong Yang 
Moved code to configure sync to where check enable_sync option before.
There is no need to check enable_sync twice. Configuring sync should be
executed immediately after enabling sync.

Signed-off-by: Sidong Yang 
---
 drivers/staging/pi433/pi433_if.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 53928af696a6..0a48d6cb9547 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -318,10 +318,17 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct 
pi433_tx_cfg *tx_cfg)
return ret;
}
 
+   /* configure sync, if enabled */
if (tx_cfg->enable_sync == OPTION_ON) {
ret = rf69_enable_sync(dev->spi);
if (ret < 0)
return ret;
+   ret = rf69_set_sync_size(dev->spi, tx_cfg->sync_length);
+   if (ret < 0)
+   return ret;
+   ret = rf69_set_sync_values(dev->spi, tx_cfg->sync_pattern);
+   if (ret < 0)
+   return ret;
} else {
ret = rf69_disable_sync(dev->spi);
if (ret < 0)
@@ -348,16 +355,6 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct 
pi433_tx_cfg *tx_cfg)
return ret;
}
 
-   /* configure sync, if enabled */
-   if (tx_cfg->enable_sync == OPTION_ON) {
-   ret = rf69_set_sync_size(dev->spi, tx_cfg->sync_length);
-   if (ret < 0)
-   return ret;
-   ret = rf69_set_sync_values(dev->spi, tx_cfg->sync_pattern);
-   if (ret < 0)
-   return ret;
-   }
-
return 0;
 }
 
-- 
2.17.1

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

Re: [PATCH] staging: pi433: Fix rf69_set_tx_cfg() logic

2019-03-27 Thread Dan Carpenter 
On Wed, Mar 27, 2019 at 08:11:20AM +, Sidong Yang wrote:
> Moved code to configure sync to where check enable_sync option before.
> There is no need to check enable_sync twice. Configuring sync should be
> executed immediately after enabling sync.
> 
> Signed-off-by: Sidong Yang 
> ---
>  drivers/staging/pi433/pi433_if.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/pi433/pi433_if.c 
> b/drivers/staging/pi433/pi433_if.c
> index 53928af696a6..0a48d6cb9547 100644
> --- a/drivers/staging/pi433/pi433_if.c
> +++ b/drivers/staging/pi433/pi433_if.c
> @@ -318,10 +318,17 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct 
> pi433_tx_cfg *tx_cfg)
>   return ret;
>   }
>  
> + /* configure sync, if enabled */

This comment is obvious.  Just delete it.

>   if (tx_cfg->enable_sync == OPTION_ON) {
>   ret = rf69_enable_sync(dev->spi);
>   if (ret < 0)
>   return ret;
> + ret = rf69_set_sync_size(dev->spi, tx_cfg->sync_length);
> + if (ret < 0)
> + return ret;
> + ret = rf69_set_sync_values(dev->spi, tx_cfg->sync_pattern);
> + if (ret < 0)
> + return ret;

It's weird that we enable sync before we et the size or sync values...

regards,
dan carpenter

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

Re: [PATCH 1/1] staging: media: imx: imx7-mipi-csis: simplify getting .driver_data

2019-03-27 Thread Simon Horman 
On Tue, Mar 19, 2019 at 05:36:22PM +0100, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

> ---
> 
> Build tested only. buildbot is happy.
> 
>  drivers/staging/media/imx/imx7-mipi-csis.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c 
> b/drivers/staging/media/imx/imx7-mipi-csis.c
> index 2ddcc42ab8ff..44569c63e4de 100644
> --- a/drivers/staging/media/imx/imx7-mipi-csis.c
> +++ b/drivers/staging/media/imx/imx7-mipi-csis.c
> @@ -1039,8 +1039,7 @@ static int mipi_csis_probe(struct platform_device *pdev)
>  
>  static int mipi_csis_pm_suspend(struct device *dev, bool runtime)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct v4l2_subdev *mipi_sd = platform_get_drvdata(pdev);
> + struct v4l2_subdev *mipi_sd = dev_get_drvdata(dev);
>   struct csi_state *state = mipi_sd_to_csis_state(mipi_sd);
>   int ret = 0;
>  
> @@ -1064,8 +1063,7 @@ static int mipi_csis_pm_suspend(struct device *dev, 
> bool runtime)
>  
>  static int mipi_csis_pm_resume(struct device *dev, bool runtime)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct v4l2_subdev *mipi_sd = platform_get_drvdata(pdev);
> + struct v4l2_subdev *mipi_sd = dev_get_drvdata(dev);
>   struct csi_state *state = mipi_sd_to_csis_state(mipi_sd);
>   int ret = 0;
>  
> -- 
> 2.11.0
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] vc04_services: vchiq_arm: fix a NULL pointer dereference

2019-03-27 Thread Mukesh Ojha 



On 3/25/2019 4:13 AM, Kangjie Lu wrote:

When kzalloc fails, "platform_state->inited = 1" is a NULL pointer
dereference. The fix returns VCHIQ_ERROR in case it failed to
avoid NULL pointer dereference.

Signed-off-by: Kangjie Lu 



Reviewed-by: Mukesh Ojha 

-Mukesh


---
  .../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c  | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index dd4898861b83..0f12fe617575 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -209,6 +209,8 @@ vchiq_platform_init_state(struct vchiq_state *state)
struct vchiq_2835_state *platform_state;
  
  	state->platform_state = kzalloc(sizeof(*platform_state), GFP_KERNEL);

+   if (!state->platform_state)
+   return VCHIQ_ERROR;
platform_state = (struct vchiq_2835_state *)state->platform_state;
  
  	platform_state->inited = 1;

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

[PATCH] staging: comedi: ni_tio: Use data[insn->n-1] in ni_tio_insn_write()

2019-03-27 Thread Ian Abbott 
The `insn_write` handler for the counter subdevices
(`ni_tio_insn_write()`) writes a single data value `data[0]` to the
channel.  Technically, `insn->n` specifies the number of successive
values from `data[]` to write to the channel, but when there is little
benefit in writing multiple data values, the usual Comedi convention is
to just write the last data value `data[insn->n - 1]`.  Change the
function to follow that convention and use `data[insn->n - 1]` instead
of `data[0]`.  (In practice, `insn->n` would normally be 1 anyway.)

Also follow the usual Comedi convention and return `insn->n` from the
handler to indicate success instead of 0 (although any non-negative
return value will do).

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/drivers/ni_tio.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
b/drivers/staging/comedi/drivers/ni_tio.c
index 048cb35723ad..943c5177cbea 100644
--- a/drivers/staging/comedi/drivers/ni_tio.c
+++ b/drivers/staging/comedi/drivers/ni_tio.c
@@ -1682,9 +1682,11 @@ int ni_tio_insn_write(struct comedi_device *dev,
unsigned int cidx = counter->counter_index;
unsigned int chip = counter->chip_index;
unsigned int load_reg;
+   unsigned int load_val;
 
if (insn->n < 1)
return 0;
+   load_val = data[insn->n - 1];
switch (channel) {
case 0:
/*
@@ -1697,7 +1699,7 @@ int ni_tio_insn_write(struct comedi_device *dev,
 * load register is already selected.
 */
load_reg = ni_tio_next_load_register(counter);
-   ni_tio_write(counter, data[0], load_reg);
+   ni_tio_write(counter, load_val, load_reg);
ni_tio_set_bits_transient(counter, NITIO_CMD_REG(cidx),
  0, 0, GI_LOAD);
/* restore load reg */
@@ -1705,17 +1707,17 @@ int ni_tio_insn_write(struct comedi_device *dev,
 load_reg);
break;
case 1:
-   counter_dev->regs[chip][NITIO_LOADA_REG(cidx)] = data[0];
-   ni_tio_write(counter, data[0], NITIO_LOADA_REG(cidx));
+   counter_dev->regs[chip][NITIO_LOADA_REG(cidx)] = load_val;
+   ni_tio_write(counter, load_val, NITIO_LOADA_REG(cidx));
break;
case 2:
-   counter_dev->regs[chip][NITIO_LOADB_REG(cidx)] = data[0];
-   ni_tio_write(counter, data[0], NITIO_LOADB_REG(cidx));
+   counter_dev->regs[chip][NITIO_LOADB_REG(cidx)] = load_val;
+   ni_tio_write(counter, load_val, NITIO_LOADB_REG(cidx));
break;
default:
return -EINVAL;
}
-   return 0;
+   return insn->n;
 }
 EXPORT_SYMBOL_GPL(ni_tio_insn_write);
 
-- 
2.20.1

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

Re: [PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types

2019-03-27 Thread David Hildenbrand 
On 20.12.18 14:08, Michal Hocko wrote:
> On Thu 20-12-18 13:58:16, David Hildenbrand wrote:
>> On 30.11.18 18:59, David Hildenbrand wrote:
>>> This is the second approach, introducing more meaningful memory block
>>> types and not changing online behavior in the kernel. It is based on
>>> latest linux-next.
>>>
>>> As we found out during dicussion, user space should always handle onlining
>>> of memory, in any case. However in order to make smart decisions in user
>>> space about if and how to online memory, we have to export more information
>>> about memory blocks. This way, we can formulate rules in user space.
>>>
>>> One such information is the type of memory block we are talking about.
>>> This helps to answer some questions like:
>>> - Does this memory block belong to a DIMM?
>>> - Can this DIMM theoretically ever be unplugged again?
>>> - Was this memory added by a balloon driver that will rely on balloon
>>>   inflation to remove chunks of that memory again? Which zone is advised?
>>> - Is this special standby memory on s390x that is usually not automatically
>>>   onlined?
>>>
>>> And in short it helps to answer to some extend (excluding zone imbalances)
>>> - Should I online this memory block?
>>> - To which zone should I online this memory block?
>>> ... of course special use cases will result in different anwers. But that's
>>> why user space has control of onlining memory.
>>>
>>> More details can be found in Patch 1 and Patch 3.
>>> Tested on x86 with hotplugged DIMMs. Cross-compiled for PPC and s390x.
>>>
>>>
>>> Example:
>>> $ udevadm info -q all -a /sys/devices/system/memory/memory0
>>> KERNEL=="memory0"
>>> SUBSYSTEM=="memory"
>>> DRIVER==""
>>> ATTR{online}=="1"
>>> ATTR{phys_device}=="0"
>>> ATTR{phys_index}==""
>>> ATTR{removable}=="0"
>>> ATTR{state}=="online"
>>> ATTR{type}=="boot"
>>> ATTR{valid_zones}=="none"
>>> $ udevadm info -q all -a /sys/devices/system/memory/memory90
>>> KERNEL=="memory90"
>>> SUBSYSTEM=="memory"
>>> DRIVER==""
>>> ATTR{online}=="1"
>>> ATTR{phys_device}=="0"
>>> ATTR{phys_index}=="005a"
>>> ATTR{removable}=="1"
>>> ATTR{state}=="online"
>>> ATTR{type}=="dimm"
>>> ATTR{valid_zones}=="Normal"
>>>
>>>
>>> RFC -> RFCv2:
>>> - Now also taking care of PPC (somehow missed it :/ )
>>> - Split the series up to some degree (some ideas on how to split up patch 3
>>>   would be very welcome)
>>> - Introduce more memory block types. Turns out abstracting too much was
>>>   rather confusing and not helpful. Properly document them.
>>>
>>> Notes:
>>> - I wanted to convert the enum of types into a named enum but this
>>>   provoked all kinds of different errors. For now, I am doing it just like
>>>   the other types (e.g. online_type) we are using in that context.
>>> - The "removable" property should never have been named like that. It
>>>   should have been "offlinable". Can we still rename that? E.g. boot memory
>>>   is sometimes marked as removable ...
>>>
>>
>>
>> Any feedback regarding the suggested block types would be very much
>> appreciated!
> 
> I still do not like this much to be honest. I just didn't get to think
> through this properly. My fear is that this is conflating an actual API
> with the current implementation and as such will cause problems in
> future. But I haven't really looked into your patches closely so I might
> be wrong. Anyway I won't be able to look into it by the end of year.
> 

So I started to think about this again, and I guess somehow exposing an
identification of the device driver that added the memory section could
be sufficient.

E.g. "hyperv", "xen", "acpi", "sclp", "virtio-mem" ...

Via separate device driver interfaces, other information about the
memory could be exposed. (e.g. for ACPI: which memory devices belong to
one physical device). So stuff would not have to centered around
/sys/devices/system/memory/ , uglifying it for special cases.

We would have to write udev rules to deal with these values, should be
easy. If no DRIVER is given, it is simply memory detected and detected
during boot. ACPI changing the DRIVER might be tricky (from no DRIVER ->
ACPI), but I guess it could be done.

Now, the question would be how to get the DRIVER value in there. Adding
a bunch of fake device drivers would work, however this might get a
little messy ... and then there is unbining and rebinding which can be
triggered by userspace. Thinks to care about? Most probably not.

-- 

Thanks,

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

[PATCH AUTOSEL 5.0 028/262] x86/hyperv: Fix kernel panic when kexec on HyperV

2019-03-27 Thread Sasha Levin 
From: Kairui Song 

[ Upstream commit 179fb36abb097976997f50733d5b122a29158cba ]

After commit 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments"),
kexec fails with a kernel panic:

kexec_core: Starting new kernel
BUG: unable to handle kernel NULL pointer dereference at 
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 
Hyper-V UEFI Release v3.0 03/02/2018
RIP: 0010:0xc901d000

Call Trace:
 ? __send_ipi_mask+0x1c6/0x2d0
 ? hv_send_ipi_mask_allbutself+0x6d/0xb0
 ? mp_save_irq+0x70/0x70
 ? __ioapic_read_entry+0x32/0x50
 ? ioapic_read_entry+0x39/0x50
 ? clear_IO_APIC_pin+0xb8/0x110
 ? native_stop_other_cpus+0x6e/0x170
 ? native_machine_shutdown+0x22/0x40
 ? kernel_kexec+0x136/0x156

That happens if hypercall based IPIs are used because the hypercall page is
reset very early upon kexec reboot, but kexec sends IPIs to stop CPUs,
which invokes the hypercall and dereferences the unusable page.

To fix his, reset hv_hypercall_pg to NULL before the page is reset to avoid
any misuse, IPI sending will fall back to the non hypercall based
method. This only happens on kexec / kdump so just setting the pointer to
NULL is good enough.

Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
Signed-off-by: Kairui Song 
Signed-off-by: Thomas Gleixner 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Vitaly Kuznetsov 
Cc: Dave Young 
Cc: de...@linuxdriverproject.org
Link: https://lkml.kernel.org/r/20190306111827.14131-1-kas...@redhat.com
Signed-off-by: Sasha Levin 
---
 arch/x86/hyperv/hv_init.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 7abb09e2eeb8..d3f42b6bbdac 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -406,6 +406,13 @@ void hyperv_cleanup(void)
/* Reset our OS id */
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
 
+   /*
+* Reset hypercall page reference before reset the page,
+* let hypercall operations fail safely rather than
+* panic the kernel for using invalid hypercall page
+*/
+   hv_hypercall_pg = NULL;
+
/* Reset the hypercall page */
hypercall_msr.as_uint64 = 0;
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
-- 
2.19.1

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

[PATCH AUTOSEL 5.0 126/262] media: rockchip/vpu: Correct return type for mem2mem buffer helpers

2019-03-27 Thread Sasha Levin 
From: Ezequiel Garcia 

[ Upstream commit 29701c3612fa025d5e8dc64c7a4ae8dc4763912e ]

Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:

 v4l2_m2m_next_buf
 v4l2_m2m_last_buf
 v4l2_m2m_buf_remove
 v4l2_m2m_next_src_buf
 v4l2_m2m_next_dst_buf
 v4l2_m2m_last_src_buf
 v4l2_m2m_last_dst_buf
 v4l2_m2m_src_buf_remove
 v4l2_m2m_dst_buf_remove

return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.

Fixing this is necessary to fix the mem2mem buffer handling API,
changing the return to the correct struct vb2_v4l2_buffer instead
of a void pointer.

Signed-off-by: Ezequiel Garcia 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 6 +++---
 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c 
b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index 5282236d1bb1..06daea66fb49 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -80,7 +80,7 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
 void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
 {
struct rockchip_vpu_dev *vpu = ctx->dev;
-   struct vb2_buffer *src_buf, *dst_buf;
+   struct vb2_v4l2_buffer *src_buf, *dst_buf;
struct rockchip_vpu_jpeg_ctx jpeg_ctx;
u32 reg;
 
@@ -88,7 +88,7 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 
memset(&jpeg_ctx, 0, sizeof(jpeg_ctx));
-   jpeg_ctx.buffer = vb2_plane_vaddr(dst_buf, 0);
+   jpeg_ctx.buffer = vb2_plane_vaddr(&dst_buf->vb2_buf, 0);
jpeg_ctx.width = ctx->dst_fmt.width;
jpeg_ctx.height = ctx->dst_fmt.height;
jpeg_ctx.quality = ctx->jpeg_quality;
@@ -99,7 +99,7 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
   VEPU_REG_ENC_CTRL);
 
rk3288_vpu_set_src_img_ctrl(vpu, ctx);
-   rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
+   rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, &src_buf->vb2_buf);
rk3288_vpu_jpeg_enc_set_qtable(vpu,
   rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
0),
   rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
1));
diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c 
b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
index dbc86d95fe3b..3d438797692e 100644
--- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
@@ -111,7 +111,7 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
 void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
 {
struct rockchip_vpu_dev *vpu = ctx->dev;
-   struct vb2_buffer *src_buf, *dst_buf;
+   struct vb2_v4l2_buffer *src_buf, *dst_buf;
struct rockchip_vpu_jpeg_ctx jpeg_ctx;
u32 reg;
 
@@ -119,7 +119,7 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 
memset(&jpeg_ctx, 0, sizeof(jpeg_ctx));
-   jpeg_ctx.buffer = vb2_plane_vaddr(dst_buf, 0);
+   jpeg_ctx.buffer = vb2_plane_vaddr(&dst_buf->vb2_buf, 0);
jpeg_ctx.width = ctx->dst_fmt.width;
jpeg_ctx.height = ctx->dst_fmt.height;
jpeg_ctx.quality = ctx->jpeg_quality;
@@ -130,7 +130,7 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
   VEPU_REG_ENCODE_START);
 
rk3399_vpu_set_src_img_ctrl(vpu, ctx);
-   rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
+   rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, &src_buf->vb2_buf);
rk3399_vpu_jpeg_enc_set_qtable(vpu,
   rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
0),
   rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
1));
-- 
2.19.1

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

[PATCH AUTOSEL 5.0 181/262] staging: spi: mt7621: Add return code check on device_reset()

2019-03-27 Thread Sasha Levin 
From: Stefan Roese 

[ Upstream commit 46c337872f34bc6387b0c29a4964f562c70139e3 ]

This patch adds a return code check on device_reset() and removes the
compile warning.

Signed-off-by: Stefan Roese 
Cc: Mark Brown 
Cc: Sankalp Negi 
Cc: Chuanhong Guo 
Cc: John Crispin 
Reviewed-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/staging/mt7621-spi/spi-mt7621.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c 
b/drivers/staging/mt7621-spi/spi-mt7621.c
index 513b6e79b985..e1f50efd0922 100644
--- a/drivers/staging/mt7621-spi/spi-mt7621.c
+++ b/drivers/staging/mt7621-spi/spi-mt7621.c
@@ -330,6 +330,7 @@ static int mt7621_spi_probe(struct platform_device *pdev)
int status = 0;
struct clk *clk;
struct mt7621_spi_ops *ops;
+   int ret;
 
match = of_match_device(mt7621_spi_match, &pdev->dev);
if (!match)
@@ -377,7 +378,11 @@ static int mt7621_spi_probe(struct platform_device *pdev)
rs->pending_write = 0;
dev_info(&pdev->dev, "sys_freq: %u\n", rs->sys_freq);
 
-   device_reset(&pdev->dev);
+   ret = device_reset(&pdev->dev);
+   if (ret) {
+   dev_err(&pdev->dev, "SPI reset failed!\n");
+   return ret;
+   }
 
mt7621_spi_reset(rs);
 
-- 
2.19.1

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

[PATCH AUTOSEL 5.0 253/262] staging: iio: adt7316: fix dac_bits assignment

2019-03-27 Thread Sasha Levin 
From: Jeremy Fertic 

[ Upstream commit e9de475723de5bf207a5b7b88bdca863393e42c8 ]

The value of dac_bits is used in adt7316_show_DAC() and adt7316_store_DAC(),
and it should be either 8, 10, or 12 bits depending on the device in use. The
driver currently only assigns a value to dac_bits in
adt7316_store_da_high_resolution(). The purpose of the dac high resolution
option is not to change dac resolution for normal operation. Instead, it
is specific to an optional feature where one or two of the four dacs can
be set to output voltage proportional to temperature. If the user chooses
to set dac a and/or dac b to output voltage proportional to temperature,
the da_high_resolution attribute can optionally be enabled to use 10 bit
resolution rather than the default 8 bits. This is only available on the
10 and 12 bit dac devices. If the user attempts to read or write dacs a
or b under these settings, the driver's current behaviour is to return an
error. Dacs c and d continue to operate normally under these conditions.
With the above in mind, remove the dac_bits assignments from this function
since the value of dac_bits as used in the driver is not dependent on this
dac high resolution option.

Since the dac_bits assignments discussed above are currently the only ones
in this driver, the default value of dac_bits is 0. This results in incorrect
calculations when the dacs are read or written in adt7316_show_DAC() and
adt7316_store_DAC(). To correct this, assign a value to dac_bits in
adt7316_probe() to ensure correct operation as soon as the device is
registered and available to userspace.

Fixes: 35f6b6b86ede ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver")
Signed-off-by: Jeremy Fertic 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/staging/iio/addac/adt7316.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/iio/addac/adt7316.c 
b/drivers/staging/iio/addac/adt7316.c
index dc93e85808e0..7839d869d25d 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -651,17 +651,10 @@ static ssize_t adt7316_store_da_high_resolution(struct 
device *dev,
u8 config3;
int ret;
 
-   chip->dac_bits = 8;
-
-   if (buf[0] == '1') {
+   if (buf[0] == '1')
config3 = chip->config3 | ADT7316_DA_HIGH_RESOLUTION;
-   if (chip->id == ID_ADT7316 || chip->id == ID_ADT7516)
-   chip->dac_bits = 12;
-   else if (chip->id == ID_ADT7317 || chip->id == ID_ADT7517)
-   chip->dac_bits = 10;
-   } else {
+   else
config3 = chip->config3 & (~ADT7316_DA_HIGH_RESOLUTION);
-   }
 
ret = chip->bus.write(chip->bus.client, ADT7316_CONFIG3, config3);
if (ret)
@@ -2123,6 +2116,13 @@ int adt7316_probe(struct device *dev, struct adt7316_bus 
*bus,
else
return -ENODEV;
 
+   if (chip->id == ID_ADT7316 || chip->id == ID_ADT7516)
+   chip->dac_bits = 12;
+   else if (chip->id == ID_ADT7317 || chip->id == ID_ADT7517)
+   chip->dac_bits = 10;
+   else
+   chip->dac_bits = 8;
+
chip->ldac_pin = devm_gpiod_get_optional(dev, "adi,ldac", 
GPIOD_OUT_LOW);
if (IS_ERR(chip->ldac_pin)) {
ret = PTR_ERR(chip->ldac_pin);
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 019/192] x86/hyperv: Fix kernel panic when kexec on HyperV

2019-03-27 Thread Sasha Levin 
From: Kairui Song 

[ Upstream commit 179fb36abb097976997f50733d5b122a29158cba ]

After commit 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments"),
kexec fails with a kernel panic:

kexec_core: Starting new kernel
BUG: unable to handle kernel NULL pointer dereference at 
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 
Hyper-V UEFI Release v3.0 03/02/2018
RIP: 0010:0xc901d000

Call Trace:
 ? __send_ipi_mask+0x1c6/0x2d0
 ? hv_send_ipi_mask_allbutself+0x6d/0xb0
 ? mp_save_irq+0x70/0x70
 ? __ioapic_read_entry+0x32/0x50
 ? ioapic_read_entry+0x39/0x50
 ? clear_IO_APIC_pin+0xb8/0x110
 ? native_stop_other_cpus+0x6e/0x170
 ? native_machine_shutdown+0x22/0x40
 ? kernel_kexec+0x136/0x156

That happens if hypercall based IPIs are used because the hypercall page is
reset very early upon kexec reboot, but kexec sends IPIs to stop CPUs,
which invokes the hypercall and dereferences the unusable page.

To fix his, reset hv_hypercall_pg to NULL before the page is reset to avoid
any misuse, IPI sending will fall back to the non hypercall based
method. This only happens on kexec / kdump so just setting the pointer to
NULL is good enough.

Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
Signed-off-by: Kairui Song 
Signed-off-by: Thomas Gleixner 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Vitaly Kuznetsov 
Cc: Dave Young 
Cc: de...@linuxdriverproject.org
Link: https://lkml.kernel.org/r/20190306111827.14131-1-kas...@redhat.com
Signed-off-by: Sasha Levin 
---
 arch/x86/hyperv/hv_init.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 20c876c7c5bf..87abd5145cc9 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -387,6 +387,13 @@ void hyperv_cleanup(void)
/* Reset our OS id */
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
 
+   /*
+* Reset hypercall page reference before reset the page,
+* let hypercall operations fail safely rather than
+* panic the kernel for using invalid hypercall page
+*/
+   hv_hypercall_pg = NULL;
+
/* Reset the hypercall page */
hypercall_msr.as_uint64 = 0;
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 131/192] staging: spi: mt7621: Add return code check on device_reset()

2019-03-27 Thread Sasha Levin 
From: Stefan Roese 

[ Upstream commit 46c337872f34bc6387b0c29a4964f562c70139e3 ]

This patch adds a return code check on device_reset() and removes the
compile warning.

Signed-off-by: Stefan Roese 
Cc: Mark Brown 
Cc: Sankalp Negi 
Cc: Chuanhong Guo 
Cc: John Crispin 
Reviewed-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/staging/mt7621-spi/spi-mt7621.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c 
b/drivers/staging/mt7621-spi/spi-mt7621.c
index d045b5568e0f..578aa6824ad3 100644
--- a/drivers/staging/mt7621-spi/spi-mt7621.c
+++ b/drivers/staging/mt7621-spi/spi-mt7621.c
@@ -429,6 +429,7 @@ static int mt7621_spi_probe(struct platform_device *pdev)
int status = 0;
struct clk *clk;
struct mt7621_spi_ops *ops;
+   int ret;
 
match = of_match_device(mt7621_spi_match, &pdev->dev);
if (!match)
@@ -476,7 +477,11 @@ static int mt7621_spi_probe(struct platform_device *pdev)
rs->pending_write = 0;
dev_info(&pdev->dev, "sys_freq: %u\n", rs->sys_freq);
 
-   device_reset(&pdev->dev);
+   ret = device_reset(&pdev->dev);
+   if (ret) {
+   dev_err(&pdev->dev, "SPI reset failed!\n");
+   return ret;
+   }
 
mt7621_spi_reset(rs, 0);
 
-- 
2.19.1

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

[PATCH v2] staging: rtl8723bs: core: fix line over 80 characters warning

2019-03-27 Thread Anirudh Rayabharam 
Checkpatch.pl complains that these lines are over 80 characters. Use the
"psecuritypriv" pointer for consistency, remove unnecessary parantheses
and fix the alignment.

This patch just cleans up a condition, it doesn't affect runtime.

Signed-off-by: Anirudh Rayabharam 
---
v2: Made the commit message clearer, removed unnecessary parantheses and fixed
the alignment as suggested by Dan Carpenter 

 drivers/staging/rtl8723bs/core/rtw_ap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c 
b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 18fabf5ff44b..8062b7f36de2 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -2336,8 +2336,8 @@ void rtw_ap_restore_network(struct adapter *padapter)
Update_RA_Entry(padapter, psta);
/* pairwise key */
/* per sta pairwise key and settings */
-   if ((padapter->securitypriv.dot11PrivacyAlgrthm == 
_TKIP_) ||
-   (padapter->securitypriv.dot11PrivacyAlgrthm == 
_AES_)) {
+   if (psecuritypriv->dot11PrivacyAlgrthm == _TKIP_ ||
+   psecuritypriv->dot11PrivacyAlgrthm == _AES_) {
rtw_setstakey_cmd(padapter, psta, true, false);
}
}
-- 
2.17.1

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

Re: [PATCH] Staging: emxx_udc: emxx_udc: Fixed a coding style error

2019-03-27 Thread Greg KH 
On Tue, Mar 26, 2019 at 09:47:23AM -0400, Will Cunningham wrote:
> Removed unnecessary parentheses.
> 
> Signed-off-by: Will Cunningham 
> ---
>  drivers/staging/emxx_udc/emxx_udc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Someone else sent this patch right before you did, sorry.

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

Re: [PATCH v2] staging/android: use multiple futex wait queues

2019-03-27 Thread Greg Kroah-Hartman 
On Fri, Feb 15, 2019 at 08:44:01AM +0100, Hugo Lefeuvre wrote:
> Use multiple per-offset wait queues instead of one big wait queue per
> region.
> 
> Signed-off-by: Hugo Lefeuvre 
> ---
> Changes in v2:
>   - dereference the it pointer instead of wait_queue (which is not set
> yet) in handle_vsoc_cond_wait()


How did you test this change?  This code needs a lot of testing by
someone before I can take it.

thanks,

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

Re: [PATCH v2] driver : staging : ion: optimization for decreasing memory fragmentaion

2019-03-27 Thread Greg KH 
On Wed, Mar 20, 2019 at 02:38:23PM +0800, Zhaoyang Huang wrote:
> From: Zhaoyang Huang 
> 
> Two action for this patch:
> 1. set a batch size for system heap's shrinker, which can have it buffer
> reasonable page blocks in pool for future allocation.
> 2. reverse the order sequence when free page blocks, the purpose is also
> to have system heap keep as more big blocks as it can.
> 
> By testing on an android system with 2G RAM, the changes with setting
> batch = 48MB can help reduce the fragmentation obviously and improve
> big block allocation speed for 15%.
> 
> Signed-off-by: Zhaoyang Huang 
> ---
>  drivers/staging/android/ion/ion_heap.c| 16 +++-
>  drivers/staging/android/ion/ion_system_heap.c |  2 +-
>  2 files changed, 16 insertions(+), 2 deletions(-)

What changed from v1?  Always put that below the --- line as the
documentation asks you to.

thanks,

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

[PATCH] staging: vt6655: Remove vif check from vnt_interrupt

2019-03-27 Thread Malcolm Priestley 
A check for vif is made in vnt_interrupt_work.

There is a small chance of leaving interrupt disabled while vif
is NULL and the work hasn't been scheduled.

Signed-off-by: Malcolm Priestley 
CC: sta...@vger.kernel.org # v4.2+
---
 drivers/staging/vt6655/device_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 83f1a1cf9182..c6bb4aaf9bd0 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1137,8 +1137,7 @@ static irqreturn_t vnt_interrupt(int irq,  void *arg)
 {
struct vnt_private *priv = arg;
 
-   if (priv->vif)
-   schedule_work(&priv->interrupt_work);
+   schedule_work(&priv->interrupt_work);
 
MACvIntDisable(priv->PortOffset);
 
-- 
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: wilc1000: assign scan result callback before starting the scan

2019-03-27 Thread Adham.Abozaeid 
From: Adham Abozaeid 

When scan is triggered, sometimes scan results are received before the scan
result callback is assigned, causing the recieved results to be ignored.

Signed-off-by: Adham Abozaeid 
---
 drivers/staging/wilc1000/host_interface.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 91ea16a6ae2e..e1a35bb426f9 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -313,6 +313,9 @@ int wilc_scan(struct wilc_vif *vif, u8 scan_source, u8 
scan_type,
wid_list[index].val = (s8 *)&scan_source;
index++;
 
+   hif_drv->usr_scan_req.scan_result = scan_result_fn;
+   hif_drv->usr_scan_req.arg = user_arg;
+
result = wilc_send_config_pkt(vif, WILC_SET_CFG, wid_list,
  index,
  wilc_get_vif_idx(vif));
@@ -321,8 +324,6 @@ int wilc_scan(struct wilc_vif *vif, u8 scan_source, u8 
scan_type,
goto error;
}
 
-   hif_drv->usr_scan_req.scan_result = scan_result_fn;
-   hif_drv->usr_scan_req.arg = user_arg;
hif_drv->scan_timer_vif = vif;
mod_timer(&hif_drv->scan_timer,
  jiffies + msecs_to_jiffies(WILC_HIF_SCAN_TIMEOUT_MS));
-- 
2.17.1

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

[PATCH] staging: rtl8192u: ieee80211: ieee80211_wx: add space before open brace

2019-03-27 Thread Julius Hemanth Pitti 
Fix checkpatch error "ERROR: that open brace { should be on
the previous line" in ieee80211_wx.c.

Signed-off-by: Julius Hemanth Pitti 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index fa59c71..ebcc642 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -195,7 +195,7 @@ static inline char *rtl819x_translate_scan(struct 
ieee80211_device *ieee,
if (iwe.u.data.length)
start = iwe_stream_add_point(info, start, stop, &iwe, custom);
 
-   if (ieee->wpa_enabled && network->wpa_ie_len){
+   if (ieee->wpa_enabled && network->wpa_ie_len) {
char buf[MAX_WPA_IE_LEN * 2 + 30];
//  printk("WPA IE\n");
u8 *p = buf;
@@ -210,7 +210,7 @@ static inline char *rtl819x_translate_scan(struct 
ieee80211_device *ieee,
start = iwe_stream_add_point(info, start, stop, &iwe, buf);
}
 
-   if (ieee->wpa_enabled && network->rsn_ie_len){
+   if (ieee->wpa_enabled && network->rsn_ie_len) {
char buf[MAX_WPA_IE_LEN * 2 + 30];
 
u8 *p = buf;
@@ -766,15 +766,13 @@ int ieee80211_wx_set_auth(struct ieee80211_device *ieee,
case IW_AUTH_80211_AUTH_ALG:
//printk("==>%s():data->value is 
%d\n",__func__,data->value);
//  ieee->open_wep = (data->value&IW_AUTH_ALG_OPEN_SYSTEM)?1:0;
-   if(data->value & IW_AUTH_ALG_SHARED_KEY){
+   if (data->value & IW_AUTH_ALG_SHARED_KEY) {
ieee->open_wep = 0;
ieee->auth_mode = 1;
-   }
-   else if(data->value & IW_AUTH_ALG_OPEN_SYSTEM){
+   } else if (data->value & IW_AUTH_ALG_OPEN_SYSTEM) {
ieee->open_wep = 1;
ieee->auth_mode = 0;
-   }
-   else if(data->value & IW_AUTH_ALG_LEAP){
+   } else if (data->value & IW_AUTH_ALG_LEAP) {
ieee->open_wep = 1;
ieee->auth_mode = 2;
}
-- 
2.7.4

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

Re: [PATCH] staging: rtl8192u: ieee80211: ieee80211_wx: add space before open brace

2019-03-27 Thread Julius Hemanth P 
On Wed, Mar 27, 2019 at 02:53:35PM -0700, Julius Hemanth Pitti wrote:
> Fix checkpatch error "ERROR: that open brace { should be on
> the previous line" in ieee80211_wx.c.
> 
> Signed-off-by: Julius Hemanth Pitti 
> ---
>  drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
> b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> index fa59c71..ebcc642 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> @@ -195,7 +195,7 @@ static inline char *rtl819x_translate_scan(struct 
> ieee80211_device *ieee,
>   if (iwe.u.data.length)
>   start = iwe_stream_add_point(info, start, stop, &iwe, custom);
>  
> - if (ieee->wpa_enabled && network->wpa_ie_len){
> + if (ieee->wpa_enabled && network->wpa_ie_len) {
>   char buf[MAX_WPA_IE_LEN * 2 + 30];
>   //  printk("WPA IE\n");
>   u8 *p = buf;
> @@ -210,7 +210,7 @@ static inline char *rtl819x_translate_scan(struct 
> ieee80211_device *ieee,
>   start = iwe_stream_add_point(info, start, stop, &iwe, buf);
>   }
>  
> - if (ieee->wpa_enabled && network->rsn_ie_len){
> + if (ieee->wpa_enabled && network->rsn_ie_len) {
>   char buf[MAX_WPA_IE_LEN * 2 + 30];
>  
>   u8 *p = buf;
> @@ -766,15 +766,13 @@ int ieee80211_wx_set_auth(struct ieee80211_device *ieee,
>   case IW_AUTH_80211_AUTH_ALG:
>   //printk("==>%s():data->value is 
> %d\n",__func__,data->value);
>   //  ieee->open_wep = (data->value&IW_AUTH_ALG_OPEN_SYSTEM)?1:0;
> - if(data->value & IW_AUTH_ALG_SHARED_KEY){
> + if (data->value & IW_AUTH_ALG_SHARED_KEY) {
>   ieee->open_wep = 0;
>   ieee->auth_mode = 1;
> - }
> - else if(data->value & IW_AUTH_ALG_OPEN_SYSTEM){
> + } else if (data->value & IW_AUTH_ALG_OPEN_SYSTEM) {
>   ieee->open_wep = 1;
>   ieee->auth_mode = 0;
> - }
> - else if(data->value & IW_AUTH_ALG_LEAP){
> + } else if (data->value & IW_AUTH_ALG_LEAP) {
>   ieee->open_wep = 1;
>   ieee->auth_mode = 2;
>   }
> -- 
> 2.7.4
>
Sorry for typo in commit message, please ignore this patch.
Will send updated one as v2.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: rtl8192u: ieee80211: ieee80211_wx: add space before open brace

2019-03-27 Thread Julius Hemanth Pitti 
Fix checkpatch error "ERROR: space required before the open brace
'{'" in ieee80211_wx.c.

Signed-off-by: Julius Hemanth Pitti 
---
Changes in v2:
 - Corrected commit message typo

 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index fa59c71..ebcc642 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -195,7 +195,7 @@ static inline char *rtl819x_translate_scan(struct 
ieee80211_device *ieee,
if (iwe.u.data.length)
start = iwe_stream_add_point(info, start, stop, &iwe, custom);
 
-   if (ieee->wpa_enabled && network->wpa_ie_len){
+   if (ieee->wpa_enabled && network->wpa_ie_len) {
char buf[MAX_WPA_IE_LEN * 2 + 30];
//  printk("WPA IE\n");
u8 *p = buf;
@@ -210,7 +210,7 @@ static inline char *rtl819x_translate_scan(struct 
ieee80211_device *ieee,
start = iwe_stream_add_point(info, start, stop, &iwe, buf);
}
 
-   if (ieee->wpa_enabled && network->rsn_ie_len){
+   if (ieee->wpa_enabled && network->rsn_ie_len) {
char buf[MAX_WPA_IE_LEN * 2 + 30];
 
u8 *p = buf;
@@ -766,15 +766,13 @@ int ieee80211_wx_set_auth(struct ieee80211_device *ieee,
case IW_AUTH_80211_AUTH_ALG:
//printk("==>%s():data->value is 
%d\n",__func__,data->value);
//  ieee->open_wep = (data->value&IW_AUTH_ALG_OPEN_SYSTEM)?1:0;
-   if(data->value & IW_AUTH_ALG_SHARED_KEY){
+   if (data->value & IW_AUTH_ALG_SHARED_KEY) {
ieee->open_wep = 0;
ieee->auth_mode = 1;
-   }
-   else if(data->value & IW_AUTH_ALG_OPEN_SYSTEM){
+   } else if (data->value & IW_AUTH_ALG_OPEN_SYSTEM) {
ieee->open_wep = 1;
ieee->auth_mode = 0;
-   }
-   else if(data->value & IW_AUTH_ALG_LEAP){
+   } else if (data->value & IW_AUTH_ALG_LEAP) {
ieee->open_wep = 1;
ieee->auth_mode = 2;
}
-- 
2.7.4

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

[RFC PATCH 22/68] vfs: Convert binderfs to use the new mount API

2019-03-27 Thread David Howells 
Convert the binderfs filesystem to the new internal mount API as the old
one will be obsoleted and removed.  This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.

See Documentation/filesystems/mount_api.txt for more information.

Signed-off-by: David Howells 
Reviewed-by: Christian Brauner 
cc: Greg Kroah-Hartman 
cc: "Arve Hjønnevåg" 
cc: Todd Kjos 
cc: Martijn Coenen 
cc: Joel Fernandes 
cc: de...@driverdev.osuosl.org
---

 drivers/android/binderfs.c |  173 
 1 file changed, 96 insertions(+), 77 deletions(-)

diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index e773f45d19d9..0a16ecc9594f 100644
--- a/drivers/android/binderfs.c
+++ b/drivers/android/binderfs.c
@@ -18,7 +18,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -48,22 +49,18 @@ static dev_t binderfs_dev;
 static DEFINE_MUTEX(binderfs_minors_mutex);
 static DEFINE_IDA(binderfs_minors);
 
-/**
- * binderfs_mount_opts - mount options for binderfs
- * @max: maximum number of allocatable binderfs binder devices
- */
-struct binderfs_mount_opts {
-   int max;
-};
-
 enum {
Opt_max,
-   Opt_err
 };
 
-static const match_table_t tokens = {
-   { Opt_max, "max=%d" },
-   { Opt_err, NULL }
+static const struct fs_parameter_spec binderfs_param_specs[] = {
+   fsparam_s32   ("max",   Opt_max),
+   {}
+};
+
+static const struct fs_parameter_description binderfs_fs_parameters = {
+   .name   = "binderfs",
+   .specs  = binderfs_param_specs,
 };
 
 /**
@@ -75,7 +72,7 @@ static const match_table_t tokens = {
  *  created.
  * @root_gid:   gid that needs to be used when a new binder device is
  *  created.
- * @mount_opts: The mount options in use.
+ * @max:   Maximum number of allocatable binderfs binder devices.
  * @device_count:   The current number of allocated binder devices.
  */
 struct binderfs_info {
@@ -83,7 +80,7 @@ struct binderfs_info {
struct dentry *control_dentry;
kuid_t root_uid;
kgid_t root_gid;
-   struct binderfs_mount_opts mount_opts;
+   int max;
int device_count;
 };
 
@@ -138,7 +135,7 @@ static int binderfs_binder_device_create(struct inode 
*ref_inode,
 
/* Reserve new minor number for the new device. */
mutex_lock(&binderfs_minors_mutex);
-   if (++info->device_count <= info->mount_opts.max)
+   if (++info->device_count <= info->max)
minor = ida_alloc_max(&binderfs_minors,
  use_reserve ? BINDERFS_MAX_MINOR :
BINDERFS_MAX_MINOR_CAPPED,
@@ -285,46 +282,36 @@ static void binderfs_evict_inode(struct inode *inode)
 }
 
 /**
- * binderfs_parse_mount_opts - parse binderfs mount options
- * @data: options to set (can be NULL in which case defaults are used)
+ * binderfs_parse_param - parse a binderfs mount option
+ * @fc: The context to be configured
+ * @param: The parameter to apply
  */
-static int binderfs_parse_mount_opts(char *data,
-struct binderfs_mount_opts *opts)
+static int binderfs_parse_param(struct fs_context *fc, struct fs_parameter 
*param)
 {
-   char *p;
-   opts->max = BINDERFS_MAX_MINOR;
-
-   while ((p = strsep(&data, ",")) != NULL) {
-   substring_t args[MAX_OPT_ARGS];
-   int token;
-   int max_devices;
-
-   if (!*p)
-   continue;
-
-   token = match_token(p, tokens, args);
-   switch (token) {
-   case Opt_max:
-   if (match_int(&args[0], &max_devices) ||
-   (max_devices < 0 ||
-(max_devices > BINDERFS_MAX_MINOR)))
-   return -EINVAL;
-
-   opts->max = max_devices;
-   break;
-   default:
-   pr_err("Invalid mount options\n");
-   return -EINVAL;
-   }
+   struct fs_parse_result result;
+   struct binderfs_info *info = fc->s_fs_info;
+   int opt;
+
+   opt = fs_parse(fc, &binderfs_fs_parameters, param, &result);
+   if (opt < 0)
+   return opt;
+
+   switch (opt) {
+   case Opt_max:
+   info->max = result.int_32;
+   break;
}
 
return 0;
 }
 
-static int binderfs_remount(struct super_block *sb, int *flags, char *data)
+static int binderfs_reconfigure(struct fs_context *fc)
 {
-   struct binderfs_info *info = sb->s_fs_info;
-   return binderfs_parse_mount_opts(data, &info->mount_opts);
+   struct binderfs_info *info = fc->root->d_sb->s_fs_info;
+   struct binderfs_info *cfg = fc->s_fs_info;
+
+   info->max = cfg->max

Re: [PATCH v2] staging: rtl8723bs: core: fix line over 80 characters warning

2019-03-27 Thread Dan Carpenter 
Thanks!

Reviewed-by: Dan Carpenter 

regards,
dan carpenter

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