RE: [PATCH] x86/hyper-v: Zero out the VP assist page to fix CPU offlining

2019-07-17 Thread Dexuan Cui
> From: Thomas Gleixner 
> Sent: Wednesday, July 17, 2019 4:04 PM
> To: Dexuan Cui 
> ...
> On Thu, 4 Jul 2019, Dexuan Cui wrote:
> > When a CPU is being offlined, the CPU usually still receives a few
> > interrupts (e.g. reschedule IPIs), after hv_cpu_die() disables the
> > HV_X64_MSR_VP_ASSIST_PAGE, so hv_apic_eoi_write() may not write 
> > the EOI MSR, if the apic_assist field's bit0 happens to be 1; as a result,
> > Hyper-V may not be able to deliver all the interrupts to the CPU, and the
> > CPU may not be stopped, and the kernel will hang soon.
> >
> > The VP ASSIST PAGE is an "overlay" page (see Hyper-V TLFS's Section
> > 5.2.1 "GPA Overlay Pages"), so with this fix we're sure the apic_assist
> > field is still zero, after the VP ASSIST PAGE is disabled.
> >
> > Fixes: ba696429d290 ("x86/hyper-v: Implement EOI assist")
> > Signed-off-by: Dexuan Cui 
> > 
> > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> > index 0e033ef11a9f..db51a301f759 100644
> > --- a/arch/x86/hyperv/hv_init.c
> > +++ b/arch/x86/hyperv/hv_init.c
> > @@ -60,8 +60,14 @@ static int hv_cpu_init(unsigned int cpu)
> > if (!hv_vp_assist_page)
> > return 0;
> >
> > +   /*
> > +* The ZERO flag is necessary, because in the case of CPU offlining
> > +* the page can still be used by hv_apic_eoi_write() for a while,
> > +* after the VP ASSIST PAGE is disabled in hv_cpu_die().
> > +*/
> > if (!*hvp)
> > -   *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL);
> > +   *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO,
> > +PAGE_KERNEL);
> 
> This is the allocation when the CPU is brought online for the first
> time. So what effect has zeroing at allocation time vs. offlining and
> potentially receiving IPIs? That allocation is never freed.
> 
> Neither the comment nor the changelog make any sense to me.
>   tglx

That allocation was introduced by the commit
a46d15cc1ae5 ("x86/hyper-v: allocate and use Virtual Processor Assist Pages").

I think it's ok to not free the page when a CPU is offlined: every
CPU uses only 1 page and CPU offlining is not really a very usual
operation except for the scenario of hibernation (and suspend-to-memory), 
where the CPUs are quickly onlined again, when we resume from hibernation.
IMO Vitaly intentionally decided to not free the page for simplicity of the
code.

When a CPU (e.g. CPU1) is being onlined, in hv_cpu_init(), we allocate the
VP_ASSIST_PAGE page and enable the PV EOI optimization for this CPU by
writing the MSR HV_X64_MSR_VP_ASSIST_PAGE. From now on, this CPU
*always* uses hvp->apic_assist (which is updated by the hypervisor) to
decide if it needs to write the EOI MSR:

static void hv_apic_eoi_write(u32 reg, u32 val)
{
struct hv_vp_assist_page *hvp = hv_vp_assist_page[smp_processor_id()];

if (hvp && (xchg(>apic_assist, 0) & 0x1))
return;

wrmsr(HV_X64_MSR_EOI, val, 0);
}

When a CPU (e.g. CPU1) is being offlined, on this CPU, we do:
1. in hv_cpu_die(), we disable the PV EOI optimizaton for this CPU;
2. we finish the remaining work of stopping this CPU;
3. this CPU is completed stopped.

Between 1 and 3, this CPU can still receive interrupts (e.g. IPIs from CPU0,
and Local APIC timer interrupts), and this CPU *must* write the EOI MSR for
every interrupt received, otherwise the hypervisor may not deliver further
interrupts, which may be needed to stop this CPU completely.

So we need to make sure hvp->apic_assist.bit0 is zero, after we run the line
"wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE, 0);" in hv_cpu_die(). The easiest
way is what I do in this patch. Alternatively, we can use the below patch:

@@ -188,8 +188,12 @@ static int hv_cpu_die(unsigned int cpu)
local_irq_restore(flags);
free_page((unsigned long)input_pg);

-   if (hv_vp_assist_page && hv_vp_assist_page[cpu])
+   if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
+   local_irq_save(flags);
wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE, 0);
+   hvp->apic_assist &= ~1;
+   local_irq_restore(flags);
+   }

if (hv_reenlightenment_cb == NULL)
return 0;

This second version needs 3+ lines, so I prefer the one-line version. :-)

Thanks,
-- Dexuan


Re: [PATCH] x86/hyper-v: Zero out the VP assist page to fix CPU offlining

2019-07-17 Thread Thomas Gleixner
Dexuan,

On Thu, 4 Jul 2019, Dexuan Cui wrote:

