Re: [PATCH 09/11] staging: speakup: Simplify the NULL comparisons

2017-03-23 Thread Greg KH
On Tue, Mar 21, 2017 at 05:12:33PM +0530, Arushi Singhal wrote:
> 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/fakekey.c |  2 +-
>  drivers/staging/speakup/main.c| 32 
>  2 files changed, 17 insertions(+), 17 deletions(-)

You used this same subject line in this series, not good :(

greg k-h


Re: [PATCH 05/11] staging: speakup: Remove multiple assignments

2017-03-23 Thread Greg KH
On Tue, Mar 21, 2017 at 05:12:29PM +0530, Arushi Singhal wrote:
> 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;

Also harder to read now :(



Re: [PATCH 02/11] staging: speakup: Remove multiple assignments

2017-03-23 Thread Greg KH
On Tue, Mar 21, 2017 at 05:12:26PM +0530, Arushi Singhal wrote:
> 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;

Ick, this is harder to read now, don't you think?

not good.

greg k-h


Re: kvm: use-after-free function call in kvm_io_bus_destroy

2017-03-23 Thread David Hildenbrand
On 23.03.2017 13:33, Dmitry Vyukov wrote:
> Hello,
> 
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure, most likely it's the root cause.
> 
> 
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 0 PID: 14650 Comm: syz-executor2 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  __do_kmalloc mm/slab.c:3734 [inline]
>  __kmalloc+0x220/0x730 mm/slab.c:3745
>  kmalloc include/linux/slab.h:495 [inline]
>  kvm_io_bus_unregister_dev+0x1a2/0x300
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:3594
>  kvm_free_pit+0x58/0x110 arch/x86/kvm/i8254.c:727
>  kvm_arch_sync_events+0x35/0x40 arch/x86/kvm/x86.c:8078
>  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:727 [inline]
>  kvm_put_kvm+0x27f/0xa70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:761
>  kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:772
>  __fput+0x327/0x7f0 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:245
>  task_work_run+0x1a4/0x270 kernel/task_work.c:116
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
>  prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
>  syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
>  entry_SYSCALL_64_fastpath+0xc0/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f6e094bc858 EFLAGS: 0292 ORIG_RAX: 0021
> RAX: 001c RBX: 00708000 RCX: 00445b79
> RDX:  RSI: 001c RDI: 001b
> RBP: 0430 R08:  R09: 
> R10:  R11: 0292 R12: 006de4f0
> R13: 001c R14:  R15: 001b
> ==
> BUG: KASAN: use-after-free in kvm_io_bus_destroy
> include/kvm/iodev.h:72 [inline] at addr 88003bfb7d40
> BUG: KASAN: use-after-free in kvm_destroy_vm
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:733 [inline] at addr
> 88003bfb7d40
> BUG: KASAN: use-after-free in kvm_put_kvm+0x932/0xa70
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:761 at addr 88003bfb7d40
> Read of size 8 by task syz-executor2/14650
> CPU: 0 PID: 14650 Comm: syz-executor2 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:166
>  print_address_description mm/kasan/report.c:210 [inline]
>  kasan_report_error mm/kasan/report.c:294 [inline]
>  kasan_report.part.2+0x1be/0x480 mm/kasan/report.c:316
>  kasan_report mm/kasan/report.c:337 [inline]
>  __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:337
>  kvm_io_bus_destroy include/kvm/iodev.h:72 [inline]
>  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:733 [inline]
>  kvm_put_kvm+0x932/0xa70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:761
>  kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:772
>  __fput+0x327/0x7f0 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:245
>  task_work_run+0x1a4/0x270 kernel/task_work.c:116
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
>  prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
>  syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
>  entry_SYSCALL_64_fastpath+0xc0/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f6e094bc858 EFLAGS: 0292 ORIG_RAX: 0021
> RAX: 001c RBX: 00708000 RCX: 00445b79
> RDX:  RSI: 001c RDI: 001b
> RBP: 0430 R08:  R09: 
> R10:  R11: 0292 R12: 006de4f0
> R13: 001c R14:  R15: 001b
> Object at 88003bfb7d40, in cache kmalloc-512 size: 512
> Allocated:
> PID = 14650
>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:517
>  set_track mm/kasan/kasan.c:529 [inline]
>  kasan_kmalloc+0xbc/0xf0 mm/kasan/kasan.c:620
>  kmem_cache_alloc_trace+0x11a/0x720 mm/slab.c:3638
>  kmalloc include/linux/slab.h:490 [inline]
>  kzalloc include/linux/slab.h:663 [inline]
>  kvm_create_pit+0xc2/0x8b0 arch/x86/kvm/i8254.c:656
>  kvm_arch_vm_ioctl+0x1339/0x2190 arch/x86/kvm/x86.c:405

Re: [PATCH staging/speakup v3 3/3] use speakup_allocate as per required context

2017-03-23 Thread Greg KH
On Tue, Mar 21, 2017 at 12:40:24PM +0530, Pranay Kr. Srivastava wrote:
> speakup_allocate used GFP_ATOMIC for allocations
> even while during initialization due to it's use
> in notifier call.
> 
> Pass GFP_ flags as well to speakup_allocate depending
> on the context it is called in.
> 
> Signed-off-by: Pranay Kr. Srivastava 
> ---
>  drivers/staging/speakup/main.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

This patch didn't apply to my staging-testing branch, but the 2 others
did, odd.  Can you rebase it and resend?

thanks,

greg k-h


Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen

2017-03-23 Thread Stanislaw Gruszka
On Wed, Mar 22, 2017 at 10:56:02AM -0700, Ankur Arora wrote:
> >It is ok to do upload_pm_data() with delay i.e. after some other
> >resume actions are done and possibly xen-acpi-processor is in
> >running state ?
> The state uploaded is ACPI P and C state from struct acpi_processor
> which AFAICS is stable once inited so a delay would not lead to
> invalid state.
> The only concern would be the ACPI pCPU hotplug logic in
> acpi_processor_add() which could add a new entry in
> per_cpu(processors) but that also looks okay because either we
> get a NULL or we get a pointer to an inited structure.
> 
> As for the hypervisor -- that falls back to more limited state after
> resume (because some of this state is thrown away at suspend) and so
> uses that until it gets the uploaded PM state from the initial-domain.

Patch looks good to me then.

Reviewed-by: Stanislaw Gruszka 


[PATCH] microblaze: use sg_phys()

2017-03-23 Thread Geliang Tang
Use sg_phys() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 arch/microblaze/kernel/dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
index 12e093a..e45ada8 100644
--- a/arch/microblaze/kernel/dma.c
+++ b/arch/microblaze/kernel/dma.c
@@ -65,8 +65,7 @@ static int dma_direct_map_sg(struct device *dev, struct 
scatterlist *sgl,
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
continue;
 
-   __dma_sync(page_to_phys(sg_page(sg)) + sg->offset,
-   sg->length, direction);
+   __dma_sync(sg_phys(sg), sg->length, direction);
}
 
return nents;
-- 
2.9.3



[PATCH] qla2xxx: use sg_virt()

2017-03-23 Thread Geliang Tang
Use sg_virt() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/scsi/qla2xxx/qla_isr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 3203367..9610d85 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -1991,7 +1991,7 @@ qla2x00_handle_dif_error(srb_t *sp, struct sts_entry_24xx 
*sts24)
return 1;
}
 
-   spt = page_address(sg_page(sg)) + sg->offset;
+   spt = sg_virt(sg);
spt += j;
 
spt->app_tag = 0x;
-- 
2.9.3



[PATCH] iommu: use sg_phys()

2017-03-23 Thread Geliang Tang
Use sg_phys() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/iommu/intel-iommu.c | 2 +-
 drivers/iommu/iommu.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index d412a31..9d09a9e 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3892,7 +3892,7 @@ static int intel_nontranslate_map_sg(struct device *hddev,
 
for_each_sg(sglist, sg, nelems, i) {
BUG_ON(!sg_page(sg));
-   sg->dma_address = page_to_phys(sg_page(sg)) + sg->offset;
+   sg->dma_address = sg_phys(sg);
sg->dma_length = sg->length;
}
return nelems;
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 3b67144..26f57b3 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1603,7 +1603,7 @@ size_t default_iommu_map_sg(struct iommu_domain *domain, 
unsigned long iova,
min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
 
for_each_sg(sg, s, nents, i) {
-   phys_addr_t phys = page_to_phys(sg_page(s)) + s->offset;
+   phys_addr_t phys = sg_phys(s);
 
/*
 * We are mapping on IOMMU page boundaries, so offset within
-- 
2.9.3



[PATCH] crypto: ixp4xx - Use sg_virt()

2017-03-23 Thread Geliang Tang
Use sg_virt() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/crypto/ixp4xx_crypto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 7868765..771dd26 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -806,7 +806,7 @@ static struct buffer_desc *chainup_buffers(struct device 
*dev,
void *ptr;
 
nbytes -= len;
-   ptr = page_address(sg_page(sg)) + sg->offset;
+   ptr = sg_virt(sg);
next_buf = dma_pool_alloc(buffer_pool, flags, &next_buf_phys);
if (!next_buf) {
buf = NULL;
-- 
2.9.3



[PATCH] isdn: use setup_timer

2017-03-23 Thread Geliang Tang
Use setup_timer() instead of init_timer() to simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/isdn/divert/isdn_divert.c   |  9 +++--
 drivers/isdn/hardware/eicon/divasi.c|  5 ++---
 drivers/isdn/hardware/mISDN/hfcmulti.c  | 10 --
 drivers/isdn/hardware/mISDN/hfcpci.c|  9 +++--
 drivers/isdn/hardware/mISDN/mISDNipac.c |  5 ++---
 drivers/isdn/hardware/mISDN/mISDNisar.c | 10 --
 drivers/isdn/hardware/mISDN/w6692.c |  5 ++---
 drivers/isdn/hisax/amd7930_fn.c |  4 +---
 drivers/isdn/hisax/arcofi.c |  4 +---
 drivers/isdn/hisax/diva.c   |  5 ++---
 drivers/isdn/hisax/elsa.c   |  4 +---
 drivers/isdn/hisax/fsm.c|  4 +---
 drivers/isdn/hisax/hfc4s8s_l1.c |  5 ++---
 drivers/isdn/hisax/hfc_2bds0.c  |  4 +---
 drivers/isdn/hisax/hfc_pci.c|  8 ++--
 drivers/isdn/hisax/hfc_sx.c |  8 ++--
 drivers/isdn/hisax/hfc_usb.c|  8 ++--
 drivers/isdn/hisax/hfcscard.c   |  4 +---
 drivers/isdn/hisax/icc.c|  4 +---
 drivers/isdn/hisax/ipacx.c  |  4 +---
 drivers/isdn/hisax/isac.c   |  4 +---
 drivers/isdn/hisax/isar.c   | 10 --
 drivers/isdn/hisax/isdnl3.c |  4 +---
 drivers/isdn/hisax/teleint.c|  4 +---
 drivers/isdn/hisax/w6692.c  |  5 ++---
 drivers/isdn/i4l/isdn_ppp.c |  5 ++---
 drivers/isdn/i4l/isdn_tty.c |  5 ++---
 drivers/isdn/mISDN/dsp_core.c   |  4 +---
 drivers/isdn/mISDN/fsm.c|  4 +---
 drivers/isdn/mISDN/l1oip_core.c |  4 +---
 30 files changed, 54 insertions(+), 114 deletions(-)

diff --git a/drivers/isdn/divert/isdn_divert.c 
b/drivers/isdn/divert/isdn_divert.c
index 50749a7..060d357 100644
--- a/drivers/isdn/divert/isdn_divert.c
+++ b/drivers/isdn/divert/isdn_divert.c
@@ -157,10 +157,8 @@ int cf_command(int drvid, int mode,
/* allocate mem for information struct */
if (!(cs = kmalloc(sizeof(struct call_struc), GFP_ATOMIC)))
return (-ENOMEM); /* no memory */
-   init_timer(&cs->timer);
+   setup_timer(&cs->timer, deflect_timer_expire, (ulong)cs);
cs->info[0] = '\0';
-   cs->timer.function = deflect_timer_expire;
-   cs->timer.data = (ulong) cs; /* pointer to own structure */
cs->ics.driver = drvid;
cs->ics.command = ISDN_CMD_PROT_IO; /* protocol specific io */
cs->ics.arg = DSS1_CMD_INVOKE; /* invoke supplementary service */
@@ -452,10 +450,9 @@ static int isdn_divert_icall(isdn_ctrl *ic)
return (0); /* no external deflection 
needed */
if (!(cs = kmalloc(sizeof(struct call_struc), 
GFP_ATOMIC)))
return (0); /* no memory */
-   init_timer(&cs->timer);
+   setup_timer(&cs->timer, deflect_timer_expire,
+   (ulong)cs);
cs->info[0] = '\0';
-   cs->timer.function = deflect_timer_expire;
-   cs->timer.data = (ulong) cs; /* pointer to own 
structure */
 
cs->ics = *ic; /* copy incoming data */
if (!cs->ics.parm.setup.phone[0]) 
strcpy(cs->ics.parm.setup.phone, "0");
diff --git a/drivers/isdn/hardware/eicon/divasi.c 
b/drivers/isdn/hardware/eicon/divasi.c
index cb88090..c610495 100644
--- a/drivers/isdn/hardware/eicon/divasi.c
+++ b/drivers/isdn/hardware/eicon/divasi.c
@@ -300,9 +300,8 @@ static int um_idi_open_adapter(struct file *file, int 
adapter_nr)
p_os = (diva_um_idi_os_context_t *) diva_um_id_get_os_context(e);
init_waitqueue_head(&p_os->read_wait);
init_waitqueue_head(&p_os->close_wait);
-   init_timer(&p_os->diva_timer_id);
-   p_os->diva_timer_id.function = (void *) diva_um_timer_function;
-   p_os->diva_timer_id.data = (unsigned long) p_os;
+   setup_timer(&p_os->diva_timer_id, (void *)diva_um_timer_function,
+   (unsigned long)p_os);
p_os->aborted = 0;
p_os->adapter_nr = adapter_nr;
return (1);
diff --git a/drivers/isdn/hardware/mISDN/hfcmulti.c 
b/drivers/isdn/hardware/mISDN/hfcmulti.c
index 480c2d7..961c07e 100644
--- a/drivers/isdn/hardware/mISDN/hfcmulti.c
+++ b/drivers/isdn/hardware/mISDN/hfcmulti.c
@@ -3878,9 +3878,8 @@ hfcmulti_initmode(struct dchannel *dch)
if (hc->dnum[pt]) {
mode_hfcmulti(hc, dch->slot, dch->dev.D.protocol,
  -1, 0, -1, 0);
-   dch->timer.function = (void *) hfcmulti_dbusy_timer;
-   dch->timer.data = (long) dch;
-   init_timer(&dch->timer);
+   setup_timer(&dch->timer, (void *)hfcmulti_dbusy_timer,
+   (long)dch);
}
   

[PATCH] pstore: remove unused vmalloc.h in pmsg

2017-03-23 Thread Geliang Tang
Since the vmalloc code has been removed from write_pmsg() in the commit
"5bf6d1b pstore/pmsg: drop bounce buffer", remove the unused header
vmalloc.h.

Signed-off-by: Geliang Tang 
---
 fs/pstore/pmsg.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/pstore/pmsg.c b/fs/pstore/pmsg.c
index c16a247..209755e 100644
--- a/fs/pstore/pmsg.c
+++ b/fs/pstore/pmsg.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "internal.h"
 
 static DEFINE_MUTEX(pmsg_lock);
-- 
2.9.3



Re: [PATCH v1] mfd: core: Preserve PLATFORM_DEVID_NONE

2017-03-23 Thread Andy Shevchenko
On Thu, 2017-03-23 at 11:21 +, Lee Jones wrote:
> On Thu, 16 Mar 2017, Andy Shevchenko wrote:
> 
> > There is a potential flaw if cell has id > 0 and is going to be
> > registered with PLATFORM_DEVID_NONE.
> > 
> > Ignore if PLATFORM_DEVID_NONE is supplied.
> 
> This is a substantial change to a pretty tried and tested piece of
> sub-system code.  Can you put some more meat on the bones in the
> commit log, and include examples.

Example in pseudo code:

cells = {
 [0] = { .id = 0, .name = "moduleX", },
 [1] = { .id = 1, .name = "moduleY", },
 [2] = { .id = 2, .name = "moduleZ", },
 ...
};

mfd_add_devices(..., PLATFORM_DEVID_NONE, cells, ARRAY_SIZE(cells),
...);

Output (names of the devices in the drivers):
"moduleX"
"moduleY.0"
"moduleX.1"

Desired output:
"moduleX"
"moduleY"
"moduleZ"

Is it by design?

> 
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  drivers/mfd/mfd-core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> > index c57e407020f1..c9583f895058 100644
> > --- a/drivers/mfd/mfd-core.c
> > +++ b/drivers/mfd/mfd-core.c
> > @@ -149,7 +149,7 @@ static int mfd_add_device(struct device *parent,
> > int id,
> >     int platform_id;
> >     int r;
> >  
> > -   if (id == PLATFORM_DEVID_AUTO)
> > +   if (id < 0)
> >     platform_id = id;
> >     else
> >     platform_id = id + cell->id;
> 
> 

-- 
Andy Shevchenko 
Intel Finland Oy


[PATCH] staging: media: atomisp: use kvmalloc and kvfree

2017-03-23 Thread Geliang Tang
Use kvmalloc() and kvfree() instead of open-coding.

Signed-off-by: Geliang Tang 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 94bc793..c7b9320 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -90,10 +90,7 @@ union host {
 void *atomisp_kernel_malloc(size_t bytes)
 {
/* vmalloc() is preferable if allocating more than 1 page */
-   if (bytes > PAGE_SIZE)
-   return vmalloc(bytes);
-
-   return kmalloc(bytes, GFP_KERNEL);
+   return kvmalloc(bytes, GFP_KERNEL);
 }
 
 /*
@@ -118,10 +115,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool zero_mem)
 void atomisp_kernel_free(void *ptr)
 {
/* Verify if buffer was allocated by vmalloc() or kmalloc() */
-   if (is_vmalloc_addr(ptr))
-   vfree(ptr);
-   else
-   kfree(ptr);
+   kvfree(ptr);
 }
 
 /*
-- 
2.9.3



[PATCH] staging: media: atomisp: fix build error

2017-03-23 Thread Geliang Tang
Fix the following build error:

  CC  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2:
 error: excess elements in array initializer [-Werror]
  "i", /* ion */
  ^~~
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2:
 note: (near initialization for ‘hmm_bo_type_strings’)
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target
'drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o' failed

Signed-off-by: Geliang Tang 
---
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index a362b49..e78f02f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -49,7 +49,9 @@ const char *hmm_bo_type_strings[HMM_BO_LAST] = {
"p", /* private */
"s", /* shared */
"u", /* user */
+#ifdef CONFIG_ION
"i", /* ion */
+#endif
 };
 
 static ssize_t bo_show(struct device *dev, struct device_attribute *attr,
-- 
2.9.3



Re: [PATCH 1/5] w83627ehf: Use hwmon_device_register_with_info and sensor groups

2017-03-23 Thread Guenter Roeck

On 03/23/2017 06:05 AM, Peter Hüwe wrote:

This is of course v2 of the series
Forgot to add it to git-send-email, sorry.
Shall I resend with v2 in subject?



No, it's ok. At least you have a change log :-).

Thanks,
Guenter



Re: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

2017-03-23 Thread Ulf Hansson
On 23 March 2017 at 11:45, Bean Huo (beanhuo)  wrote:
> Hi,
>
>>On 19 March 2017 at 01:45, Bean Huo (beanhuo)  wrote:
>>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache
>>> when eMMC cache has already been off through user space tool, such as
>>> mmc-utils.
>>> The reason is that card->ext_csd.cache_ctrl isn't reset.
>>
>>First, why do you want to turn of the cache ctrl? Is the eMMC device having
>>issues with it? Then we should invent a card quirk instead.
>
>
> Why I turn off it? because I did power loss testing and validation, I should 
> switch it off and on.
> When I do some performance and power loss case validation on several Linux 
> release versions,
> I need to switch off or on cache through user space tool.
> I can't confirm every user that likes me, But I think at least it is not 
> reasonable to
> flush eMMC cache, when internal eMMC cache is off.

Ah, I see. Your use-case seems reasonable while validating robustness
of the eMMC!

>
>>Second, what errors do you encounter when the mmc core tries to flush the
>>cache when it has been turned off? Can you please elaborate on this?
>
>
> No error found, but firstly, please think about overhead introduced by 
> useless flush cache, Unless you
> Don't care this tiny time. second, under the condition of cache off, 
> additional flush cache request still has impact on
> Internal eMMC logic. I don't know What and how impact, but at least it is 
> really exist.

Got it!

However I still don't like the mmc ioctls API to compensate and deal
with all "crazy-ness" that user-space may cause. Cache-ctrl is only
one case out of many.

I see two viable options to solve your problem.
1) Extend mmc_test with a new test(s) for cache ctrl and perhaps
suspend/resume. Isn't this actually exactly what you want?
2) Extend debugfs to be able to turn cache ctrl on/off.

[...]

Kind regards
Uffe


Re: [PATCH v5 08/13] powerpc/perf: PMU functions for Core IMC and hotplugging

2017-03-23 Thread Gautham R Shenoy
Hi Maddy, Hemant, Anju,

On Thu, Mar 16, 2017 at 01:05:02PM +0530, Madhavan Srinivasan wrote:

[..snip..]

> +
> +static void core_imc_change_cpu_context(int old_cpu, int new_cpu)
> +{
> + if (!core_imc_pmu)
> + return;
> + perf_pmu_migrate_context(&core_imc_pmu->pmu, old_cpu, new_cpu);
> +}
> +
> +
> +static int ppc_core_imc_cpu_online(unsigned int cpu)
> +{
> + int ret;
> +
> + /* If a cpu for this core is already set, then, don't do anything */
> + ret = cpumask_any_and(&core_imc_cpumask,
> +  cpu_sibling_mask(cpu));
> + if (ret < nr_cpu_ids)
> + return 0;
> +
> + /* Else, set the cpu in the mask, and change the context */
> + cpumask_set_cpu(cpu, &core_imc_cpumask);
> + core_imc_change_cpu_context(-1, cpu);

So, in the core case, we are ok as long as any cpu in the core is
present in the imc_cpumask. It need not have to be the smallest online
cpu in the core.

Can the same logic be applied to the earlier nest case ?

We can have a single function for cpu_offline and cpu_online which
implements these checks and sets the cpu bit if required.

ppc_entity_imc_cpu_offline(unsigned int cpu, cpumask_t
   entity_imc_mask,
   entity_imc_change_cpu_context_fn)
{
.
.
.

}


static ppc_nest_imc_cpu_offline(unsigned int cpu)
{
return ppc_entity_imc_cpu_offline(cpu, nest_imc_mask,
  nest_imc_change_cpu_context);
}

And similar ones for core imc and thread imc.

Does this sound reasonable ?

> + return 0;
> +}
> +
> +static int ppc_core_imc_cpu_offline(unsigned int cpu)
> +{
> + int target;
> + unsigned int ncpu;
> +
> + /*
> +  * clear this cpu out of the mask, if not present in the mask,
> +  * don't bother doing anything.
> +  */
> + if (!cpumask_test_and_clear_cpu(cpu, &core_imc_cpumask))
> + return 0;
> +
> + /* Find any online cpu in that core except the current "cpu" */
> + ncpu = cpumask_any_but(cpu_sibling_mask(cpu), cpu);
> +
> + if (ncpu < nr_cpu_ids) {
> + target = ncpu;
> + cpumask_set_cpu(target, &core_imc_cpumask);
> + } else
> + target = -1;
> +
> + /* migrate the context */
> + core_imc_change_cpu_context(cpu, target);
> +
> + return 0;
> +}
> +

--
Thanks and Regards
gautham.



Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Dmitry Vyukov
On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure in inode_alloc_security, most likely it's the root
> cause.
>
>
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
>  kmem_cache_zalloc include/linux/slab.h:653 [inline]
>  inode_alloc_security security/selinux/hooks.c:221 [inline]
>  selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
>  security_inode_alloc+0x90/0xd0 security/security.c:387
>  inode_init_always+0x5af/0xc20 fs/inode.c:166
>  alloc_inode+0x82/0x180 fs/inode.c:214
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==
> BUG: KASAN: user-memory-access in atomic_inc
> include/asm-generic/atomic-instrumented.h:87 [inline] at addr
> 00131730bd7a
> BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
> kernel/locking/lockdep.c:3239 at addr 00131730bd7a
> Write of size 4 by task syz-executor6/14086
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  kasan_report_error mm/kasan/report.c:291 [inline]
>  kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
>  kasan_report+0x21/0x30 mm/kasan/report.c:303
>  check_memory_region_inline mm/kasan/kasan.c:326 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
>  kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
>  atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
>  __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
>  lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
>  __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
>  _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
>  mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
>  hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
>  alloc_inode+0x10d/0x180 fs/inode.c:216
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==


Similar on address 0x2d302e31312e35c7, looks like uninit.

==
BUG: KASAN: wild-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
2d302e31312e35c7
BUG: KASAN: wild-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 2d302e31312e35c7
Write of size 4 by task syz-executor1/9446
CPU: 1 PID: 9446 Comm: syz-executor1 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIO

security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Dmitry Vyukov
Hello,

I've got the following report while running syzkaller fuzzer on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure in inode_alloc_security, most likely it's the root
cause.


FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
 kmem_cache_zalloc include/linux/slab.h:653 [inline]
 inode_alloc_security security/selinux/hooks.c:221 [inline]
 selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
 security_inode_alloc+0x90/0xd0 security/security.c:387
 inode_init_always+0x5af/0xc20 fs/inode.c:166
 alloc_inode+0x82/0x180 fs/inode.c:214
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==
BUG: KASAN: user-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
00131730bd7a
BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 00131730bd7a
Write of size 4 by task syz-executor6/14086
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
 kasan_report+0x21/0x30 mm/kasan/report.c:303
 check_memory_region_inline mm/kasan/kasan.c:326 [inline]
 check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
 kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
 atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
 __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
 lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
 __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
 _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
 mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
 hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
 alloc_inode+0x10d/0x180 fs/inode.c:216
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==


[RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

2017-03-23 Thread Mason
I think this version is ready for review.
It has all the required bits and pieces.
I still have a few questions, embedded as comments in the code.
(Missing are ancillary changes to Kconfig, Makefile)
---
 drivers/pci/host/pcie-tango.c | 350 ++
 1 file changed, 350 insertions(+)
 create mode 100644 drivers/pci/host/pcie-tango.c

diff --git a/drivers/pci/host/pcie-tango.c b/drivers/pci/host/pcie-tango.c
new file mode 100644
index ..b2e6448aed2d
--- /dev/null
+++ b/drivers/pci/host/pcie-tango.c
@@ -0,0 +1,350 @@
+#include 
+#include 
+#include 
+#include 
+
+#define MSI_COUNT 32
+
+struct tango_pcie {
+   void __iomem *mux;
+   void __iomem *msi_status;
+   void __iomem *msi_mask;
+   phys_addr_t msi_doorbell;
+   struct mutex lock; /* lock for updating msi_mask */
+   struct irq_domain *irq_domain;
+   struct irq_domain *msi_domain;
+   int irq;
+};
+
+/*** MSI CONTROLLER SUPPORT ***/
+
+static void tango_msi_isr(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct tango_pcie *pcie;
+   unsigned long status, virq;
+   int pos;
+
+   chained_irq_enter(chip, desc);
+   pcie = irq_desc_get_handler_data(desc);
+
+   status = readl_relaxed(pcie->msi_status);
+   writel_relaxed(status, pcie->msi_status); /* clear IRQs */
+
+   for_each_set_bit(pos, &status, MSI_COUNT) {
+   virq = irq_find_mapping(pcie->irq_domain, pos);
+   if (virq)
+   generic_handle_irq(virq);
+   else
+   pr_err("Unhandled MSI: %d\n", pos);
+   }
+
+   chained_irq_exit(chip, desc);
+}
+
+static struct irq_chip tango_msi_irq_chip = {
+   .name = "MSI",
+   .irq_mask = pci_msi_mask_irq,
+   .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info msi_domain_info = {
+   .flags  = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS,
+   .chip   = &tango_msi_irq_chip,
+};
+
+static void tango_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+   struct tango_pcie *pcie = irq_data_get_irq_chip_data(data);
+
+   msg->address_lo = lower_32_bits(pcie->msi_doorbell);
+   msg->address_hi = upper_32_bits(pcie->msi_doorbell);
+   msg->data = data->hwirq;
+}
+
+static int tango_set_affinity(struct irq_data *irq_data,
+   const struct cpumask *mask, bool force)
+{
+return -EINVAL;
+}
+
+static struct irq_chip tango_msi_chip = {
+   .name   = "MSI",
+   .irq_compose_msi_msg= tango_compose_msi_msg,
+   .irq_set_affinity   = tango_set_affinity,
+};
+
+static int tango_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+   unsigned int nr_irqs, void *args)
+{
+   struct tango_pcie *pcie = domain->host_data;
+   int pos, err = 0;
+   u32 mask;
+
+   if (nr_irqs != 1) /* When does that happen? */
+   return -EINVAL;
+
+   mutex_lock(&pcie->lock);
+
+   mask = readl_relaxed(pcie->msi_mask);
+   pos = find_first_zero_bit(&mask, MSI_COUNT);
+   if (pos < MSI_COUNT)
+   writel(mask | BIT(pos), pcie->msi_mask);
+   else
+   err = -ENOSPC;
+
+   mutex_unlock(&pcie->lock);
+
+   irq_domain_set_info(domain, virq, pos, &tango_msi_chip,
+   domain->host_data, handle_simple_irq, NULL, NULL);
+
+   return err;
+}
+
+static void tango_irq_domain_free(struct irq_domain *domain,
+  unsigned int virq, unsigned int nr_irqs)
+{
+   struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+   struct tango_pcie *pcie = irq_data_get_irq_chip_data(d);
+   int pos = d->hwirq;
+   u32 mask;
+
+   mutex_lock(&pcie->lock);
+
+   mask = readl(pcie->msi_mask);
+   writel(mask & ~BIT(pos), pcie->msi_mask);
+
+   mutex_unlock(&pcie->lock);
+}
+
+static const struct irq_domain_ops msi_domain_ops = {
+   .alloc  = tango_irq_domain_alloc,
+   .free   = tango_irq_domain_free,
+};
+
+static int tango_msi_remove(struct platform_device *pdev)
+{
+   struct tango_pcie *msi = platform_get_drvdata(pdev);
+
+   irq_set_chained_handler(msi->irq, NULL);
+   irq_set_handler_data(msi->irq, NULL);
+   /* irq_set_chained_handler_and_data(msi->irq, NULL, NULL); instead? */
+
+   irq_domain_remove(msi->msi_domain);
+   irq_domain_remove(msi->irq_domain);
+
+   return 0;
+}
+
+static int tango_msi_probe(struct platform_device *pdev, struct tango_pcie 
*pcie)
+{
+   int virq;
+   struct fwnode_handle *fwnode = of_node_to_fwnode(pdev->dev.of_node);
+   struct irq_domain *msi_dom, *irq_dom;
+
+   mutex_init(&pcie->lock);
+   writel(0, pcie->msi_mask);
+
+   /* Why is fwnode for this call? */
+   irq_dom = irq_domain_add_linear(NULL, MSI_COUNT, &msi_domain_ops, pcie);
+   if (!irq_dom) {
+  

Re: [PATCH v2] kasan: report only the first error by default

2017-03-23 Thread Andrey Ryabinin


On 03/23/2017 03:41 PM, Mark Rutland wrote:
> On Thu, Mar 23, 2017 at 02:49:16PM +0300, Andrey Ryabinin wrote:
>> +kasan_multi_shot
>> +[KNL] Enforce KASAN (Kernel Address Sanitizer) to print
>> +report on every invalid memory access. Without this
>> +parameter KASAN will print report only for the first
>> +invalid access.
>> +
> 
> The option looks fine to me.
> 
>>  static int __init kmalloc_tests_init(void)
>>  {
>> +/* Rise reports limit high enough to see all the following bugs */
>> +atomic_add(100, &kasan_report_count);
> 
>> +
>> +/*
>> + * kasan is unreliable now, disable reports if
>> + * we are in single shot mode
>> + */
>> +atomic_sub(100, &kasan_report_count);
>>  return -EAGAIN;
>>  }
> 
> ... but these magic numbers look rather messy.
> 
> [...]
> 
>> +atomic_t kasan_report_count = ATOMIC_INIT(1);
>> +EXPORT_SYMBOL_GPL(kasan_report_count);
>> +
>> +static int __init kasan_set_multi_shot(char *str)
>> +{
>> +atomic_set(&kasan_report_count, 10);
>> +return 1;
>> +}
>> +__setup("kasan_multi_shot", kasan_set_multi_shot);
> 
> ... likewise.
> 
> Rather than trying to pick an arbitrarily large number, how about we use
> separate flags to determine whether we're in multi-shot mode, and
> whether a (oneshot) report has been made.
> 
> How about the below?
 
Yes, it deferentially looks better.
Can you send a patch with a changelog, or do you want me to care of it?

> Thanks,
> Mark.
> 

> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index f479365..f1c5892 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -13,6 +13,7 @@
>   *
>   */
>  
> +#include 
>  #include 

We also need  for __setup().

>  #include 
>  #include 
> @@ -293,6 +294,40 @@ static void kasan_report_error(struct kasan_access_info 
> *info)


Re: [PATCH 1/5] w83627ehf: Use hwmon_device_register_with_info and sensor groups

2017-03-23 Thread Peter Hüwe
This is of course v2 of the series
Forgot to add it to git-send-email, sorry.
Shall I resend with v2 in subject?

Peter


[PATCH 4/5] w83627ehf: Drop FSFE template and replace with SPDX License information

2017-03-23 Thread Peter Huewe
As indicated by checkpatch it makes sense to not use the FSFE Template
about GPLv2+

Signed-off-by: Peter Huewe 
---
 drivers/hwmon/w83627ehf.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index a6f56b12727b..c4b755cd506c 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -18,19 +18,8 @@
  *  This driver also supports the W83627EHG, which is the lead-free
  *  version of the W83627EHF.
  *
- *  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.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *  Released under the GPLv2 or later.
+ *  SPDX-License-Identifier: GPL-2.0+
  *
  *  Supports the following chips:
  *
-- 
2.10.2



[PATCH] x86/boot: Support uncompressed kernel

2017-03-23 Thread Chao Peng
Compressed kernel has its own drawback: uncompressing takes time. Even
though the time is short enough to ignore for most cases but for cases that
time is critical this is still a big number. In our on-going optimization
for kernel boot time, the measured overall kernel boot time is ~90ms while
the uncompressing takes ~50ms with gzip.

The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built binary
can have no uncompressing at all. The experiment shows:

kernel   kernel sizetime in decompress_kernel
compressed (gzip)3.3M   53ms
uncompressed 14M3ms

Signed-off-by: Chao Peng 
---
 arch/x86/boot/compressed/Makefile |  3 +++
 arch/x86/boot/compressed/misc.c   | 14 ++
 init/Kconfig  |  7 +++
 scripts/Makefile.lib  |  8 
 4 files changed, 32 insertions(+)

diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index f9ce75d..fc0e1c0 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -73,6 +73,8 @@ $(obj)/vmlinux.relocs: vmlinux FORCE
 vmlinux.bin.all-y := $(obj)/vmlinux.bin
 vmlinux.bin.all-$(CONFIG_X86_NEED_RELOCS) += $(obj)/vmlinux.relocs
 
+$(obj)/vmlinux.bin.raw: $(vmlinux.bin.all-y) FORCE
+   $(call if_changed,raw)
 $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,gzip)
 $(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
@@ -86,6 +88,7 @@ $(obj)/vmlinux.bin.lzo: $(vmlinux.bin.all-y) FORCE
 $(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lz4)
 
+suffix-$(CONFIG_KERNEL_RAW):= raw
 suffix-$(CONFIG_KERNEL_GZIP)   := gz
 suffix-$(CONFIG_KERNEL_BZIP2)  := bz2
 suffix-$(CONFIG_KERNEL_LZMA)   := lzma
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 79dac17..fb3cd43 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -123,6 +123,20 @@ static char *vidmem;
 static int vidport;
 static int lines, cols;
 
+#ifdef CONFIG_KERNEL_RAW
+#include 
+static int __decompress(unsigned char *buf, long len,
+   long (*fill)(void*, unsigned long),
+   long (*flush)(void*, unsigned long),
+   unsigned char *outbuf, long olen,
+   long *pos,
+   void (*error)(char *x))
+{
+   memcpy(outbuf, buf, olen);
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_KERNEL_GZIP
 #include "../../../../lib/decompress_inflate.c"
 #endif
diff --git a/init/Kconfig b/init/Kconfig
index 2232080..1db2ea2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -137,6 +137,13 @@ choice
 
  If in doubt, select 'gzip'
 
+config KERNEL_RAW
+   bool "RAW"
+   help
+ No compression. It creates much bigger kernel and uses much more
+ space (disk/memory) than other choices. It can be useful when
+ decompression speed is the most concern while space is not a problem.
+
 config KERNEL_GZIP
bool "Gzip"
depends on HAVE_KERNEL_GZIP
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 2edbcad..384128d 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -344,6 +344,14 @@ cmd_lz4 = (cat $(filter-out FORCE,$^) | \
lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out 
FORCE,$^))) > $@ || \
(rm -f $@ ; false)
 
+# RAW
+# ---
+quiet_cmd_raw = RAW $@
+cmd_raw = (cat $(filter-out FORCE,$^) && \
+   $(call size_append, $(filter-out FORCE,$^))) > $@ || \
+   (rm -f $@ ; false)
+
+
 # U-Boot mkimage
 # ---
 
-- 
1.8.3.1



[PATCH 2/5] w83627ehf: Use octal values for access rights of sysfs files

2017-03-23 Thread Peter Huewe
As indicated by checkpatch, use the octal representation for the access
rights.

S_IWUSR | S_IRUGO => 0644
S_IRUGO => 0444

Signed-off-by: Peter Huewe 
---
 drivers/hwmon/w83627ehf.c | 52 ---
 1 file changed, 22 insertions(+), 30 deletions(-)

diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index f2f33dd35fd4..0acadeece509 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -1098,25 +1098,17 @@ store_tolerance(struct device *dev, struct 
device_attribute *attr,
 }
 
 static struct sensor_device_attribute sda_target_temp[] = {
-   SENSOR_ATTR(pwm1_target, S_IWUSR | S_IRUGO, show_target_temp,
-   store_target_temp, 0),
-   SENSOR_ATTR(pwm2_target, S_IWUSR | S_IRUGO, show_target_temp,
-   store_target_temp, 1),
-   SENSOR_ATTR(pwm3_target, S_IWUSR | S_IRUGO, show_target_temp,
-   store_target_temp, 2),
-   SENSOR_ATTR(pwm4_target, S_IWUSR | S_IRUGO, show_target_temp,
-   store_target_temp, 3),
+   SENSOR_ATTR(pwm1_target, 0644, show_target_temp, store_target_temp, 0),
+   SENSOR_ATTR(pwm2_target, 0644, show_target_temp, store_target_temp, 1),
+   SENSOR_ATTR(pwm3_target, 0644, show_target_temp, store_target_temp, 2),
+   SENSOR_ATTR(pwm4_target, 0644, show_target_temp, store_target_temp, 3),
 };
 
 static struct sensor_device_attribute sda_tolerance[] = {
-   SENSOR_ATTR(pwm1_tolerance, S_IWUSR | S_IRUGO, show_tolerance,
-   store_tolerance, 0),
-   SENSOR_ATTR(pwm2_tolerance, S_IWUSR | S_IRUGO, show_tolerance,
-   store_tolerance, 1),
-   SENSOR_ATTR(pwm3_tolerance, S_IWUSR | S_IRUGO, show_tolerance,
-   store_tolerance, 2),
-   SENSOR_ATTR(pwm4_tolerance, S_IWUSR | S_IRUGO, show_tolerance,
-   store_tolerance, 3),
+   SENSOR_ATTR(pwm1_tolerance, 0644, show_tolerance, store_tolerance, 0),
+   SENSOR_ATTR(pwm2_tolerance, 0644, show_tolerance, store_tolerance, 1),
+   SENSOR_ATTR(pwm3_tolerance, 0644, show_tolerance, store_tolerance, 2),
+   SENSOR_ATTR(pwm4_tolerance, 0644, show_tolerance, store_tolerance, 3),
 };
 
 /* Smart Fan registers */
@@ -1194,24 +1186,24 @@ store_##reg(struct device *dev, struct device_attribute 
*attr, \
 fan_time_functions(fan_stop_time, FAN_STOP_TIME)
 
 static struct sensor_device_attribute sda_sf3_arrays_fan4[] = {
-   SENSOR_ATTR(pwm4_stop_time, S_IWUSR | S_IRUGO, show_fan_stop_time,
+   SENSOR_ATTR(pwm4_stop_time, 0644, show_fan_stop_time,
store_fan_stop_time, 3),
-   SENSOR_ATTR(pwm4_start_output, S_IWUSR | S_IRUGO, show_fan_start_output,
+   SENSOR_ATTR(pwm4_start_output, 0644, show_fan_start_output,
store_fan_start_output, 3),
-   SENSOR_ATTR(pwm4_stop_output, S_IWUSR | S_IRUGO, show_fan_stop_output,
+   SENSOR_ATTR(pwm4_stop_output, 0644, show_fan_stop_output,
store_fan_stop_output, 3),
-   SENSOR_ATTR(pwm4_max_output, S_IWUSR | S_IRUGO, show_fan_max_output,
+   SENSOR_ATTR(pwm4_max_output, 0644, show_fan_max_output,
store_fan_max_output, 3),
-   SENSOR_ATTR(pwm4_step_output, S_IWUSR | S_IRUGO, show_fan_step_output,
+   SENSOR_ATTR(pwm4_step_output, 0644, show_fan_step_output,
store_fan_step_output, 3),
 };
 
 static struct sensor_device_attribute sda_sf3_arrays_fan3[] = {
-   SENSOR_ATTR(pwm3_stop_time, S_IWUSR | S_IRUGO, show_fan_stop_time,
+   SENSOR_ATTR(pwm3_stop_time, 0644, show_fan_stop_time,
store_fan_stop_time, 2),
-   SENSOR_ATTR(pwm3_start_output, S_IWUSR | S_IRUGO, show_fan_start_output,
+   SENSOR_ATTR(pwm3_start_output, 0644, show_fan_start_output,
store_fan_start_output, 2),
-   SENSOR_ATTR(pwm3_stop_output, S_IWUSR | S_IRUGO, show_fan_stop_output,
+   SENSOR_ATTR(pwm3_stop_output, 0644, show_fan_stop_output,
store_fan_stop_output, 2),
 };
 
@@ -1233,17 +1225,17 @@ static SENSOR_DEVICE_ATTR(pwm2_stop_output, 0644, 
show_fan_stop_output,
  * Need to check support while generating/removing attribute files.
  */
 static struct sensor_device_attribute sda_sf3_max_step_arrays[] = {
-   SENSOR_ATTR(pwm1_max_output, S_IWUSR | S_IRUGO, show_fan_max_output,
+   SENSOR_ATTR(pwm1_max_output, 0644, show_fan_max_output,
store_fan_max_output, 0),
-   SENSOR_ATTR(pwm1_step_output, S_IWUSR | S_IRUGO, show_fan_step_output,
+   SENSOR_ATTR(pwm1_step_output, 0644, show_fan_step_output,
store_fan_step_output, 0),
-   SENSOR_ATTR(pwm2_max_output, S_IWUSR | S_IRUGO, show_fan_max_output,
+   SENSOR_ATTR(pwm2_max_output, 0644, show_fan_max_output,
store_fan_max_output, 1),
-   SENSOR_ATTR(pwm2_step_output, S_IWUSR | S_IRUGO, show_fan_step_output,
+   SENSOR_ATTR(pwm2_step_output, 0644, show_fan_step_

[PATCH 5/5] w83627ehf: Drop support for nct6775/nct6776

2017-03-23 Thread Peter Huewe
Since there exists a dedicated driver for nct6775/nct6776 it makes sense
to remove support for these chips from this driver, in order to have
only one code base for these types of chips.

This also improves maintainability and readability (and size) of this
driver.

Some not so-obvious changes are:
- removal of fan_debounce module parameter (now unused)
- removal of has_fan_div flag (nct6776 specific)
- w83627ehf_update_fan_div_common -> w83627ehf_update_fan_div
  (no distinction needed anymore)
- w83627ehf_update_pwm_common -> w83627ehf_update_pwm
  (no distinction needed anymore)
- NUM_REG_TEMP changed to ARRAY_SIZE(W83627EHF_REG_TEMP)
  (different number of max temp sensors)
- removal of intrusion1_alarm (nct6776 specific)

v2: Updated Kconfig, Documentation and removed unused temp_sensors (5-9)

Tested on NCT6776F (not probed anymore)

Signed-off-by: Peter Huewe 
---
 Documentation/hwmon/w83627ehf |  36 +--
 drivers/hwmon/Kconfig |   5 +-
 drivers/hwmon/w83627ehf.c | 546 --
 3 files changed, 57 insertions(+), 530 deletions(-)

diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf
index 735c42a85ead..d6b05abc1dcb 100644
--- a/Documentation/hwmon/w83627ehf
+++ b/Documentation/hwmon/w83627ehf
@@ -26,14 +26,6 @@ Supported chips:
 Prefix: 'w83667hg'
 Addresses scanned: ISA address retrieved from Super I/O registers
 Datasheet: Available from Nuvoton upon request
-  * Nuvoton NCT6775F/W83667HG-I
-Prefix: 'nct6775'
-Addresses scanned: ISA address retrieved from Super I/O registers
-Datasheet: Available from Nuvoton upon request
-  * Nuvoton NCT6776F
-Prefix: 'nct6776'
-Addresses scanned: ISA address retrieved from Super I/O registers
-Datasheet: Available from Nuvoton upon request
 
 Authors:
 Jean Delvare 
@@ -46,24 +38,22 @@ Description
 ---
 
 This driver implements support for the Winbond W83627EHF, W83627EHG,
-W83627DHG, W83627DHG-P, W83627UHG, W83667HG, W83667HG-B, W83667HG-I
-(NCT6775F), and NCT6776F super I/O chips. We will refer to them collectively
-as Winbond chips.
+W83627DHG, W83627DHG-P, W83627UHG, W83667HG and W83667HG-B super I/O chips.
+We will refer to them collectively as Winbond chips.
 
-The chips implement 3 to 4 temperature sensors (9 for NCT6775F and NCT6776F),
-2 to 5 fan rotation speed sensors, 8 to 10 analog voltage sensors, one VID
-(except for 627UHG), alarms with beep warnings (control unimplemented),
-and some automatic fan regulation strategies (plus manual fan control mode).
+The chips implement 3 to 4 temperature sensors, 2 to 5 fan rotation speed
+sensors, 8 to 10 analog voltage sensors, one VID (except for 627UHG), alarms
+with beep warnings (control unimplemented), and some automatic fan regulation
+strategies (plus manual fan control mode).
 
-The temperature sensor sources on W82677HG-B, NCT6775F, and NCT6776F are
-configurable. temp4 and higher attributes are only reported if its temperature
-source differs from the temperature sources of the already reported temperature
-sensors. The configured source for each of the temperature sensors is provided
-in tempX_label.
+The temperature sensor sources on W82677HG-B are configurable. temp4 and higher
+attributes are only reported if its temperature source differs from the
+temperature sources of the already reported temperature sensors. The configured
+source for each of the temperature sensors is provided in tempX_label.
 
 Temperatures are measured in degrees Celsius and measurement resolution is 1
 degC for temp1 and and 0.5 degC for temp2 and temp3. For temp4 and higher,
-resolution is 1 degC for W83667HG-B and 0.0 degC for NCT6775F and NCT6776F.
+resolution is 1 degC for W83667HG-B.
 An alarm is triggered when the temperature gets higher than high limit;
 it stays on until the temperature falls below the hysteresis value.
 Alarms are only supported for temp1, temp2, and temp3.
@@ -110,10 +100,8 @@ pwm[1-4]_enable - this file controls mode of 
fan/temperature control:
* 4 "Smart Fan III" mode
* 5 "Smart Fan IV" mode
 
-   SmartFan III mode is not supported on NCT6776F.
-
SmartFan IV mode is configurable only if it was configured at system
-   startup, and is only supported for W83677HG-B, NCT6775F, and NCT6776F.
+   startup, and is only supported for W83677HG-B.
SmartFan IV operational parameters can not be configured at this time,
and the various pwm attributes are not used in SmartFan IV mode.
The attributes can be written to, which is useful if you plan to
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 0649d53f3d16..38edc81fb87e 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1807,7 +1807,7 @@ config SENSORS_W83627HF
  will be called w83627hf.
 
 config SENSORS_W83627EHF
-   tristate "Winbond W83627EHF/EHG/DHG/UHG, W83667HG, NCT6775F, NCT6776F"
+   tristate "Winbond W83627EHF/EHG/DHG/

Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

2017-03-23 Thread Robin Murphy
On 22/03/17 06:27, Zhen Lei wrote:
> Reserve the first granule size memory(start at start_pfn) as boundary
> iova, to make sure that iovad->cached32_node can not be NULL in future.
> Meanwhile, changed the assignment of iovad->cached32_node from rb_next to
> rb_prev of &free->node in function __cached_rbnode_delete_update.

I'm not sure I follow this. It's a top-down allocator, so cached32_node
points to the last node allocated (or the node above the last one freed)
on the assumption that there is likely free space directly below there,
thus it's a pretty good place for the next allocation to start searching
from. On the other hand, start_pfn is a hard "do not go below this line"
limit, so it doesn't seem to make any sense to ever point the former at
the latter.

I could understand slightly more if we were reserving the PFN *above*
the cached range, but as-is I don't see what we gain from the change
here, nor what benefit the cached32_node != NULL assumption gives
(AFAICS it would be more useful to simply restrict the cases where it
may be NULL to when the address space is either completely full or
completely empty, or perhaps both).

Robin.

> Signed-off-by: Zhen Lei 
> ---
>  drivers/iommu/iova.c | 63 
> ++--
>  1 file changed, 37 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 1c49969..b5a148e 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -32,6 +32,17 @@ static unsigned long iova_rcache_get(struct iova_domain 
> *iovad,
>  static void init_iova_rcaches(struct iova_domain *iovad);
>  static void free_iova_rcaches(struct iova_domain *iovad);
>  
> +static void
> +insert_iova_boundary(struct iova_domain *iovad)
> +{
> + struct iova *iova;
> + unsigned long start_pfn_32bit = iovad->start_pfn;
> +
> + iova = reserve_iova(iovad, start_pfn_32bit, start_pfn_32bit);
> + BUG_ON(!iova);
> + iovad->cached32_node = &iova->node;
> +}
> +
>  void
>  init_iova_domain(struct iova_domain *iovad, unsigned long granule,
>   unsigned long start_pfn, unsigned long pfn_32bit)
> @@ -45,27 +56,38 @@ init_iova_domain(struct iova_domain *iovad, unsigned long 
> granule,
>  
>   spin_lock_init(&iovad->iova_rbtree_lock);
>   iovad->rbroot = RB_ROOT;
> - iovad->cached32_node = NULL;
>   iovad->granule = granule;
>   iovad->start_pfn = start_pfn;
>   iovad->dma_32bit_pfn = pfn_32bit;
>   init_iova_rcaches(iovad);
> +
> + /*
> +  * Insert boundary nodes for dma32. So cached32_node can not be NULL in
> +  * future.
> +  */
> + insert_iova_boundary(iovad);
>  }
>  EXPORT_SYMBOL_GPL(init_iova_domain);
>  
>  static struct rb_node *
>  __get_cached_rbnode(struct iova_domain *iovad, unsigned long *limit_pfn)
>  {
> - if ((*limit_pfn > iovad->dma_32bit_pfn) ||
> - (iovad->cached32_node == NULL))
> + struct rb_node *cached_node;
> + struct rb_node *next_node;
> +
> + if (*limit_pfn > iovad->dma_32bit_pfn)
>   return rb_last(&iovad->rbroot);
> - else {
> - struct rb_node *prev_node = rb_prev(iovad->cached32_node);
> - struct iova *curr_iova =
> - rb_entry(iovad->cached32_node, struct iova, node);
> - *limit_pfn = curr_iova->pfn_lo - 1;
> - return prev_node;
> + else
> + cached_node = iovad->cached32_node;
> +
> + next_node = rb_next(cached_node);
> + if (next_node) {
> + struct iova *next_iova = rb_entry(next_node, struct iova, node);
> +
> + *limit_pfn = min(*limit_pfn, next_iova->pfn_lo - 1);
>   }
> +
> + return cached_node;
>  }
>  
>  static void
> @@ -83,20 +105,13 @@ __cached_rbnode_delete_update(struct iova_domain *iovad, 
> struct iova *free)
>   struct iova *cached_iova;
>   struct rb_node *curr;
>  
> - if (!iovad->cached32_node)
> - return;
>   curr = iovad->cached32_node;
>   cached_iova = rb_entry(curr, struct iova, node);
>  
>   if (free->pfn_lo >= cached_iova->pfn_lo) {
> - struct rb_node *node = rb_next(&free->node);
> - struct iova *iova = rb_entry(node, struct iova, node);
> -
>   /* only cache if it's below 32bit pfn */
> - if (node && iova->pfn_lo < iovad->dma_32bit_pfn)
> - iovad->cached32_node = node;
> - else
> - iovad->cached32_node = NULL;
> + if (free->pfn_hi <= iovad->dma_32bit_pfn)
> + iovad->cached32_node = rb_prev(&free->node);
>   }
>  }
>  
> @@ -114,7 +129,7 @@ static int __alloc_and_insert_iova_range(struct 
> iova_domain *iovad,
>   unsigned long size, unsigned long limit_pfn,
>   struct iova *new, bool size_aligned)
>  {
> - struct rb_node *prev, *curr = NULL;
> + struct rb_node *prev, *curr;
>   unsigned long flags;
>   unsigned l

[PATCH 3/5] w83627ehf: Minor readability fixes

2017-03-23 Thread Peter Huewe
just some cosmetics for better readability, proposed by
Lindent/checkpatch

Signed-off-by: Peter Huewe 
---
 drivers/hwmon/w83627ehf.c | 39 +++
 1 file changed, 15 insertions(+), 24 deletions(-)

diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index 0acadeece509..a6f56b12727b 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -410,6 +410,7 @@ div_from_reg(u8 reg)
 static const u16 scale_in_common[10] = {
800, 800, 1600, 1600, 800, 800, 800, 1600, 1600, 800
 };
+
 static const u16 scale_in_w83627uhg[9] = {
800, 800, 3328, 3424, 800, 800, 0, 3328, 3400
 };
@@ -432,7 +433,6 @@ struct w83627ehf_sio_data {
enum kinds kind;
 };
 
-
 struct w83627ehf_data {
int addr;   /* IO base of hw monitor block */
const char *name;
@@ -532,6 +532,7 @@ struct w83627ehf_data {
 static inline void w83627ehf_set_bank(struct w83627ehf_data *data, u16 reg)
 {
u8 bank = reg >> 8;
+
if (data->bank != bank) {
outb_p(W83627EHF_REG_BANK, data->addr + ADDR_REG_OFFSET);
outb_p(bank, data->addr + DATA_REG_OFFSET);
@@ -549,8 +550,7 @@ static u16 w83627ehf_read_value(struct w83627ehf_data 
*data, u16 reg)
outb_p(reg & 0xff, data->addr + ADDR_REG_OFFSET);
res = inb_p(data->addr + DATA_REG_OFFSET);
if (word_sized) {
-   outb_p((reg & 0xff) + 1,
-  data->addr + ADDR_REG_OFFSET);
+   outb_p((reg & 0xff) + 1, data->addr + ADDR_REG_OFFSET);
res = (res << 8) + inb_p(data->addr + DATA_REG_OFFSET);
}
 
@@ -569,8 +569,7 @@ static int w83627ehf_write_value(struct w83627ehf_data 
*data, u16 reg,
outb_p(reg & 0xff, data->addr + ADDR_REG_OFFSET);
if (word_sized) {
outb_p(value >> 8, data->addr + DATA_REG_OFFSET);
-   outb_p((reg & 0xff) + 1,
-  data->addr + ADDR_REG_OFFSET);
+   outb_p((reg & 0xff) + 1, data->addr + ADDR_REG_OFFSET);
}
outb_p(value & 0xff, data->addr + DATA_REG_OFFSET);
 
@@ -590,8 +589,7 @@ static u16 w83627ehf_read_temp(struct w83627ehf_data *data, 
u16 reg)
return res;
 }
 
-static int w83627ehf_write_temp(struct w83627ehf_data *data, u16 reg,
-  u16 value)
+static int w83627ehf_write_temp(struct w83627ehf_data *data, u16 reg, u16 
value)
 {
if (!is_word_sized(reg))
value >>= 8;
@@ -700,7 +698,7 @@ static void nct6775_update_fan_div(struct w83627ehf_data 
*data)
data->fan_div[1] = (i & 0x70) >> 4;
i = w83627ehf_read_value(data, NCT6775_REG_FANDIV2);
data->fan_div[2] = i & 0x7;
-   if (data->has_fan & (1<<3))
+   if (data->has_fan & (1 << 3))
data->fan_div[3] = (i & 0x70) >> 4;
 }
 
@@ -935,9 +933,7 @@ static struct w83627ehf_data 
*w83627ehf_update_device(struct device *dev)
return data;
 }
 
-
-static void
-store_fan_min(struct device *dev, u32 channel, unsigned long val)
+static void store_fan_min(struct device *dev, u32 channel, unsigned long val)
 {
struct w83627ehf_data *data = dev_get_drvdata(dev);
int nr = channel;
@@ -1014,10 +1010,8 @@ store_fan_min(struct device *dev, u32 channel, unsigned 
long val)
data->last_updated = jiffies;
}
 done:
-   w83627ehf_write_value(data, data->REG_FAN_MIN[nr],
- data->fan_min[nr]);
+   w83627ehf_write_value(data, data->REG_FAN_MIN[nr], data->fan_min[nr]);
mutex_unlock(&data->update_lock);
-
 }
 
 #define show_tol_temp(reg) \
@@ -1036,7 +1030,7 @@ show_tol_temp(target_temp)
 
 static ssize_t
 store_target_temp(struct device *dev, struct device_attribute *attr,
-   const char *buf, size_t count)
+ const char *buf, size_t count)
 {
struct w83627ehf_data *data = dev_get_drvdata(dev);
struct sensor_device_attribute *sensor_attr = to_sensor_dev_attr(attr);
@@ -1059,7 +1053,7 @@ store_target_temp(struct device *dev, struct 
device_attribute *attr,
 
 static ssize_t
 store_tolerance(struct device *dev, struct device_attribute *attr,
-   const char *buf, size_t count)
+   const char *buf, size_t count)
 {
struct w83627ehf_data *data = dev_get_drvdata(dev);
struct w83627ehf_sio_data *sio_data = data->sio_data;
@@ -1243,6 +1237,7 @@ static ssize_t
 cpu0_vid_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
struct w83627ehf_data *data = dev_get_drvdata(dev);
+
return sprintf(buf, "%d\n", vid_from_reg(data->vid, data->vrm));
 }
 static DEVICE_ATTR_RO(cpu0_vid);
@@ -1486,8 +1481,7 @@ static inline void w83627ehf_init_device(struct 
w83627ehf_data *data,
/* Start monitoring is needed */
tmp = w83627ehf_read_value(data, W83627EHF_REG_CONFIG);
if (!(tmp & 0x01))
-   w83627ehf_write_value(d

[PATCH 1/5] w83627ehf: Use hwmon_device_register_with_info and sensor groups

2017-03-23 Thread Peter Huewe
This patch replaces the old, deprecated call to hwmon_device_register
with the new hwmon_device_register_with_info and converts the whole
driver to the new hwmon interface using the hwmon_chip_info methods
and the attribute_group method.

All standard attributes were converted to the corresponding
hwmon_chip_info methods.
For some functions a hwmon channel to device channel conversion had to
be performed, e.g. hwmon_in_alarm has the info for alert_5 in channel 8.

All non-standard attributes are converted to the attribute_group method,
by
- adding them statically to the attribute_group if they are available
for all variants of devices supported by this driver
- adding them at probe time to the attribute_group if the availability
is depending on the actual chip type.
The appropriate count of entries was reserved.

As a pre-condition a reference to the sio_data structure was moved into
w83627ehf_data for easier retrieval of the information, since this is
much easier than trying to access the platform_data.

The driver is now much more "checkpatch clean" than it used to be, but
still not completely.
The conversion saves about 20k in the resulting .ko

Tested with a NCT6776F chip.

v2:
- converted to proper is_visible methods
- applied minor feedback of v1

Signed-off-by: Peter Huewe 
---
 drivers/hwmon/w83627ehf.c | 1536 +++--
 1 file changed, 778 insertions(+), 758 deletions(-)

diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index ad68b6d9ff17..f2f33dd35fd4 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -1,6 +1,7 @@
 /*
  *  w83627ehf - Driver for the hardware monitoring functionality of
  * the Winbond W83627EHF Super-I/O chip
+ *  Copyright (C) 2017  Peter Huewe 
  *  Copyright (C) 2005-2012  Jean Delvare 
  *  Copyright (C) 2006  Yuan Mu (Winbond),
  * Rudolf Marek 
@@ -426,6 +427,11 @@ static inline u8 in_to_reg(u32 val, u8 nr, const u16 
*scale_in)
 /*
  * Data structures and manipulation thereof
  */
+struct w83627ehf_sio_data {
+   int sioreg;
+   enum kinds kind;
+};
+
 
 struct w83627ehf_data {
int addr;   /* IO base of hw monitor block */
@@ -514,11 +520,7 @@ struct w83627ehf_data {
u8 fandiv1;
u8 fandiv2;
 #endif
-};
-
-struct w83627ehf_sio_data {
-   int sioreg;
-   enum kinds kind;
+   struct w83627ehf_sio_data *sio_data;
 };
 
 /*
@@ -679,7 +681,7 @@ static void w83627ehf_write_fan_div(struct w83627ehf_data 
*data, int nr)
 static void w83627ehf_write_fan_div_common(struct device *dev,
   struct w83627ehf_data *data, int nr)
 {
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
+   struct w83627ehf_sio_data *sio_data = data->sio_data;
 
if (sio_data->kind == nct6776)
; /* no dividers, do nothing */
@@ -730,11 +732,9 @@ static void w83627ehf_update_fan_div(struct w83627ehf_data 
*data)
 static void w83627ehf_update_fan_div_common(struct device *dev,
struct w83627ehf_data *data)
 {
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
-
-   if (sio_data->kind == nct6776)
+   if (data->sio_data->kind == nct6776)
; /* no dividers, do nothing */
-   else if (sio_data->kind == nct6775)
+   else if (data->sio_data->kind == nct6775)
nct6775_update_fan_div(data);
else
w83627ehf_update_fan_div(data);
@@ -787,7 +787,7 @@ static void w83627ehf_update_pwm(struct w83627ehf_data 
*data)
 static void w83627ehf_update_pwm_common(struct device *dev,
struct w83627ehf_data *data)
 {
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
+   struct w83627ehf_sio_data *sio_data = data->sio_data;
 
if (sio_data->kind == nct6775 || sio_data->kind == nct6776)
nct6775_update_pwm(data);
@@ -798,8 +798,7 @@ static void w83627ehf_update_pwm_common(struct device *dev,
 static struct w83627ehf_data *w83627ehf_update_device(struct device *dev)
 {
struct w83627ehf_data *data = dev_get_drvdata(dev);
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
-
+   struct w83627ehf_sio_data *sio_data = data->sio_data;
int i;
 
mutex_lock(&data->update_lock);
@@ -936,157 +935,15 @@ static struct w83627ehf_data 
*w83627ehf_update_device(struct device *dev)
return data;
 }
 
-/*
- * Sysfs callback functions
- */
-#define show_in_reg(reg) \
-static ssize_t \
-show_##reg(struct device *dev, struct device_attribute *attr, \
-  char *buf) \
-{ \
-   struct w83627ehf_data *data = w83627ehf_update_device(dev); \
-   struct sensor_device_attribute *sensor_attr = \
-   to_sensor_dev_attr(attr); \
-   int nr = sensor_attr->index; \
-   return sprintf(buf, "%ld\n", in_from_reg(data->reg[nr], nr, \
-  

Re: [PATCH] ARM: gemini: don't select SERIAL_OF_PLATFORM

2017-03-23 Thread Linus Walleij
On Thu, Mar 23, 2017 at 1:13 PM, Arnd Bergmann  wrote:
> On Thu, Mar 23, 2017 at 11:22 AM, Linus Walleij
>  wrote:
>> On Tue, Mar 21, 2017 at 9:52 PM, Arnd Bergmann  wrote:
>>
>>> We cannot select the option when SERIAL_8250 is not also set:
>>>
>>> warning: (ARCH_GEMINI) selects SERIAL_OF_PLATFORM which has unmet direct 
>>> dependencies (TTY && HAS_IOMEM && SERIAL_8250 && OF)
>>>
>>> This removes the 'select' statement, requiring that users enable the
>>> option manually. Alternatively, we could make it a conditional
>>> 'select SERIAL_OF_PLATFORM if SERIAL_8250' or also select a handful
>>> of other symbols that it depends on.
>>>
>>> Signed-off-by: Arnd Bergmann 
>>
>> Reviewed-by: Linus Walleij 
>>
>> Will you apply this directly to the interestingly misspelled
>> "gemeni/multiplatform" branch in the ARM SoC tree
>> directly?
>>
>> I will send pull requests on top of that branch later
>> for more features.
>
> If you are going to send more pull requests, just add the fixup there,
> it's not urgent.

OK thanks, I'll queue it.

Yours,
Linus Walleij


Re: net/kcm: use-after-free in kcm_wq

2017-03-23 Thread Dmitry Vyukov
On Fri, Mar 3, 2017 at 9:03 PM, Cong Wang  wrote:
> On Fri, Mar 3, 2017 at 2:11 AM, Dmitry Vyukov  wrote:
>> Also like this one:
>>
>> ==
>> BUG: KASAN: use-after-free in atomic_long_read
>> include/linux/compiler.h:254 [inline] at addr 8800538aba60
>> BUG: KASAN: use-after-free in get_work_pool+0x2f2/0x340
>> kernel/workqueue.c:709 at addr 8800538aba60
>> Read of size 8 by task syz-executor6/7965
>> CPU: 2 PID: 7965 Comm: syz-executor6 Not tainted 4.10.0+ #248
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:15 [inline]
>>  dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
>>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:166
>>  print_address_description mm/kasan/report.c:204 [inline]
>>  kasan_report_error mm/kasan/report.c:288 [inline]
>>  kasan_report.part.2+0x198/0x440 mm/kasan/report.c:310
>>  kasan_report mm/kasan/report.c:331 [inline]
>>  __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:331
>>  atomic_long_read include/linux/compiler.h:254 [inline]
>>  get_work_pool+0x2f2/0x340 kernel/workqueue.c:709
>>  __queue_work+0x2b3/0x1210 kernel/workqueue.c:1401
>>  queue_work_on+0x2e9/0x330 kernel/workqueue.c:1486
>>  queue_work include/linux/workqueue.h:487 [inline]
>>  strp_check_rcv+0x25/0x30 net/strparser/strparser.c:494
>
>
> It is not kcm_wq, it is strp_wq, and the work struct is strp->rx_work
> which lives in struct kcm_psock. The work is cancelled by strp_done(),
> it seems get queued again after strp_done()...


on 093b995e3b55a0ae0670226ddfcb05bfbf0099ae:

==
BUG: KASAN: use-after-free in worker_thread+0x1024/0x1340
kernel/workqueue.c:2229 at addr 88006d164ae0
Read of size 8 by task kworker/u8:3/25139
CPU: 2 PID: 25139 Comm: kworker/u8:3 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:166
 print_address_description mm/kasan/report.c:210 [inline]
 kasan_report_error mm/kasan/report.c:294 [inline]
 kasan_report.part.2+0x1be/0x480 mm/kasan/report.c:316
 kasan_report mm/kasan/report.c:337 [inline]
 __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:337
 worker_thread+0x1024/0x1340 kernel/workqueue.c:2229
 kthread+0x359/0x420 kernel/kthread.c:229
 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
Object at 88006d1649c0, in cache kcm_psock_cache size: 616
Allocated:
PID = 25123
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:517
 set_track mm/kasan/kasan.c:529 [inline]
 kasan_kmalloc+0xbc/0xf0 mm/kasan/kasan.c:620
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:559
 kmem_cache_alloc+0x110/0x720 mm/slab.c:3572
 kmem_cache_zalloc include/linux/slab.h:653 [inline]
 kcm_attach net/kcm/kcmsock.c:1386 [inline]
 kcm_attach_ioctl net/kcm/kcmsock.c:1457 [inline]
 kcm_ioctl+0x2bc/0x17e0 net/kcm/kcmsock.c:1692
 sock_do_ioctl+0x65/0xb0 net/socket.c:895
 sock_ioctl+0x2c2/0x440 net/socket.c:993
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 25139
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:517
 set_track mm/kasan/kasan.c:529 [inline]
 kasan_slab_free+0x81/0xc0 mm/kasan/kasan.c:593
 __cache_free mm/slab.c:3514 [inline]
 kmem_cache_free+0x71/0x240 mm/slab.c:3774
 unreserve_psock+0x5d4/0x7b0 net/kcm/kcmsock.c:547
 kcm_write_msgs+0xba6/0x1ba0 net/kcm/kcmsock.c:590
 kcm_tx_work+0x32/0x1f0 net/kcm/kcmsock.c:731
 process_one_work+0xb20/0x1b40 kernel/workqueue.c:2097
 worker_thread+0x1b4/0x1340 kernel/workqueue.c:2231
 kthread+0x359/0x420 kernel/kthread.c:229
 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
Memory state around the buggy address:
 88006d164980: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
 88006d164a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>88006d164a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
   ^
 88006d164b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 88006d164b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==


[RFC PATCH 2/2] arm64: hugetlbpages: Correctly handle swap entries in huge_pte_offset()

2017-03-23 Thread Punit Agrawal
huge_pte_offset() does not correctly handle poisoned or migration page
table entries. Not knowing the size of the hugepage entry being
requested only compounded the problem.

The recently added hstate parameter can be used to determine the size of
hugepage being accessed. Use the size to find the correct page table
entry to return when coming across a swap page table entry.

Signed-off-by: Punit Agrawal 
Cc: David Woods 
---
 arch/arm64/mm/hugetlbpage.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 75d8cc3e138b..db108fa6e197 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -191,38 +191,39 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
 
 pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, struct hstate 
*h)
 {
+   unsigned long sz = huge_page_size(h);
pgd_t *pgd;
pud_t *pud;
-   pmd_t *pmd = NULL;
-   pte_t *pte = NULL;
+   pmd_t *pmd;
+   pte_t *pte;
 
pgd = pgd_offset(mm, addr);
pr_debug("%s: addr:0x%lx pgd:%p\n", __func__, addr, pgd);
if (!pgd_present(*pgd))
return NULL;
+
pud = pud_offset(pgd, addr);
-   if (!pud_present(*pud))
+   if (pud_none(*pud) && sz != PUD_SIZE)
return NULL;
-
-   if (pud_huge(*pud))
+   else if (!pud_table(*pud))
return (pte_t *)pud;
+
+   if (sz == CONT_PMD_SIZE)
+   addr &= CONT_PMD_MASK;
+
pmd = pmd_offset(pud, addr);
-   if (!pmd_present(*pmd))
+   if (pmd_none(*pmd) &&
+   !(sz == PMD_SIZE || sz == CONT_PMD_SIZE))
return NULL;
-
-   if (pte_cont(pmd_pte(*pmd))) {
-   pmd = pmd_offset(
-   pud, (addr & CONT_PMD_MASK));
-   return (pte_t *)pmd;
-   }
-   if (pmd_huge(*pmd))
+   else if (!pmd_table(*pmd))
return (pte_t *)pmd;
-   pte = pte_offset_kernel(pmd, addr);
-   if (pte_present(*pte) && pte_cont(*pte)) {
+
+   if (sz == CONT_PTE_SIZE) {
pte = pte_offset_kernel(
pmd, (addr & CONT_PTE_MASK));
return pte;
}
+
return NULL;
 }
 
-- 
2.11.0



Re: [PATCH] hangcheck-timer: Fix typo in comment

2017-03-23 Thread Greg Kroah-Hartman
On Thu, Mar 23, 2017 at 05:08:00PM +0800, Shile Zhang wrote:
> Fix the typo "alloted" -> "allotted" in comment.
> 
> Signed-off-by: Shile Zhang 
> ---
>  drivers/char/hangcheck-timer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

You sent me two different patches, with the same subject, yet they did
different things, so I have no idea what to do with them here :(

Please resend, the correct one, as a v2 patch, with the needed v2
information, and I'll be glad to consider it.

thanks,

greg k-h


[RFC PATCH 1/2] mm/hugetlb.c: add hstate parameter to huge_pte_offset()

2017-03-23 Thread Punit Agrawal
A poisoned or migrated hugepage is stored as a swap entry in the page
tables. On architectures that support hugepages consisting of contiguous
page table entries (such as on arm64) this leads to ambiguity in
determining the right page table entry to return in huge_pte_offset()
when a poisoned entry is encountered.

Let's remove the ambiguity by adding a hstate parameter to convey
additional information about the requested address. Also fixup the
definition/usage of huge_pte_offset() throughout the tree.

Signed-off-by: Punit Agrawal 
---
 arch/arm64/mm/hugetlbpage.c   |  2 +-
 arch/ia64/mm/hugetlbpage.c|  4 ++--
 arch/metag/mm/hugetlbpage.c   |  2 +-
 arch/mips/mm/hugetlbpage.c|  2 +-
 arch/parisc/mm/hugetlbpage.c  |  2 +-
 arch/powerpc/mm/hugetlbpage.c |  2 +-
 arch/s390/mm/hugetlbpage.c|  2 +-
 arch/sh/mm/hugetlbpage.c  |  2 +-
 arch/sparc/mm/hugetlbpage.c   |  2 +-
 arch/tile/mm/hugetlbpage.c|  2 +-
 arch/x86/mm/hugetlbpage.c |  2 +-
 fs/userfaultfd.c  |  7 +--
 include/linux/hugetlb.h   |  2 +-
 mm/hugetlb.c  | 18 +-
 mm/page_vma_mapped.c  |  2 +-
 mm/pagewalk.c |  2 +-
 16 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index e2106932daa0..75d8cc3e138b 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -189,7 +189,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
return pte;
 }
 
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, struct hstate 
*h)
 {
pgd_t *pgd;
pud_t *pud;
diff --git a/arch/ia64/mm/hugetlbpage.c b/arch/ia64/mm/hugetlbpage.c
index 85de86d36fdf..09c865be3cfe 100644
--- a/arch/ia64/mm/hugetlbpage.c
+++ b/arch/ia64/mm/hugetlbpage.c
@@ -44,7 +44,7 @@ huge_pte_alloc(struct mm_struct *mm, unsigned long addr, 
unsigned long sz)
 }
 
 pte_t *
-huge_pte_offset (struct mm_struct *mm, unsigned long addr)
+huge_pte_offset (struct mm_struct *mm, unsigned long addr, struct hstate *h)
 {
unsigned long taddr = htlbpage_to_page(addr);
pgd_t *pgd;
@@ -92,7 +92,7 @@ struct page *follow_huge_addr(struct mm_struct *mm, unsigned 
long addr, int writ
if (REGION_NUMBER(addr) != RGN_HPAGE)
return ERR_PTR(-EINVAL);
 
-   ptep = huge_pte_offset(mm, addr);
+   ptep = huge_pte_offset(mm, addr, size_to_hstate(HPAGE_SIZE));
if (!ptep || pte_none(*ptep))
return NULL;
page = pte_page(*ptep);
diff --git a/arch/metag/mm/hugetlbpage.c b/arch/metag/mm/hugetlbpage.c
index db1b7da91e4f..2c3b34189d29 100644
--- a/arch/metag/mm/hugetlbpage.c
+++ b/arch/metag/mm/hugetlbpage.c
@@ -74,7 +74,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
return pte;
 }
 
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, struct hstate 
*h)
 {
pgd_t *pgd;
pud_t *pud;
diff --git a/arch/mips/mm/hugetlbpage.c b/arch/mips/mm/hugetlbpage.c
index 74aa6f62468f..e66f47074ea4 100644
--- a/arch/mips/mm/hugetlbpage.c
+++ b/arch/mips/mm/hugetlbpage.c
@@ -36,7 +36,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long 
addr,
return pte;
 }
 
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, struct hstate 
*h)
 {
pgd_t *pgd;
pud_t *pud;
diff --git a/arch/parisc/mm/hugetlbpage.c b/arch/parisc/mm/hugetlbpage.c
index aa50ac090e9b..c146ee7d80c7 100644
--- a/arch/parisc/mm/hugetlbpage.c
+++ b/arch/parisc/mm/hugetlbpage.c
@@ -69,7 +69,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
return pte;
 }
 
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, struct hstate 
*h)
 {
pgd_t *pgd;
pud_t *pud;
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 8c3389cbcd12..9fddb22c60d9 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -55,7 +55,7 @@ static unsigned nr_gpages;
 
 #define hugepd_none(hpd)   (hpd_val(hpd) == 0)
 
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, struct hstate 
*h)
 {
/* Only called for hugetlbfs pages, hence can ignore THP */
return __find_linux_pte_or_hugepte(mm->pgd, addr, NULL, NULL);
diff --git a/arch/s390/mm/hugetlbpage.c b/arch/s390/mm/hugetlbpage.c
index 9b4050caa4e9..63061fcb0560 100644
--- a/arch/s390/mm/hugetlbpage.c
+++ b/arch/s390/mm/hugetlbpage.c
@@ -176,7 +176,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
return (pte_t *) pmdp;
 }
 
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, struc

[RFC PATCH 0/2] Add hstate parameter to huge_pte_offset()

2017-03-23 Thread Punit Agrawal
On architectures that support hugepages composed of contiguous pte as
well as block entries at the same level in the page table,
huge_pte_offset() is not able to determine the right offset to return
when it encounters a swap entry (which is used to mark poisoned as
well as migrated pages in the page table).

huge_pte_offset() needs to know the size of the hugepage at the
requested address to determine the offset to return - the current
entry or the first entry of a set of contiguous hugepages. This came
up while enabling support for memory failure handling on arm64[0].

Patch 1 adds a hstate parameter to huge_pte_offset() to provide
additional information about the target address. It also updates the
signatures (and usage) of huge_pte_offset() for architectures that
override the generic implementation. This patch has been compile
tested on ia64 and x86.

Patch 2 uses the size determined by the parameter added in Patch 1, to
return the correct page table offset.

The patchset is based on top of v4.11-rc3 and the arm64 huge page
cleanup for break-before-make[1].

Thanks,
Punit


[0] http://marc.info/?l=linux-arm-kernel&m=148772028907925&w=2
[1] https://www.spinics.net/lists/arm-kernel/msg570422.html

Punit Agrawal (2):
  mm/hugetlb.c: add hstate parameter to huge_pte_offset()
  arm64: hugetlbpages: Correctly handle swap entries in
huge_pte_offset()

 arch/arm64/mm/hugetlbpage.c   | 33 +
 arch/ia64/mm/hugetlbpage.c|  4 ++--
 arch/metag/mm/hugetlbpage.c   |  2 +-
 arch/mips/mm/hugetlbpage.c|  2 +-
 arch/parisc/mm/hugetlbpage.c  |  2 +-
 arch/powerpc/mm/hugetlbpage.c |  2 +-
 arch/s390/mm/hugetlbpage.c|  2 +-
 arch/sh/mm/hugetlbpage.c  |  2 +-
 arch/sparc/mm/hugetlbpage.c   |  2 +-
 arch/tile/mm/hugetlbpage.c|  2 +-
 arch/x86/mm/hugetlbpage.c |  2 +-
 fs/userfaultfd.c  |  7 +--
 include/linux/hugetlb.h   |  2 +-
 mm/hugetlb.c  | 18 +-
 mm/page_vma_mapped.c  |  2 +-
 mm/pagewalk.c |  2 +-
 16 files changed, 45 insertions(+), 41 deletions(-)

-- 
2.11.0



Re: [PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

2017-03-23 Thread afzal mohammed
Hi,

On Thu, Mar 23, 2017 at 09:37:48PM +1000, Greg Ungerer wrote:
> Tested-by: Greg Ungerer 

Thanks Greg

Since there was no negative feedback yet, change has been deposited in
rmk's patch system as 8665/1

Regards
afzal 


Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

2017-03-23 Thread Joao Pinto
Às 10:56 AM de 3/23/2017, Joao Pinto escreveu:
> Às 10:51 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
>> On 3/23/2017 11:48 AM, Giuseppe CAVALLARO wrote:
>>> Hello
>>>
>>> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
>>>>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>>>>>> Could you please share the iperf cmds you are using in order for me to
>>>>> reproduce
>>>>>> in my side?
>>>

HW Version: 4.21 QoS Core in HAPS DX7 (FPGA)
The connection between the FPGA and PC where stmmac is running is PCIe.
My configurations are done in stmmac_pci. Here they are:

@@ -68,10 +70,52 @@ static void stmmac_default_data(struct plat_stmmacenet_data
*plat)
 {
plat->bus_id = 1;
plat->phy_addr = 0;
-   plat->interface = PHY_INTERFACE_MODE_GMII;
-   plat->clk_csr = 2;  /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
-   plat->has_gmac = 1;
-   plat->force_sf_dma_mode = 1;
+   plat->interface = PHY_INTERFACE_MODE_SGMII;
+   plat->clk_csr = 0x5;
+   plat->has_gmac = 0;
+   plat->has_gmac4 = 1;
+   plat->force_sf_dma_mode = 0;
+
+   plat->rx_queues_to_use = 4;
+   plat->tx_queues_to_use = 4;
+
+   plat->rx_sched_algorithm = MTL_RX_ALGORITHM_SP;
+
+   plat->rx_queues_cfg[0].mode_to_use = MTL_QUEUE_AVB;
+   plat->rx_queues_cfg[1].mode_to_use = MTL_QUEUE_DCB;
+   plat->rx_queues_cfg[2].mode_to_use = MTL_QUEUE_DCB;
+   plat->rx_queues_cfg[3].mode_to_use = MTL_QUEUE_DCB;
+
+   plat->tx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
+   plat->tx_queues_cfg[1].mode_to_use = MTL_QUEUE_AVB;
+   plat->tx_queues_cfg[2].mode_to_use = MTL_QUEUE_DCB;
+   plat->tx_queues_cfg[3].mode_to_use = MTL_QUEUE_DCB;
+
+   plat->tx_queues_cfg[1].send_slope = 0xCCC;
+   plat->tx_queues_cfg[1].idle_slope = 0x1333;
+   plat->tx_queues_cfg[1].high_credit = 0x4B;
+   plat->tx_queues_cfg[1].low_credit = 0xFFB5;
+
+   plat->rx_queues_cfg[0].chan = 0;
+   plat->rx_queues_cfg[1].chan = 1;
+   plat->rx_queues_cfg[2].chan = 2;
+   plat->rx_queues_cfg[3].chan = 3;
+
+   plat->tx_sched_algorithm = MTL_TX_ALGORITHM_WRR;
+   plat->tx_queues_cfg[0].weight = 0x10;
+   plat->tx_queues_cfg[1].weight = 0x11;
+   plat->tx_queues_cfg[2].weight = 0x12;
+   plat->tx_queues_cfg[3].weight = 0x13;
+
+   /* Disable Priority config by default */
+   plat->tx_queues_cfg[0].use_prio = false;
+   plat->rx_queues_cfg[0].use_prio = false;
+
+   /* Disable RX queues routing by default */
+   plat->rx_queues_cfg[0].pkt_route = 0x0;
+   plat->rx_queues_cfg[1].pkt_route = 0x0;
+   plat->rx_queues_cfg[2].pkt_route = 0x0;
+   plat->rx_queues_cfg[3].pkt_route = 0x0;

plat->mdio_bus_data->phy_reset = NULL;
plat->mdio_bus_data->phy_mask = 0;
@@ -83,22 +127,14 @@ static void stmmac_default_data(struct plat_stmmacenet_data
*plat)
/* Set default value for multicast hash bins */
plat->multicast_filter_bins = HASH_TABLE_SIZE;

+   plat->dma_cfg->fixed_burst = 0;
+   plat->dma_cfg->aal = 0;
+
/* Set default value for unicast filter entries */
plat->unicast_filter_entries = 1;

/* Set the maxmtu to a default of JUMBO_LEN */
plat->maxmtu = JUMBO_LEN;
-
-   /* Set default number of RX and TX queues to use */
-   plat->tx_queues_to_use = 1;
-   plat->rx_queues_to_use = 1;
-
-   /* Disable Priority config by default */
-   plat->tx_queues_cfg[0].use_prio = false;
-   plat->rx_queues_cfg[0].use_prio = false;
-
-   /* Disable RX queues routing by default */
-   plat->rx_queues_cfg[0].pkt_route = 0x0;
 }


*** TESTS ***


*TEST 1: File (linux-next tarball) transfer of ~1.4G by scp to the DUT*

scp net-next-20170323.tar.gz x@XXX:/home/synopsys/
The authenticity of host 'X' can't be established.
ECDSA key fingerprint is SHA256:/XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XX' (ECDSA) to the list of known hosts.
XX@X's password:
net-next20170323.tar.gz

 100% 1366MB  79.3MB/s   00:17

ifconfig after transfer:

eth1  Link encap:Ethernet  HWaddr 
  inet addr:  Bcast:  Mask:
  inet6 addr: X Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1026614 errors:0 dropped:0 overruns:0 frame:0
  TX packets:56804 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:1502856063 (1.5 GB)  TX bytes:4224767 (4.2 MB)
  Interrupt:16

*stmmac Log after transfer:

#:~/tem

netlink: NULL timer crash

2017-03-23 Thread Dmitry Vyukov
Hello,

The following program triggers call of NULL timer func:

https://gist.githubusercontent.com/dvyukov/c210d01c74b911273469a93862ea7788/raw/2a3182772a6a6e20af3e71c02c2a1c2895d803fb/gistfile1.txt


BUG: unable to handle kernel NULL pointer dereference at   (null)
IP:   (null)
PGD 0
Oops: 0010 [#1] SMP KASAN
Modules linked in:
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006c634300 task.stack: 88006c64
RIP: 0010:  (null)
RSP: 0018:88006d1077c8 EFLAGS: 00010246
RAX: dc00 RBX: 880062bddb00 RCX: 8154e161
RDX: 1090c1f1 RSI:  RDI: 880062bddb00
RBP: 88006d1077e8 R08: fbfff0a936a8 R09: 0001
R10: 0001 R11: fbfff0a936a7 R12: 84860f80
R13:  R14: 880062bddb60 R15: 11000da20f05
FS:  () GS:88006d10() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 04e21000 CR4: 001406e0
Call Trace:
 
 neigh_timer_handler+0x365/0xd40 net/core/neighbour.c:944
 call_timer_fn+0x232/0x8c0 kernel/time/timer.c:1268
 expire_timers kernel/time/timer.c:1307 [inline]
 __run_timers+0x6f7/0xbd0 kernel/time/timer.c:1601
 run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
 __do_softirq+0x2d6/0xb54 kernel/softirq.c:284
 invoke_softirq kernel/softirq.c:364 [inline]
 irq_exit+0x1b1/0x1e0 kernel/softirq.c:405
 exiting_irq arch/x86/include/asm/apic.h:657 [inline]
 smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
 apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487
RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
RSP: 0018:88006c647dc0 EFLAGS: 0286 ORIG_RAX: ff10
RAX: dc00 RBX: 11000d8c8fbb RCX: 
RDX: 109d8ed4 RSI: 0001 RDI: 84ec76a0
RBP: 88006c647dc0 R08: ed000d8c6861 R09: 
R10:  R11:  R12: fbfff09d8ed2
R13: 88006c647e78 R14: 84ec7690 R15: 0002
 
 arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
 default_idle+0xba/0x450 arch/x86/kernel/process.c:275
 arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:266
 default_idle_call+0x37/0x80 kernel/sched/idle.c:97
 cpuidle_idle_call kernel/sched/idle.c:155 [inline]
 do_idle+0x230/0x380 kernel/sched/idle.c:244
 cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:346
 start_secondary+0x2a7/0x340 arch/x86/kernel/smpboot.c:275
 start_cpu+0x14/0x14 arch/x86/kernel/head_64.S:306
Code:  Bad RIP value.
RIP:   (null) RSP: 88006d1077c8
CR2: 
---[ end trace 845120b8a0d21411 ]---

On commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae


[PATCH] xen, fbfront: add support for specifying size via xenstore

2017-03-23 Thread Juergen Gross
Today xen-fbfront supports specifying the display size via module
parameters only. Add support for specifying the size via Xenstore in
order to enable doing this easily via the domain's Xen configuration.

Add an error message in case the configured display size conflicts
with video memory size.

Signed-off-by: Juergen Gross 
---
 drivers/video/fbdev/xen-fbfront.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/video/fbdev/xen-fbfront.c 
b/drivers/video/fbdev/xen-fbfront.c
index 3ee309c..46f6396 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -18,6 +18,8 @@
  * frame buffer.
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -380,10 +382,18 @@ static int xenfb_probe(struct xenbus_device *dev,
video[KPARAM_MEM] = val;
}
 
+   video[KPARAM_WIDTH] = xenbus_read_unsigned(dev->otherend, "width",
+  video[KPARAM_WIDTH]);
+   video[KPARAM_HEIGHT] = xenbus_read_unsigned(dev->otherend, "height",
+   video[KPARAM_HEIGHT]);
+
/* If requested res does not fit in available memory, use default */
fb_size = video[KPARAM_MEM] * 1024 * 1024;
if (video[KPARAM_WIDTH] * video[KPARAM_HEIGHT] * XENFB_DEPTH / 8
> fb_size) {
+   pr_warn("display parameters %d,%d,%d invalid, use defaults\n",
+   video[KPARAM_MEM], video[KPARAM_WIDTH],
+   video[KPARAM_HEIGHT]);
video[KPARAM_WIDTH] = XENFB_WIDTH;
video[KPARAM_HEIGHT] = XENFB_HEIGHT;
fb_size = XENFB_DEFAULT_FB_LEN;
-- 
2.10.2



[PATCH] xen, fbfront: fix connecting to backend

2017-03-23 Thread Juergen Gross
Connecting to the backend isn't working reliably in xen-fbfront: in
case XenbusStateInitWait of the backend has been missed the backend
transition to XenbusStateConnected will trigger the connected state
only without doing the actions required when the backend has
connected.

Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross 
---
 drivers/video/fbdev/xen-fbfront.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/xen-fbfront.c 
b/drivers/video/fbdev/xen-fbfront.c
index d0115a7..3ee309c 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -643,7 +643,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
break;
 
case XenbusStateInitWait:
-InitWait:
xenbus_switch_state(dev, XenbusStateConnected);
break;
 
@@ -654,7 +653,8 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
 * get Connected twice here.
 */
if (dev->state != XenbusStateConnected)
-   goto InitWait; /* no InitWait seen yet, fudge it */
+   /* no InitWait seen yet, fudge it */
+   xenbus_switch_state(dev, XenbusStateConnected);
 
if (xenbus_read_unsigned(info->xbdev->otherend,
 "request-update", 0))
-- 
2.10.2



Re: [PATCH v18 0/3] USB Type-C Connector class

2017-03-23 Thread Greg KH
On Tue, Mar 21, 2017 at 01:56:45PM +0200, Heikki Krogerus wrote:
> The USB Type-C class is meant to provide unified interface to the
> userspace to present the USB Type-C ports in a system.

Now applied, nice job, thanks for sticking with this, it's much
appreciated.

greg k-h


[PATCH] arm/arm64: KVM: send SIGBUS error to qemu

2017-03-23 Thread Dongjiu Geng
when the pfn is KVM_PFN_ERR_HWPOISON, it indicates to send
SIGBUS signal from KVM's fault-handling code to qemu, qemu
can handle this signal according to the fault address.

Signed-off-by: Dongjiu Geng 
---
 arch/arm/kvm/mmu.c   | 20 
 include/linux/kvm_host.h |  5 +
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 962616fd4ddd..1307ec400de3 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1237,6 +1237,20 @@ static void coherent_cache_guest_page(struct kvm_vcpu 
*vcpu, kvm_pfn_t pfn,
__coherent_cache_guest_page(vcpu, pfn, size);
 }
 
+static void kvm_send_hwpoison_signal(unsigned long address,
+   struct task_struct *tsk)
+{
+   siginfo_t info;
+
+   info.si_signo   = SIGBUS;
+   info.si_errno   = 0;
+   info.si_code= BUS_MCEERR_AR;
+   info.si_addr= (void __user *)address;
+   info.si_addr_lsb = PAGE_SHIFT;
+
+   send_sig_info(SIGBUS, &info, tsk);
+}
+
 static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
  struct kvm_memory_slot *memslot, unsigned long hva,
  unsigned long fault_status)
@@ -1309,6 +1323,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, 
phys_addr_t fault_ipa,
if (is_error_noslot_pfn(pfn))
return -EFAULT;
 
+   if (is_error_hwpoison_pfn(pfn)) {
+   kvm_send_hwpoison_signal(kvm_vcpu_gfn_to_hva(vcpu, gfn),
+   current);
+   return -EFAULT;
+   }
+
if (kvm_is_device_pfn(pfn)) {
mem_type = PAGE_S2_DEVICE;
flags |= KVM_S2PTE_FLAG_IS_IOMAP;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 2c14ad9809da..610ded9ebe9b 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -91,6 +91,11 @@ static inline bool is_noslot_pfn(kvm_pfn_t pfn)
 {
return pfn == KVM_PFN_NOSLOT;
 }
+/* hwpoison pfn indicates that it needs to send SIGBUS */
+static inline bool is_error_hwpoison_pfn(kvm_pfn_t pfn)
+{
+   return pfn == KVM_PFN_ERR_HWPOISON;
+}
 
 /*
  * architectures with KVM_HVA_ERR_BAD other than PAGE_OFFSET (e.g. s390)
-- 
2.11.0



Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

2017-03-23 Thread Geert Uytterhoeven
Hi Uwe,

On Thu, Mar 23, 2017 at 1:34 PM, Uwe Kleine-König
 wrote:
> On Thu, Mar 23, 2017 at 01:03:56PM +0100, Geert Uytterhoeven wrote:
>> On Thu, Mar 23, 2017 at 12:11 PM, Uwe Kleine-König
>>  wrote:
>> >> Make sure to enable all drivers and subsystems you need when building
>> >> your kernel. That's always true. And may indeed be hard to debug (e.g. 
>> >> what
>> >> kernel options do I need to make systemd work?).
>> >
>> > It's worse here. If you forget to enable a driver the device isn't bound
>> > and that's obvious to diagnose. When ignoring an optional GPIO there
>> > might be a device that claims to work but fails to do so. (e.g. you
>> > write to memory, write() returns 0, but the data never landed there.)
>> >
>> >> > write(2) and close(2) succeed most of the time, too. Still it's not a
>> >> > good idea to not check the return value. Or let the kernel return
>> >> > success unconditionally.
>> >>
>> >> Writing all bytes passed in the buffer is "optional" in another sense than
>> >> an "optional" GPIO: you must retry the write, while you can continue if
>> >> an optional GPIO is not present.
>> >
>> > And that is the point. You can continue *iff* the optional GPIO is not
>> > present. The patch in question removes the ability to determine if that
>> > GPIO is present and claims it is not present.
>>
>> If you forget to enable a driver/subsystem, you sometimes cannot determine
>> if the device is present or not neither.
>>
>> Hence it boils down to "knowing" if there is a GPIO or not.
>> So, when can there be a GPIO?
>>   1. The GPIO is described in DT.
>>  => Not an issue, as DT GPIO implies GPIOLIB,
>>   2. The GPIO is described in legacy platform data.
>>  => The platform code should make sure GPIOLIB is selected when needed.
>>
>> Issue solved?
>
> I like it better to not rely on platform code to do the right thing.

;-)

> Maybe we can make gpiod_get_optional look like this:
>
> if (!dev->of_node && isnt_a_acpi_device(dev) && !IS_ENABLED(GPIOLIB))
> return NULL;
> else
> return -ENOSYS;
>
> I don't know how isnt_a_acpi_device looks like, probably it involves
> CONFIG_ACPI and/or dev->acpi_node.
>
> This should be safe and still comfortable for legacy platforms, isn't it?

Yes, that should do the trick.

No feedback from me about ACPI.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH linux-next V2] tty: Disable default console blanking interval

2017-03-23 Thread Austin S. Hemmelgarn

On 2017-03-22 21:32, Scot Doyle wrote:

On Wed, 22 Mar 2017, Tim Gardner wrote:

BugLink: http://bugs.launchpad.net/bugs/869017

Console blanking is not enabling DPMS power saving (thereby negating any
power-saving benefit), and is simply turning the screen content blank. This
means that any crash output is invisible which is unhelpful on a server
(virtual or otherwise).

Furthermore, CRT burn in concerns should no longer govern the default case.
Affected users could always set consoleblank on the kernel command line.


Does screen blanking save some power by disabling the cursor blink?

Unless you're dealing with ancient hardware, the difference in power 
usage is probably on the order of single digit micro-watts, which is not 
worth worrying about on almost anything you would expect to have a 
console display connected to.


Re: [PATCH v2] kasan: report only the first error by default

2017-03-23 Thread Mark Rutland
On Thu, Mar 23, 2017 at 02:49:16PM +0300, Andrey Ryabinin wrote:
> + kasan_multi_shot
> + [KNL] Enforce KASAN (Kernel Address Sanitizer) to print
> + report on every invalid memory access. Without this
> + parameter KASAN will print report only for the first
> + invalid access.
> +

The option looks fine to me.

>  static int __init kmalloc_tests_init(void)
>  {
> + /* Rise reports limit high enough to see all the following bugs */
> + atomic_add(100, &kasan_report_count);

> +
> + /*
> +  * kasan is unreliable now, disable reports if
> +  * we are in single shot mode
> +  */
> + atomic_sub(100, &kasan_report_count);
>   return -EAGAIN;
>  }

... but these magic numbers look rather messy.

[...]

> +atomic_t kasan_report_count = ATOMIC_INIT(1);
> +EXPORT_SYMBOL_GPL(kasan_report_count);
> +
> +static int __init kasan_set_multi_shot(char *str)
> +{
> + atomic_set(&kasan_report_count, 10);
> + return 1;
> +}
> +__setup("kasan_multi_shot", kasan_set_multi_shot);

... likewise.

Rather than trying to pick an arbitrarily large number, how about we use
separate flags to determine whether we're in multi-shot mode, and
whether a (oneshot) report has been made.

How about the below?

Thanks,
Mark.

>8
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index ceb3fe7..291d7b3 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -74,6 +74,9 @@ struct kasan_cache {
 static inline void kasan_unpoison_slab(const void *ptr) { ksize(ptr); }
 size_t kasan_metadata_size(struct kmem_cache *cache);
 
+bool kasan_save_enable_multi_shot(void);
+void kasan_restore_multi_shot(bool enabled);
+
 #else /* CONFIG_KASAN */
 
 static inline void kasan_unpoison_shadow(const void *address, size_t size) {}
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 0b1d314..ae59dc2 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -12,6 +12,7 @@
 #define pr_fmt(fmt) "kasan test: %s " fmt, __func__
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -474,6 +475,12 @@ static noinline void __init use_after_scope_test(void)
 
 static int __init kmalloc_tests_init(void)
 {
+   /*
+* Temporarily enable multi-shot mode. Otherwise, we'd only get a
+* report for the first case.
+*/
+   bool multishot = kasan_save_enable_multi_shot();
+
kmalloc_oob_right();
kmalloc_oob_left();
kmalloc_node_oob_right();
@@ -499,6 +506,9 @@ static int __init kmalloc_tests_init(void)
ksize_unpoisons_memory();
copy_user_test();
use_after_scope_test();
+
+   kasan_restore_multi_shot(multishot);
+
return -EAGAIN;
 }
 
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index 1c260e6..dd2dea8 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -96,11 +96,6 @@ static inline const void *kasan_shadow_to_mem(const void 
*shadow_addr)
<< KASAN_SHADOW_SCALE_SHIFT);
 }
 
-static inline bool kasan_report_enabled(void)
-{
-   return !current->kasan_depth;
-}
-
 void kasan_report(unsigned long addr, size_t size,
bool is_write, unsigned long ip);
 void kasan_report_double_free(struct kmem_cache *cache, void *object,
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index f479365..f1c5892 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -13,6 +13,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -293,6 +294,40 @@ static void kasan_report_error(struct kasan_access_info 
*info)
kasan_end_report(&flags);
 }
 
+static unsigned long kasan_flags;
+
+#define KASAN_BIT_REPORTED 0
+#define KASAN_BIT_MULTI_SHOT   1
+
+bool kasan_save_enable_multi_shot(void)
+{
+   return test_and_set_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags);
+}
+EXPORT_SYMBOL_GPL(kasan_save_enable_multi_shot);
+
+void kasan_restore_multi_shot(bool enabled)
+{
+   if (!enabled)
+   clear_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags);
+}
+EXPORT_SYMBOL_GPL(kasan_restore_multi_shot);
+
+static int __init kasan_set_multi_shot(char *str)
+{
+   set_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags);
+   return 1;
+}
+__setup("kasan_multi_shot", kasan_set_multi_shot);
+
+static inline bool kasan_report_enabled(void)
+{
+   if (current->kasan_depth)
+   return false;
+   if (test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
+   return true;
+   return !test_and_set_bit(KASAN_BIT_REPORTED, &kasan_flags);
+}
+
 void kasan_report(unsigned long addr, size_t size,
bool is_write, unsigned long ip)
 {


Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

2017-03-23 Thread Chris Wilson
On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote:
> From: Colin Ian King 
> 
> info is being checked to see if it is a null pointer, however, vpgu is
> dereferencing info before this check, leading to a potential null
> pointer dereference.  If info is null, then the error message being
> printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> use a null vpgu as the macro has a sanity check to see if vpgu is null,
> so this is OK.

It is never NULL, it gets checked by its only caller.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

2017-03-23 Thread Uwe Kleine-König
On Thu, Mar 23, 2017 at 01:03:56PM +0100, Geert Uytterhoeven wrote:
> Hi Uwe,
> 
> On Thu, Mar 23, 2017 at 12:11 PM, Uwe Kleine-König
>  wrote:
> >> Make sure to enable all drivers and subsystems you need when building
> >> your kernel. That's always true. And may indeed be hard to debug (e.g. what
> >> kernel options do I need to make systemd work?).
> >
> > It's worse here. If you forget to enable a driver the device isn't bound
> > and that's obvious to diagnose. When ignoring an optional GPIO there
> > might be a device that claims to work but fails to do so. (e.g. you
> > write to memory, write() returns 0, but the data never landed there.)
> >
> >> > write(2) and close(2) succeed most of the time, too. Still it's not a
> >> > good idea to not check the return value. Or let the kernel return
> >> > success unconditionally.
> >>
> >> Writing all bytes passed in the buffer is "optional" in another sense than
> >> an "optional" GPIO: you must retry the write, while you can continue if
> >> an optional GPIO is not present.
> >
> > And that is the point. You can continue *iff* the optional GPIO is not
> > present. The patch in question removes the ability to determine if that
> > GPIO is present and claims it is not present.
> 
> If you forget to enable a driver/subsystem, you sometimes cannot determine
> if the device is present or not neither.
> 
> Hence it boils down to "knowing" if there is a GPIO or not.
> So, when can there be a GPIO?
>   1. The GPIO is described in DT.
>  => Not an issue, as DT GPIO implies GPIOLIB,
>   2. The GPIO is described in legacy platform data.
>  => The platform code should make sure GPIOLIB is selected when needed.
> 
> Issue solved?

I like it better to not rely on platform code to do the right thing.

Maybe we can make gpiod_get_optional look like this:

if (!dev->of_node && isnt_a_acpi_device(dev) && !IS_ENABLED(GPIOLIB))
return NULL;
else
return -ENOSYS;

I don't know how isnt_a_acpi_device looks like, probably it involves
CONFIG_ACPI and/or dev->acpi_node.

This should be safe and still comfortable for legacy platforms, isn't it?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |


kvm: use-after-free function call in kvm_io_bus_destroy

2017-03-23 Thread Dmitry Vyukov
Hello,

I've got the following report while running syzkaller fuzzer on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure, most likely it's the root cause.


FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 0 PID: 14650 Comm: syz-executor2 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 __do_kmalloc mm/slab.c:3734 [inline]
 __kmalloc+0x220/0x730 mm/slab.c:3745
 kmalloc include/linux/slab.h:495 [inline]
 kvm_io_bus_unregister_dev+0x1a2/0x300
arch/x86/kvm/../../../virt/kvm/kvm_main.c:3594
 kvm_free_pit+0x58/0x110 arch/x86/kvm/i8254.c:727
 kvm_arch_sync_events+0x35/0x40 arch/x86/kvm/x86.c:8078
 kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:727 [inline]
 kvm_put_kvm+0x27f/0xa70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:761
 kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:772
 __fput+0x327/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x1a4/0x270 kernel/task_work.c:116
 tracehook_notify_resume include/linux/tracehook.h:191 [inline]
 exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f6e094bc858 EFLAGS: 0292 ORIG_RAX: 0021
RAX: 001c RBX: 00708000 RCX: 00445b79
RDX:  RSI: 001c RDI: 001b
RBP: 0430 R08:  R09: 
R10:  R11: 0292 R12: 006de4f0
R13: 001c R14:  R15: 001b
==
BUG: KASAN: use-after-free in kvm_io_bus_destroy
include/kvm/iodev.h:72 [inline] at addr 88003bfb7d40
BUG: KASAN: use-after-free in kvm_destroy_vm
arch/x86/kvm/../../../virt/kvm/kvm_main.c:733 [inline] at addr
88003bfb7d40
BUG: KASAN: use-after-free in kvm_put_kvm+0x932/0xa70
arch/x86/kvm/../../../virt/kvm/kvm_main.c:761 at addr 88003bfb7d40
Read of size 8 by task syz-executor2/14650
CPU: 0 PID: 14650 Comm: syz-executor2 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:166
 print_address_description mm/kasan/report.c:210 [inline]
 kasan_report_error mm/kasan/report.c:294 [inline]
 kasan_report.part.2+0x1be/0x480 mm/kasan/report.c:316
 kasan_report mm/kasan/report.c:337 [inline]
 __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:337
 kvm_io_bus_destroy include/kvm/iodev.h:72 [inline]
 kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:733 [inline]
 kvm_put_kvm+0x932/0xa70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:761
 kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:772
 __fput+0x327/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x1a4/0x270 kernel/task_work.c:116
 tracehook_notify_resume include/linux/tracehook.h:191 [inline]
 exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f6e094bc858 EFLAGS: 0292 ORIG_RAX: 0021
RAX: 001c RBX: 00708000 RCX: 00445b79
RDX:  RSI: 001c RDI: 001b
RBP: 0430 R08:  R09: 
R10:  R11: 0292 R12: 006de4f0
R13: 001c R14:  R15: 001b
Object at 88003bfb7d40, in cache kmalloc-512 size: 512
Allocated:
PID = 14650
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:517
 set_track mm/kasan/kasan.c:529 [inline]
 kasan_kmalloc+0xbc/0xf0 mm/kasan/kasan.c:620
 kmem_cache_alloc_trace+0x11a/0x720 mm/slab.c:3638
 kmalloc include/linux/slab.h:490 [inline]
 kzalloc include/linux/slab.h:663 [inline]
 kvm_create_pit+0xc2/0x8b0 arch/x86/kvm/i8254.c:656
 kvm_arch_vm_ioctl+0x1339/0x2190 arch/x86/kvm/x86.c:4058
 kvm_vm_ioctl+0x20f/0x1c60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3113
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_S

[GIT PULL] Immutable branch between MFD, IIO and Input due for the v4.12 merge window

2017-03-23 Thread Lee Jones
Enjoy!

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
ib-mfd-iio-input-v4.12

for you to fetch changes up to b2d476404601806c5a94a5f9bfc441d3898a5541:

  dt-bindings: mfd: Move mxs-lradc binding document from IIO to MFD (2017-03-23 
12:29:29 +)


Immutable branch between MFD, IIO and Input due for the v4.12 merge window


Ksenija Stanojevic (5):
  mfd: mxs-lradc: Add support for mxs-lradc
  iio: adc: mxs-lradc: Add support for ADC driver
  input: touchscreen: mxs-lradc: Add support for touchscreen
  iio: adc: mxs-lradc: Remove driver
  dt-bindings: mfd: Move mxs-lradc binding document from IIO to MFD

 .../bindings/{iio/adc => mfd}/mxs-lradc.txt|0
 drivers/iio/adc/Kconfig|   27 +-
 drivers/iio/adc/Makefile   |2 +-
 drivers/iio/adc/mxs-lradc-adc.c|  843 ++
 drivers/iio/adc/mxs-lradc.c| 1750 
 drivers/input/touchscreen/Kconfig  |   10 +
 drivers/input/touchscreen/Makefile |1 +
 drivers/input/touchscreen/mxs-lradc-ts.c   |  714 
 drivers/mfd/Kconfig|   17 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/mxs-lradc.c|  267 +++
 include/linux/mfd/mxs-lradc.h  |  187 +++
 12 files changed, 2054 insertions(+), 1765 deletions(-)
 rename Documentation/devicetree/bindings/{iio/adc => mfd}/mxs-lradc.txt (100%)
 create mode 100644 drivers/iio/adc/mxs-lradc-adc.c
 delete mode 100644 drivers/iio/adc/mxs-lradc.c
 create mode 100644 drivers/input/touchscreen/mxs-lradc-ts.c
 create mode 100644 drivers/mfd/mxs-lradc.c
 create mode 100644 include/linux/mfd/mxs-lradc.h

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


[PATCH v5] KVM: VMX: Fix enable VPID conditions

2017-03-23 Thread Wanpeng Li
From: Wanpeng Li 

This can be reproduced by running L2 on L1, and disable VPID on L0 
if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 
crash as below:

KVM: entry failed, hardware error 0x7
EAX= EBX= ECX= EDX=000306c3
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   9300
CS =f000   9b00
SS =   9300
DS =   9300
FS =   9300
GS =   9300
LDT=   8200
TR =   8b00
GDT=  
IDT=  
CR0=6010 CR2= CR3= CR4=
DR0= DR1= DR2= 
DR3= 
DR6=0ff0 DR7=0400
EFER=

Reference SDM 30.3 INVVPID:
 
Protected Mode Exceptions
#UD 
  - If not in VMX operation.
  - If the logical processor does not support VPIDs 
(IA32_VMX_PROCBASED_CTLS2[37]=0).
  - If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1) 
but does 
not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).

So we should check both VPID enable bit in vmx exec control and INVVPID support 
bit 
in vmx capability MSRs to enable VPID. This patch adds the guarantee to not 
enable 
VPID if either INVVPID or single-context/all-context invalidation is not 
exposed in 
vmx capability MSRs.

Reviewed-by: David Hildenbrand 
Cc: David Hildenbrand 
Cc: Jim Mattson 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8795a70..8925c76 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1239,6 +1239,11 @@ static inline bool cpu_has_vmx_invvpid_global(void)
return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
 }
 
+static inline bool cpu_has_vmx_invvpid(void)
+{
+   return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
+}
+
 static inline bool cpu_has_vmx_ept(void)
 {
return vmcs_config.cpu_based_2nd_exec_ctrl &
@@ -6518,8 +6523,10 @@ static __init int hardware_setup(void)
if (boot_cpu_has(X86_FEATURE_NX))
kvm_enable_efer_bits(EFER_NX);
 
-   if (!cpu_has_vmx_vpid())
+   if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() ||
+   !(cpu_has_vmx_invvpid_single() || cpu_has_vmx_invvpid_global()))
enable_vpid = 0;
+
if (!cpu_has_vmx_shadow_vmcs())
enable_shadow_vmcs = 0;
if (enable_shadow_vmcs)
-- 
2.7.4



Re: [PATCH v3 3/5] coresight: add support for debug module

2017-03-23 Thread Mike Leach
Also agree with Suzuki's excellent summary.

A couple of notes on using EDPRCR

The logic for this assuming a correctly implemented system should be
something like.

if (prsr() == powered_down) { // if we are powered down request power up.
sw_unlock()   // ensure that the sw lock register on the device is unlocked
write(prcr(bit3=1))
wait_with_timeout(prsr()==powered_up)   // must wait to see if the
system does power up - otherwise bad things happen!
if(timed_out)
   fail("power up request for CPU N failed.")  // nothing to do
after this point though if a CPU can't be powered is should not be
included in the list to be checked on crash.
}
ensure_os_lock_unlocked()  // os lock has to be unlocked for bit 0 of
prcr to be writeable.
sw_unlock()   // ensure that the sw lock register on the device is unlocked
write(prcr(bit3=1 | bit0=1)) // the core is powered, set the
nopowerdown request bit so we don't lose it & emulate power down


I think that some of the above logic is already in the driver, so
needs to be adapted for the PRCR handling.


On the "bad" systems, the initial prsr check is likely to fail (crash
/ buslock) if the debug logic is not correctly powered. The user will
then have to use one or more of the PM mitigations previously
discussed that are appropriate for that specific platform and retry

Regards

Mike


On 23 March 2017 at 05:43, Leo Yan  wrote:
> On Wed, Mar 22, 2017 at 05:25:50PM +, Sudeep Holla wrote:
>>
>>
>> On 22/03/17 17:09, Suzuki K Poulose wrote:
>> > On 22/03/17 16:17, Sudeep Holla wrote:
>>
>> [...]
>>
>> >>
>> >> Point taken. So we could just specify that all necessary power
>> >> domains need to be on for proper functionality for this feature and
>> >> that it's highly platform specific instead of mixing cpu/cluster
>> >> idle details here.
>> >>
>> >>> The key point is that the caveat in using this driver is that
>> >>> the power management has to be considered on a platform specific
>> >>> basis before it is configured; and appropriate actions may be
>> >>> needed for it to work correctly. Without this then the driver
>> >>> could cause more issues than it debugs. A user selecting this
>> >>> _must_ be told about these issues
>> >>>
>> >
>> > So given all the possible caveats, I think we :
>> >
>> > 1) Shouldn't enable the driver by default at runtime even if it is
>> > built-in.
>> > 2) Should provide mechanisms to turn it on at boot (via
>> > kernel commandline) or anytime later (via sysfs), which kind of puts
>> > the responsibility back on the user : "You know what you are doing".
>> > 3) Shouldn't turn the driver on based on "nohlt" which the user
>> > could use it for some other purposes, without explicit intention of
>> > turning this driver on).
>> > 4) Should document the fact that, on some
>> > platforms, the user may have to disable CPUidle explicitly to get the
>> > driver working. But let us not make it the default. The user with a
>> > not so ideal platform could add "nohlt" and get it working.
>> >
>>
>> Agreed on all points and well summarized.
>> I would like to highlight (3) and (4) as it needs to be well understood.
>>
>> "nohlt" has a *different* meaning already, so using that in this
>> driver for something else is simple wrong as it affects the system in
>> unintended ways. And yes if user (mis)uses it to get things working,
>> it's fine but shouldn't be recommended way.
>
> Understand this point.
>
> I will try to use general way to constraint CPUIdle like other
> drivers.
>
> Thanks all for these good suggestions :)
>
> Thanks,
> Leo Yan



-- 
Mike Leach
Principal Engineer, ARM Ltd.
Blackburn Design Centre. UK


Re: [PATCH v4 7/7] mfd: dt-bindings: Add RK805 device tree bindings document

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Elaine Zhang wrote:

> Add device tree bindings documentation for Rockchip's RK805 PMIC.
> 
> Signed-off-by: Elaine Zhang 
> ---
>  Documentation/devicetree/bindings/mfd/rk808.txt | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt 
> b/Documentation/devicetree/bindings/mfd/rk808.txt
> index 9636ae8d8d41..05eb07134483 100644
> --- a/Documentation/devicetree/bindings/mfd/rk808.txt
> +++ b/Documentation/devicetree/bindings/mfd/rk808.txt
> @@ -1,11 +1,12 @@
>  RK8XX Power Management Integrated Circuit
>  
>  The rk8xx family current members:
> +rk805
>  rk808
>  rk818
>  
>  Required properties:
> -- compatible: "rockchip,rk808", "rockchip,rk818"
> +- compatible: "rockchip,rk805", "rockchip,rk808", "rockchip,rk818"
>  - reg: I2C slave address
>  - interrupt-parent: The parent interrupt controller.
>  - interrupts: the interrupt outputs of the controller.
> @@ -18,6 +19,14 @@ Optional properties:
>  - rockchip,system-power-controller: Telling whether or not this pmic is 
> controlling
>the system power.
>  
> +Optional RK805 properties:
> +- vcc1-supply:  The input supply for DCDC_REG1
> +- vcc2-supply:  The input supply for DCDC_REG2
> +- vcc3-supply:  The input supply for DCDC_REG3
> +- vcc4-supply:  The input supply for DCDC_REG4
> +- vcc5-supply:  The input supply for LDO_REG1 and LDO_REG2
> +- vcc6-supply:  The input supply for LDO_REG3
> +
>  Optional RK808 properties:
>  - vcc1-supply:  The input supply for DCDC_REG1
>  - vcc2-supply:  The input supply for DCDC_REG2
> @@ -56,6 +65,15 @@ by a child node of the 'regulators' node.
>   /* standard regulator bindings here */
>   };
>  
> +Following regulators of the RK805 PMIC block are supported. Note that

"The following RK805 PMIC regulators are supported."

> +the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or 
> LDO
> +number as described in RK805 datasheet.
> +
> + - DCDC_REGn
> + - valid values for n are 1 to 4.
> + - LDO_REGn
> + - valid values for n are 1 to 3
> +
>  Following regulators of the RK808 PMIC block are supported. Note that
>  the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or 
> LDO
>  number as described in RK808 datasheet.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 0/2] serial: Add name field to uart_port

2017-03-23 Thread Vignesh R


On Thursday 23 March 2017 12:16 AM, Andy Shevchenko wrote:
> On Tue, Mar 21, 2017 at 3:36 PM, Vignesh R  wrote:
>> This series adds name attribute to uart_port struct inorder to store
>> name of the tty port that will help in identify different uart
>> instances.
>> This patch series is based on discussion here[1].
> 
> Please, use versioning for the series. This AFAIU should be v3, and
> next (which is expecting based on comments) would be v4.

The very first patch I submitted was accepted. So I did not make the
previous patch as v2 as it was an incremental fix. Since, this series is
very different from previous patch, I chose not to label this as v3.
Anyways, will make the next version as v4.

Thanks for the review!


-- 
Regards
Vignesh


Re: [PATCH v4 4/7] mfd: rk808: Add RK805 support

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Elaine Zhang wrote:

> The RK805 chip is a Power Management IC (PMIC) for multimedia and handheld
> devices. It contains the following components:
> 
> - Regulators
> - RTC
> - Clocking
> 
> Both RK808 and RK805 chips are using a similar register map,
> so we can reuse the RTC and Clocking functionality.
> 
> Signed-off-by: Elaine Zhang 
> ---
>  drivers/mfd/Kconfig |   4 +-
>  drivers/mfd/rk808.c | 122 
> 
>  2 files changed, 124 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 55ecdfb74d31..b410a348b756 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -892,13 +892,13 @@ config MFD_RC5T583
> different functionality of the device.
>  
>  config MFD_RK808
> - tristate "Rockchip RK808/RK818 Power Management Chip"
> + tristate "Rockchip RK805/RK808/RK818 Power Management Chip"
>   depends on I2C && OF
>   select MFD_CORE
>   select REGMAP_I2C
>   select REGMAP_IRQ
>   help
> -   If you say yes here you get support for the RK808 and RK818
> +   If you say yes here you get support for the RK805, RK808 and RK818
> Power Management chips.
> This driver provides common support for accessing the device
> through I2C interface. The device supports multiple sub-devices
> diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
> index 3334a2a7f3fb..fdd4449b14b0 100644
> --- a/drivers/mfd/rk808.c
> +++ b/drivers/mfd/rk808.c
> @@ -70,6 +70,14 @@ static bool rk808_is_volatile_reg(struct device *dev, 
> unsigned int reg)
>   .volatile_reg = rk808_is_volatile_reg,
>  };
>  
> +static const struct regmap_config rk805_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = RK805_OFF_SOURCE_REG,
> + .cache_type = REGCACHE_RBTREE,
> + .volatile_reg = rk808_is_volatile_reg,
> +};
> +
>  static const struct regmap_config rk808_regmap_config = {
>   .reg_bits = 8,
>   .val_bits = 8,
> @@ -86,6 +94,16 @@ static bool rk808_is_volatile_reg(struct device *dev, 
> unsigned int reg)
>   }
>  };
>  
> +static const struct mfd_cell rk805s[] = {
> + { .name = "rk808-clkout", },
> + { .name = "rk808-regulator", },
> + {
> + .name = "rk808-rtc",
> + .num_resources = ARRAY_SIZE(rtc_resources),
> + .resources = &rtc_resources[0],
> + },
> +};
> +
>  static const struct mfd_cell rk808s[] = {
>   { .name = "rk808-clkout", },
>   { .name = "rk808-regulator", },
> @@ -106,6 +124,20 @@ static bool rk808_is_volatile_reg(struct device *dev, 
> unsigned int reg)
>   },
>  };
>  
> +static const struct rk808_reg_data rk805_pre_init_reg[] = {
> + {RK805_BUCK1_CONFIG_REG, RK805_BUCK1_2_ILMAX_MASK,
> +  RK805_BUCK1_2_ILMAX_4000MA},
> + {RK805_BUCK2_CONFIG_REG, RK805_BUCK1_2_ILMAX_MASK,
> +  RK805_BUCK1_2_ILMAX_4000MA},
> + {RK805_BUCK3_CONFIG_REG, RK805_BUCK3_4_ILMAX_MASK,
> +  RK805_BUCK3_ILMAX_3000MA},
> + {RK805_BUCK4_CONFIG_REG, RK805_BUCK3_4_ILMAX_MASK,
> +  RK805_BUCK4_ILMAX_3500MA},
> + {RK805_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_400MA},
> + {RK805_GPIO_IO_POL_REG, SLP_SD_MSK, SLEEP_FUN},
> + {RK805_THERMAL_REG, TEMP_HOTDIE_MSK, TEMP115C},
> +};
> +
>  static const struct rk808_reg_data rk808_pre_init_reg[] = {
>   { RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_150MA },
>   { RK808_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_200MA },
> @@ -135,6 +167,41 @@ static bool rk808_is_volatile_reg(struct device *dev, 
> unsigned int reg)
>   VB_LO_SEL_3500MV },
>  };
>  
> +static const struct regmap_irq rk805_irqs[] = {
> + [RK805_IRQ_PWRON_RISE] = {
> + .mask = RK805_IRQ_PWRON_RISE_MSK,
> + .reg_offset = 0,
> + },
> + [RK805_IRQ_VB_LOW] = {
> + .mask = RK805_IRQ_VB_LOW_MSK,
> + .reg_offset = 0,
> + },
> + [RK805_IRQ_PWRON] = {
> + .mask = RK805_IRQ_PWRON_MSK,
> + .reg_offset = 0,
> + },
> + [RK805_IRQ_PWRON_LP] = {
> + .mask = RK805_IRQ_PWRON_LP_MSK,
> + .reg_offset = 0,
> + },
> + [RK805_IRQ_HOTDIE] = {
> + .mask = RK805_IRQ_HOTDIE_MSK,
> + .reg_offset = 0,
> + },
> + [RK805_IRQ_RTC_ALARM] = {
> + .mask = RK805_IRQ_RTC_ALARM_MSK,
> + .reg_offset = 0,
> + },
> + [RK805_IRQ_RTC_PERIOD] = {
> + .mask = RK805_IRQ_RTC_PERIOD_MSK,
> + .reg_offset = 0,
> + },
> + [RK805_IRQ_PWRON_FALL] = {
> + .mask = RK805_IRQ_PWRON_FALL_MSK,
> + .reg_offset = 0,
> + },
> +};
> +
>  static const struct regmap_irq rk808_irqs[] = {
>   /* INT_STS */
>   [RK808_IRQ_VOUT_LO]

sound: use-after-free in snd_seq_cell_alloc

2017-03-23 Thread Dmitry Vyukov
Hello,

I've got the following report while running syzkaller fuzzer on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Unfortunately this is not
reproducible so far.

==
BUG: KASAN: use-after-free in __lock_acquire+0x39df/0x3a80
kernel/locking/lockdep.c:3230 at addr 8800495fb6a0
Read of size 8 by task syz-executor7/17253
CPU: 2 PID: 17253 Comm: syz-executor7 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:337
 __lock_acquire+0x39df/0x3a80 kernel/locking/lockdep.c:3230
 lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x9f/0xd0 kernel/locking/spinlock.c:159
 snd_seq_cell_alloc.isra.1+0x17d/0x6a0 sound/core/seq/seq_memory.c:238
 snd_seq_event_dup+0x15d/0xa00 sound/core/seq/seq_memory.c:309
 snd_seq_fifo_event_in+0xe3/0x420 sound/core/seq/seq_fifo.c:128
 snd_seq_deliver_single_event.constprop.12+0x814/0x980
sound/core/seq/seq_clientmgr.c:615
 snd_seq_deliver_event+0x12c/0x720 sound/core/seq/seq_clientmgr.c:818
 snd_seq_kernel_client_dispatch+0x131/0x160 sound/core/seq/seq_clientmgr.c:2319
 snd_seq_system_notify+0x11b/0x160 sound/core/seq/seq_system.c:112
 snd_seq_client_notify_subscription+0x16f/0x210
sound/core/seq/seq_clientmgr.c:1414
 subscribe_port sound/core/seq/seq_ports.c:434 [inline]
 check_and_subscribe_port+0x725/0x950 sound/core/seq/seq_ports.c:510
 snd_seq_port_connect+0x3e5/0x700 sound/core/seq/seq_ports.c:579
 snd_seq_ioctl_subscribe_port+0x24b/0x300 sound/core/seq/seq_clientmgr.c:1443
 snd_seq_kernel_client_ctl+0x122/0x160 sound/core/seq/seq_clientmgr.c:2350
 snd_seq_oss_midi_open+0x640/0x850 sound/core/seq/oss/seq_oss_midi.c:375
 snd_seq_oss_synth_setup_midi+0x109/0x4d0 sound/core/seq/oss/seq_oss_synth.c:281
 snd_seq_oss_open+0x70f/0x8b0 sound/core/seq/oss/seq_oss_init.c:274
 odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
 soundcore_open+0x321/0x630 sound/sound_core.c:639
 chrdev_open+0x257/0x730 fs/char_dev.c:392
 do_dentry_open+0x710/0xc80 fs/open.c:751
 vfs_open+0x105/0x220 fs/open.c:864
 do_last fs/namei.c:3349 [inline]
 path_openat+0x1151/0x35b0 fs/namei.c:3490
 do_filp_open+0x249/0x370 fs/namei.c:3525
 do_sys_open+0x502/0x6d0 fs/open.c:1051
 SYSC_openat fs/open.c:1078 [inline]
 SyS_openat+0x30/0x40 fs/open.c:1072
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f02452a6858 EFLAGS: 0292 ORIG_RAX: 0101
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX:  RSI: 20063ff0 RDI: ff9c
RBP: 0086 R08:  R09: 
R10:  R11: 0292 R12: 006e0fe0
R13: 1000 R14: 0003 R15: 2000
Object at 8800495fb600, in cache kmalloc-192 size: 192
Allocated:
PID = 17260
 kmalloc include/linux/slab.h:490 [inline]
 kzalloc include/linux/slab.h:663 [inline]
 snd_seq_pool_new+0x93/0x2f0 sound/core/seq/seq_memory.c:470
 snd_seq_fifo_new+0xc3/0x360 sound/core/seq/seq_fifo.c:41
 snd_seq_open+0x404/0x520 sound/core/seq/seq_clientmgr.c:333
 snd_open+0x1fa/0x3f0 sound/core/sound.c:177
 chrdev_open+0x257/0x730 fs/char_dev.c:392
 do_dentry_open+0x710/0xc80 fs/open.c:751
 vfs_open+0x105/0x220 fs/open.c:864
 do_last fs/namei.c:3349 [inline]
 path_openat+0x1151/0x35b0 fs/namei.c:3490
 do_filp_open+0x249/0x370 fs/namei.c:3525
 do_sys_open+0x502/0x6d0 fs/open.c:1051
 SYSC_open fs/open.c:1069 [inline]
 SyS_open+0x2d/0x40 fs/open.c:1064
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 17280
 kfree+0xd7/0x250 mm/slab.c:3831
 snd_seq_pool_delete+0x52/0x70 sound/core/seq/seq_memory.c:498
 snd_seq_fifo_resize+0x263/0x3e0 sound/core/seq/seq_fifo.c:275
 snd_seq_ioctl_set_client_pool+0x481/0x600 sound/core/seq/seq_clientmgr.c:1849
 snd_seq_ioctl+0x204/0x470 sound/core/seq/seq_clientmgr.c:2131
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Memory state around the buggy address:
 8800495fb580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
 8800495fb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>8800495fb680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
   ^
 8800495fb700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 8800495fb780: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==


[PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

2017-03-23 Thread Colin King
From: Colin Ian King 

info is being checked to see if it is a null pointer, however, vpgu is
dereferencing info before this check, leading to a potential null
pointer dereference.  If info is null, then the error message being
printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
use a null vpgu as the macro has a sanity check to see if vpgu is null,
so this is OK.

Detected with CoverityScan, CID#1420672 ("Dereference nefore null check")

Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 1ea3eb270de8..f8619a772c44 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1339,9 +1339,9 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
 
 static bool kvmgt_guest_exit(struct kvmgt_guest_info *info)
 {
-   struct intel_vgpu *vgpu = info->vgpu;
-
if (!info) {
+   struct intel_vgpu *vgpu = NULL;
+
gvt_vgpu_err("kvmgt_guest_info invalid\n");
return false;
}
-- 
2.11.0



Re: [PATCH 0/7] Misc GDT fixes and a cleanup

2017-03-23 Thread Boris Ostrovsky
On 03/22/2017 05:32 PM, Andy Lutomirski wrote:
> Hi all-
>
> This applies to tip:x86/mm.  For ease of testing, the series is here, too:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/tag/?h=review_20170322_gdt_and_wp
>
> This fixes a few issues, most of which appear to be rather old.  For
> whatever reason, Thomas' GDT series unearthed them.  (And one is a
> genuine bug in Thomas' code but, in his defense, he might have
> cut-and-pasted it verbatim from the identical bug in the EFI code.)
>
> The last three patches are cleanups I did while tracking these down.
>
> Boris, any chance you could test this series on Xen?  The 64-bit
> case works for me, but I'm having issues testing on 32-bit right
> now.

Yes, this is all good. Tests passed.

-boris



usb: use-after-free write in usb_hcd_link_urb_to_ep

2017-03-23 Thread Dmitry Vyukov
Hello,

I've got the following report while running syzkaller fuzzer on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected
kmalloc failure, most likely it's the root cause.

FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 0 PID: 3348 Comm: syz-executor7 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 __do_kmalloc mm/slab.c:3734 [inline]
 __kmalloc+0x220/0x730 mm/slab.c:3745
 kmalloc include/linux/slab.h:495 [inline]
 kzalloc include/linux/slab.h:663 [inline]
 rh_call_control drivers/usb/core/hcd.c:522 [inline]
 rh_urb_enqueue drivers/usb/core/hcd.c:843 [inline]
 usb_hcd_submit_urb+0x693/0x1e40 drivers/usb/core/hcd.c:1646
 usb_submit_urb+0x8d4/0x1030 drivers/usb/core/urb.c:542
 usb_start_wait_urb+0x135/0x320 drivers/usb/core/message.c:56
 usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
 usb_control_msg+0x330/0x460 drivers/usb/core/message.c:151
 get_port_status drivers/usb/core/hub.c:554 [inline]
 hub_ext_port_status+0x122/0x440 drivers/usb/core/hub.c:571
 hub_port_status drivers/usb/core/hub.c:593 [inline]
 hub_activate+0x3ea/0x1650 drivers/usb/core/hub.c:1068
 hub_resume+0x3c/0x50 drivers/usb/core/hub.c:3595
 usb_resume_interface.isra.5+0x149/0x380 drivers/usb/core/driver.c:1260
 usb_resume_both+0x1c2/0x710 drivers/usb/core/driver.c:1402
 usb_runtime_resume+0x1e/0x30 drivers/usb/core/driver.c:1856
 __rpm_callback+0x338/0xa50 drivers/base/power/runtime.c:334
 rpm_callback+0x18a/0x220 drivers/base/power/runtime.c:464
 rpm_resume+0xe9d/0x1880 drivers/base/power/runtime.c:818
 __pm_runtime_resume+0xa2/0x130 drivers/base/power/runtime.c:1039
 pm_runtime_get_sync include/linux/pm_runtime.h:237 [inline]
 usb_autoresume_device+0x23/0x60 drivers/usb/core/driver.c:1581
 usbdev_open+0x25b/0xa50 drivers/usb/core/devio.c:1011
 chrdev_open+0x257/0x730 fs/char_dev.c:392
 do_dentry_open+0x710/0xc80 fs/open.c:751
 vfs_open+0x105/0x220 fs/open.c:864
 do_last fs/namei.c:3349 [inline]
 path_openat+0x1151/0x35b0 fs/namei.c:3490
 do_filp_open+0x249/0x370 fs/namei.c:3525
 do_sys_open+0x502/0x6d0 fs/open.c:1051
 SYSC_open fs/open.c:1069 [inline]
 SyS_open+0x2d/0x40 fs/open.c:1064
 entry_SYSCALL_64_fastpath+0x1f/0xc2
==
BUG: KASAN: use-after-free in __list_add_valid+0xc6/0xd0
lib/list_debug.c:26 at addr 88003c377a20
Read of size 8 by task syz-executor7/3348
CPU: 3 PID: 3348 Comm: syz-executor7 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:166
 print_address_description mm/kasan/report.c:210 [inline]
 kasan_report_error mm/kasan/report.c:294 [inline]
 kasan_report.part.2+0x1be/0x480 mm/kasan/report.c:316
 kasan_report mm/kasan/report.c:337 [inline]
 __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:337
 __list_add_valid+0xc6/0xd0 lib/list_debug.c:26
 __list_add include/linux/list.h:59 [inline]
 list_add_tail include/linux/list.h:92 [inline]
 usb_hcd_link_urb_to_ep+0x281/0x4e0 drivers/usb/core/hcd.c:1275
 rh_call_control drivers/usb/core/hcd.c:502 [inline]
 rh_urb_enqueue drivers/usb/core/hcd.c:843 [inline]
 usb_hcd_submit_urb+0x403/0x1e40 drivers/usb/core/hcd.c:1646
 usb_submit_urb+0x8d4/0x1030 drivers/usb/core/urb.c:542
 usb_start_wait_urb+0x135/0x320 drivers/usb/core/message.c:56
 usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
 usb_control_msg+0x330/0x460 drivers/usb/core/message.c:151
 get_port_status drivers/usb/core/hub.c:554 [inline]
 hub_ext_port_status+0x122/0x440 drivers/usb/core/hub.c:571
 hub_port_status drivers/usb/core/hub.c:593 [inline]
 hub_activate+0x3ea/0x1650 drivers/usb/core/hub.c:1068
 hub_resume+0x3c/0x50 drivers/usb/core/hub.c:3595
 usb_resume_interface.isra.5+0x149/0x380 drivers/usb/core/driver.c:1260
 usb_resume_both+0x1c2/0x710 drivers/usb/core/driver.c:1402
 usb_runtime_resume+0x1e/0x30 drivers/usb/core/driver.c:1856
 __rpm_callback+0x338/0xa50 drivers/base/power/runtime.c:334
 rpm_callback+0x18a/0x220 drivers/base/power/runtime.c:464
 rpm_resume+0xe9d/0x1880 drivers/base/power/runtime.c:818
 __pm_runtime_resume+0xa2/0x130 drivers/base/power/runtime.c:1039
 pm_runtime_get_sync include/linux/pm_runtime.h:237 [inline]
 usb_autoresume_device+0x23/0x60 drivers/usb/core/driver.c:1581
 usbdev_open+0x25b/0xa50 drivers/usb/core/devio.c:1011
 chrdev_open+0x257/0x730 fs/char_dev.c:392
 do_dentry_open+0x710/0xc80 fs/open.c:751
 vfs_open+0x105/0x220 fs/open.c:864
 do_last fs

Re: [PATCH v4 2/7] mfd: rk808: add rk805 regs addr and ID

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Elaine Zhang wrote:

> Signed-off-by: Elaine Zhang 
> ---
>  include/linux/mfd/rk808.h | 119 
> ++
>  1 file changed, 119 insertions(+)
> 
> diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
> index 54feb140c210..a133309b52f9 100644
> --- a/include/linux/mfd/rk808.h
> +++ b/include/linux/mfd/rk808.h
> @@ -206,6 +206,96 @@ enum rk818_reg {
>  #define RK818_USB_ILMIN_2000MA   0x7
>  #define RK818_USB_CHG_SD_VSEL_MASK   0x70
>  
> +/* RK805 */
> +enum rk805_reg {
> + RK805_ID_DCDC1,
> + RK805_ID_DCDC2,
> + RK805_ID_DCDC3,
> + RK805_ID_DCDC4,
> + RK805_ID_LDO1,
> + RK805_ID_LDO2,
> + RK805_ID_LDO3,
> +};
> +
> +/* INTERRUPT REGISTER */
> +#define RK805_INT_STS_REG0x4C
> +#define RK805_INT_STS_MSK_REG0x4D
> +#define RK805_GPIO_IO_POL_REG0x50
> +#define RK805_OUT_REG0x52
> +#define RK805_ON_SOURCE_REG  0xAE
> +#define RK805_OFF_SOURCE_REG 0xAF
> +
> +/* POWER CHANNELS ENABLE REGISTER */
> +#define RK805_DCDC_EN_REG0x23
> +#define RK805_SLP_DCDC_EN_REG0x25
> +#define RK805_SLP_LDO_EN_REG 0x26
> +#define RK805_LDO_EN_REG 0x27
> +
> +/* CONFIG REGISTER */
> +#define RK805_THERMAL_REG0x22
> +
> +/* BUCK AND LDO CONFIG REGISTER */
> +#define RK805_BUCK_LDO_SLP_LP_EN_REG 0x2A
> +#define RK805_BUCK1_CONFIG_REG   0x2E
> +#define RK805_BUCK1_ON_VSEL_REG  0x2F
> +#define RK805_BUCK1_SLP_VSEL_REG 0x30
> +#define RK805_BUCK2_CONFIG_REG   0x32
> +#define RK805_BUCK2_ON_VSEL_REG  0x33
> +#define RK805_BUCK2_SLP_VSEL_REG 0x34
> +#define RK805_BUCK3_CONFIG_REG   0x36
> +#define RK805_BUCK4_CONFIG_REG   0x37
> +#define RK805_BUCK4_ON_VSEL_REG  0x38
> +#define RK805_BUCK4_SLP_VSEL_REG 0x39
> +#define RK805_LDO1_ON_VSEL_REG   0x3B
> +#define RK805_LDO1_SLP_VSEL_REG  0x3C
> +#define RK805_LDO2_ON_VSEL_REG   0x3D
> +#define RK805_LDO2_SLP_VSEL_REG  0x3E
> +#define RK805_LDO3_ON_VSEL_REG   0x3F
> +#define RK805_LDO3_SLP_VSEL_REG  0x40
> +#define RK805_OUT_REG0x52
> +#define RK805_ON_SOURCE_REG  0xAE
> +#define RK805_OFF_SOURCE_REG 0xAF

Why aren't all of these in numerical order?

> +#define RK805_NUM_REGULATORS 7
> +
> +#define RK805_PWRON_FALL_RISE_INT_EN 0x0
> +#define RK805_PWRON_FALL_RISE_INT_MSK0x81
> +
> +/* RK805 IRQ Definitions */
> +#define RK805_IRQ_PWRON_RISE 0
> +#define RK805_IRQ_VB_LOW 1
> +#define RK805_IRQ_PWRON  2
> +#define RK805_IRQ_PWRON_LP   3
> +#define RK805_IRQ_HOTDIE 4
> +#define RK805_IRQ_RTC_ALARM  5
> +#define RK805_IRQ_RTC_PERIOD 6
> +#define RK805_IRQ_PWRON_FALL 7
> +
> +#define RK805_IRQ_PWRON_RISE_MSK BIT(0)
> +#define RK805_IRQ_VB_LOW_MSK BIT(1)
> +#define RK805_IRQ_PWRON_MSK  BIT(2)
> +#define RK805_IRQ_PWRON_LP_MSK   BIT(3)
> +#define RK805_IRQ_HOTDIE_MSK BIT(4)
> +#define RK805_IRQ_RTC_ALARM_MSK  BIT(5)
> +#define RK805_IRQ_RTC_PERIOD_MSK BIT(6)
> +#define RK805_IRQ_PWRON_FALL_MSK BIT(7)
> +
> +#define RK805_PWR_RISE_INT_STATUSBIT(0)
> +#define RK805_VB_LOW_INT_STATUS  BIT(1)
> +#define RK805_PWRON_INT_STATUS   BIT(2)
> +#define RK805_PWRON_LP_INT_STATUSBIT(3)
> +#define RK805_HOTDIE_INT_STATUS  BIT(4)
> +#define RK805_ALARM_INT_STATUS   BIT(5)
> +#define RK805_PERIOD_INT_STATUS  BIT(6)
> +#define RK805_PWR_FALL_INT_STATUSBIT(7)
> +
> +#define RK805_BUCK1_2_ILMAX_MASK (3 << 6)
> +#define RK805_BUCK3_4_ILMAX_MASK(3 << 3)
> +#define RK805_RTC_PERIOD_INT_MASK(1 << 6)
> +#define RK805_RTC_ALARM_INT_MASK (1 << 5)
> +#define RK805_INT_ALARM_EN   (1 << 3)
> +#define RK805_INT_TIMER_EN   (1 << 2)
> +
>  /* RK808 IRQ Definitions */
>  #define RK808_IRQ_VOUT_LO0
>  #define RK808_IRQ_VB_LO  1
> @@ -298,7 +388,14 @@ enum rk818_reg {
>  #define VOUT_LO_INT  BIT(0)
>  #define CLK32KOUT2_ENBIT(0)
>  
> +#define TEMP115C 0x0c
> +#define TEMP_HOTDIE_MSK  0x0c
> +#define SLP_SD_MSK   (0x3 << 2)
> +#define SHUTDOWN_FUN (0x2 << 2)
> +#define SLEEP_FUN(0x1 << 2)
>  #define RK8XX_ID_MSK 0xfff0
> +#define FPWM_MODEBIT(7)
> +
>  enum {
>   BUCK_ILMIN_50MA,
>   BUCK_ILMIN_100MA,
> @@ -322,6 +419,28 @@ enum {
>  };
>  
>  enum {
> + RK805_BUCK1_2_ILMAX_2500MA,
> + RK805_BUCK1_2_ILMAX_3000MA,
> + RK805_BUCK1_2_ILMAX_3500MA,
> + RK805_BUCK1_2_ILMAX_4000MA,
> +};
> +
> +enum {
> + RK805_BUCK3_ILMAX_1500MA,
> + RK805_B

Re: [PATCH 1/2] tty: serial_core: Add name field to uart_port struct

2017-03-23 Thread Vignesh R


On Thursday 23 March 2017 12:15 AM, Andy Shevchenko wrote:
> On Tue, Mar 21, 2017 at 3:36 PM, Vignesh R  wrote:
>> Introduce a field to store name of uart_port that can be used to easily
>> identify uart port instances on a system that has more than one uart
> 
> uart -> UART
> 
>> instance. The name is of the form ttyXN(eg. ttyS0, ttyAMA0,..) where N
>> is number that particular uart instance.
>> This field will be useful when printing debug info for a particular port
>> or in register irqs with unique irq name. Port name is populated during
> 
> irq(s) -> IRQ(s)
> 
>> uart_add_one_port().
> 
>> +   snprintf(uport->name, sizeof(uport->name), "%s%d", drv->dev_name,
>> +drv->tty_driver->name_base + uport->line);
> 
> This is fragile. dev_name is defined as pointer, so, it would be any length.
> So, better to use [devm_]kasprintf().
> 

Ok, will you use kasprintf() (and corresponding kfree()) as device is
not yet allocated at this stage to use devm_*.

-- 
Regards
Vignesh


Re: [PATCH v4 1/7] mfd: rk808: fix up the chip id get failed

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Elaine Zhang wrote:

> the rk8xx chip id is:
> ((MSB << 8) | LSB) & 0xfff0
> 
> Signed-off-by: Elaine Zhang 
> ---
>  drivers/mfd/rk808.c   | 21 +++--
>  include/linux/mfd/rk808.h |  1 +
>  2 files changed, 16 insertions(+), 6 deletions(-)

For my own reference:
  Acked-for-MFD-by: Lee Jones 
  
> diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
> index fd087cbb0bde..3334a2a7f3fb 100644
> --- a/drivers/mfd/rk808.c
> +++ b/drivers/mfd/rk808.c
> @@ -325,7 +325,7 @@ static int rk808_probe(struct i2c_client *client,
>   void (*pm_pwroff_fn)(void);
>   int nr_pre_init_regs;
>   int nr_cells;
> - int pm_off = 0;
> + int pm_off = 0, msb, lsb;
>   int ret;
>   int i;
>  
> @@ -333,14 +333,23 @@ static int rk808_probe(struct i2c_client *client,
>   if (!rk808)
>   return -ENOMEM;
>  
> - rk808->variant = i2c_smbus_read_word_data(client, RK808_ID_MSB);
> - if (rk808->variant < 0) {
> - dev_err(&client->dev, "Failed to read the chip id at 0x%02x\n",
> + /* read Chip variant */
> + msb = i2c_smbus_read_byte_data(client, RK808_ID_MSB);
> + if (msb < 0) {
> + dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
>   RK808_ID_MSB);
> - return rk808->variant;
> + return msb;
>   }
>  
> - dev_dbg(&client->dev, "Chip id: 0x%x\n", (unsigned int)rk808->variant);
> + lsb = i2c_smbus_read_byte_data(client, RK808_ID_LSB);
> + if (lsb < 0) {
> + dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
> + RK808_ID_LSB);
> + return lsb;
> + }
> +
> + rk808->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
> + dev_info(&client->dev, "Chip id: 0x%x\n", (unsigned int)rk808->variant);
>  
>   switch (rk808->variant) {
>   case RK808_ID:
> diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
> index 83701ef7d3c7..54feb140c210 100644
> --- a/include/linux/mfd/rk808.h
> +++ b/include/linux/mfd/rk808.h
> @@ -298,6 +298,7 @@ enum rk818_reg {
>  #define VOUT_LO_INT  BIT(0)
>  #define CLK32KOUT2_ENBIT(0)
>  
> +#define RK8XX_ID_MSK 0xfff0
>  enum {
>   BUCK_ILMIN_50MA,
>   BUCK_ILMIN_100MA,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v3 2/3] mfd: intel_soc_pmic_bxtwc: Move inclusion to c-file

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Andy Shevchenko wrote:

> There is no need to include intel_soc_pmic.h into header which doesn't
> require it.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/intel_soc_pmic_bxtwc.c | 1 +
>  include/linux/mfd/intel_bxtwc.h| 2 --
>  2 files changed, 1 insertion(+), 2 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
> b/drivers/mfd/intel_soc_pmic_bxtwc.c
> index 699c8c7c9052..c71db687b7ca 100644
> --- a/drivers/mfd/intel_soc_pmic_bxtwc.c
> +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /* PMIC device registers */
> diff --git a/include/linux/mfd/intel_bxtwc.h b/include/linux/mfd/intel_bxtwc.h
> index 1a0ee9d6efe9..240d6752ec64 100644
> --- a/include/linux/mfd/intel_bxtwc.h
> +++ b/include/linux/mfd/intel_bxtwc.h
> @@ -13,8 +13,6 @@
>   * more details.
>   */
>  
> -#include 
> -
>  #ifndef __INTEL_BXTWC_H__
>  #define __INTEL_BXTWC_H__
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v3 3/3] mfd: intel_soc_pmic_bxtwc: Rename header to follow c-file

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Andy Shevchenko wrote:

> For better understanding of relationship between headers and modules
> rename:
>   intel_bxtwc.h -> intel_soc_pmic_bxtwc.h
> 
> While here, remove file name from the file itself.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/intel_soc_pmic_bxtwc.c  | 2 +-
>  include/linux/mfd/{intel_bxtwc.h => intel_soc_pmic_bxtwc.h} | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>  rename include/linux/mfd/{intel_bxtwc.h => intel_soc_pmic_bxtwc.h} (96%)

Applied, thanks.

> diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
> b/drivers/mfd/intel_soc_pmic_bxtwc.c
> index c71db687b7ca..1496a862baa6 100644
> --- a/drivers/mfd/intel_soc_pmic_bxtwc.c
> +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
> @@ -20,8 +20,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
>  
>  /* PMIC device registers */
> diff --git a/include/linux/mfd/intel_bxtwc.h 
> b/include/linux/mfd/intel_soc_pmic_bxtwc.h
> similarity index 96%
> rename from include/linux/mfd/intel_bxtwc.h
> rename to include/linux/mfd/intel_soc_pmic_bxtwc.h
> index 240d6752ec64..0c351bc85d2d 100644
> --- a/include/linux/mfd/intel_bxtwc.h
> +++ b/include/linux/mfd/intel_soc_pmic_bxtwc.h
> @@ -1,5 +1,5 @@
>  /*
> - * intel_bxtwc.h - Header file for Intel Broxton Whiskey Cove PMIC
> + * Header file for Intel Broxton Whiskey Cove PMIC
>   *
>   * Copyright (C) 2015 Intel Corporation. All rights reserved.
>   *

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH] ARM: gemini: don't select SERIAL_OF_PLATFORM

2017-03-23 Thread Arnd Bergmann
On Thu, Mar 23, 2017 at 11:22 AM, Linus Walleij
 wrote:
> On Tue, Mar 21, 2017 at 9:52 PM, Arnd Bergmann  wrote:
>
>> We cannot select the option when SERIAL_8250 is not also set:
>>
>> warning: (ARCH_GEMINI) selects SERIAL_OF_PLATFORM which has unmet direct 
>> dependencies (TTY && HAS_IOMEM && SERIAL_8250 && OF)
>>
>> This removes the 'select' statement, requiring that users enable the
>> option manually. Alternatively, we could make it a conditional
>> 'select SERIAL_OF_PLATFORM if SERIAL_8250' or also select a handful
>> of other symbols that it depends on.
>>
>> Signed-off-by: Arnd Bergmann 
>
> Reviewed-by: Linus Walleij 
>
> Will you apply this directly to the interestingly misspelled
> "gemeni/multiplatform" branch in the ARM SoC tree
> directly?
>
> I will send pull requests on top of that branch later
> for more features.

If you are going to send more pull requests, just add the fixup there,
it's not urgent.

  Arnd


Re: [PATCH] blk-mq: don't complete un-started request in timeout handler

2017-03-23 Thread Ming Lei
On Wed, Mar 22, 2017 at 11:58:17AM -0400, Keith Busch wrote:
> On Tue, Mar 21, 2017 at 11:03:59PM -0400, Jens Axboe wrote:
> > On 03/21/2017 10:14 PM, Ming Lei wrote:
> > > When iterating busy requests in timeout handler,
> > > if the STARTED flag of one request isn't set, that means
> > > the request is being processed in block layer or driver, and
> > > isn't submitted to hardware yet.
> > > 
> > > In current implementation of blk_mq_check_expired(),
> > > if the request queue becomes dying, un-started requests are
> > > handled as being completed/freed immediately. This way is
> > > wrong, and can cause rq corruption or double allocation[1][2],
> > > when doing I/O and removing&resetting NVMe device at the sametime.
> > 
> > I agree, completing it looks bogus. If the request is in a scheduler or
> > on a software queue, this won't end well at all. Looks like it was
> > introduced by this patch:
> > 
> > commit eb130dbfc40eabcd4e10797310bda6b9f6dd7e76
> > Author: Keith Busch 
> > Date:   Thu Jan 8 08:59:53 2015 -0700
> > 
> > blk-mq: End unstarted requests on a dying queue
> > 
> > Before that, we just ignored it. Keith?
> 
> The above was intended for a stopped hctx on a dying queue such that
> there's nothing in flight to the driver. Nvme had been relying on this
> to end unstarted requests so we may progress when a controller dies.

So the brokenness started just from the begining.

> 
> We've since obviated the need: we restart the hw queues to flush entered
> requests to failure, so we don't need that brokenness.

Looks the following commit need to be backported too if we port this patch.

commit 69d9a99c258eb1d6478fd9608a2070890797eed7
Author: Keith Busch 
Date:   Wed Feb 24 09:15:56 2016 -0700

NVMe: Move error handling to failed reset handler
 

Thanks,
Ming


Re: [PATCH v3 1/3] mfd: intel_soc_pmic: Fix a mess with compilation units

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Andy Shevchenko wrote:

> Crystal Cove and Whiskey Cove are two different PMICs which are
> installed on Intel Atom SoC based platforms.
> 
> Moreover there are two independent drivers that by some reason were
> supposed (*) to get into one kernel module.
> 
> Fix the mess by clarifying Kconfig option for Crystal Cove and split
> Whiskey Cove out of it.
> 
> (*) It looks like the configuration was never tested with
> INTEL_SOC_PMIC=n. The line in Makefile is actually wrong.
> 
> Cc: "Rafael J. Wysocki"  (supporter:ACPI)
> Cc: Linus Walleij  (maintainer:GPIO SUBSYSTEM)
> Cc: Zhang Rui  (supporter:THERMAL)
> Cc: Eduardo Valentin  (supporter:THERMAL)
> Signed-off-by: Andy Shevchenko 
> ---
> - make option visible
> - fix dependencies
>  drivers/acpi/Kconfig |  2 +-

This needs an ACPI Ack before I can do anything with it.

>  drivers/gpio/Kconfig |  2 +-
>  drivers/mfd/Kconfig  | 14 --
>  drivers/mfd/Makefile |  2 +-
>  drivers/platform/x86/Kconfig |  2 +-
>  drivers/thermal/Kconfig  |  2 +-
>  6 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 83e5f7e1a20d..03708e08fcb4 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -512,7 +512,7 @@ config XPOWER_PMIC_OPREGION
>  
>  config BXT_WC_PMIC_OPREGION
>   bool "ACPI operation region support for BXT WhiskeyCove PMIC"
> - depends on INTEL_SOC_PMIC
> + depends on INTEL_SOC_PMIC_BXTWC
>   help
> This config adds ACPI operation region support for BXT WhiskeyCove 
> PMIC.
>  
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 05043071fc98..9b1bcb4d0df7 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1054,7 +1054,7 @@ config GPIO_UCB1400
>  
>  config GPIO_WHISKEY_COVE
>   tristate "GPIO support for Whiskey Cove PMIC"
> - depends on (X86 || COMPILE_TEST) && INTEL_SOC_PMIC
> + depends on (X86 || COMPILE_TEST) && INTEL_SOC_PMIC_BXTWC
>   select GPIOLIB_IRQCHIP
>   help
> Support for GPIO pins on Whiskey Cove PMIC.
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 55ecdfb74d31..e43afb8956ea 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -425,18 +425,28 @@ config LPC_SCH
> System Management Bus and General Purpose I/O.
>  
>  config INTEL_SOC_PMIC
> - bool "Support for Intel Atom SoC PMIC"
> + bool "Support for Crystal Cove PMIC"
>   depends on GPIOLIB
>   depends on I2C=y
>   select MFD_CORE
>   select REGMAP_I2C
>   select REGMAP_IRQ
>   help
> -   Select this option to enable support for the PMIC device
> +   Select this option to enable support for Crystal Cove PMIC
> on some Intel SoC systems. The PMIC provides ADC, GPIO,
> thermal, charger and related power management functions
> on these systems.
>  
> +config INTEL_SOC_PMIC_BXTWC
> + tristate "Support for Intel Broxton Whiskey Cove PMIC"
> + select MFD_CORE
> + select REGMAP_IRQ
> + help
> +   Select this option to enable support for Whiskey Cove PMIC
> +   on Intel Broxton systems. The PMIC provides ADC, GPIO,
> +   thermal, charger and related power management functions
> +   on these systems.
> +
>  config MFD_INTEL_LPSS
>   tristate
>   select COMMON_CLK
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 31ce07611a6f..201aeaf5112a 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -207,8 +207,8 @@ obj-$(CONFIG_MFD_RT5033)  += rt5033.o
>  obj-$(CONFIG_MFD_SKY81452)   += sky81452.o
>  
>  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
> -intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> +obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>  
>  obj-$(CONFIG_MFD_ALTERA_A10SR)   += altera-a10sr.o
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index e1bffc9bb194..883fbe7a2466 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -1019,7 +1019,7 @@ config INTEL_PMC_IPC
>  config INTEL_BXTWC_PMIC_TMU
>   tristate "Intel BXT Whiskey Cove TMU Driver"
>   depends on REGMAP
> - depends on INTEL_SOC_PMIC && INTEL_PMC_IPC
> + depends on INTEL_SOC_PMIC_BXTWC && INTEL_PMC_IPC
>   ---help---
> Select this driver to use Intel BXT Whiskey Cove PMIC TMU feature.
> This driver enables the alarm wakeup functionality in the TMU unit
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 776b34396144..751e50a3d946 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -365,7 +365,7 @@ endmenu
>  
>  config INTEL_BXT_PMIC_THERMAL
>   tristate "Intel Broxton PMIC thermal driver"
> - depends on X86 && 

Re: [PATCH 2/7] iommu/iova: cut down judgement times

2017-03-23 Thread Robin Murphy
On 22/03/17 06:27, Zhen Lei wrote:
> Below judgement can only be satisfied at the last time, which produced 2N
> judgements(suppose N times failed, 0 or 1 time successed) in vain.
> 
> if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) {
>   return iova;
> }

For me, GCC (6.2.1 AArch64) seems to do a pretty good job of this
function already, so this change only saves two instructions in total
(pfn is compared against pfn_lo only once instead of twice), which I
wouldn't expect to see a noticeable performance effect from.

Given the improvement in readability, though, I don't even care about
any codegen differences :)

Reviewed-by: Robin Murphy 

> Signed-off-by: Zhen Lei 
> ---
>  drivers/iommu/iova.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 8ba8b496..1c49969 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -312,15 +312,12 @@ private_find_iova(struct iova_domain *iovad, unsigned 
> long pfn)
>   while (node) {
>   struct iova *iova = rb_entry(node, struct iova, node);
>  
> - /* If pfn falls within iova's range, return iova */
> - if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) {
> - return iova;
> - }
> -
>   if (pfn < iova->pfn_lo)
>   node = node->rb_left;
> - else if (pfn > iova->pfn_lo)
> + else if (pfn > iova->pfn_hi)
>   node = node->rb_right;
> + else
> + return iova;/* pfn falls within iova's range */
>   }
>  
>   return NULL;
> 



Re: [RFC][PATCH 2/4] printk: offload printing from wake_up_klogd_work_func()

2017-03-23 Thread Petr Mladek
On Thu 2017-03-23 18:00:42, Sergey Senozhatsky wrote:
> On (03/20/17 17:09), Petr Mladek wrote:
> [..]
> > 
> > BTW: wake_up_klogd_work does not need to be per-CPU as well.
> > irq_work infrastructure heavily uses per-CPU variables.
> > But a global struct irq_work is safe, see irq_work_claim().
> 
> so I have a patch that turns wake_up_klogd_work into a global variable,
> out of curiosity, but I'm not entire sure about it. the sort of a problem
> is that queued irq_works still go into a per-CPU run_lists.  per-CPU
> wake_up_klogd_work permits us to queue irq work on several CPUs so we
> might have better chances to execute wake_up_klogd_work_func(), while
> global wake_up_klogd_work will be only in one run_list. this can defer
> wake_up_klogd_work processing until that particular single CPU handles
> its interrupt and calls irq_work_run_list(). what do you think?

Good question! I personally think that it should not cause a big harm
but I am not completely sure. It might need some more testing.

Let's postpone this change and do it alone in the future.

Best Regards,
Petr


net/kcm: double free of kcm inode

2017-03-23 Thread Dmitry Vyukov
Hello,

I've got the following report while running syzkaller fuzzer. Note the
preceding kmem_cache_alloc injected failure, it's most likely the root
cause.

FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 21839 Comm: syz-executor4 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
 sk_prot_alloc+0x65/0x2a0 net/core/sock.c:1331
 sk_alloc+0x8c/0x710 net/core/sock.c:1393
 kcm_clone net/kcm/kcmsock.c:1655 [inline]
 kcm_ioctl+0xb65/0x17e0 net/kcm/kcmsock.c:1713
 sock_do_ioctl+0x65/0xb0 net/socket.c:895
 sock_ioctl+0x2c2/0x440 net/socket.c:993
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f05eb28e858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 20001000 RSI: 89e2 RDI: 0005
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 004a7e31
R13:  R14: 7f05eb28e618 R15: 7f05eb28e788
==
BUG: KASAN: use-after-free in __fput+0x6b0/0x7f0 fs/file_table.c:211
at addr 880037a25670
Read of size 2 by task syz-executor4/21839
CPU: 1 PID: 21839 Comm: syz-executor4 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:166
 print_address_description mm/kasan/report.c:210 [inline]
 kasan_report_error mm/kasan/report.c:294 [inline]
 kasan_report.part.2+0x1be/0x480 mm/kasan/report.c:316
 kasan_report mm/kasan/report.c:335 [inline]
 __asan_report_load2_noabort+0x29/0x30 mm/kasan/report.c:335
 __fput+0x6b0/0x7f0 fs/file_table.c:211
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x1a4/0x270 kernel/task_work.c:116
 tracehook_notify_resume include/linux/tracehook.h:191 [inline]
 exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f05eb28e858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: fff4 RBX: 00708000 RCX: 00445b79
RDX: 20001000 RSI: 89e2 RDI: 0005
RBP: 2170 R08:  R09: 
R10:  R11: 0286 R12: 006e0230
R13: 89e2 R14: 20001000 R15: 0005
Object at 880037a25640, in cache sock_inode_cache size: 944
Allocated:
PID = 21839
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:517
 set_track mm/kasan/kasan.c:529 [inline]
 kasan_kmalloc+0xbc/0xf0 mm/kasan/kasan.c:620
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:559
 kmem_cache_alloc+0x110/0x720 mm/slab.c:3572
 sock_alloc_inode+0x70/0x300 net/socket.c:250
 alloc_inode+0x65/0x180 fs/inode.c:207
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 sock_alloc+0x41/0x270 net/socket.c:565
 kcm_clone net/kcm/kcmsock.c:1634 [inline]
 kcm_ioctl+0x990/0x17e0 net/kcm/kcmsock.c:1713
 sock_do_ioctl+0x65/0xb0 net/socket.c:895
 sock_ioctl+0x2c2/0x440 net/socket.c:993
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 21839
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:517
 set_track mm/kasan/kasan.c:529 [inline]
 kasan_slab_free+0x81/0xc0 mm/kasan/kasan.c:593
 __cache_free mm/slab.c:3514 [inline]
 kmem_cache_free+0x71/0x240 mm/slab.c:3774
 sock_destroy_inode+0x56/0x70 net/socket.c:280
 destroy_inode+0x15d/0x200 fs/inode.c:264
 evict+0x57e/0x920 fs/inode.c:570
 iput_final fs/inode.c:1515 [inline]
 iput+0x62b/0xa20 fs/inode.c:1542
 sock_release+0x168/0x1e0 net/socket.c:607
 sock_close+0x16/0x20 net/socket.c:1061
 __fput+0x327/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x1a4/0x270 kernel/task_work.c:116
 tracehook_notify_resume include/linux/tracehook.h:191 [inline]
 exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
 prepare_exit_to_usermode arch/x86/entry/co

Re: [PATCH] selinux: Remove unnecessary check of array base in selinux_set_mapping()

2017-03-23 Thread Paul Moore
On Wed, Mar 22, 2017 at 8:28 PM, Grant Grundler  wrote:
> Ping? Any feedback on this patch?

It's on my list of patches to review, patience please.

> On Thu, Mar 16, 2017 at 3:26 PM, Matthias Kaehlcke  wrote:
>>
>> 'perms' will never be NULL since it isn't a plain pointer but an array
>> of u32 values.
>>
>> This fixes the following warning when building with clang:
>>
>> security/selinux/ss/services.c:158:16: error: address of array
>> 'p_in->perms' will always evaluate to 'true'
>> [-Werror,-Wpointer-bool-conversion]
>> while (p_in->perms && p_in->perms[k]) {
>>
>> Signed-off-by: Matthias Kaehlcke 
>> ---
>>  security/selinux/ss/services.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/security/selinux/ss/services.c
>> b/security/selinux/ss/services.c
>> index 082b20c78363..2f20b5f974f4 100644
>> --- a/security/selinux/ss/services.c
>> +++ b/security/selinux/ss/services.c
>> @@ -155,7 +155,7 @@ static int selinux_set_mapping(struct policydb *pol,
>> }
>>
>> k = 0;
>> -   while (p_in->perms && p_in->perms[k]) {
>> +   while (p_in->perms[k]) {
>> /* An empty permission string skips ahead */
>> if (!*p_in->perms[k]) {
>> k++;
>> --
>> 2.12.0.367.g23dc2f6d3c-goog
>>
>



-- 
paul moore
www.paul-moore.com


Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

2017-03-23 Thread Geert Uytterhoeven
Hi Uwe,

On Thu, Mar 23, 2017 at 12:11 PM, Uwe Kleine-König
 wrote:
>> Make sure to enable all drivers and subsystems you need when building
>> your kernel. That's always true. And may indeed be hard to debug (e.g. what
>> kernel options do I need to make systemd work?).
>
> It's worse here. If you forget to enable a driver the device isn't bound
> and that's obvious to diagnose. When ignoring an optional GPIO there
> might be a device that claims to work but fails to do so. (e.g. you
> write to memory, write() returns 0, but the data never landed there.)
>
>> > write(2) and close(2) succeed most of the time, too. Still it's not a
>> > good idea to not check the return value. Or let the kernel return
>> > success unconditionally.
>>
>> Writing all bytes passed in the buffer is "optional" in another sense than
>> an "optional" GPIO: you must retry the write, while you can continue if
>> an optional GPIO is not present.
>
> And that is the point. You can continue *iff* the optional GPIO is not
> present. The patch in question removes the ability to determine if that
> GPIO is present and claims it is not present.

If you forget to enable a driver/subsystem, you sometimes cannot determine
if the device is present or not neither.

Hence it boils down to "knowing" if there is a GPIO or not.
So, when can there be a GPIO?
  1. The GPIO is described in DT.
 => Not an issue, as DT GPIO implies GPIOLIB,
  2. The GPIO is described in legacy platform data.
 => The platform code should make sure GPIOLIB is selected when needed.

Issue solved?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v4] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

2017-03-23 Thread David Hildenbrand
On 23.03.2017 03:39, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> This can be reproduced by running L2 on L1, and disable VPID on L0 
> if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 
> crash as below:
> 
> KVM: entry failed, hardware error 0x7
> EAX= EBX= ECX= EDX=000306c3
> ESI= EDI= EBP= ESP=
> EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =   9300
> CS =f000   9b00
> SS =   9300
> DS =   9300
> FS =   9300
> GS =   9300
> LDT=   8200
> TR =   8b00
> GDT=  
> IDT=  
> CR0=6010 CR2= CR3= CR4=
> DR0= DR1= DR2= 
> DR3= 
> DR6=0ff0 DR7=0400
> EFER=
> 
> Reference SDM 30.3 INVVPID:
>  
> Protected Mode Exceptions
> #UD 
>   - If not in VMX operation.
>   - If the logical processor does not support VPIDs 
> (IA32_VMX_PROCBASED_CTLS2[37]=0).
>   - If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1) 
> but does 
> not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).
> 
> So we should check both VPID enable bit in vmx exec control and INVVPID 
> support bit 
> in vmx capability MSRs to enable VPID. This patch adds the guarantee to not 
> enable VPID
> if INVVPID is not exposed in vmx capability MSRs.

You should change the subject and this description to also take the
single/global capability into account.

> 
> Reviewed-by: David Hildenbrand 
> Cc: Jim Mattson 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/vmx.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 8795a70..8925c76 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -1239,6 +1239,11 @@ static inline bool cpu_has_vmx_invvpid_global(void)
>   return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
>  }
>  
> +static inline bool cpu_has_vmx_invvpid(void)
> +{
> + return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
> +}
> +
>  static inline bool cpu_has_vmx_ept(void)
>  {
>   return vmcs_config.cpu_based_2nd_exec_ctrl &
> @@ -6518,8 +6523,10 @@ static __init int hardware_setup(void)
>   if (boot_cpu_has(X86_FEATURE_NX))
>   kvm_enable_efer_bits(EFER_NX);
>  
> - if (!cpu_has_vmx_vpid())
> + if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() ||
> + !cpu_has_vmx_invvpid_single() || !cpu_has_vmx_invvpid_global())

According to Jim

"KVM's vpid_sync_context() assumes that at least one of
{VMX_VPID_EXTENT_SINGLE_CONTEXT, VMX_VPID_EXTENT_ALL_CONTEXT} ..."

So we should only require one of these two, not both.

if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() ||
!(cpu_has_vmx_invvpid_single() || cpu_has_vmx_invvpid_global()))

>   enable_vpid = 0;
> +
>   if (!cpu_has_vmx_shadow_vmcs())
>   enable_shadow_vmcs = 0;
>   if (enable_shadow_vmcs)
> 


-- 

Thanks,

David


[PATCH] ASoC: WM8962: Let codec driver enable/disable its MCLK

2017-03-23 Thread Daniel Baluta
From: Nicolin Chen 

WM8962 needs its MCLK when powerup in wm8962_resume(). Thus it's better
to control the MCLK in codec driver. Thus remove the clock enable in
machine dirver accordingly.

While at it, get rid of imx_wm8962_remove function since it is now
empty.

Signed-off-by: Nicolin Chen 
Signed-off-by: Daniel Baluta 
---
 sound/soc/fsl/imx-wm8962.c | 40 
 1 file changed, 8 insertions(+), 32 deletions(-)

diff --git a/sound/soc/fsl/imx-wm8962.c b/sound/soc/fsl/imx-wm8962.c
index 1b60958..3d894d9 100644
--- a/sound/soc/fsl/imx-wm8962.c
+++ b/sound/soc/fsl/imx-wm8962.c
@@ -33,7 +33,6 @@ struct imx_wm8962_data {
struct snd_soc_card card;
char codec_dai_name[DAI_NAME_SIZE];
char platform_name[DAI_NAME_SIZE];
-   struct clk *codec_clk;
unsigned int clk_frequency;
 };
 
@@ -163,6 +162,7 @@ static int imx_wm8962_probe(struct platform_device *pdev)
struct imx_priv *priv = &card_priv;
struct i2c_client *codec_dev;
struct imx_wm8962_data *data;
+   struct clk *codec_clk;
int int_port, ext_port;
int ret;
 
@@ -231,19 +231,14 @@ static int imx_wm8962_probe(struct platform_device *pdev)
goto fail;
}
 
-   data->codec_clk = devm_clk_get(&codec_dev->dev, NULL);
-   if (IS_ERR(data->codec_clk)) {
-   ret = PTR_ERR(data->codec_clk);
+   codec_clk = devm_clk_get(&codec_dev->dev, NULL);
+   if (IS_ERR(codec_clk)) {
+   ret = PTR_ERR(codec_clk);
dev_err(&codec_dev->dev, "failed to get codec clk: %d\n", ret);
goto fail;
}
 
-   data->clk_frequency = clk_get_rate(data->codec_clk);
-   ret = clk_prepare_enable(data->codec_clk);
-   if (ret) {
-   dev_err(&codec_dev->dev, "failed to enable codec clk: %d\n", 
ret);
-   goto fail;
-   }
+   data->clk_frequency = clk_get_rate(codec_clk);
 
data->dai.name = "HiFi";
data->dai.stream_name = "HiFi";
@@ -258,10 +253,10 @@ static int imx_wm8962_probe(struct platform_device *pdev)
data->card.dev = &pdev->dev;
ret = snd_soc_of_parse_card_name(&data->card, "model");
if (ret)
-   goto clk_fail;
+   goto fail;
ret = snd_soc_of_parse_audio_routing(&data->card, "audio-routing");
if (ret)
-   goto clk_fail;
+   goto fail;
data->card.num_links = 1;
data->card.owner = THIS_MODULE;
data->card.dai_link = &data->dai;
@@ -277,16 +272,9 @@ static int imx_wm8962_probe(struct platform_device *pdev)
ret = devm_snd_soc_register_card(&pdev->dev, &data->card);
if (ret) {
dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret);
-   goto clk_fail;
+   goto fail;
}
 
-   of_node_put(ssi_np);
-   of_node_put(codec_np);
-
-   return 0;
-
-clk_fail:
-   clk_disable_unprepare(data->codec_clk);
 fail:
of_node_put(ssi_np);
of_node_put(codec_np);
@@ -294,17 +282,6 @@ static int imx_wm8962_probe(struct platform_device *pdev)
return ret;
 }
 
-static int imx_wm8962_remove(struct platform_device *pdev)
-{
-   struct snd_soc_card *card = platform_get_drvdata(pdev);
-   struct imx_wm8962_data *data = snd_soc_card_get_drvdata(card);
-
-   if (!IS_ERR(data->codec_clk))
-   clk_disable_unprepare(data->codec_clk);
-
-   return 0;
-}
-
 static const struct of_device_id imx_wm8962_dt_ids[] = {
{ .compatible = "fsl,imx-audio-wm8962", },
{ /* sentinel */ }
@@ -318,7 +295,6 @@ static struct platform_driver imx_wm8962_driver = {
.of_match_table = imx_wm8962_dt_ids,
},
.probe = imx_wm8962_probe,
-   .remove = imx_wm8962_remove,
 };
 module_platform_driver(imx_wm8962_driver);
 
-- 
2.7.4



Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

2017-03-23 Thread Daniel Stone
Hi Michel,

On 23 March 2017 at 08:53, Michel Dänzer  wrote:
> Otherwise this can also prevent modesets e.g. for switching VTs, when
> multiple monitors with different native resolutions are connected.
>
> The depths must match though, so keep the != test for that.
>
> Also update the DRM_DEBUG output to be slightly more accurate, this
> doesn't only affect requests from userspace.

This test looks much more sensible, and also fixes VT switching for me.

Reviewed-by: Daniel Stone 

Cheers,
Daniel


Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

2017-03-23 Thread Petr Mladek
On Wed 2017-03-22 18:59:20, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 09:45:50PM +0900, Sergey Senozhatsky wrote:
> >  sysrq is potentially even trickier. can we always wake_up() kernel
> >  thread from sysrq? there probably might be cases when we can't rely
> >  on the scheduler.
> 
> sysrq runs from interrupt context, right? Should be able to do wakeups.

It would make sense to actually switch to the old mode when
handling sysrq. At least for some requests that are used
for debugging when the system is not responsible.

It is pity that it is the irq context that is prone to
softlocks. But this might be the only way to actually
see the messages.

Tetsuo already suggested to use the old mode for SysRq-t, see
https://lkml.kernel.org/r/201612261954.fje69201.oflvtfjsqfo...@i-love.sakura.ne.jp

Best Regards,
Petr


Re: [PATCH v6 2/2] soc/imx: Add GPCv2 power gating driver

2017-03-23 Thread Dong Aisheng
On Mon, Mar 20, 2017 at 01:34:19PM -0700, Andrey Smirnov wrote:
> On Mon, Mar 20, 2017 at 12:03 AM, Dong Aisheng  wrote:
> > On Thu, Mar 16, 2017 at 06:30:50AM -0700, Andrey Smirnov wrote:
> >> Add code allowing for control of various power domains managed by GPCv2
> >> IP block found in i.MX7 series of SoCs. Power domains covered by this
> >> patch are:
> >>
> >> - PCIE PHY
> >> - MIPI PHY
> >> - USB HSIC PHY
> >> - USB OTG1/2 PHY
> >>
> >> Support for any other power domain controlled by GPC is not present, and
> >> can be added at some later point.
> >>
> >> Testing of this code was done against a PCIe driver.
> >>
> >> Cc: yurov...@gmail.com
> >> Cc: Lucas Stach 
> >> Cc: Fabio Estevam 
> >> Cc: linux-arm-ker...@lists.infradead.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Signed-off-by: Andrey Smirnov 
> >> ---
> >>  drivers/soc/Kconfig  |   1 +
> >>  drivers/soc/imx/Kconfig  |  10 ++
> >>  drivers/soc/imx/Makefile |   1 +
> >>  drivers/soc/imx/gpcv2.c  | 385 
> >> +++
> >
> > Personally i'd like more naming gpc-imx7.c since gpcv2 is too generic,
> > and actually you also mix using imx7d name below.
> >
> 
> This IP block is already referenced as GPCv2 in
> drivers/irqchip/irq-imx-gpcv2.c, so IMHO re-naming it to gpc-imx7
> would be confusing.
> 

Okay, i see.

I got a NXP internal GPC block guide which also names it as GPCv2.
So internally we call it GPCv2.
And we can still grep two GPCv2 in RM, although most has been
changed to GPC.

Due to above reasons and to stop the bothering, i think we can
use the name as it is now to make things keep going.

> > And AFAIK only MX7 will use this new driver.
> >
> > Probably should also change the exist gpc to gpc-imx6.
> >
> >>  4 files changed, 397 insertions(+)
> >>  create mode 100644 drivers/soc/imx/Kconfig
> >>  create mode 100644 drivers/soc/imx/gpcv2.c
> >>
> >> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> >> index f31bceb..55a4eb8 100644
> >> --- a/drivers/soc/Kconfig
> >> +++ b/drivers/soc/Kconfig
> >> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
> >>
> >>  source "drivers/soc/bcm/Kconfig"
> >>  source "drivers/soc/fsl/Kconfig"
> >> +source "drivers/soc/imx/Kconfig"
> >>  source "drivers/soc/mediatek/Kconfig"
> >>  source "drivers/soc/qcom/Kconfig"
> >>  source "drivers/soc/rockchip/Kconfig"
> >> diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
> >> new file mode 100644
> >> index 000..bc7f0ee0
> >> --- /dev/null
> >> +++ b/drivers/soc/imx/Kconfig
> >> @@ -0,0 +1,10 @@
> >> +menu "i.MX SoC drivers"
> >> +
> >> +config IMX7_PM_DOMAINS
> >> + bool "i.MX7 PM domains"
> >> + select PM_GENERIC_DOMAINS
> >> + depends on SOC_IMX7D || (COMPILE_TEST && OF)
> >> + default y if SOC_IMX7D
> >> +
> >> +endmenu
> >> +
> >> diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
> >> index 35861f5..5b6e396 100644
> >> --- a/drivers/soc/imx/Makefile
> >> +++ b/drivers/soc/imx/Makefile
> >> @@ -1 +1,2 @@
> >>  obj-y += gpc.o
> >> +obj-$(CONFIG_IMX7_PM_DOMAINS) += gpcv2.o
> >> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> >> new file mode 100644
> >> index 000..73c58ca
> >> --- /dev/null
> >> +++ b/drivers/soc/imx/gpcv2.c
> >> @@ -0,0 +1,385 @@
> >> +/*
> >> + * Copyright 2017 Impinj, Inc
> >> + * Author: Andrey Smirnov 
> >> + *
> >> + * Based on the code of analogus driver:
> >> + *
> >> + * Copyright 2015-2017 Pengutronix, Lucas Stach 
> >> + *
> >> + * The code contained herein is licensed under the GNU General Public
> >> + * License. You may obtain a copy of the GNU General Public License
> >> + * Version 2 or later at the following locations:
> >> + *
> >> + * http://www.opensource.org/licenses/gpl-license.html
> >> + * http://www.gnu.org/copyleft/gpl.html
> >> + */
> >> +
> >> +#include 
> >
> > Where did you use it?
> 
> Not sure, I'll double check and drop it if it's unused.
> 
> >
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#define GPC_PGC_CPU_MAPPING  0xec
> >> +#define USB_HSIC_PHY_A7_DOMAIN   BIT(6)
> >> +#define USB_OTG2_PHY_A7_DOMAIN   BIT(5)
> >> +#define USB_OTG1_PHY_A7_DOMAIN   BIT(4)
> >> +#define PCIE_PHY_A7_DOMAIN   BIT(3)
> >> +#define MIPI_PHY_A7_DOMAIN   BIT(2)
> >> +
> >> +#define GPC_PU_PGC_SW_PUP_REQ0xf8
> >> +#define GPC_PU_PGC_SW_PDN_REQ0x104
> >> +#define USB_HSIC_PHY_SW_Pxx_REQ  BIT(4)
> >> +#define USB_OTG2_PHY_SW_Pxx_REQ  BIT(3)
> >> +#define USB_OTG1_PHY_SW_Pxx_REQ  BIT(2)
> >> +#define PCIE_PHY_SW_Pxx_REQ  BIT(1)
> >> +#define MIPI_PHY_SW_Pxx_REQ  BIT(0)
> >> +
> >> +#define GPC_MAX_REGISTER 0x1000
> >> +
> >> +#define GPC_PGC_nCTRL_PCRBIT(0)
> >> +
> >> +struct imx7_pgc_domain {
> >> + struct generic_pm_domain genpd;
> >> + struct regmap *regmap;
> >> + struct regulator *regulator;
> >> +
> >> + unsigned int pgc_nctrl;

Re: [PATCH] staging: tsl2x7x: Moved contents of the header to the source file.

2017-03-23 Thread Lars-Peter Clausen
On 03/23/2017 12:53 PM, Arushi Singhal wrote:
> Moved the contents of the header(tsl2x7x.h) into the source file
> tsl2x7x_core.c with the exception of the platform data struct which is
> supposed to be used from somewhere else other than the driver.

The platform_data struct uses the other structs though.


Re: [GIT PULL] Immutable branch between MFD and PHY due for the v4.12 merge window

2017-03-23 Thread Krzysztof Kozlowski
On Thu, Mar 23, 2017 at 12:51 PM, Lee Jones  wrote:
> Enjoy!
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
>   Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-phy-v4.12
>
> for you to fetch changes up to f7f6c060547c51691f9b943e6c33f63675c1a0a9:
>
>   mfd: exynos-lpass: Use common soc/exynos-regs-pmu.h header (2017-03-23 
> 10:47:27 +)
>
> 
> Immutable branch between MFD and PHY due for the v4.12 merge window
>
> 
> Krzysztof Kozlowski (1):
>   mfd: exynos-lpass: Use common soc/exynos-regs-pmu.h header
>
>  drivers/mfd/exynos-lpass.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Thanks.

Kishon,
This is the dependency for last patch in v4 of:
https://www.spinics.net/lists/arm-kernel/msg568609.html

Everything else is acked and ready for you to apply.

Any comments?

Best regards,
Krzysztof


[PATCH V2] i2c: tegra-bpmp: Enable Tegra BPMP I2C adapter

2017-03-23 Thread Jon Hunter
Enable the Tegra BPMP I2C adapter by default if the Tegra BPMP itself
is enabled. This adapter is used as the I2C interface for the PMIC on
the Tegra186 Jetson-TX2 platform.

Signed-off-by: Jon Hunter 
Acked-by: Thierry Reding 
---

Changes since V1:
- Dropped redundant 'if' condition from 'default' statement.

 drivers/i2c/busses/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 8adc0f1d7ad0..39c0ead2a6df 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -933,6 +933,7 @@ config I2C_TEGRA
 config I2C_TEGRA_BPMP
tristate "NVIDIA Tegra BPMP I2C controller"
depends on TEGRA_BPMP
+   default y
help
  If you say yes to this option, support will be included for the I2C
  controller embedded in NVIDIA Tegra SoCs accessed via the BPMP.
-- 
2.7.4



[PATCH] [media] coda: remove redundant call to v4l2_m2m_get_vq

2017-03-23 Thread Colin King
From: Colin Ian King 

The call to v4ls_m2m_get_vq is only used to get the return value
which is not being used, so it appears to be redundant and can
be removed.

Detected with CoverityScan, CID#1420674 ("Useless call")

Signed-off-by: Colin Ian King 
---
 drivers/media/platform/coda/coda-common.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 800d2477f1a0..95e4648f18e6 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -817,8 +817,6 @@ static int coda_qbuf(struct file *file, void *priv,
 static bool coda_buf_is_end_of_stream(struct coda_ctx *ctx,
  struct vb2_v4l2_buffer *buf)
 {
-   v4l2_m2m_get_vq(ctx->fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
-
return ((ctx->bit_stream_param & CODA_BIT_STREAM_END_FLAG) &&
(buf->sequence == (ctx->qsequence - 1)));
 }
-- 
2.11.0



[PATCH] staging: tsl2x7x: Moved contents of the header to the source file.

2017-03-23 Thread Arushi Singhal
Moved the contents of the header(tsl2x7x.h) into the source file
tsl2x7x_core.c with the exception of the platform data struct which is
supposed to be used from somewhere else other than the driver.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/iio/light/tsl2x7x.h  | 57 ---
 drivers/staging/iio/light/tsl2x7x_core.c | 58 
 2 files changed, 58 insertions(+), 57 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index ecae92211216..7b71003ddb33 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -23,63 +23,6 @@
 #define __TSL2X7X_H
 #include 
 
-/* Max number of segments allowable in LUX table */
-#define TSL2X7X_MAX_LUX_TABLE_SIZE 9
-#define MAX_DEFAULT_TABLE_BYTES (sizeof(int) * TSL2X7X_MAX_LUX_TABLE_SIZE)
-
-struct iio_dev;
-
-struct tsl2x7x_lux {
-   unsigned int ratio;
-   unsigned int ch0;
-   unsigned int ch1;
-};
-
-/**
- * struct tsl2x7x_default_settings - power on defaults unless
- *   overridden by platform data.
- *  @als_time:  ALS Integration time - multiple of 50mS
- *  @als_gain:  Index into the ALS gain table.
- *  @als_gain_trim: default gain trim to account for
- *  aperture effects.
- *  @wait_time: Time between PRX and ALS cycles
- *  in 2.7 periods
- *  @prx_time:  5.2ms prox integration time -
- *  decrease in 2.7ms periods
- *  @prx_gain:  Proximity gain index
- *  @prox_config:   Prox configuration filters.
- *  @als_cal_target:Known external ALS reading for
- *  calibration.
- *  @interrupts_en: Enable/Disable - 0x00 = none, 0x10 = als,
- *   0x20 = prx,  0x30 = bth
- *  @persistence:   H/W Filters, Number of 'out of limits'
- *  ADC readings PRX/ALS.
- *  @als_thresh_low:CH0 'low' count to trigger interrupt.
- *  @als_thresh_high:   CH0 'high' count to trigger interrupt.
- *  @prox_thres_low:Low threshold proximity detection.
- *  @prox_thres_high:   High threshold proximity detection
- *  @prox_pulse_count:  Number if proximity emitter pulses
- *  @prox_max_samples_cal:  Used for prox cal.
- */
-struct tsl2x7x_settings {
-   int als_time;
-   int als_gain;
-   int als_gain_trim;
-   int wait_time;
-   int prx_time;
-   int prox_gain;
-   int prox_config;
-   int als_cal_target;
-   u8  interrupts_en;
-   u8  persistence;
-   int als_thresh_low;
-   int als_thresh_high;
-   int prox_thres_low;
-   int prox_thres_high;
-   int prox_pulse_count;
-   int prox_max_samples_cal;
-};
-
 /**
  * struct tsl2X7X_platform_data - Platform callback, glass and defaults
  * @platform_power:Suspend/resume platform callback
diff --git a/drivers/staging/iio/light/tsl2x7x_core.c 
b/drivers/staging/iio/light/tsl2x7x_core.c
index ea15bc1c300c..21cbf7e95c4e 100644
--- a/drivers/staging/iio/light/tsl2x7x_core.c
+++ b/drivers/staging/iio/light/tsl2x7x_core.c
@@ -32,6 +32,64 @@
 #include 
 #include "tsl2x7x.h"
 
+/* Max number of segments allowable in LUX table */
+#define TSL2X7X_MAX_LUX_TABLE_SIZE  9
+#define MAX_DEFAULT_TABLE_BYTES (sizeof(int) * TSL2X7X_MAX_LUX_TABLE_SIZE)
+
+struct iio_dev;
+
+struct tsl2x7x_lux {
+   unsigned int ratio;
+   unsigned int ch0;
+   unsigned int ch1;
+};
+
+/**
+ * struct tsl2x7x_default_settings - power on defaults unless
+ *   overridden by platform data.
+ *  @als_time:  ALS Integration time - multiple of 50mS
+ *  @als_gain:  Index into the ALS gain table.
+ *  @als_gain_trim: default gain trim to account for
+ *  aperture effects.
+ *  @wait_time: Time between PRX and ALS cycles
+ *  in 2.7 periods
+ *  @prx_time:  5.2ms prox integration time -
+ *  decrease in 2.7ms periods
+ *  @prx_gain:  Proximity gain index
+ *  @prox_config:   Prox configuration filters.
+ *  @als_cal_target:Known external ALS reading for
+ *  calibration.
+ *  @interrupts_en: Enable/Disable - 0x00 = none, 0x10 = als,
+ *   0x20 = prx,  0x30 = bth
+ *  @persistence:   H/W Filters, Number of 'out of limits'
+ *  ADC readings PRX/ALS.
+ *  @als_thresh_low:CH0 'low' count to trigger interrupt.
+ *  @als_thresh_high:   CH0 'high' count to trigger interrupt.
+ *  @prox_thres_low:Low threshold proximity detection.
+ *  @prox_thres_high:   High threshold proximity detection
+ *  @prox_pulse_coun

Re: [PATCH v5 06/13] powerpc/perf: IMC pmu cpumask and cpu hotplug support

2017-03-23 Thread Gautham R Shenoy
Hi Hemant, Maddy, 

On Thu, Mar 16, 2017 at 01:05:00PM +0530, Madhavan Srinivasan wrote:
> From: Hemant Kumar 
> 
> Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any
> online CPU) from each chip for nest PMUs is designated to read counters.
> 
> On CPU hotplug, dying CPU is checked to see whether it is one of the
> designated cpus, if yes, next online cpu from the same chip (for nest
> units) is designated as new cpu to read counters. For this purpose, we
> introduce a new state : CPUHP_AP_PERF_POWERPC_NEST_ONLINE.
> 
> Cc: Gautham R. Shenoy 
> Cc: Balbir Singh 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Anton Blanchard 
> Cc: Sukadev Bhattiprolu 
> Cc: Michael Neuling 
> Cc: Stewart Smith 
> Cc: Daniel Axtens 
> Cc: Stephane Eranian 
> Cc: Anju T Sudhakar 
> Signed-off-by: Hemant Kumar 
> Signed-off-by: Madhavan Srinivasan 
> ---
>  arch/powerpc/include/asm/opal-api.h|   3 +-
>  arch/powerpc/include/asm/opal.h|   3 +
>  arch/powerpc/perf/imc-pmu.c| 163 
> -
>  arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
>  include/linux/cpuhotplug.h |   1 +
>  5 files changed, 169 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/opal-api.h 
> b/arch/powerpc/include/asm/opal-api.h
> index a0aa285869b5..e1c3d4837857 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -168,7 +168,8 @@
>  #define OPAL_INT_SET_MFRR125
>  #define OPAL_PCI_TCE_KILL126
>  #define OPAL_NMMU_SET_PTCR   127
> -#define OPAL_LAST127
> +#define OPAL_NEST_IMC_COUNTERS_CONTROL   145
> +#define OPAL_LAST145
> 
>  /* Device tree flags */
> 
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index 1ff03a6da76e..d93d08204243 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -227,6 +227,9 @@ int64_t opal_pci_tce_kill(uint64_t phb_id, uint32_t 
> kill_type,
> uint64_t dma_addr, uint32_t npages);
>  int64_t opal_nmmu_set_ptcr(uint64_t chip_id, uint64_t ptcr);
> 
> +int64_t opal_nest_imc_counters_control(uint64_t mode, uint64_t value1,
> + uint64_t value2, uint64_t value3);
> +
>  /* Internal functions */
>  extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
>  int depth, void *data);
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index f6f1ef9f56af..e46ff6d2a584 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -16,6 +16,7 @@
> +static int ppc_nest_imc_cpu_online(unsigned int cpu)
> +{

I take it that 'cpu' is coming online.

> + int nid, fcpu, ncpu;
> + struct cpumask *l_cpumask, tmp_mask;
> +
> + /* Fint the cpumask of this node */
> + nid = cpu_to_node(cpu);
> + l_cpumask = cpumask_of_node(nid);
> +
> + /*
> +  * If any of the cpu from this node is already present in the mask,
> +  * just return, if not, then set this cpu in the mask.
> +  */
> + if (!cpumask_and(&tmp_mask, l_cpumask, &nest_imc_cpumask)) {

In this case, none of the cpus in the node are in the mask. So we set
and this cpu in the imc cpumask and return.

> + cpumask_set_cpu(cpu, &nest_imc_cpumask);
> + return 0;
> + }

But this case implies that there is already a CPU from the node which
is in the imc_cpumask. As per the comment above, we are supposed to
just return. So why are we doing the following ?

Either the comment above is incorrect or I am missing something here.

> +
> + fcpu = cpumask_first(l_cpumask);
> + ncpu = cpumask_next(cpu, l_cpumask);
> + if (cpu == fcpu) {
> + if (cpumask_test_and_clear_cpu(ncpu, &nest_imc_cpumask)) {
> + cpumask_set_cpu(cpu, &nest_imc_cpumask);
> + nest_change_cpu_context(ncpu, cpu);
> + }
> + }

It seems that we want to set only the smallest online cpu in the node
in the nest_imc_cpumask. So, if the newly onlined cpu is the smallest,
we replace the previous representative with cpu.

So, the comment above needs to be fixed.

> +
> + return 0;
> +}
> +
> +static int ppc_nest_imc_cpu_offline(unsigned int cpu)
> +{
> + int nid, target = -1;
> + struct cpumask *l_cpumask;
> +
> + /*
> +  * Check in the designated list for this cpu. Dont bother
> +  * if not one of them.
> +  */
> + if (!cpumask_test_and_clear_cpu(cpu, &nest_imc_cpumask))
> + return 0;
> +
> + /*
> +  * Now that this cpu is one of the designated,
> +  * find a next cpu a) which is online and b) in same chip.
> +  */
> + nid = cpu_to_node(cpu);
> + l_cpumask = cpumask_of_node(nid);
> + target = cpumask_next(cpu, l

Re: [PATCH 05/13] platform/chrome: cros_ec_lpc: Add R/W helpers to LPC protocol variants

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Enric Balletbo i Serra wrote:

> From: Shawn Nematbakhsh 
> 
> Call common functions for read / write to prepare support for future
> LPC protocol variants which use different I/O ops than inb / outb.
> 
> Signed-off-by: Shawn Nematbakhsh 
> Signed-off-by: Thierry Escande 
> ---
> Changelog:
>  - v2:
>-Fixed coding style issues
>-Updated copyright to year 2016
> 
>  drivers/platform/chrome/Makefile  |  3 +-
>  drivers/platform/chrome/cros_ec_lpc.c | 88 
> +--
>  drivers/platform/chrome/cros_ec_lpc_reg.c | 64 ++

>  include/linux/mfd/cros_ec_lpc_reg.h   | 47 +

Acked-by: Lee Jones 

>  4 files changed, 151 insertions(+), 51 deletions(-)
>  create mode 100644 drivers/platform/chrome/cros_ec_lpc_reg.c
>  create mode 100644 include/linux/mfd/cros_ec_lpc_reg.h
> 
> diff --git a/drivers/platform/chrome/Makefile 
> b/drivers/platform/chrome/Makefile
> index 3870afe..61182fd 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -5,6 +5,7 @@ cros_ec_devs-objs := cros_ec_dev.o 
> cros_ec_sysfs.o \
>  cros_ec_lightbar.o cros_ec_vbc.o \
>  cros_ec_debugfs.o
>  obj-$(CONFIG_CROS_EC_CHARDEV)+= cros_ec_devs.o
> -obj-$(CONFIG_CROS_EC_LPC)+= cros_ec_lpc.o
> +cros_ec_lpcs-objs:= cros_ec_lpc.o cros_ec_lpc_reg.o
> +obj-$(CONFIG_CROS_EC_LPC)+= cros_ec_lpcs.o
>  obj-$(CONFIG_CROS_EC_PROTO)  += cros_ec_proto.o
>  obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index f9a2454..6a782a6 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -26,19 +26,22 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  
> -#define DRV_NAME "cros_ec_lpc"
> +#define DRV_NAME "cros_ec_lpcs"
>  
>  static int ec_response_timed_out(void)
>  {
>   unsigned long one_second = jiffies + HZ;
> + u8 data;
>  
>   usleep_range(200, 300);
>   do {
> - if (!(inb(EC_LPC_ADDR_HOST_CMD) & EC_LPC_STATUS_BUSY_MASK))
> + if (!(cros_ec_lpc_read_bytes(EC_LPC_ADDR_HOST_CMD, 1, &data) &
> + EC_LPC_STATUS_BUSY_MASK))
>   return 0;
>   usleep_range(100, 200);
>   } while (time_before(jiffies, one_second));
> @@ -51,21 +54,20 @@ static int cros_ec_pkt_xfer_lpc(struct cros_ec_device *ec,
>  {
>   struct ec_host_request *request;
>   struct ec_host_response response;
> - u8 sum = 0;
> - int i;
> + u8 sum;
>   int ret = 0;
>   u8 *dout;
>  
>   ret = cros_ec_prepare_tx(ec, msg);
>  
>   /* Write buffer */
> - for (i = 0; i < ret; i++)
> - outb(ec->dout[i], EC_LPC_ADDR_HOST_PACKET + i);
> + cros_ec_lpc_write_bytes(EC_LPC_ADDR_HOST_PACKET, ret, ec->dout);
>  
>   request = (struct ec_host_request *)ec->dout;
>  
>   /* Here we go */
> - outb(EC_COMMAND_PROTOCOL_3, EC_LPC_ADDR_HOST_CMD);
> + sum = EC_COMMAND_PROTOCOL_3;
> + cros_ec_lpc_write_bytes(EC_LPC_ADDR_HOST_CMD, 1, &sum);
>  
>   if (ec_response_timed_out()) {
>   dev_warn(ec->dev, "EC responsed timed out\n");
> @@ -74,17 +76,15 @@ static int cros_ec_pkt_xfer_lpc(struct cros_ec_device *ec,
>   }
>  
>   /* Check result */
> - msg->result = inb(EC_LPC_ADDR_HOST_DATA);
> + msg->result = cros_ec_lpc_read_bytes(EC_LPC_ADDR_HOST_DATA, 1, &sum);
>   ret = cros_ec_check_result(ec, msg);
>   if (ret)
>   goto done;
>  
>   /* Read back response */
>   dout = (u8 *)&response;
> - for (i = 0; i < sizeof(response); i++) {
> - dout[i] = inb(EC_LPC_ADDR_HOST_PACKET + i);
> - sum += dout[i];
> - }
> + sum = cros_ec_lpc_read_bytes(EC_LPC_ADDR_HOST_PACKET, sizeof(response),
> +  dout);
>  
>   msg->result = response.result;
>  
> @@ -97,11 +97,9 @@ static int cros_ec_pkt_xfer_lpc(struct cros_ec_device *ec,
>   }
>  
>   /* Read response and process checksum */
> - for (i = 0; i < response.data_len; i++) {
> - msg->data[i] =
> - inb(EC_LPC_ADDR_HOST_PACKET + sizeof(response) + i);
> - sum += msg->data[i];
> - }
> + sum += cros_ec_lpc_read_bytes(EC_LPC_ADDR_HOST_PACKET +
> +   sizeof(response), response.data_len,
> +   msg->data);
>  
>   if (sum) {
>   dev_err(ec->dev,
> @@ -121,8 +119,7 @@ static int cros_ec_cmd_xfer_lpc(struct cros_ec_device *ec,
>   struct cros_ec_command *msg)
>  {
>   struct ec_lpc_host_args args;
> - int csum;
> - int i;
> + 

Re: [PATCH 06/13] platform/chrome: cros_ec_lpc: Add support for mec1322 EC

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Enric Balletbo i Serra wrote:

> From: Shawn Nematbakhsh 
> 
> This adds support for the ChromeOS LPC Microchip Embedded Controller
> (mec1322) variant.
> 
> mec1322 accesses I/O region [800h, 9ffh] through embedded memory
> interface (EMI) rather than LPC.
> 
> Signed-off-by: Shawn Nematbakhsh 
> Signed-off-by: Thierry Escande 
> ---
> Changelog:
>  - v2:
>-Add a few lines in Kconfig description
>-Fixed coding style issues
>-Updated copyright to year 2016
> 
>  drivers/platform/chrome/Kconfig   |  12 +++
>  drivers/platform/chrome/Makefile  |   1 +
>  drivers/platform/chrome/cros_ec_lpc.c |   5 ++
>  drivers/platform/chrome/cros_ec_lpc_mec.c | 140 
> ++
>  drivers/platform/chrome/cros_ec_lpc_reg.c |  69 +++

>  include/linux/mfd/cros_ec_lpc_mec.h   |  90 +++
>  include/linux/mfd/cros_ec_lpc_reg.h   |  14 +++

Acked-by: Lee Jones 

>  7 files changed, 331 insertions(+)
>  create mode 100644 drivers/platform/chrome/cros_ec_lpc_mec.c
>  create mode 100644 include/linux/mfd/cros_ec_lpc_mec.h
> 
> diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
> index 76bdae1..6d80fb5 100644
> --- a/drivers/platform/chrome/Kconfig
> +++ b/drivers/platform/chrome/Kconfig
> @@ -59,6 +59,18 @@ config CROS_EC_LPC
>To compile this driver as a module, choose M here: the
>module will be called cros_ec_lpc.
>  
> +config CROS_EC_LPC_MEC
> + bool "ChromeOS Embedded Controller LPC Microchip EC (MEC) variant"
> + depends on CROS_EC_LPC
> + default n
> + help
> +   If you say Y here, a variant LPC protocol for the Microchip EC
> +   will be used. Note that this variant is not backward compatible
> +   with non-Microchip ECs.
> +
> +   If you have a ChromeOS Embedded Controller Microchip EC variant
> +   choose Y here.
> +
>  config CROS_EC_PROTO
>  bool
>  help
> diff --git a/drivers/platform/chrome/Makefile 
> b/drivers/platform/chrome/Makefile
> index 61182fd..66c345c 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -6,6 +6,7 @@ cros_ec_devs-objs := cros_ec_dev.o 
> cros_ec_sysfs.o \
>  cros_ec_debugfs.o
>  obj-$(CONFIG_CROS_EC_CHARDEV)+= cros_ec_devs.o
>  cros_ec_lpcs-objs:= cros_ec_lpc.o cros_ec_lpc_reg.o
> +cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC)   += cros_ec_lpc_mec.o
>  obj-$(CONFIG_CROS_EC_LPC)+= cros_ec_lpcs.o
>  obj-$(CONFIG_CROS_EC_PROTO)  += cros_ec_proto.o
>  obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 6a782a6..bc2dc62 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -346,10 +346,13 @@ static int __init cros_ec_lpc_init(void)
>   return -ENODEV;
>   }
>  
> + cros_ec_lpc_reg_init();
> +
>   /* Register the driver */
>   ret = platform_driver_register(&cros_ec_lpc_driver);
>   if (ret) {
>   pr_err(DRV_NAME ": can't register driver: %d\n", ret);
> + cros_ec_lpc_reg_destroy();
>   return ret;
>   }
>  
> @@ -358,6 +361,7 @@ static int __init cros_ec_lpc_init(void)
>   if (ret) {
>   pr_err(DRV_NAME ": can't register device: %d\n", ret);
>   platform_driver_unregister(&cros_ec_lpc_driver);
> + cros_ec_lpc_reg_destroy();
>   return ret;
>   }
>  
> @@ -368,6 +372,7 @@ static void __exit cros_ec_lpc_exit(void)
>  {
>   platform_device_unregister(&cros_ec_lpc_device);
>   platform_driver_unregister(&cros_ec_lpc_driver);
> + cros_ec_lpc_reg_destroy();
>  }
>  
>  module_init(cros_ec_lpc_init);
> diff --git a/drivers/platform/chrome/cros_ec_lpc_mec.c 
> b/drivers/platform/chrome/cros_ec_lpc_mec.c
> new file mode 100644
> index 000..2eda2c2
> --- /dev/null
> +++ b/drivers/platform/chrome/cros_ec_lpc_mec.c
> @@ -0,0 +1,140 @@
> +/*
> + * cros_ec_lpc_mec - LPC variant I/O for Microchip EC
> + *
> + * Copyright (C) 2016 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * This driver uses the Chrome OS EC byte-level message-based protocol for
> + * communicating the keyboard state (which keys are pressed) from a keyboard 
> EC
> + * to the AP over some bus (such as i2c, lpc, spi).  The EC do

[PATCH] qla2xxx: remove redundant check on sess being non-null

2017-03-23 Thread Colin King
From: Colin Ian King 

All error paths to label out_term2 result in sess being null, so the
check for sess being non-null and the call to put_sess is dead code
and can therefore be removed.

Detected with CoverityScan, CID#1420664 ("Logically dead code")

Signed-off-by: Colin Ian King 
---
 drivers/scsi/qla2xxx/qla_target.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index 0e03ca2ab3e5..32e07f21ddb2 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -5853,8 +5853,6 @@ static void qlt_abort_work(struct qla_tgt *tgt,
return;
 
 out_term2:
-   if (sess)
-   ha->tgt.tgt_ops->put_sess(sess);
spin_unlock_irqrestore(&ha->tgt.sess_lock, flags2);
 
 out_term:
-- 
2.11.0



Re: [PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

2017-03-23 Thread Greg Ungerer

Hi Afzal,

On 23/03/17 20:43, afzal mohammed wrote:

On Fri, Mar 17, 2017 at 10:10:34PM +0530, afzal mohammed wrote:

Greg upon trying to boot no-MMU Kernel on ARM926EJ reported boot
failure. He root caused it to ID_PFR1 access introduced by the
commit mentioned in the fixes tag below.

All CP15 processors need not have processor feature registers, only
for architectures defined by CPUID scheme would have it. Hence check
for it before accessing processor feature register, ID_PFR1.

Fixes: f8300a0b5de0 ("ARM: 8647/2: nommu: dynamic exception base address 
setting")
Reported-by: Greg Ungerer 
Signed-off-by: afzal mohammed 


Greg, can i add your Tested-by ?


Absolutely:

Tested-by: Greg Ungerer 

Thanks for taking care of this.

Regards
Greg



---

Hi Russell,

It would be good to have the fix go in during -rc, as,

1. Culprit commit went in during the last merge window
2. Though nothing supported in mainline is known to be broken, the
original change needs to be modified to be reliable




Re: [PATCH] video: fbdev: pmag-aa-fb: remove incorrect __exit markups

2017-03-23 Thread Maciej W. Rozycki
On Mon, 20 Mar 2017, Bartlomiej Zolnierkiewicz wrote:

> > Even if bus is not hot-pluggable, devices can be unbound from the
> > driver via sysfs, so we should not be using __exit annotations on
> > remove() methods. The only exception is drivers registered with
> > platform_driver_probe() which specifically disables sysfs bind/unbind
> > attributes.
> > 
> > Signed-off-by: Dmitry Torokhov 
> 
> Patch queued for 4.12, thanks.

 Thanks!

  Maciej


[GIT PULL] Immutable branch between MFD and GPIO due for the v4.12 merge window

2017-03-23 Thread Lee Jones
Enjoy,

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-gpio-v4.12

for you to fetch changes up to 9f7c7ceefe5e824e8333859bded12257a6d3548a:

  mfd: wm831x: Add device tree binding document (2017-03-23 11:46:00 +)


Immutable branch between MFD and GPIO due for the v4.12 merge window


Charles Keepax (3):
  mfd: wm831x: Add basic device tree binding
  gpio: wm831x: Add basic device tree support
  mfd: wm831x: Add device tree binding document

 Documentation/devicetree/bindings/mfd/wm831x.txt | 81 
 MAINTAINERS  |  1 +
 drivers/gpio/gpio-wm831x.c   |  5 +-
 drivers/mfd/wm831x-core.c| 29 ++---
 drivers/mfd/wm831x-i2c.c | 19 +-
 drivers/mfd/wm831x-irq.c |  6 +-
 drivers/mfd/wm831x-spi.c | 18 +-
 include/linux/mfd/wm831x/core.h  |  9 ++-
 8 files changed, 152 insertions(+), 16 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/wm831x.txt

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v5 3/3] mfd: wm831x: Add device tree binding document

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Charles Keepax wrote:

> Add a device tree binding document for the wm831x series of PMICs.
> Currently only support for the registering the device and the GPIOs are
> actually implemented in the driver.
> 
> Signed-off-by: Charles Keepax 
> ---
> 
> Changes since v4:
>  - Removed one extra level of ../ for relative links that was incorrect
> 
> Thanks,
> Charles
> 
>  Documentation/devicetree/bindings/mfd/wm831x.txt | 81 
> 
>  MAINTAINERS  |  1 +
>  2 files changed, 82 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/wm831x.txt

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
> b/Documentation/devicetree/bindings/mfd/wm831x.txt
> new file mode 100644
> index 000..9f8b743
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
> @@ -0,0 +1,81 @@
> +Cirrus Logic/Wolfson Microelectronics wm831x PMICs
> +
> +System PMICs with a wide range of additional features.
> +
> +Required properties:
> +
> +  - compatible : One of the following chip-specific strings:
> +"wlf,wm8310"
> +"wlf,wm8311"
> +"wlf,wm8312"
> +"wlf,wm8320"
> +"wlf,wm8321"
> +"wlf,wm8325"
> +"wlf,wm8326"
> +
> +  - reg : I2C slave address when connected using I2C, chip select number
> +when using SPI.
> +
> +  - gpio-controller : Indicates this device is a GPIO controller.
> +  - #gpio-cells : Must be 2. The first cell is the pin number and the
> +second cell is used to specify optional parameters (currently unused).
> +
> +  - interrupts : The interrupt line the IRQ signal for the device is
> +connected to.
> +  - interrupt-parent : The parent interrupt controller.
> +
> +  - interrupt-controller : wm831x devices contain interrupt controllers and
> +may provide interrupt services to other devices.
> +  - #interrupt-cells: Must be 2. The first cell is the IRQ number, and the
> +second cell is the flags, encoded as the trigger masks from
> +../interrupt-controller/interrupts.txt
> +
> +Optional sub-nodes:
> +  - regulators : Contains sub-nodes for each of the regulators supplied by
> +the device. The regulators are bound using their names listed below:
> +
> +dcdc1 : DCDC1
> +dcdc2 : DCDC2
> +dcdc3 : DCDC3
> +dcdc4 : DCDC3
> +isink1 : ISINK1
> +isink2 : ISINK2
> +ldo1 : LDO1
> +ldo2 : LDO2
> +ldo3 : LDO3
> +ldo4 : LDO4
> +ldo5 : LDO5
> +ldo7 : LDO7
> +ldo11 : LDO11
> +
> +The bindings details of each regulator can be found in:
> +../regulator/regulator.txt
> +
> +Example:
> +
> +wm8310: pmic@36 {
> + compatible = "wlf,wm8310";
> + reg = <0x36>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + interrupts = <347>;
> + interrupt-parent = <&gic>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + regulators {
> + dcdc1: dcdc1 {
> + regulator-name = "DCDC1";
> + regulator-min-microvolt = <60>;
> + regulator-max-microvolt = <60>;
> + };
> + ldo1: ldo1 {
> + regulator-name = "LDO1";
> + regulator-min-microvolt = <170>;
> + regulator-max-microvolt = <170>;
> + };
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c265a5f..dfe761b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13600,6 +13600,7 @@ F:Documentation/hwmon/wm83??
>  F:   Documentation/devicetree/bindings/extcon/extcon-arizona.txt
>  F:   Documentation/devicetree/bindings/regulator/arizona-regulator.txt
>  F:   Documentation/devicetree/bindings/mfd/arizona.txt
> +F:   Documentation/devicetree/bindings/mfd/wm831x.txt
>  F:   arch/arm/mach-s3c64xx/mach-crag6410*
>  F:   drivers/clk/clk-wm83*.c
>  F:   drivers/extcon/extcon-arizona.c

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


[PATCH v2] kasan: report only the first error by default

2017-03-23 Thread Andrey Ryabinin
Disable kasan after the first report. There are several reasons for this:
 * Single bug quite often has multiple invalid memory accesses causing
storm in the dmesg.
 * Write OOB access might corrupt metadata so the next report will print
bogus alloc/free stacktraces.
 * Reports after the first easily could be not bugs by itself but just side
effects of the first one.

Given that multiple reports usually only do harm, it makes sense to disable
kasan after the first one. If user wants to see all the reports, the
boot-time parameter kasan_multi_shot must be used.

Signed-off-by: Andrey Ryabinin 
---
Changes since v1:
- provide kasan_multi_shot boot parameter.

 Documentation/admin-guide/kernel-parameters.txt |  6 ++
 lib/test_kasan.c| 12 
 mm/kasan/kasan.h|  5 -
 mm/kasan/report.c   | 18 ++
 4 files changed, 36 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 2906987..f88d60e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1726,6 +1726,12 @@
kernel and module base offset ASLR (Address Space
Layout Randomization).
 
+   kasan_multi_shot
+   [KNL] Enforce KASAN (Kernel Address Sanitizer) to print
+   report on every invalid memory access. Without this
+   parameter KASAN will print report only for the first
+   invalid access.
+
keepinitrd  [HW,ARM]
 
kernelcore= [KNL,X86,IA-64,PPC]
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 0b1d314..f3acece 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -11,6 +11,7 @@
 
 #define pr_fmt(fmt) "kasan test: %s " fmt, __func__
 
+#include 
 #include 
 #include 
 #include 
@@ -21,6 +22,8 @@
 #include 
 #include 
 
+extern atomic_t kasan_report_count;
+
 /*
  * Note: test functions are marked noinline so that their names appear in
  * reports.
@@ -474,6 +477,9 @@ static noinline void __init use_after_scope_test(void)
 
 static int __init kmalloc_tests_init(void)
 {
+   /* Rise reports limit high enough to see all the following bugs */
+   atomic_add(100, &kasan_report_count);
+
kmalloc_oob_right();
kmalloc_oob_left();
kmalloc_node_oob_right();
@@ -499,6 +505,12 @@ static int __init kmalloc_tests_init(void)
ksize_unpoisons_memory();
copy_user_test();
use_after_scope_test();
+
+   /*
+* kasan is unreliable now, disable reports if
+* we are in single shot mode
+*/
+   atomic_sub(100, &kasan_report_count);
return -EAGAIN;
 }
 
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index 7572917..1229298 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -96,11 +96,6 @@ static inline const void *kasan_shadow_to_mem(const void 
*shadow_addr)
<< KASAN_SHADOW_SCALE_SHIFT);
 }
 
-static inline bool kasan_report_enabled(void)
-{
-   return !current->kasan_depth;
-}
-
 void kasan_report(unsigned long addr, size_t size,
bool is_write, unsigned long ip);
 void kasan_report_double_free(struct kmem_cache *cache, void *object,
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 718a10a..5650534 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -13,7 +13,9 @@
  *
  */
 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -354,6 +356,22 @@ static void kasan_report_error(struct kasan_access_info 
*info)
kasan_end_report(&flags);
 }
 
+atomic_t kasan_report_count = ATOMIC_INIT(1);
+EXPORT_SYMBOL_GPL(kasan_report_count);
+
+static int __init kasan_set_multi_shot(char *str)
+{
+   atomic_set(&kasan_report_count, 10);
+   return 1;
+}
+__setup("kasan_multi_shot", kasan_set_multi_shot);
+
+static inline bool kasan_report_enabled(void)
+{
+   return !current->kasan_depth &&
+   (atomic_dec_if_positive(&kasan_report_count) >= 0);
+}
+
 void kasan_report(unsigned long addr, size_t size,
bool is_write, unsigned long ip)
 {
-- 
2.10.2



Re: [PATCH v5 1/3] mfd: wm831x: Add basic device tree binding

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Charles Keepax wrote:

> Add the basic ability to register the device through device tree, more
> work is needed to get each individual sub-driver functioning correctly
> but this is enough to get the device to probe from device tree.
> 
> Signed-off-by: Charles Keepax 
> ---
> 
> Changes since v4:
>  - Removed pointless intermediate variable after of_match_device
>  - Moved all local variables to start of function rather than in
>their localised code block
> 
> Thanks,
> Charles
> 
>  drivers/mfd/wm831x-core.c   | 29 +
>  drivers/mfd/wm831x-i2c.c| 19 ++-
>  drivers/mfd/wm831x-irq.c|  6 +++---
>  drivers/mfd/wm831x-spi.c| 18 --
>  include/linux/mfd/wm831x/core.h |  9 -
>  5 files changed, 66 insertions(+), 15 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/wm831x-core.c b/drivers/mfd/wm831x-core.c
> index 3e0e99e..13a4c11 100644
> --- a/drivers/mfd/wm831x-core.c
> +++ b/drivers/mfd/wm831x-core.c
> @@ -19,6 +19,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1613,12 +1615,24 @@ struct regmap_config wm831x_regmap_config = {
>  };
>  EXPORT_SYMBOL_GPL(wm831x_regmap_config);
>  
> +const struct of_device_id wm831x_of_match[] = {
> + { .compatible = "wlf,wm8310", .data = (void *)WM8310 },
> + { .compatible = "wlf,wm8311", .data = (void *)WM8311 },
> + { .compatible = "wlf,wm8312", .data = (void *)WM8312 },
> + { .compatible = "wlf,wm8320", .data = (void *)WM8320 },
> + { .compatible = "wlf,wm8321", .data = (void *)WM8321 },
> + { .compatible = "wlf,wm8325", .data = (void *)WM8325 },
> + { .compatible = "wlf,wm8326", .data = (void *)WM8326 },
> + { },
> +};
> +EXPORT_SYMBOL_GPL(wm831x_of_match);
> +
>  /*
>   * Instantiate the generic non-control parts of the device.
>   */
> -int wm831x_device_init(struct wm831x *wm831x, unsigned long id, int irq)
> +int wm831x_device_init(struct wm831x *wm831x, int irq)
>  {
> - struct wm831x_pdata *pdata = dev_get_platdata(wm831x->dev);
> + struct wm831x_pdata *pdata = &wm831x->pdata;
>   int rev, wm831x_num;
>   enum wm831x_parent parent;
>   int ret, i;
> @@ -1627,8 +1641,7 @@ int wm831x_device_init(struct wm831x *wm831x, unsigned 
> long id, int irq)
>   mutex_init(&wm831x->key_lock);
>   dev_set_drvdata(wm831x->dev, wm831x);
>  
> - if (pdata)
> - wm831x->soft_shutdown = pdata->soft_shutdown;
> + wm831x->soft_shutdown = pdata->soft_shutdown;
>  
>   ret = wm831x_reg_read(wm831x, WM831X_PARENT_ID);
>   if (ret < 0) {
> @@ -1663,7 +1676,7 @@ int wm831x_device_init(struct wm831x *wm831x, unsigned 
> long id, int irq)
>*/
>   if (ret == 0) {
>   dev_info(wm831x->dev, "Device is an engineering sample\n");
> - ret = id;
> + ret = wm831x->type;
>   }
>  
>   switch (ret) {
> @@ -1736,9 +1749,9 @@ int wm831x_device_init(struct wm831x *wm831x, unsigned 
> long id, int irq)
>   /* This will need revisiting in future but is OK for all
>* current parts.
>*/
> - if (parent != id)
> - dev_warn(wm831x->dev, "Device was registered as a WM%lx\n",
> -  id);
> + if (parent != wm831x->type)
> + dev_warn(wm831x->dev, "Device was registered as a WM%x\n",
> +  wm831x->type);
>  
>   /* Bootstrap the user key */
>   ret = wm831x_reg_read(wm831x, WM831X_SECURITY_KEY);
> diff --git a/drivers/mfd/wm831x-i2c.c b/drivers/mfd/wm831x-i2c.c
> index 824bcba..781af06 100644
> --- a/drivers/mfd/wm831x-i2c.c
> +++ b/drivers/mfd/wm831x-i2c.c
> @@ -19,6 +19,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #include 
> @@ -27,15 +29,26 @@
>  static int wm831x_i2c_probe(struct i2c_client *i2c,
>   const struct i2c_device_id *id)
>  {
> + struct wm831x_pdata *pdata = dev_get_platdata(&i2c->dev);
> + const struct of_device_id *of_id;
>   struct wm831x *wm831x;
> + enum wm831x_parent type;
>   int ret;
>  
> + if (i2c->dev.of_node) {
> + of_id = of_match_device(wm831x_of_match, &i2c->dev);
> + type = (enum wm831x_parent)of_id->data;
> + } else {
> + type = (enum wm831x_parent)id->driver_data;
> + }
> +
>   wm831x = devm_kzalloc(&i2c->dev, sizeof(struct wm831x), GFP_KERNEL);
>   if (wm831x == NULL)
>   return -ENOMEM;
>  
>   i2c_set_clientdata(i2c, wm831x);
>   wm831x->dev = &i2c->dev;
> + wm831x->type = type;
>  
>   wm831x->regmap = devm_regmap_init_i2c(i2c, &wm831x_regmap_config);
>   if (IS_ERR(wm831x->regmap)) {
> @@ -45,7 +58,10 @@ static int wm831x_i2c_probe(struct i2c_client *i2c,
>   return ret;
>   }
>  
> - return wm831x_device_init(wm831x, id->driver_data, i2c->irq);
> + if (pdata)
> 

Re: [PATCH v5 2/3] gpio: wm831x: Add basic device tree support

2017-03-23 Thread Lee Jones
On Fri, 17 Mar 2017, Charles Keepax wrote:

> Now the wm831x-core has basic DT support we can update this driver to
> allow use of the GPIOs within a device tree system.
> 
> Signed-off-by: Charles Keepax 
> Acked-by: Linus Walleij 
> ---
> 
> No changes since v4, still should go through Lee's tree.
> 
> Thanks,
> Charles
> 
>  drivers/gpio/gpio-wm831x.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/gpio/gpio-wm831x.c b/drivers/gpio/gpio-wm831x.c
> index 00e3839..938bbe3 100644
> --- a/drivers/gpio/gpio-wm831x.c
> +++ b/drivers/gpio/gpio-wm831x.c
> @@ -263,7 +263,7 @@ static const struct gpio_chip template_chip = {
>  static int wm831x_gpio_probe(struct platform_device *pdev)
>  {
>   struct wm831x *wm831x = dev_get_drvdata(pdev->dev.parent);
> - struct wm831x_pdata *pdata = dev_get_platdata(wm831x->dev);
> + struct wm831x_pdata *pdata = &wm831x->pdata;
>   struct wm831x_gpio *wm831x_gpio;
>   int ret;
>  
> @@ -280,6 +280,9 @@ static int wm831x_gpio_probe(struct platform_device *pdev)
>   wm831x_gpio->gpio_chip.base = pdata->gpio_base;
>   else
>   wm831x_gpio->gpio_chip.base = -1;
> +#ifdef CONFIG_OF_GPIO
> + wm831x_gpio->gpio_chip.of_node = wm831x->dev->of_node;
> +#endif
>  
>   ret = devm_gpiochip_add_data(&pdev->dev, &wm831x_gpio->gpio_chip,
>wm831x_gpio);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH] scsi: fcoe: sanity check string size for store_ctrl_mode option

2017-03-23 Thread Dan Carpenter
On Wed, Mar 22, 2017 at 07:42:08PM +, Colin Ian King wrote:
> On 22/03/17 19:39, Dan Carpenter wrote:
> > On Wed, Mar 22, 2017 at 02:01:37PM +, Colin King wrote:
> >> From: Colin Ian King 
> >>
> >> Reading and writing to mode[count - 1] implies the count should not
> >> be less than 1 so add a sanity check for this.
> >>
> >> Detected with CoverityScan, CID#1357345 ("Overflowed array index write")
> >>
> >> Signed-off-by: Colin Ian King 
> > 
> > This is harmless, of course, but count can't be zero.  This is a sysfs
> > file so we test for zero size writes in sysfs_kf_write() and return
> > early.
> 
> Ah, thanks for pointing out that. I overlooked that detail.
> 

The only reason I know this stuff is because it's annotated in Smatch.
So I do this:

diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c b/drivers/scsi/fcoe/fcoe_sysfs.c
index 9cf3d56296ab..c491ad8fb0a8 100644
--- a/drivers/scsi/fcoe/fcoe_sysfs.c
+++ b/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -281,6 +281,7 @@ static ssize_t show_ctlr_mode(struct device *dev,
"%s\n", name);
 }
 
+#include "/home/dcarpenter/progs/smatch/devel/check_debug.h"
 static ssize_t store_ctlr_mode(struct device *dev,
   struct device_attribute *attr,
   const char *buf, size_t count)
@@ -288,6 +289,7 @@ static ssize_t store_ctlr_mode(struct device *dev,
struct fcoe_ctlr_device *ctlr = dev_to_ctlr(dev);
char mode[FCOE_MAX_MODENAME_LEN + 1];
 
+   __smatch_implied(count);
if (count > FCOE_MAX_MODENAME_LEN)
return -EINVAL;
 

Then when I run kchecker drivers/scsi/fcoe/fcoe_sysfs.c, it tells me:

drivers/scsi/fcoe/fcoe_sysfs.c:292 store_ctlr_mode() implied: count = 
'1-10,2147479552'

Which is sort of surprising...  The 10 value is a hack I made so
that it would never complain that "off + count" will wrap.  But
apparently something has changed so it's also picking up the true limit
of count which is 2147479552.

Then I run the following commands to view the call tree:
smdb.py store_ctlr_mode
smdb.py dev_attr_store
smdb.py sysfs_kf_write
I have some vim macros so I can look these up really quickly.

regards,
dan carpenter


[PATCH] staging: rtl8192e: Fix embedded function names with __func__

2017-03-23 Thread suniel . spartan
From: Suniel Mahesh 

Prefer and make it generic by using %s and __func__ to print
functions name instead of embedding functions name in print statements

Signed-off-by: Suniel Mahesh 
---
 drivers/staging/rtl8192e/rtl8192e/rtl_ps.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
index aa4b015..9281116 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
@@ -35,7 +35,7 @@ static void _rtl92e_hw_sleep(struct net_device *dev)
if (priv->RFChangeInProgress) {
spin_unlock_irqrestore(&priv->rf_ps_lock, flags);
RT_TRACE(COMP_DBG,
-"_rtl92e_hw_sleep(): RF Change in progress!\n");
+"%s(): RF Change in progress!\n", __func__);
return;
}
spin_unlock_irqrestore(&priv->rf_ps_lock, flags);
@@ -62,7 +62,7 @@ void rtl92e_hw_wakeup(struct net_device *dev)
if (priv->RFChangeInProgress) {
spin_unlock_irqrestore(&priv->rf_ps_lock, flags);
RT_TRACE(COMP_DBG,
-"rtl92e_hw_wakeup(): RF Change in progress!\n");
+"%s(): RF Change in progress!\n", __func__);
schedule_delayed_work(&priv->rtllib->hw_wakeup_wq,
  msecs_to_jiffies(10));
return;
@@ -121,15 +121,15 @@ static void _rtl92e_ps_update_rf_state(struct net_device 
*dev)
struct rt_pwr_save_ctrl *pPSC = (struct rt_pwr_save_ctrl *)
&(priv->rtllib->PowerSaveControl);
 
-   RT_TRACE(COMP_PS, "_rtl92e_ps_update_rf_state() ->\n");
+   RT_TRACE(COMP_PS, "%s() ->\n", __func__);
pPSC->bSwRfProcessing = true;
 
-   RT_TRACE(COMP_PS, "_rtl92e_ps_update_rf_state(): Set RF to %s.\n",
+   RT_TRACE(COMP_PS, "%s(): Set RF to %s.\n", __func__,
 pPSC->eInactivePowerState == eRfOff ? "OFF" : "ON");
rtl92e_set_rf_state(dev, pPSC->eInactivePowerState, RF_CHANGE_BY_IPS);
 
pPSC->bSwRfProcessing = false;
-   RT_TRACE(COMP_PS, "_rtl92e_ps_update_rf_state() <-\n");
+   RT_TRACE(COMP_PS, "%s() <-\n", __func__);
 }
 
 void rtl92e_ips_enter(struct net_device *dev)
@@ -144,7 +144,7 @@ void rtl92e_ips_enter(struct net_device *dev)
if (rtState == eRfOn && !pPSC->bSwRfProcessing &&
(priv->rtllib->state != RTLLIB_LINKED) &&
(priv->rtllib->iw_mode != IW_MODE_MASTER)) {
-   RT_TRACE(COMP_PS, "rtl92e_ips_enter(): Turn off RF.\n");
+   RT_TRACE(COMP_PS, "%s(): Turn off RF.\n", __func__);
pPSC->eInactivePowerState = eRfOff;
priv->isRFOff = true;
priv->bInPowerSaveMode = true;
@@ -164,7 +164,7 @@ void rtl92e_ips_leave(struct net_device *dev)
rtState = priv->rtllib->eRFPowerState;
if (rtState != eRfOn  && !pPSC->bSwRfProcessing &&
priv->rtllib->RfOffReason <= RF_CHANGE_BY_IPS) {
-   RT_TRACE(COMP_PS, "rtl92e_ips_leave(): Turn on RF.\n");
+   RT_TRACE(COMP_PS, "%s(): Turn on RF.\n", __func__);
pPSC->eInactivePowerState = eRfOn;
priv->bInPowerSaveMode = false;
_rtl92e_ps_update_rf_state(dev);
@@ -247,7 +247,7 @@ void rtl92e_leisure_ps_enter(struct net_device *dev)
struct rt_pwr_save_ctrl *pPSC = (struct rt_pwr_save_ctrl *)
&(priv->rtllib->PowerSaveControl);
 
-   RT_TRACE(COMP_PS, "rtl92e_leisure_ps_enter()...\n");
+   RT_TRACE(COMP_PS, "%s()...\n", __func__);
RT_TRACE(COMP_PS,
 "pPSC->bLeisurePs = %d, ieee->ps = %d,pPSC->LpsIdleCount is 
%d,RT_CHECK_FOR_HANG_PERIOD is %d\n",
 pPSC->bLeisurePs, priv->rtllib->ps, pPSC->LpsIdleCount,
@@ -265,7 +265,7 @@ void rtl92e_leisure_ps_enter(struct net_device *dev)
if (priv->rtllib->ps == RTLLIB_PS_DISABLED) {
 
RT_TRACE(COMP_LPS,
-"rtl92e_leisure_ps_enter(): Enter 
802.11 power save mode...\n");
+"%s(): Enter 802.11 power save 
mode...\n", __func__);
 
if (!pPSC->bFwCtrlLPS) {
if (priv->rtllib->SetFwCmdHandler)
@@ -287,14 +287,14 @@ void rtl92e_leisure_ps_leave(struct net_device *dev)
&(priv->rtllib->PowerSaveControl);
 
 
-   RT_TRACE(COMP_PS, "rtl92e_leisure_ps_leave()...\n");
+   RT_TRACE(COMP_PS, "%s()...\n", __func__);
RT_TRACE(COMP_PS, "pPSC->bLeisurePs = %d, ieee->ps = %d\n",
p

Re: [PATCH] staging: ad7746: Moved contents of the header to the source file.

2017-03-23 Thread Lars-Peter Clausen
On 03/23/2017 12:36 PM, Arushi Singhal wrote:
> Moved the contents of the header(ad7746.h) into the source file
> ad7746.c with the exception of the platform data struct which is
> supposed to be used from somewhere else other than the driver.
> 
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/iio/cdc/ad7746.c | 5 +
>  drivers/staging/iio/cdc/ad7746.h | 5 -
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index 2d8397b11b19..033a41fd9bee 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -21,6 +21,11 @@
>  
>  #include "ad7746.h"
>  
> +#define AD7466_EXCLVL_0 0 /* +-VDD/8 */
> +#define AD7466_EXCLVL_1 1 /* +-VDD/4 */
> +#define AD7466_EXCLVL_2 2 /* +-VDD * 3/8 */
> +#define AD7466_EXCLVL_3 3 /* +-VDD/2 */
> +
>  /*
>   * AD7746 Register Definition
>   */
> diff --git a/drivers/staging/iio/cdc/ad7746.h 
> b/drivers/staging/iio/cdc/ad7746.h
> index ea8572d1df02..2fbcee88fda6 100644
> --- a/drivers/staging/iio/cdc/ad7746.h
> +++ b/drivers/staging/iio/cdc/ad7746.h
> @@ -13,11 +13,6 @@
>   * TODO: struct ad7746_platform_data needs to go into include/linux/iio
>   */
>  
> -#define AD7466_EXCLVL_0  0 /* +-VDD/8 */
> -#define AD7466_EXCLVL_1  1 /* +-VDD/4 */
> -#define AD7466_EXCLVL_2  2 /* +-VDD * 3/8 */
> -#define AD7466_EXCLVL_3  3 /* +-VDD/2 */
> -

I believe those are settings for the exclvl field in the platform data
struct. Hence this has to stay here.

>  struct ad7746_platform_data {
>   unsigned char exclvl;   /*Excitation Voltage Level */
>   bool exca_en;   /* enables EXCA pin as the excitation output */
> 



Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

2017-03-23 Thread Robin Murphy
On 22/03/17 06:27, Zhen Lei wrote:
> Keep these four variables type consistent with the paramters of function
> __alloc_and_insert_iova_range and the members of struct iova:
> 
> 1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
>   unsigned long size, unsigned long limit_pfn,
> 
> 2. struct iova {
>   unsigned long   pfn_hi;
>   unsigned long   pfn_lo;
> 
> In fact, limit_pfn is most likely larger than 32 bits on DMA64.

FWIW if pad_size manages to overflow an int something's probably gone
horribly wrong, but there's no harm in making it consistent with
everything else here. However, given that patch #6 makes this irrelevant
anyway, do we really need to bother?

Robin.

> Signed-off-by: Zhen Lei 
> ---
>  drivers/iommu/iova.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index b7268a1..8ba8b496 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -104,8 +104,8 @@ __cached_rbnode_delete_update(struct iova_domain *iovad, 
> struct iova *free)
>   * Computes the padding size required, to make the start address
>   * naturally aligned on the power-of-two order of its size
>   */
> -static unsigned int
> -iova_get_pad_size(unsigned int size, unsigned int limit_pfn)
> +static unsigned long
> +iova_get_pad_size(unsigned long size, unsigned long limit_pfn)
>  {
>   return (limit_pfn + 1 - size) & (__roundup_pow_of_two(size) - 1);
>  }
> @@ -117,7 +117,7 @@ static int __alloc_and_insert_iova_range(struct 
> iova_domain *iovad,
>   struct rb_node *prev, *curr = NULL;
>   unsigned long flags;
>   unsigned long saved_pfn;
> - unsigned int pad_size = 0;
> + unsigned long pad_size = 0;
>  
>   /* Walk the tree backwards */
>   spin_lock_irqsave(&iovad->iova_rbtree_lock, flags);
> 



[PATCH] staging: ad7746: Moved contents of the header to the source file.

2017-03-23 Thread Arushi Singhal
Moved the contents of the header(ad7746.h) into the source file
ad7746.c with the exception of the platform data struct which is
supposed to be used from somewhere else other than the driver.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/iio/cdc/ad7746.c | 5 +
 drivers/staging/iio/cdc/ad7746.h | 5 -
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 2d8397b11b19..033a41fd9bee 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -21,6 +21,11 @@
 
 #include "ad7746.h"
 
+#define AD7466_EXCLVL_0 0 /* +-VDD/8 */
+#define AD7466_EXCLVL_1 1 /* +-VDD/4 */
+#define AD7466_EXCLVL_2 2 /* +-VDD * 3/8 */
+#define AD7466_EXCLVL_3 3 /* +-VDD/2 */
+
 /*
  * AD7746 Register Definition
  */
diff --git a/drivers/staging/iio/cdc/ad7746.h b/drivers/staging/iio/cdc/ad7746.h
index ea8572d1df02..2fbcee88fda6 100644
--- a/drivers/staging/iio/cdc/ad7746.h
+++ b/drivers/staging/iio/cdc/ad7746.h
@@ -13,11 +13,6 @@
  * TODO: struct ad7746_platform_data needs to go into include/linux/iio
  */
 
-#define AD7466_EXCLVL_00 /* +-VDD/8 */
-#define AD7466_EXCLVL_11 /* +-VDD/4 */
-#define AD7466_EXCLVL_22 /* +-VDD * 3/8 */
-#define AD7466_EXCLVL_33 /* +-VDD/2 */
-
 struct ad7746_platform_data {
unsigned char exclvl;   /*Excitation Voltage Level */
bool exca_en;   /* enables EXCA pin as the excitation output */
-- 
2.11.0



[PATCH 2/4] sched: cpudeadline: don't re-initialize struct cpudl

2017-03-23 Thread Viresh Kumar
The struct cpudl passed to cpudl_init() is already initialized to zero.
Don't do that again.

Signed-off-by: Viresh Kumar 
---
 kernel/sched/cpudeadline.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index fba235c7d026..a51e91bf3907 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -246,9 +246,7 @@ int cpudl_init(struct cpudl *cp)
 {
int i;
 
-   memset(cp, 0, sizeof(*cp));
raw_spin_lock_init(&cp->lock);
-   cp->size = 0;
 
cp->elements = kcalloc(nr_cpu_ids,
   sizeof(struct cpudl_item),
-- 
2.12.0.432.g71c3a4f4ba37



[PATCH 1/4] sched: topology: drop memset() from init_rootdomain()

2017-03-23 Thread Viresh Kumar
There are only two callers of init_rootdomain(). One of them passes a
global to it and another one sends dynamically allocated root-domain.

There is no need to memset the root-domain in the first case as the
structure is already reset.

Update alloc_rootdomain() to allocate the memory with kzalloc() and
remove the memset() call from init_rootdomain().

Signed-off-by: Viresh Kumar 
---
 kernel/sched/topology.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 1b0b4fb12837..a2497702e628 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -242,8 +242,6 @@ void rq_attach_root(struct rq *rq, struct root_domain *rd)
 
 static int init_rootdomain(struct root_domain *rd)
 {
-   memset(rd, 0, sizeof(*rd));
-
if (!zalloc_cpumask_var(&rd->span, GFP_KERNEL))
goto out;
if (!zalloc_cpumask_var(&rd->online, GFP_KERNEL))
@@ -292,7 +290,7 @@ static struct root_domain *alloc_rootdomain(void)
 {
struct root_domain *rd;
 
-   rd = kmalloc(sizeof(*rd), GFP_KERNEL);
+   rd = kzalloc(sizeof(*rd), GFP_KERNEL);
if (!rd)
return NULL;
 
-- 
2.12.0.432.g71c3a4f4ba37



<    3   4   5   6   7   8   9   10   11   >