> When a CPU is being offlined, the CPU usually still receives a few
> interrupts (e.g. reschedule IPIs), after hv_cpu_die() disables the
> HV_X64_MSR_VP_ASSIST_PAGE, so hv_apic_eoi_write() may not write the EOI
> MSR, if the apic_assist field's bit0 happens to be 1; as a result, Hyper-V
> may not be able to deliver all the interrupts to the CPU, and the CPU may
> not be stopped, and the kernel will hang soon.
> 
> The VP ASSIST PAGE is an "overlay" page (see Hyper-V TLFS's Section
> 5.2.1 "GPA Overlay Pages"), so with this fix we're sure the apic_assist
> field is still zero, after the VP ASSIST PAGE is disabled.
> 
> Fixes: ba696429d290 ("x86/hyper-v: Implement EOI assist")
> Signed-off-by: Dexuan Cui 
> ---
>  arch/x86/hyperv/hv_init.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 0e033ef11a9f..db51a301f759 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -60,8 +60,14 @@ static int hv_cpu_init(unsigned int cpu)
>   if (!hv_vp_assist_page)
>   return 0;
>  
> + /*
> +  * The ZERO flag is necessary, because in the case of CPU offlining
> +  * the page can still be used by hv_apic_eoi_write() for a while,
> +  * after the VP ASSIST PAGE is disabled in hv_cpu_die().
> +  */
>   if (!*hvp)
> - *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL);
> + *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO,
> +  PAGE_KERNEL);

This is the allocation when the CPU is brought online for the first
time. So what effect has zeroing at allocation time vs. offlining and
potentially receiving IPIs? That allocation is never freed.

Neither the comment nor the changelog make any sense to me.

Thanks,

tglx



Re: WARNING in binder_transaction_buffer_release

2019-07-17 Thread Todd Kjos
+Hridya Valsaraju

Fix posted: 
https://lkml.kernel.org/lkml/20190715191804.112933-1-hri...@google.com/


On Wed, Jun 12, 2019 at 1:14 PM Todd Kjos  wrote:
>
> On Wed, Jun 12, 2019 at 12:23 PM Eric Biggers  wrote:
> >
> > On Mon, May 20, 2019 at 07:18:06AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:72cf0b07 Merge tag 'sound-fix-5.2-rc1' of 
> > > git://git.kernel..
> > > git tree:   upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=17c7d4bca0
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=d103f114f9010324
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=8b3c354d33c4ac78bfad
> > > compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> > > userspace arch: i386
> > > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15b99b44a0
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+8b3c354d33c4ac78b...@syzkaller.appspotmail.com
> > >
> > > WARNING: CPU: 1 PID: 8535 at drivers/android/binder.c:2368
> > > binder_transaction_buffer_release+0x673/0x8f0 
> > > drivers/android/binder.c:2368
> > > Kernel panic - not syncing: panic_on_warn set ...
> > > CPU: 1 PID: 8535 Comm: syz-executor.2 Not tainted 5.1.0+ #19
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > >  __dump_stack lib/dump_stack.c:77 [inline]
> > >  dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > >  panic+0x2cb/0x715 kernel/panic.c:214
> > >  __warn.cold+0x20/0x4c kernel/panic.c:571
> > >  report_bug+0x263/0x2b0 lib/bug.c:186
> > >  fixup_bug arch/x86/kernel/traps.c:179 [inline]
> > >  fixup_bug arch/x86/kernel/traps.c:174 [inline]
> > >  do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
> > >  do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
> > >  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986
> > > RIP: 0010:binder_transaction_buffer_release+0x673/0x8f0
> > > drivers/android/binder.c:2368
> > > Code: 31 ff 41 89 c5 89 c6 e8 7b 04 1f fc 45 85 ed 0f 85 1f 41 01 00 49 8d
> > > 47 40 48 89 85 50 fe ff ff e9 9d fa ff ff e8 dd 02 1f fc <0f> 0b e9 7f fc 
> > > ff
> > > ff e8 d1 02 1f fc 48 89 d8 45 31 c9 4c 89 fe 4c
> > > RSP: 0018:88807b2775f0 EFLAGS: 00010293
> > > RAX: 888092b1e040 RBX: 0060 RCX: 111012563caa
> > > RDX:  RSI: 85519e13 RDI: 888097a2d248
> > > RBP: 88807b2777d8 R08: 888092b1e040 R09: ed100f64eee3
> > > R10: ed100f64eee2 R11: 88807b277717 R12: 88808fd2c340
> > > R13: 0068 R14: 88807b2777b0 R15: 88809f7ea580
> > >  binder_transaction+0x153d/0x6620 drivers/android/binder.c:3484
> > >  binder_thread_write+0x87e/0x2820 drivers/android/binder.c:3792
> > >  binder_ioctl_write_read drivers/android/binder.c:4836 [inline]
> > >  binder_ioctl+0x102f/0x1833 drivers/android/binder.c:5013
> > >  __do_compat_sys_ioctl fs/compat_ioctl.c:1052 [inline]
> > >  __se_compat_sys_ioctl fs/compat_ioctl.c:998 [inline]
> > >  __ia32_compat_sys_ioctl+0x195/0x620 fs/compat_ioctl.c:998
> > >  do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline]
> > >  do_fast_syscall_32+0x27b/0xd7d arch/x86/entry/common.c:408
> > >  entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> > > RIP: 0023:0xf7f9e849
> > > Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90
> > > 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 
> > > 90
> > > 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
> > > RSP: 002b:f7f9a0cc EFLAGS: 0296 ORIG_RAX: 0036
> > > RAX: ffda RBX: 0004 RCX: c0306201
> > > RDX: 2140 RSI:  RDI: 
> > > RBP:  R08:  R09: 
> > > R10:  R11:  R12: 
> > > R13:  R14:  R15: 
> > > Kernel Offset: disabled
> > > Rebooting in 86400 seconds..
> > >
> > >
> > > ---
> > > This bug is generated by a bot. It may contain errors.
> > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > syzbot engineers can be reached at syzkal...@googlegroups.com.
> > >
> > > syzbot will keep track of this bug report. See:
> > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > > syzbot can test patches for this bug, for details see:
> > > https://goo.gl/tpsmEJ#testing-patches
> > >
> >
> > Are any of the binder maintainers planning to fix this?  This seems to be 
> > the
> > only open syzbot report for binder on the upstream kernel.
>
> Taking a look.
>
> >
> > - Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] v3: staging: erofs: fix typo

2019-07-17 Thread Karen Palacio
Fix typo in Kconfig

Signed-off-by: Karen Palacio 

diff --git a/drivers/staging/erofs/Kconfig b/drivers/staging/erofs/Kconfig
index d04b798..0dcefac 100644
--- a/drivers/staging/erofs/Kconfig
+++ b/drivers/staging/erofs/Kconfig
@@ -88,7 +88,7 @@ config EROFS_FS_IO_MAX_RETRIES
  If unsure, leave the default value (5 retries, 6 IOs at most).

 config EROFS_FS_ZIP
-   bool "EROFS Data Compresssion Support"
+   bool "EROFS Data Compression Support"
depends on EROFS_FS
select LZ4_DECOMPRESS
help
---
 drivers/staging/erofs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/erofs/Kconfig b/drivers/staging/erofs/Kconfig
index d04b798..0dcefac 100644
--- a/drivers/staging/erofs/Kconfig
+++ b/drivers/staging/erofs/Kconfig
@@ -88,7 +88,7 @@ config EROFS_FS_IO_MAX_RETRIES
  If unsure, leave the default value (5 retries, 6 IOs at most).
 
 config EROFS_FS_ZIP
-   bool "EROFS Data Compresssion Support"
+   bool "EROFS Data Compression Support"
depends on EROFS_FS
select LZ4_DECOMPRESS
help
-- 
2.7.4

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


good day

2019-07-17 Thread Raymond Chien Kuo Fung
I am Vice Chairman of Hang Seng Bank, I have Important Matter to Discuss with 
you concerning my late client, Died without a NEXT OF KIN. Send me your private 
email for full details information. email me at (infocar...@aim.com)

Mail:infocar...@aim.com

Regards
Dr.Raymond Chien Kuo Fung
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: rtl8723bs: core: Remove Unneeded variable ret

2019-07-17 Thread Hariprasad Kelam
Remove Unneeded variable ret . Return _FAIL .

We cannot change return type of on_action_spct as its callback function.

Issue identified with coccicheck.

Signed-off-by: Hariprasad Kelam 
---
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 4285844..0bec806 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -1882,7 +1882,6 @@ unsigned int OnAtim(struct adapter *padapter, union 
recv_frame *precv_frame)
 
 unsigned int on_action_spct(struct adapter *padapter, union recv_frame 
*precv_frame)
 {
-   unsigned int ret = _FAIL;
struct sta_info *psta = NULL;
struct sta_priv *pstapriv = >stapriv;
u8 *pframe = precv_frame->u.hdr.rx_data;
@@ -1914,7 +1913,7 @@ unsigned int on_action_spct(struct adapter *padapter, 
union recv_frame *precv_fr
}
 
 exit:
-   return ret;
+   return _FAIL;
 }
 
 unsigned int OnAction_back(struct adapter *padapter, union recv_frame 
*precv_frame)
-- 
2.7.4

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


[PATCH] staging: rtl8723bs: os_dep: change return type of rtw_suspend_ap_wow

2019-07-17 Thread Hariprasad Kelam
Change return type of rtw_suspend_ap_wow as its always return SUCCCESS.

Issue found with coccicheck

Signed-off-by: Hariprasad Kelam 
---
 drivers/staging/rtl8723bs/os_dep/os_intfs.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/os_intfs.c 
b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
index 544e799..285fd54 100644
--- a/drivers/staging/rtl8723bs/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
@@ -1361,13 +1361,12 @@ void rtw_suspend_wow(struct adapter *padapter)
 #endif /* ifdef CONFIG_WOWLAN */
 
 #ifdef CONFIG_AP_WOWLAN
-int rtw_suspend_ap_wow(struct adapter *padapter)
+void rtw_suspend_ap_wow(struct adapter *padapter)
 {
u8 ch, bw, offset;
struct net_device *pnetdev = padapter->pnetdev;
struct pwrctrl_priv *pwrpriv = adapter_to_pwrctl(padapter);
struct wowlan_ioctl_param poidparam;
-   int ret = _SUCCESS;
 
DBG_871X("==> " FUNC_ADPT_FMT " entry\n", FUNC_ADPT_ARG(padapter));
 
@@ -1409,7 +1408,6 @@ int rtw_suspend_ap_wow(struct adapter *padapter)
rtw_set_ps_mode(padapter, PS_MODE_MIN, 0, 0, "AP-WOWLAN");
 
DBG_871X("<== " FUNC_ADPT_FMT " exit\n", FUNC_ADPT_ARG(padapter));
-   return ret;
 }
 #endif /* ifdef CONFIG_AP_WOWLAN */
 
-- 
2.7.4

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


Limits for ION Memory Allocator

2019-07-17 Thread Alexander Popov
Hello!

The syzkaller [1] has a trouble with fuzzing the Linux kernel with ION Memory
Allocator.

Syzkaller uses several methods [2] to limit memory consumption of the userspace
processes calling the syscalls for testing the kernel:
 - setrlimit(),
 - cgroups,
 - various sysctl.
But these methods don't work for ION Memory Allocator, so any userspace process
that has access to /dev/ion can bring the system to the out-of-memory state.

An example of a program doing that:


#include 
#include 
#include 
#include 
#include 
#include 

#define ION_IOC_MAGIC   'I'
#define ION_IOC_ALLOC   _IOWR(ION_IOC_MAGIC, 0, \
  struct ion_allocation_data)

struct ion_allocation_data {
__u64 len;
__u32 heap_id_mask;
__u32 flags;
__u32 fd;
__u32 unused;
};

int main(void)
{
unsigned long i = 0;
int fd = -1;
struct ion_allocation_data data = {
.len = 0x13f65d8c,
.heap_id_mask = 1,
.flags = 0,
.fd = -1,
.unused = 0
};

fd = open("/dev/ion", 0);
if (fd == -1) {
perror("[-] open /dev/ion");
return 1;
}

while (1) {
printf("iter %lu\n", i);
ioctl(fd, ION_IOC_ALLOC, );
i++;
}

return 0;
}


I looked through the code of ion_alloc() and didn't find any limit checks.
Is it currently possible to limit ION kernel allocations for some process?

If not, is it a right idea to do that?
Thanks!

Best regards,
Alexander


[1]: https://github.com/google/syzkaller
[2]: https://github.com/google/syzkaller/blob/master/executor/common_linux.h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: android: ion: Remove unused rbtree for ion_buffer

2019-07-17 Thread Laura Abbott

On 7/12/19 4:47 AM, Lecopzer Chen wrote:

ion_buffer_add() insert ion_buffer into rbtree every time creating
an ion_buffer but never use it after ION reworking.
Also, buffer_lock protects only rbtree operation, remove it together.

Signed-off-by: Lecopzer Chen 
Cc: YJ Chiang 
Cc: Lecopzer Chen 
---
  drivers/staging/android/ion/ion.c | 36 ---
  drivers/staging/android/ion/ion.h | 10 +
  2 files changed, 1 insertion(+), 45 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 92c2914239e3..e6b1ca141b93 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -29,32 +29,6 @@
  static struct ion_device *internal_dev;
  static int heap_id;
  
-/* this function should only be called while dev->lock is held */

-static void ion_buffer_add(struct ion_device *dev,
-  struct ion_buffer *buffer)
-{
-   struct rb_node **p = >buffers.rb_node;
-   struct rb_node *parent = NULL;
-   struct ion_buffer *entry;
-
-   while (*p) {
-   parent = *p;
-   entry = rb_entry(parent, struct ion_buffer, node);
-
-   if (buffer < entry) {
-   p = &(*p)->rb_left;
-   } else if (buffer > entry) {
-   p = &(*p)->rb_right;
-   } else {
-   pr_err("%s: buffer already found.", __func__);
-   BUG();
-   }
-   }
-
-   rb_link_node(>node, parent, p);
-   rb_insert_color(>node, >buffers);
-}
-
  /* this function should only be called while dev->lock is held */
  static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
@@ -100,9 +74,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
  
  	INIT_LIST_HEAD(>attachments);

mutex_init(>lock);
-   mutex_lock(>buffer_lock);
-   ion_buffer_add(dev, buffer);
-   mutex_unlock(>buffer_lock);
return buffer;
  
  err1:

@@ -131,11 +102,6 @@ void ion_buffer_destroy(struct ion_buffer *buffer)
  static void _ion_buffer_destroy(struct ion_buffer *buffer)
  {
struct ion_heap *heap = buffer->heap;
-   struct ion_device *dev = buffer->dev;
-
-   mutex_lock(>buffer_lock);
-   rb_erase(>node, >buffers);
-   mutex_unlock(>buffer_lock);
  
  	if (heap->flags & ION_HEAP_FLAG_DEFER_FREE)

ion_heap_freelist_add(heap, buffer);
@@ -694,8 +660,6 @@ static int ion_device_create(void)
}
  
  	idev->debug_root = debugfs_create_dir("ion", NULL);

-   idev->buffers = RB_ROOT;
-   mutex_init(>buffer_lock);
init_rwsem(>lock);
plist_head_init(>heaps);
internal_dev = idev;
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index e291299fd35f..74914a266e25 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -23,7 +23,6 @@
  
  /**

   * struct ion_buffer - metadata for a particular buffer
- * @node:  node in the ion_device buffers tree
   * @list: element in list of deferred freeable buffers
   * @dev:  back pointer to the ion_device
   * @heap: back pointer to the heap the buffer came from
@@ -39,10 +38,7 @@
   * @attachments:  list of devices attached to this buffer
   */
  struct ion_buffer {
-   union {
-   struct rb_node node;
-   struct list_head list;
-   };
+   struct list_head list;
struct ion_device *dev;
struct ion_heap *heap;
unsigned long flags;
@@ -61,14 +57,10 @@ void ion_buffer_destroy(struct ion_buffer *buffer);
  /**
   * struct ion_device - the metadata of the ion device node
   * @dev:  the actual misc device
- * @buffers:   an rb tree of all the existing buffers
- * @buffer_lock:   lock protecting the tree of buffers
   * @lock: rwsem protecting the tree of heaps and clients
   */
  struct ion_device {
struct miscdevice dev;
-   struct rb_root buffers;
-   struct mutex buffer_lock;
struct rw_semaphore lock;
struct plist_head heaps;
struct dentry *debug_root;



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


[PATCH v2] Staging: fbtft: Fix GPIO handling

2019-07-17 Thread Jan Sebastian Götte
Commit c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor
interface") breaks GPIO handling. In several places, checks to only set
a GPIO if it was configured ended up backwards.
I have tested this fix. The fixed driver works with a ili9486
display connected to a raspberry pi via SPI.

Fixes: commit c440eee1a7a1d ("Staging: fbtft: Switch to the gpio descriptor 
interface")
Tested-by: Jan Sebastian Götte 
Reviewed-by: Nicolas Saenz Julienne 
Signed-off-by: Jan Sebastian Götte 
---
 drivers/staging/fbtft/fb_bd663474.c  | 2 +-
 drivers/staging/fbtft/fb_ili9163.c   | 2 +-
 drivers/staging/fbtft/fb_ili9325.c   | 2 +-
 drivers/staging/fbtft/fb_s6d1121.c   | 2 +-
 drivers/staging/fbtft/fb_ssd1289.c   | 2 +-
 drivers/staging/fbtft/fb_ssd1331.c   | 4 ++--
 drivers/staging/fbtft/fb_upd161704.c | 2 +-
 drivers/staging/fbtft/fbtft-bus.c| 2 +-
 drivers/staging/fbtft/fbtft-core.c   | 4 ++--
 9 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/fbtft/fb_bd663474.c 
b/drivers/staging/fbtft/fb_bd663474.c
index b6c6d66e4eb1..e2c7646588f8 100644
--- a/drivers/staging/fbtft/fb_bd663474.c
+++ b/drivers/staging/fbtft/fb_bd663474.c
@@ -24,7 +24,7 @@
 
 static int init_display(struct fbtft_par *par)
 {
-   if (!par->gpio.cs)
+   if (par->gpio.cs)
gpiod_set_value(par->gpio.cs, 0);  /* Activate chip */
 
par->fbtftops.reset(par);
diff --git a/drivers/staging/fbtft/fb_ili9163.c 
b/drivers/staging/fbtft/fb_ili9163.c
index d609a2b67db9..fd32376700e2 100644
--- a/drivers/staging/fbtft/fb_ili9163.c
+++ b/drivers/staging/fbtft/fb_ili9163.c
@@ -77,7 +77,7 @@ static int init_display(struct fbtft_par *par)
 {
par->fbtftops.reset(par);
 
-   if (!par->gpio.cs)
+   if (par->gpio.cs)
gpiod_set_value(par->gpio.cs, 0);  /* Activate chip */
 
write_reg(par, MIPI_DCS_SOFT_RESET); /* software reset */
diff --git a/drivers/staging/fbtft/fb_ili9325.c 
b/drivers/staging/fbtft/fb_ili9325.c
index b090e7ab6fdd..85e54a10ed72 100644
--- a/drivers/staging/fbtft/fb_ili9325.c
+++ b/drivers/staging/fbtft/fb_ili9325.c
@@ -85,7 +85,7 @@ static int init_display(struct fbtft_par *par)
 {
par->fbtftops.reset(par);
 
-   if (!par->gpio.cs)
+   if (par->gpio.cs)
gpiod_set_value(par->gpio.cs, 0);  /* Activate chip */
 
bt &= 0x07;
diff --git a/drivers/staging/fbtft/fb_s6d1121.c 
b/drivers/staging/fbtft/fb_s6d1121.c
index b3d0701880fe..5a129b1352cc 100644
--- a/drivers/staging/fbtft/fb_s6d1121.c
+++ b/drivers/staging/fbtft/fb_s6d1121.c
@@ -29,7 +29,7 @@ static int init_display(struct fbtft_par *par)
 {
par->fbtftops.reset(par);
 
-   if (!par->gpio.cs)
+   if (par->gpio.cs)
gpiod_set_value(par->gpio.cs, 0);  /* Activate chip */
 
/* Initialization sequence from Lib_UTFT */
diff --git a/drivers/staging/fbtft/fb_ssd1289.c 
b/drivers/staging/fbtft/fb_ssd1289.c
index bbf75f795234..88a5b6925901 100644
--- a/drivers/staging/fbtft/fb_ssd1289.c
+++ b/drivers/staging/fbtft/fb_ssd1289.c
@@ -28,7 +28,7 @@ static int init_display(struct fbtft_par *par)
 {
par->fbtftops.reset(par);
 
-   if (!par->gpio.cs)
+   if (par->gpio.cs)
gpiod_set_value(par->gpio.cs, 0);  /* Activate chip */
 
write_reg(par, 0x00, 0x0001);
diff --git a/drivers/staging/fbtft/fb_ssd1331.c 
b/drivers/staging/fbtft/fb_ssd1331.c
index 4cfe9f8535d0..37622c9462aa 100644
--- a/drivers/staging/fbtft/fb_ssd1331.c
+++ b/drivers/staging/fbtft/fb_ssd1331.c
@@ -81,7 +81,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
va_start(args, len);
 
*buf = (u8)va_arg(args, unsigned int);
-   if (!par->gpio.dc)
+   if (par->gpio.dc)
gpiod_set_value(par->gpio.dc, 0);
ret = par->fbtftops.write(par, par->buf, sizeof(u8));
if (ret < 0) {
@@ -104,7 +104,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
return;
}
}
-   if (!par->gpio.dc)
+   if (par->gpio.dc)
gpiod_set_value(par->gpio.dc, 1);
va_end(args);
 }
diff --git a/drivers/staging/fbtft/fb_upd161704.c 
b/drivers/staging/fbtft/fb_upd161704.c
index 564a38e34440..c77832ae5e5b 100644
--- a/drivers/staging/fbtft/fb_upd161704.c
+++ b/drivers/staging/fbtft/fb_upd161704.c
@@ -26,7 +26,7 @@ static int init_display(struct fbtft_par *par)
 {
par->fbtftops.reset(par);
 
-   if (!par->gpio.cs)
+   if (par->gpio.cs)
gpiod_set_value(par->gpio.cs, 0);  /* Activate chip */
 
/* Initialization sequence from Lib_UTFT */
diff --git a/drivers/staging/fbtft/fbtft-bus.c 
b/drivers/staging/fbtft/fbtft-bus.c
index 2ea814d0dca5..63c65dd67b17 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -135,7 +135,7 @@ int fbtft_write_vmem16_bus8(struct fbtft_par *par, size_t 
offset, size_t len)
remain = len / 2;

[driver-core:debugfs_cleanup 22/55] sound//soc/soc-core.c:231:2: note: in expansion of macro 'if'

2019-07-17 Thread kbuild test robot
tree:   
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/driver-core.git 
debugfs_cleanup
head:   e1b58c1031e00b7530c136d770b15fff28fe127e
commit: 404c2a99031c0ce08425dbec2e556c6a02861bbd [22/55] sound: soc: core: no 
need to check return value of debugfs_create functions
config: x86_64-randconfig-c001-201928 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
git checkout 404c2a99031c0ce08425dbec2e556c6a02861bbd
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All warnings (new ones prefixed by >>):

   sound//soc/soc-core.c: In function 'soc_init_card_debugfs':
   sound//soc/soc-core.c:228:8: error: 'struct snd_soc_card' has no member 
named 'debugfs_pop_time'; did you mean 'debugfs_card_root'?
 card->debugfs_pop_time = debugfs_create_u32("dapm_pop_time", 0644,
   ^~~~
   debugfs_card_root
   In file included from include/linux/export.h:45:0,
from include/linux/linkage.h:7,
from include/linux/kernel.h:8,
from include/linux/list.h:9,
from include/linux/module.h:9,
from sound//soc/soc-core.c:20:
   sound//soc/soc-core.c:231:19: error: 'struct snd_soc_card' has no member 
named 'debugfs_pop_time'; did you mean 'debugfs_card_root'?
 if (IS_ERR(card->debugfs_pop_time))
  ^
   include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
#define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
   ^~~~
>> sound//soc/soc-core.c:231:2: note: in expansion of macro 'if'
 if (IS_ERR(card->debugfs_pop_time))
 ^~
   sound//soc/soc-core.c:231:19: error: 'struct snd_soc_card' has no member 
named 'debugfs_pop_time'; did you mean 'debugfs_card_root'?
 if (IS_ERR(card->debugfs_pop_time))
  ^
   include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var'
#define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
^~~~
>> sound//soc/soc-core.c:231:2: note: in expansion of macro 'if'
 if (IS_ERR(card->debugfs_pop_time))
 ^~
   sound//soc/soc-core.c:231:19: error: 'struct snd_soc_card' has no member 
named 'debugfs_pop_time'; did you mean 'debugfs_card_root'?
 if (IS_ERR(card->debugfs_pop_time))
  ^
   include/linux/compiler.h:69:3: note: in definition of macro 
'__trace_if_value'
 (cond) ? \
  ^~~~
   include/linux/compiler.h:56:28: note: in expansion of macro '__trace_if_var'
#define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
   ^~
>> sound//soc/soc-core.c:231:2: note: in expansion of macro 'if'
 if (IS_ERR(card->debugfs_pop_time))
 ^~
   In file included from include/linux/platform_device.h:13:0,
from sound//soc/soc-core.c:27:
   sound//soc/soc-core.c:234:19: error: 'struct snd_soc_card' has no member 
named 'debugfs_pop_time'; did you mean 'debugfs_card_root'?
PTR_ERR(card->debugfs_pop_time));
  ^
   include/linux/device.h:1495:33: note: in definition of macro 'dev_warn'
 _dev_warn(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~

vim +/if +231 sound//soc/soc-core.c

db795f9b Kuninori Morimoto 2018-05-08  215  
a6052154 Jarkko Nikula 2010-11-05  216  static void 
soc_init_card_debugfs(struct snd_soc_card *card)
a6052154 Jarkko Nikula 2010-11-05  217  {
a6052154 Jarkko Nikula 2010-11-05  218  card->debugfs_card_root = 
debugfs_create_dir(card->name,
8a9dab1a Mark Brown2011-01-10  219  
 snd_soc_debugfs_root);
c2c928c9 Mark Brown2019-06-21  220  if 
(IS_ERR(card->debugfs_card_root)) {
a6052154 Jarkko Nikula 2010-11-05  221  dev_warn(card->dev,
c2c928c9 Mark Brown2019-06-21  222   "ASoC: Failed 
to create card debugfs directory: %ld\n",
c2c928c9 Mark Brown2019-06-21  223   
PTR_ERR(card->debugfs_card_root));
c2c928c9 Mark Brown2019-06-21  224  card->debugfs_card_root 
= NULL;
3a45b867 Jarkko Nikula 2010-11-05  225  return;
3a45b867 Jarkko Nikula 2010-11-05  226  }
3a45b867 Jarkko Nikula 2010-11-05  227  
3a45b867 Jarkko Nikula 2010-11-05  228  card->debugfs_pop_time = 
debugfs_create_u32("dapm_pop_time", 0644,
3a45b867 Jarkko Nikula 2010-11-05  229  
card->debugfs_card_root,
3a45b867 Jarkko Nikula 2010-11-05  230  
>pop_time);
c2c928c9 Mark Brown   

[PATCH] staging: rtl8192e: remove set but not used variable 'payload '

2019-07-17 Thread YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:

drivers/staging/rtl8192e/rtllib_rx.c: In function rtllib_rx_InfraAdhoc:
drivers/staging/rtl8192e/rtllib_rx.c:1303:6: warning:
 variable payload set but not used [-Wunused-but-set-variable]

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
---
 drivers/staging/rtl8192e/rtllib_rx.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_rx.c 
b/drivers/staging/rtl8192e/rtllib_rx.c
index 0c19ac2..0bae0a0 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -1300,7 +1300,6 @@ static int rtllib_rx_InfraAdhoc(struct rtllib_device 
*ieee, struct sk_buff *skb,
struct rx_ts_record *pTS = NULL;
u16 fc, sc, SeqNum = 0;
u8 type, stype, multicast = 0, unicast = 0, nr_subframes = 0, TID = 0;
-   u8 *payload;
u8 dst[ETH_ALEN];
u8 src[ETH_ALEN];
u8 bssid[ETH_ALEN] = {0};
@@ -1412,7 +1411,6 @@ static int rtllib_rx_InfraAdhoc(struct rtllib_device 
*ieee, struct sk_buff *skb,
 
/* Parse rx data frame (For AMSDU) */
/* skb: hdr + (possible reassembled) full plaintext payload */
-   payload = skb->data + hdrlen;
rxb = kmalloc(sizeof(struct rtllib_rxb), GFP_ATOMIC);
if (!rxb)
goto rx_dropped;
-- 
2.7.4


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


[PATCH] staging: rtl8723bs: remove set but not used variable 'cck_highpwr'

2019-07-17 Thread YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:

drivers/staging/rtl8723bs/hal/odm_HWConfig.c:
 In function odm_RxPhyStatus92CSeries_Parsing:
drivers/staging/rtl8723bs/hal/odm_HWConfig.c:92:5: warning:
 variable cck_highpwr set but not used [-Wunused-but-set-variable]

It is never used and can be removed.

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
---
 drivers/staging/rtl8723bs/hal/odm_HWConfig.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/odm_HWConfig.c 
b/drivers/staging/rtl8723bs/hal/odm_HWConfig.c
index 49fa81406..71919a3 100644
--- a/drivers/staging/rtl8723bs/hal/odm_HWConfig.c
+++ b/drivers/staging/rtl8723bs/hal/odm_HWConfig.c
@@ -89,7 +89,6 @@ static void odm_RxPhyStatus92CSeries_Parsing(
u8 RSSI, total_rssi = 0;
bool isCCKrate = false;
u8 rf_rx_num = 0;
-   u8 cck_highpwr = 0;
u8 LNA_idx, VGA_idx;
PPHY_STATUS_RPT_8192CD_T pPhyStaRpt = 
(PPHY_STATUS_RPT_8192CD_T)pPhyStatus;
 
@@ -107,16 +106,10 @@ static void odm_RxPhyStatus92CSeries_Parsing(
/*  (2)PWDB, Average PWDB cacluated by hardware (for rate 
adaptive) */
/*  */
 
-   /* if (pHalData->eRFPowerState == eRfOn) */
-   cck_highpwr = pDM_Odm->bCckHighPower;
-   /* else */
-   /* cck_highpwr = false; */
-
cck_agc_rpt =  pPhyStaRpt->cck_agc_rpt_ofdm_cfosho_a ;
 
/* 2011.11.28 LukeLee: 88E use different LNA & VGA gain table */
/* The RSSI formula should be modified according to the gain 
table */
-   /* In 88E, cck_highpwr is always set to 1 */
LNA_idx = ((cck_agc_rpt & 0xE0)>>5);
VGA_idx = (cck_agc_rpt & 0x1F);
rx_pwr_all = odm_CCKRSSI_8723B(LNA_idx, VGA_idx);
-- 
2.7.4


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


[PATCH] staging: media: sunxi: Add bool cast to value

2019-07-17 Thread Nishka Dasgupta
Typecast as bool the return value of cedrus_find_format in
cedrus_check_format as the return value of cedrus_check_format is always
treated like a boolean value.

Signed-off-by: Nishka Dasgupta 
---
 drivers/staging/media/sunxi/cedrus/cedrus_video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index e2b530b1a956..f00a048a0a01 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -86,7 +86,7 @@ static struct cedrus_format *cedrus_find_format(u32 
pixelformat, u32 directions,
 static bool cedrus_check_format(u32 pixelformat, u32 directions,
unsigned int capabilities)
 {
-   return cedrus_find_format(pixelformat, directions, capabilities);
+   return (bool)cedrus_find_format(pixelformat, directions, capabilities);
 }
 
 static void cedrus_prepare_format(struct v4l2_pix_format *pix_fmt)
-- 
2.19.1

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


Re: [PATCH 2/2] staging: media: sunxi: Replace function cedrus_check_format()

2019-07-17 Thread Paul Kocialkowski
Hi,

On Fri 05 Jul 19, 17:43, Nishka Dasgupta wrote:
> On 05/07/19 3:56 PM, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Wed 03 Jul 19, 13:43, Nishka Dasgupta wrote:
> > > Remove function cedrus_check_format as all it does is call
> > > cedrus_find_format.
> > > Rename cedrus_find_format to cedrus_check_format to maintain
> > > compatibility with call sites.
> > > Issue found with Coccinelle.
> > 
> > Maybe we could have a !! or a bool cast to make coccinelle happy here?
> 
> Coccinelle didn't flag the type mismatch, just the single-line functions. I
> could add the bool cast then?

Looks like I failed to follow-up on this in due time, sorry.

Yes a bool cast would definitely be welcome :)

Cheers,

Paul

> Thanking you,
> Nishka
> 
> > Cheers,
> > 
> > Paul
> > 
> > > Signed-off-by: Nishka Dasgupta 
> > > ---
> > >   drivers/staging/media/sunxi/cedrus/cedrus_video.c | 10 ++
> > >   1 file changed, 2 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c 
> > > b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > index 0ec31b9e0aea..d5cc9ed04fd2 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > @@ -55,8 +55,8 @@ static inline struct cedrus_ctx *cedrus_file2ctx(struct 
> > > file *file)
> > >   return container_of(file->private_data, struct cedrus_ctx, fh);
> > >   }
> > > -static bool cedrus_find_format(u32 pixelformat, u32 directions,
> > > -unsigned int capabilities)
> > > +static bool cedrus_check_format(u32 pixelformat, u32 directions,
> > > + unsigned int capabilities)
> > >   {
> > >   struct cedrus_format *fmt;
> > >   unsigned int i;
> > > @@ -76,12 +76,6 @@ static bool cedrus_find_format(u32 pixelformat, u32 
> > > directions,
> > >   return false;
> > >   }
> > > -static bool cedrus_check_format(u32 pixelformat, u32 directions,
> > > - unsigned int capabilities)
> > > -{
> > > - return cedrus_find_format(pixelformat, directions, capabilities);
> > > -}
> > > -
> > >   static void cedrus_prepare_format(struct v4l2_pix_format *pix_fmt)
> > >   {
> > >   unsigned int width = pix_fmt->width;
> > > -- 
> > > 2.19.1
> > > 
> > 
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 1/2] staging: rts5208: Rewrite redundant if statement to improve code style

2019-07-17 Thread Dan Carpenter
On Sun, Jun 30, 2019 at 04:12:44PM +0200, Tobias Nießen wrote:
> Am 26.06.2019 um 16:56 schrieb Dan Carpenter:
> > Both these patches seem fine.
> > 
> > On Wed, Jun 26, 2019 at 04:28:56PM +0200, Tobias Nießen wrote:
> >> This commit uses the fact that
> >>
> >> if (a) {
> >> if (b) {
> >> ...
> >> }
> >> }
> >>
> >> can instead be written as
> >>
> >> if (a && b) {
> >> ...
> >> }
> >>
> >> without any change in behavior, allowing to decrease the indentation
> >> of the contained code block and thus reducing the average line length.
> >>
> >> Signed-off-by: Tobias Nießen 
> >> Signed-off-by: Sabrina Gaube 
> > 
> > Signed-off-by is like signing a legal document that you didn't put any
> > of SCO's secret UNIXWARE source code into your patch or do other illegal
> > activities.  Everyone who handles a patch is supposed to Sign it.
> > 
> > It's weird to see Sabrina randomly signing your patches.  Probably there
> > is a more appropriate kind of tag to use as well or instead such as
> > Co-Developed-by, Reviewed-by or Suggested-by.
> > 
> > regards,
> > dan carpenter
> > 
> 
> Thank you, Dan. This patch series is a mandatory part of a course
> Sabrina and I are taking at university. We were told to add
> Signed-off-by for both of us. I can add Co-Developed-by if that helps?

Yes.  It does help.

regards,
dan carpenter

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