Re: [PATCH BUGFIX 1/1] block, bfq: add requeue-request hook

[Mike Galbraith]

On Tue, 2018-02-06 at 08:44 +0100, Oleksandr Natalenko wrote:
> Hi, Paolo.
> 
> I can confirm that this patch fixes cfdisk hang for me. I've also tried 
> to trigger the issue Mike has encountered, but with no luck (maybe, I 
> wasn't insistent enough, just was doing dd on usb-storage device in the 
> VM).

I was doing kbuilds, and it blew up on me twice.  Switching back to cfq
seemed to confirm it was indeed the patch causing trouble, but that's
by no means a certainty.

-Mike

Re: [PATCH BUGFIX 1/1] block, bfq: add requeue-request hook

[Mike Galbraith]

On Tue, 2018-02-06 at 08:44 +0100, Oleksandr Natalenko wrote:
> Hi, Paolo.
> 
> I can confirm that this patch fixes cfdisk hang for me. I've also tried 
> to trigger the issue Mike has encountered, but with no luck (maybe, I 
> wasn't insistent enough, just was doing dd on usb-storage device in the 
> VM).

I was doing kbuilds, and it blew up on me twice.  Switching back to cfq
seemed to confirm it was indeed the patch causing trouble, but that's
by no means a certainty.

-Mike

Re: [PATCH v3 3/3] x86/entry: Clear registers for compat syscalls

[Dan Williams]

On Mon, Feb 5, 2018 at 11:26 PM, Ingo Molnar  wrote:
>
> * Dan Williams  wrote:
>
>> From: Andi Kleen 
>>
>> At entry userspace may have populated registers with values that could
>> be useful in a speculative execution attack. Clear them to minimize the
>> kernel's attack surface.
>>
>> [djbw: interleave the clearing with setting up the stack ]
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: "H. Peter Anvin" 
>> Cc: x...@kernel.org
>> Cc: Andy Lutomirski 
>> Signed-off-by: Andi Kleen 
>> Signed-off-by: Dan Williams 
>> ---
>>  arch/x86/entry/entry_64_compat.S |   30 ++
>>  1 file changed, 30 insertions(+)
>>
>> diff --git a/arch/x86/entry/entry_64_compat.S 
>> b/arch/x86/entry/entry_64_compat.S
>> index 98d5358e4041..fd65e016e413 100644
>> --- a/arch/x86/entry/entry_64_compat.S
>> +++ b/arch/x86/entry/entry_64_compat.S
>> @@ -85,15 +85,25 @@ ENTRY(entry_SYSENTER_compat)
>>   pushq   %rcx/* pt_regs->cx */
>>   pushq   $-ENOSYS/* pt_regs->ax */
>>   pushq   $0  /* pt_regs->r8  = 0 */
>> + xorq%r8, %r8/* nospec   r8 */
>>   pushq   $0  /* pt_regs->r9  = 0 */
>> + xorq%r9, %r9/* nospec   r9 */
>>   pushq   $0  /* pt_regs->r10 = 0 */
>> + xorq%r10, %r10  /* nospec   r10 */
>>   pushq   $0  /* pt_regs->r11 = 0 */
>> + xorq%r11, %r11  /* nospec   r11 */
>>   pushq   %rbx/* pt_regs->rbx */
>> + xorl%ebx, %ebx  /* nospec   rbx */
>>   pushq   %rbp/* pt_regs->rbp (will be overwritten) 
>> */
>> + xorl%ebp, %ebp  /* nospec   rbp */
>>   pushq   $0  /* pt_regs->r12 = 0 */
>> + xorq%r12, %r12  /* nospec   r12 */
>>   pushq   $0  /* pt_regs->r13 = 0 */
>> + xorq%r13, %r13  /* nospec   r13 */
>>   pushq   $0  /* pt_regs->r14 = 0 */
>> + xorq%r14, %r14  /* nospec   r14 */
>>   pushq   $0  /* pt_regs->r15 = 0 */
>> + xorq%r15, %r15  /* nospec   r15 */
>>   cld
>>
>>   /*
>> @@ -214,15 +224,25 @@ GLOBAL(entry_SYSCALL_compat_after_hwframe)
>>   pushq   %rbp/* pt_regs->cx (stashed in bp) */
>>   pushq   $-ENOSYS/* pt_regs->ax */
>>   pushq   $0  /* pt_regs->r8  = 0 */
>> + xorq%r8, %r8/* nospec   r8 */
>>   pushq   $0  /* pt_regs->r9  = 0 */
>> + xorq%r9, %r9/* nospec   r9 */
>>   pushq   $0  /* pt_regs->r10 = 0 */
>> + xorq%r10, %r10  /* nospec   r10 */
>>   pushq   $0  /* pt_regs->r11 = 0 */
>> + xorq%r11, %r11  /* nospec   r11 */
>>   pushq   %rbx/* pt_regs->rbx */
>> + xorl%ebx, %ebx  /* nospec   rbx */
>>   pushq   %rbp/* pt_regs->rbp (will be overwritten) 
>> */
>> + xorl%ebp, %ebp  /* nospec   rbp */
>>   pushq   $0  /* pt_regs->r12 = 0 */
>> + xorq%r12, %r12  /* nospec   r12 */
>>   pushq   $0  /* pt_regs->r13 = 0 */
>> + xorq%r13, %r13  /* nospec   r13 */
>>   pushq   $0  /* pt_regs->r14 = 0 */
>> + xorq%r14, %r14  /* nospec   r14 */
>>   pushq   $0  /* pt_regs->r15 = 0 */
>> + xorq%r15, %r15  /* nospec   r15 */
>
> I really love it how you've aligned the comment fields vertically - nice!
>
>>   /*
>>* User mode is traced as though IRQs are on, and SYSENTER
>> @@ -338,15 +358,25 @@ ENTRY(entry_INT80_compat)
>>   pushq   %rcx/* pt_regs->cx */
>>   pushq   $-ENOSYS/* pt_regs->ax */
>>   pushq   $0  /* pt_regs->r8  = 0 */
>> + xorq%r8, %r8/* nospec   r8 */
>>   pushq   $0  /* pt_regs->r9  = 0 */
>> + xorq%r9, %r9/* nospec   r9 */
>>   pushq   $0  /* pt_regs->r10 = 0 */
>> + xorq%r10, %r10  /* nospec   r10 */
>>   pushq   $0  /* pt_regs->r11 = 0 */
>> + xorq%r11, %r11  /* nospec   r11 */
>>   pushq   %rbx/* pt_regs->rbx */
>> + xorl%ebx, %ebx  /* nospec   rbx */
>>   pushq   %rbp/* pt_regs->rbp */
>> + xorl%ebp, %ebp 

Re: [PATCH v3 3/3] x86/entry: Clear registers for compat syscalls

[Dan Williams]

On Mon, Feb 5, 2018 at 11:26 PM, Ingo Molnar  wrote:
>
> * Dan Williams  wrote:
>
>> From: Andi Kleen 
>>
>> At entry userspace may have populated registers with values that could
>> be useful in a speculative execution attack. Clear them to minimize the
>> kernel's attack surface.
>>
>> [djbw: interleave the clearing with setting up the stack ]
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: "H. Peter Anvin" 
>> Cc: x...@kernel.org
>> Cc: Andy Lutomirski 
>> Signed-off-by: Andi Kleen 
>> Signed-off-by: Dan Williams 
>> ---
>>  arch/x86/entry/entry_64_compat.S |   30 ++
>>  1 file changed, 30 insertions(+)
>>
>> diff --git a/arch/x86/entry/entry_64_compat.S 
>> b/arch/x86/entry/entry_64_compat.S
>> index 98d5358e4041..fd65e016e413 100644
>> --- a/arch/x86/entry/entry_64_compat.S
>> +++ b/arch/x86/entry/entry_64_compat.S
>> @@ -85,15 +85,25 @@ ENTRY(entry_SYSENTER_compat)
>>   pushq   %rcx/* pt_regs->cx */
>>   pushq   $-ENOSYS/* pt_regs->ax */
>>   pushq   $0  /* pt_regs->r8  = 0 */
>> + xorq%r8, %r8/* nospec   r8 */
>>   pushq   $0  /* pt_regs->r9  = 0 */
>> + xorq%r9, %r9/* nospec   r9 */
>>   pushq   $0  /* pt_regs->r10 = 0 */
>> + xorq%r10, %r10  /* nospec   r10 */
>>   pushq   $0  /* pt_regs->r11 = 0 */
>> + xorq%r11, %r11  /* nospec   r11 */
>>   pushq   %rbx/* pt_regs->rbx */
>> + xorl%ebx, %ebx  /* nospec   rbx */
>>   pushq   %rbp/* pt_regs->rbp (will be overwritten) 
>> */
>> + xorl%ebp, %ebp  /* nospec   rbp */
>>   pushq   $0  /* pt_regs->r12 = 0 */
>> + xorq%r12, %r12  /* nospec   r12 */
>>   pushq   $0  /* pt_regs->r13 = 0 */
>> + xorq%r13, %r13  /* nospec   r13 */
>>   pushq   $0  /* pt_regs->r14 = 0 */
>> + xorq%r14, %r14  /* nospec   r14 */
>>   pushq   $0  /* pt_regs->r15 = 0 */
>> + xorq%r15, %r15  /* nospec   r15 */
>>   cld
>>
>>   /*
>> @@ -214,15 +224,25 @@ GLOBAL(entry_SYSCALL_compat_after_hwframe)
>>   pushq   %rbp/* pt_regs->cx (stashed in bp) */
>>   pushq   $-ENOSYS/* pt_regs->ax */
>>   pushq   $0  /* pt_regs->r8  = 0 */
>> + xorq%r8, %r8/* nospec   r8 */
>>   pushq   $0  /* pt_regs->r9  = 0 */
>> + xorq%r9, %r9/* nospec   r9 */
>>   pushq   $0  /* pt_regs->r10 = 0 */
>> + xorq%r10, %r10  /* nospec   r10 */
>>   pushq   $0  /* pt_regs->r11 = 0 */
>> + xorq%r11, %r11  /* nospec   r11 */
>>   pushq   %rbx/* pt_regs->rbx */
>> + xorl%ebx, %ebx  /* nospec   rbx */
>>   pushq   %rbp/* pt_regs->rbp (will be overwritten) 
>> */
>> + xorl%ebp, %ebp  /* nospec   rbp */
>>   pushq   $0  /* pt_regs->r12 = 0 */
>> + xorq%r12, %r12  /* nospec   r12 */
>>   pushq   $0  /* pt_regs->r13 = 0 */
>> + xorq%r13, %r13  /* nospec   r13 */
>>   pushq   $0  /* pt_regs->r14 = 0 */
>> + xorq%r14, %r14  /* nospec   r14 */
>>   pushq   $0  /* pt_regs->r15 = 0 */
>> + xorq%r15, %r15  /* nospec   r15 */
>
> I really love it how you've aligned the comment fields vertically - nice!
>
>>   /*
>>* User mode is traced as though IRQs are on, and SYSENTER
>> @@ -338,15 +358,25 @@ ENTRY(entry_INT80_compat)
>>   pushq   %rcx/* pt_regs->cx */
>>   pushq   $-ENOSYS/* pt_regs->ax */
>>   pushq   $0  /* pt_regs->r8  = 0 */
>> + xorq%r8, %r8/* nospec   r8 */
>>   pushq   $0  /* pt_regs->r9  = 0 */
>> + xorq%r9, %r9/* nospec   r9 */
>>   pushq   $0  /* pt_regs->r10 = 0 */
>> + xorq%r10, %r10  /* nospec   r10 */
>>   pushq   $0  /* pt_regs->r11 = 0 */
>> + xorq%r11, %r11  /* nospec   r11 */
>>   pushq   %rbx/* pt_regs->rbx */
>> + xorl%ebx, %ebx  /* nospec   rbx */
>>   pushq   %rbp/* pt_regs->rbp */
>> + xorl%ebp, %ebp  /* nospec   rbp */
>>   pushq   %r12/* pt_regs->r12 */
>> + xorq%r12, %r12  /* nospec   r12 */
>>   pushq   %r13

Re: [PATCH 3/3] vfio: disable filesystem-dax page pinning

[Haozhong Zhang]

Hi Dan,

On 02/04/18 15:05 -0800, Dan Williams wrote:
> Filesystem-DAX is incompatible with 'longterm' page pinning. Without
> page cache indirection a DAX mapping maps filesystem blocks directly.
> This means that the filesystem must not modify a file's block map while
> any page in a mapping is pinned. In order to prevent the situation of
> userspace holding of filesystem operations indefinitely, disallow
> 'longterm' Filesystem-DAX mappings.
> 
> RDMA has the same conflict and the plan there is to add a 'with lease'
> mechanism to allow the kernel to notify userspace that the mapping is
> being torn down for block-map maintenance. Perhaps something similar can
> be put in place for vfio.
> 
> Note that xfs and ext4 still report:
> 
>"DAX enabled. Warning: EXPERIMENTAL, use at your own risk"
> 
> ...at mount time, and resolving the dax-dma-vs-truncate problem is one
> of the last hurdles to remove that designation.
> 
> Cc: Alex Williamson 
> Cc: Michal Hocko 
> Cc: Christoph Hellwig 
> Cc: k...@vger.kernel.org
> Cc: 
> Reported-by: Haozhong Zhang 
> Fixes: d475c6346a38 ("dax,ext2: replace XIP read and write with DAX I/O")
> Signed-off-by: Dan Williams 
> ---
>  drivers/vfio/vfio_iommu_type1.c |   18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index e30e29ae4819..45657e2b1ff7 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -338,11 +338,12 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
> long vaddr,
>  {
>   struct page *page[1];
>   struct vm_area_struct *vma;
> + struct vm_area_struct *vmas[1];
>   int ret;
>  
>   if (mm == current->mm) {
> - ret = get_user_pages_fast(vaddr, 1, !!(prot & IOMMU_WRITE),
> -   page);
> + ret = get_user_pages_longterm(vaddr, 1, !!(prot & IOMMU_WRITE),
> +   page, vmas);
>   } else {
>   unsigned int flags = 0;
>  
> @@ -351,7 +352,18 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
> long vaddr,
>  
>   down_read(>mmap_sem);
>   ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
> - NULL, NULL);
> + vmas, NULL);
> + /*
> +  * The lifetime of a vaddr_get_pfn() page pin is
> +  * userspace-controlled. In the fs-dax case this could
> +  * lead to indefinite stalls in filesystem operations.
> +  * Disallow attempts to pin fs-dax pages via this
> +  * interface.
> +  */
> + if (ret > 0 && vma_is_fsdax(vmas[0])) {
> + ret = -EOPNOTSUPP;
> + put_page(page[0]);
> + }
>   up_read(>mmap_sem);
>   }
>  
> 

Besides this patch series, are there other patches needed to make
vma_is_fsdax() to work with device-dax?

I applied this patch series on the libvdimm-for-next branch of nvdimm
tree (ee95f4059a83), and found this patch series also failed
device-dax mapping with vfio. It can be reproduced by following steps:

1. Attach PCI device at BDF :03:10.2 to vfio-pci.
   # modprobe vfio-pci
   # lspci -n -s :03:10.2
   03:10.2 0200: 8086:1515 (rev 01)
   # echo :03:10.2 > /sys/bus/pci/devices/:06:0d.0/driver/unbind
   # echo 8086:1515 > /sys/bus/pci/drivers/vfio-pci/new_id

2. Use RAM to emulate NVDIMM and create a device-dax device /dev/dax0.0
   # cat /proc/iomem
   ...
   1-2 : Persistent Memory (legacy)
 1-2 : namespace0.0
   ...

   # ndctl create-namespace -f -e namespace0.0 -m dax
   {
 "dev":"namespace0.0",
 "mode":"dax",
 "size":8453619712,
 "uuid":"e1db00bc-f830-4f1b-ac18-091ae7df4f93",
 "daxdevs":[
   {
 "chardev":"dax0.0",
 "size":8453619712
   }
 ]
   }

3. Create a VM with assigned PCI device in step 1 and the device-dax
   device in step 2.
   # qemu-system-x86_64 -machine pc,accel=kvm,nvdimm=on -smp host \
-m 4G,slots=32,maxmem=128G \
-drive file=VM_DISK_IMG.img,format=raw,if=virtio \
-object 
memory-backend-file,id=nv_be1,share=on,mem-path=/dev/dax0.0,size=4G,align=2M \
-device nvdimm,id=nv1,memdev=nv_be1 \
-device ioh3420,id=root.0,slot=4 \
-device 
vfio-pci,sysfsdev=/sys/bus/pci/devices/:03:10.2,id=nic1,bus=pci.0,addr=0x6

   It then fails with the following QEMU error messages:
 qemu-system-x86_64: -device 
vfio-pci,sysfsdev=/sys/bus/pci/devices/:03:10.2,id=nic1,bus=pci.0,addr=0x6: 
VFIO_MAP_DMA: -95
 

Re: [PATCH 3/3] vfio: disable filesystem-dax page pinning

[Haozhong Zhang]

Hi Dan,

On 02/04/18 15:05 -0800, Dan Williams wrote:
> Filesystem-DAX is incompatible with 'longterm' page pinning. Without
> page cache indirection a DAX mapping maps filesystem blocks directly.
> This means that the filesystem must not modify a file's block map while
> any page in a mapping is pinned. In order to prevent the situation of
> userspace holding of filesystem operations indefinitely, disallow
> 'longterm' Filesystem-DAX mappings.
> 
> RDMA has the same conflict and the plan there is to add a 'with lease'
> mechanism to allow the kernel to notify userspace that the mapping is
> being torn down for block-map maintenance. Perhaps something similar can
> be put in place for vfio.
> 
> Note that xfs and ext4 still report:
> 
>"DAX enabled. Warning: EXPERIMENTAL, use at your own risk"
> 
> ...at mount time, and resolving the dax-dma-vs-truncate problem is one
> of the last hurdles to remove that designation.
> 
> Cc: Alex Williamson 
> Cc: Michal Hocko 
> Cc: Christoph Hellwig 
> Cc: k...@vger.kernel.org
> Cc: 
> Reported-by: Haozhong Zhang 
> Fixes: d475c6346a38 ("dax,ext2: replace XIP read and write with DAX I/O")
> Signed-off-by: Dan Williams 
> ---
>  drivers/vfio/vfio_iommu_type1.c |   18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index e30e29ae4819..45657e2b1ff7 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -338,11 +338,12 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
> long vaddr,
>  {
>   struct page *page[1];
>   struct vm_area_struct *vma;
> + struct vm_area_struct *vmas[1];
>   int ret;
>  
>   if (mm == current->mm) {
> - ret = get_user_pages_fast(vaddr, 1, !!(prot & IOMMU_WRITE),
> -   page);
> + ret = get_user_pages_longterm(vaddr, 1, !!(prot & IOMMU_WRITE),
> +   page, vmas);
>   } else {
>   unsigned int flags = 0;
>  
> @@ -351,7 +352,18 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
> long vaddr,
>  
>   down_read(>mmap_sem);
>   ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
> - NULL, NULL);
> + vmas, NULL);
> + /*
> +  * The lifetime of a vaddr_get_pfn() page pin is
> +  * userspace-controlled. In the fs-dax case this could
> +  * lead to indefinite stalls in filesystem operations.
> +  * Disallow attempts to pin fs-dax pages via this
> +  * interface.
> +  */
> + if (ret > 0 && vma_is_fsdax(vmas[0])) {
> + ret = -EOPNOTSUPP;
> + put_page(page[0]);
> + }
>   up_read(>mmap_sem);
>   }
>  
> 

Besides this patch series, are there other patches needed to make
vma_is_fsdax() to work with device-dax?

I applied this patch series on the libvdimm-for-next branch of nvdimm
tree (ee95f4059a83), and found this patch series also failed
device-dax mapping with vfio. It can be reproduced by following steps:

1. Attach PCI device at BDF :03:10.2 to vfio-pci.
   # modprobe vfio-pci
   # lspci -n -s :03:10.2
   03:10.2 0200: 8086:1515 (rev 01)
   # echo :03:10.2 > /sys/bus/pci/devices/:06:0d.0/driver/unbind
   # echo 8086:1515 > /sys/bus/pci/drivers/vfio-pci/new_id

2. Use RAM to emulate NVDIMM and create a device-dax device /dev/dax0.0
   # cat /proc/iomem
   ...
   1-2 : Persistent Memory (legacy)
 1-2 : namespace0.0
   ...

   # ndctl create-namespace -f -e namespace0.0 -m dax
   {
 "dev":"namespace0.0",
 "mode":"dax",
 "size":8453619712,
 "uuid":"e1db00bc-f830-4f1b-ac18-091ae7df4f93",
 "daxdevs":[
   {
 "chardev":"dax0.0",
 "size":8453619712
   }
 ]
   }

3. Create a VM with assigned PCI device in step 1 and the device-dax
   device in step 2.
   # qemu-system-x86_64 -machine pc,accel=kvm,nvdimm=on -smp host \
-m 4G,slots=32,maxmem=128G \
-drive file=VM_DISK_IMG.img,format=raw,if=virtio \
-object 
memory-backend-file,id=nv_be1,share=on,mem-path=/dev/dax0.0,size=4G,align=2M \
-device nvdimm,id=nv1,memdev=nv_be1 \
-device ioh3420,id=root.0,slot=4 \
-device 
vfio-pci,sysfsdev=/sys/bus/pci/devices/:03:10.2,id=nic1,bus=pci.0,addr=0x6

   It then fails with the following QEMU error messages:
 qemu-system-x86_64: -device 
vfio-pci,sysfsdev=/sys/bus/pci/devices/:03:10.2,id=nic1,bus=pci.0,addr=0x6: 
VFIO_MAP_DMA: -95
 qemu-system-x86_64: -device 
vfio-pci,sysfsdev=/sys/bus/pci/devices/:03:10.2,id=nic1,bus=pci.0,addr=0x6: 

Re: [PATCH BUGFIX 1/1] block, bfq: add requeue-request hook

[Oleksandr Natalenko]

Hi, Paolo.

I can confirm that this patch fixes cfdisk hang for me. I've also tried 
to trigger the issue Mike has encountered, but with no luck (maybe, I 
wasn't insistent enough, just was doing dd on usb-storage device in the 
VM).


So, with regard to cfdisk hang on usb-storage:

Tested-by: Oleksandr Natalenko 

Thank you.

Re: [PATCH BUGFIX 1/1] block, bfq: add requeue-request hook

[Oleksandr Natalenko]

Hi, Paolo.

I can confirm that this patch fixes cfdisk hang for me. I've also tried 
to trigger the issue Mike has encountered, but with no luck (maybe, I 
wasn't insistent enough, just was doing dd on usb-storage device in the 
VM).


So, with regard to cfdisk hang on usb-storage:

Tested-by: Oleksandr Natalenko 

Thank you.

Re: [PATCH V2 1/7] sched/topology: Adding function partition_sched_domains_locked()

[Juri Lelli]

On 05/02/18 11:11, Mathieu Poirier wrote:
> On 2 February 2018 at 03:19, Juri Lelli  wrote:
> > Hi Mathieu,
> >
> > On 01/02/18 09:51, Mathieu Poirier wrote:
> >> Introducing function partition_sched_domains_locked() by taking
> >> the mutex locking code out of the original function.  That way
> >> the work done by partition_sched_domains_locked() can be reused
> >> without dropping the mutex lock.
> >>
> >> This patch doesn't change the functionality provided by the
> >> original code.
> >>
> >> Signed-off-by: Mathieu Poirier 
> >> ---
> >
> > [...]
> >
> >> +/*
> >> + * Call with hotplug lock held
> >
> > Is this the one that we can actually check if it's locked with
> >
> > lockdep_assert_cpus_held()
> >
> > ?
> 
> Hi Juri,
> 
> You are correct - we could call lockdep_assert_cpus_held() but in my
> opinion it would be in a separate patch and probably outside the scope
> of this work.  The sole purpose of this patch is to get the
> locking/unlocking operations of mutex sched_domains_mutex out of
> function partition_sched_domains_locked().

Fair enough. I just thought though that, since you are adding the comment
above, we could as well add an explicit check for hotplug lock.

Best,

- Juri

Re: [PATCH V2 1/7] sched/topology: Adding function partition_sched_domains_locked()

[Juri Lelli]

On 05/02/18 11:11, Mathieu Poirier wrote:
> On 2 February 2018 at 03:19, Juri Lelli  wrote:
> > Hi Mathieu,
> >
> > On 01/02/18 09:51, Mathieu Poirier wrote:
> >> Introducing function partition_sched_domains_locked() by taking
> >> the mutex locking code out of the original function.  That way
> >> the work done by partition_sched_domains_locked() can be reused
> >> without dropping the mutex lock.
> >>
> >> This patch doesn't change the functionality provided by the
> >> original code.
> >>
> >> Signed-off-by: Mathieu Poirier 
> >> ---
> >
> > [...]
> >
> >> +/*
> >> + * Call with hotplug lock held
> >
> > Is this the one that we can actually check if it's locked with
> >
> > lockdep_assert_cpus_held()
> >
> > ?
> 
> Hi Juri,
> 
> You are correct - we could call lockdep_assert_cpus_held() but in my
> opinion it would be in a separate patch and probably outside the scope
> of this work.  The sole purpose of this patch is to get the
> locking/unlocking operations of mutex sched_domains_mutex out of
> function partition_sched_domains_locked().

Fair enough. I just thought though that, since you are adding the comment
above, we could as well add an explicit check for hotplug lock.

Best,

- Juri

[PATCH v2 3/3] backlight: adp8860: document sysfs attributes

[Aishwarya Pant]

Add documentation for sysfs interface of adp8860 series backlight
devices by reading through code and git commits.

Signed-off-by: Aishwarya Pant 
Acked-by: Michael Hennerich 
---
 .../ABI/testing/sysfs-class-backlight-adp8860  | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp8860

diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 
b/Documentation/ABI/testing/sysfs-class-backlight-adp8860
new file mode 100644
index ..54d61c788b1b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight-adp8860
@@ -0,0 +1,54 @@
+sysfs interface for analog devices adp8860 backlight driver
+---
+
+The backlight brightness control operates at three different levels for the
+adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) and
+dark (level 3). By default the brightness operates at the daylight brightness
+level.
+
+What:  /sys/class/backlight//ambient_light_level
+Date:  Apr, 2010
+KernelVersion: v2.6.35
+Contact:   Michael Hennerich 
+Description:
+   (RO) 13-bit conversion value for the first light sensor—high
+   byte (Bit 12 to Bit 8). The value is updated every 80 ms (when
+   the light sensor is enabled).
+
+
+What:  /sys/class/backlight//ambient_light_zone
+Date:  Apr, 2010
+KernelVersion: v2.6.35
+Contact:   Michael Hennerich 
+Description:
+   (RW) Read or write the specific level at which the backlight
+   operates. Value "0" enables automatic ambient light sensing, and
+   values "1", "2" or "3" set the control to daylight, office or
+   dark respectively.
+
+
+What:  /sys/class/backlight//l1_daylight_max
+What:  /sys/class/backlight//l2_office_max
+What:  /sys/class/backlight//l3_dark_max
+Date:  Apr, 2010
+KernelVersion: v2.6.35
+Contact:   Michael Hennerich 
+Description:
+   (RW) Maximum current setting for the backlight when brightness
+   is at one of the three levels (daylight, office or dark). This
+   is an input code between 0 and 127, which is transformed to a
+   value between 0 mA and 30 mA using linear or non-linear
+   algorithms.
+
+
+What:  /sys/class/backlight//l1_daylight_dim
+What:  /sys/class/backlight//l2_office_dim
+What:  /sys/class/backlight//l3_dark_dim
+Date:  Apr, 2010
+KernelVersion: v2.6.35
+Contact:   Michael Hennerich 
+Description:
+   (RW) Dim current setting for the backlight when brightness is at
+   one of the three levels (daylight, office or dark). This is an
+   input code between 0 and 127, which is transformed to a value
+   between 0 mA and 30 mA using linear or non-linear algorithms.
-- 
2.16.1

Re: [PATCH v6 19/36] nds32: VDSO support

[Vincent Chen]

2018-01-18 18:28 GMT+08:00 Arnd Bergmann :
> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu  wrote:
>> From: Greentime Hu 
>>
>> This patch adds VDSO support. The VDSO code is currently used for
>> sys_rt_sigreturn() and optimised gettimeofday() (using the SoC timer 
>> counter).
>>
>> Signed-off-by: Vincent Chen 
>> Signed-off-by: Greentime Hu 
>
> Acked-by: Arnd Bergmann 

Dear Arnd Bergmann:

We find a small bug here which make LTP 20170929 clock_getres01
fail. The bug is in __vdso_clock_getres() function. When argument res
is NULL, -EFAULT error code is returned now. But, the returned
value is 0 for SyS_clock_getres under the same conditions.
Therefore, testcase thinks it is a bug.

I will modify the code as below and add it in the next version patch
if you think it is OK.

@@ -209,7 +209,7 @@ static notrace int clock_getres_fallback( ...
 {
 if (res == NULL)
-return -EFAULT;
+return 0;


Thanks

Vincnet

[PATCH v2 3/3] backlight: adp8860: document sysfs attributes

[Aishwarya Pant]

Add documentation for sysfs interface of adp8860 series backlight
devices by reading through code and git commits.

Signed-off-by: Aishwarya Pant 
Acked-by: Michael Hennerich 
---
 .../ABI/testing/sysfs-class-backlight-adp8860  | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp8860

diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 
b/Documentation/ABI/testing/sysfs-class-backlight-adp8860
new file mode 100644
index ..54d61c788b1b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight-adp8860
@@ -0,0 +1,54 @@
+sysfs interface for analog devices adp8860 backlight driver
+---
+
+The backlight brightness control operates at three different levels for the
+adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) and
+dark (level 3). By default the brightness operates at the daylight brightness
+level.
+
+What:  /sys/class/backlight//ambient_light_level
+Date:  Apr, 2010
+KernelVersion: v2.6.35
+Contact:   Michael Hennerich 
+Description:
+   (RO) 13-bit conversion value for the first light sensor—high
+   byte (Bit 12 to Bit 8). The value is updated every 80 ms (when
+   the light sensor is enabled).
+
+
+What:  /sys/class/backlight//ambient_light_zone
+Date:  Apr, 2010
+KernelVersion: v2.6.35
+Contact:   Michael Hennerich 
+Description:
+   (RW) Read or write the specific level at which the backlight
+   operates. Value "0" enables automatic ambient light sensing, and
+   values "1", "2" or "3" set the control to daylight, office or
+   dark respectively.
+
+
+What:  /sys/class/backlight//l1_daylight_max
+What:  /sys/class/backlight//l2_office_max
+What:  /sys/class/backlight//l3_dark_max
+Date:  Apr, 2010
+KernelVersion: v2.6.35
+Contact:   Michael Hennerich 
+Description:
+   (RW) Maximum current setting for the backlight when brightness
+   is at one of the three levels (daylight, office or dark). This
+   is an input code between 0 and 127, which is transformed to a
+   value between 0 mA and 30 mA using linear or non-linear
+   algorithms.
+
+
+What:  /sys/class/backlight//l1_daylight_dim
+What:  /sys/class/backlight//l2_office_dim
+What:  /sys/class/backlight//l3_dark_dim
+Date:  Apr, 2010
+KernelVersion: v2.6.35
+Contact:   Michael Hennerich 
+Description:
+   (RW) Dim current setting for the backlight when brightness is at
+   one of the three levels (daylight, office or dark). This is an
+   input code between 0 and 127, which is transformed to a value
+   between 0 mA and 30 mA using linear or non-linear algorithms.
-- 
2.16.1

Re: [PATCH v6 19/36] nds32: VDSO support

[Vincent Chen]

2018-01-18 18:28 GMT+08:00 Arnd Bergmann :
> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu  wrote:
>> From: Greentime Hu 
>>
>> This patch adds VDSO support. The VDSO code is currently used for
>> sys_rt_sigreturn() and optimised gettimeofday() (using the SoC timer 
>> counter).
>>
>> Signed-off-by: Vincent Chen 
>> Signed-off-by: Greentime Hu 
>
> Acked-by: Arnd Bergmann 

Dear Arnd Bergmann:

We find a small bug here which make LTP 20170929 clock_getres01
fail. The bug is in __vdso_clock_getres() function. When argument res
is NULL, -EFAULT error code is returned now. But, the returned
value is 0 for SyS_clock_getres under the same conditions.
Therefore, testcase thinks it is a bug.

I will modify the code as below and add it in the next version patch
if you think it is OK.

@@ -209,7 +209,7 @@ static notrace int clock_getres_fallback( ...
 {
 if (res == NULL)
-return -EFAULT;
+return 0;


Thanks

Vincnet

[PATCH v2 2/3] backlight: adp5520: document sysfs attributes

[Aishwarya Pant]

Add documentation for sysfs interface of adp5520/adp5501 analog devices
backlight driver by reading code and looking through git commit logs.

Signed-off-by: Aishwarya Pant 
Acked-by: Michael Hennerich 
---
 .../ABI/testing/sysfs-class-backlight-adp5520  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp5520

diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp5520 
b/Documentation/ABI/testing/sysfs-class-backlight-adp5520
new file mode 100644
index ..34b6ebafa210
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight-adp5520
@@ -0,0 +1,31 @@
+sysfs interface for analog devices adp5520(01) backlight driver
+---
+
+The backlight brightness control operates at three different levels for the
+adp5520 and adp5501 devices: daylight (level 1), office (level 2) and dark
+(level 3). By default the brightness operates at the daylight brightness level.
+
+What:  /sys/class/backlight//daylight_max
+What:  /sys/class/backlight//office_max
+What:  /sys/class/backlight//dark_max
+Date:  Sep, 2009
+KernelVersion: v2.6.32
+Contact:   Michael Hennerich 
+Description:
+   (RW) Maximum current setting for the backlight when brightness
+   is at one of the three levels (daylight, office or dark). This
+   is an input code between 0 and 127, which is transformed to a
+   value between 0 mA and 30 mA using linear or non-linear
+   algorithms.
+
+What:  /sys/class/backlight//daylight_dim
+What:  /sys/class/backlight//office_dim
+What:  /sys/class/backlight//dark_dim
+Date:  Sep, 2009
+KernelVersion: v2.6.32
+Contact:   Michael Hennerich 
+Description:
+   (RW) Dim current setting for the backlight when brightness is at
+   one of the three levels (daylight, office or dark). This is an
+   input code between 0 and 127, which is transformed to a value
+   between 0 mA and 30 mA using linear or non-linear algorithms.
-- 
2.16.1

[PATCH v2 2/3] backlight: adp5520: document sysfs attributes

[Aishwarya Pant]

Add documentation for sysfs interface of adp5520/adp5501 analog devices
backlight driver by reading code and looking through git commit logs.

Signed-off-by: Aishwarya Pant 
Acked-by: Michael Hennerich 
---
 .../ABI/testing/sysfs-class-backlight-adp5520  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp5520

diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp5520 
b/Documentation/ABI/testing/sysfs-class-backlight-adp5520
new file mode 100644
index ..34b6ebafa210
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight-adp5520
@@ -0,0 +1,31 @@
+sysfs interface for analog devices adp5520(01) backlight driver
+---
+
+The backlight brightness control operates at three different levels for the
+adp5520 and adp5501 devices: daylight (level 1), office (level 2) and dark
+(level 3). By default the brightness operates at the daylight brightness level.
+
+What:  /sys/class/backlight//daylight_max
+What:  /sys/class/backlight//office_max
+What:  /sys/class/backlight//dark_max
+Date:  Sep, 2009
+KernelVersion: v2.6.32
+Contact:   Michael Hennerich 
+Description:
+   (RW) Maximum current setting for the backlight when brightness
+   is at one of the three levels (daylight, office or dark). This
+   is an input code between 0 and 127, which is transformed to a
+   value between 0 mA and 30 mA using linear or non-linear
+   algorithms.
+
+What:  /sys/class/backlight//daylight_dim
+What:  /sys/class/backlight//office_dim
+What:  /sys/class/backlight//dark_dim
+Date:  Sep, 2009
+KernelVersion: v2.6.32
+Contact:   Michael Hennerich 
+Description:
+   (RW) Dim current setting for the backlight when brightness is at
+   one of the three levels (daylight, office or dark). This is an
+   input code between 0 and 127, which is transformed to a value
+   between 0 mA and 30 mA using linear or non-linear algorithms.
-- 
2.16.1

[PATCH v2 1/3] backlight: lm3639: document sysfs attributes

[Aishwarya Pant]

Add documentation for sysfs interfaces of Texas Instruments lm3639
backlight + flash led driver chip by looking through git commits and
reading code.

Signed-off-by: Aishwarya Pant 
Acked-by: Daniel Thompson 
---
Changes in v2:
- Update contact information

 Documentation/ABI/testing/sysfs-class-backlight-lm3639 | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-lm3639

diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lm3639 
b/Documentation/ABI/testing/sysfs-class-backlight-lm3639
new file mode 100644
index ..f7e92a82ea25
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight-lm3639
@@ -0,0 +1,11 @@
+sysfs interface for Texas Instruments lm3639 backlight + flash led driver chip
+--
+
+What:  /sys/class/backlight//bled_mode
+Date:  Oct, 2012
+KernelVersion: v3.10
+Contact:   dri-de...@lists.freedesktop.org
+Description:
+   (WO) Write to the backlight mapping mode. The backlight current
+   can be mapped for either exponential (value "0") or linear
+   mapping modes (default).
-- 
2.16.1

[PATCH v2 1/3] backlight: lm3639: document sysfs attributes

[Aishwarya Pant]

Add documentation for sysfs interfaces of Texas Instruments lm3639
backlight + flash led driver chip by looking through git commits and
reading code.

Signed-off-by: Aishwarya Pant 
Acked-by: Daniel Thompson 
---
Changes in v2:
- Update contact information

 Documentation/ABI/testing/sysfs-class-backlight-lm3639 | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-lm3639

diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lm3639 
b/Documentation/ABI/testing/sysfs-class-backlight-lm3639
new file mode 100644
index ..f7e92a82ea25
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight-lm3639
@@ -0,0 +1,11 @@
+sysfs interface for Texas Instruments lm3639 backlight + flash led driver chip
+--
+
+What:  /sys/class/backlight//bled_mode
+Date:  Oct, 2012
+KernelVersion: v3.10
+Contact:   dri-de...@lists.freedesktop.org
+Description:
+   (WO) Write to the backlight mapping mode. The backlight current
+   can be mapped for either exponential (value "0") or linear
+   mapping modes (default).
-- 
2.16.1

[PATCH v2 0/3] backlight: document sysfs interfaces

[Aishwarya Pant]

Patchset contains documentation of the sysfs interfaces for the
following five backlight drivers-
1) lm3639
2) adp5520
3) adp8860

It was compiled from data sheets, reading code and git history logs. In v2 of
the patches, documentation for lp8788 and lp855x devices was dropped as the
attributes contained debug information.

Aishwarya Pant (3):
  backlight: lm3639: document sysfs attributes
  backlight: adp5520: document sysfs attributes
  backlight: adp8860: document sysfs attributes

 .../ABI/testing/sysfs-class-backlight-adp5520  | 31 +
 .../ABI/testing/sysfs-class-backlight-adp8860  | 54 ++
 .../ABI/testing/sysfs-class-backlight-lm3639   | 11 +
 3 files changed, 96 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp5520
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp8860
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-lm3639

-- 
2.16.1

[PATCH v2 0/3] backlight: document sysfs interfaces

[Aishwarya Pant]

Patchset contains documentation of the sysfs interfaces for the
following five backlight drivers-
1) lm3639
2) adp5520
3) adp8860

It was compiled from data sheets, reading code and git history logs. In v2 of
the patches, documentation for lp8788 and lp855x devices was dropped as the
attributes contained debug information.

Aishwarya Pant (3):
  backlight: lm3639: document sysfs attributes
  backlight: adp5520: document sysfs attributes
  backlight: adp8860: document sysfs attributes

 .../ABI/testing/sysfs-class-backlight-adp5520  | 31 +
 .../ABI/testing/sysfs-class-backlight-adp8860  | 54 ++
 .../ABI/testing/sysfs-class-backlight-lm3639   | 11 +
 3 files changed, 96 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp5520
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp8860
 create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-lm3639

-- 
2.16.1

Re: [RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

On Mon, Feb 05, 2018 at 12:56:04PM +0100, Linus Walleij wrote:
> On Mon, Feb 5, 2018 at 9:47 AM, Ludovic Desroches
>  wrote:
> 
> > Use GPIO descriptors instead of relying on the old method.
> >
> > Signed-off-by: Ludovic Desroches 
> 
> Ah there it is :D
> Reviewed-by: Linus Walleij 
> 
> PS: why not move it all over to use DRI/DRM/KMS? It's becoming
> easier and easier.

It concerns old products, that's why it's not converted yet.

Regards

Ludovic

> 
> Yours,
> Linus Walleij

Re: [RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

On Mon, Feb 05, 2018 at 12:56:04PM +0100, Linus Walleij wrote:
> On Mon, Feb 5, 2018 at 9:47 AM, Ludovic Desroches
>  wrote:
> 
> > Use GPIO descriptors instead of relying on the old method.
> >
> > Signed-off-by: Ludovic Desroches 
> 
> Ah there it is :D
> Reviewed-by: Linus Walleij 
> 
> PS: why not move it all over to use DRI/DRM/KMS? It's becoming
> easier and easier.

It concerns old products, that's why it's not converted yet.

Regards

Ludovic

> 
> Yours,
> Linus Walleij

[PATCH V2] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.

Signed-off-by: Ludovic Desroches 
Acked-by: Nicolas Ferre 
Reviewed-by: Linus Walleij 
Reviewed-by: Andy Shevchenko 
---
Changes
- V2:
  - remove of_gpio.h.
  - move gpiod declaration to preserve reversed tree style.
  - use devm_gpiod_get_index instead of devm_gpiod_get_index_optional
  since all errors are treated in the same way.

 drivers/video/fbdev/atmel_lcdfb.c | 31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 3dee267d7c75..076d24afbd72 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -18,10 +18,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -61,8 +61,7 @@ struct atmel_lcdfb_info {
 };
 
 struct atmel_lcdfb_power_ctrl_gpio {
-   int gpio;
-   int active_low;
+   struct gpio_desc *gpiod;
 
struct list_head list;
 };
@@ -1018,7 +1017,7 @@ static void atmel_lcdfb_power_control_gpio(struct 
atmel_lcdfb_pdata *pdata, int
struct atmel_lcdfb_power_ctrl_gpio *og;
 
list_for_each_entry(og, >pwr_gpios, list)
-   gpio_set_value(og->gpio, on);
+   gpiod_set_value(og->gpiod, on);
 }
 
 static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
@@ -1031,11 +1030,11 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
struct device_node *display_np;
struct device_node *timings_np;
struct display_timings *timings;
-   enum of_gpio_flags flags;
struct atmel_lcdfb_power_ctrl_gpio *og;
bool is_gpio_power = false;
+   struct gpio_desc *gpiod;
int ret = -ENOENT;
-   int i, gpio;
+   int i;
 
sinfo->config = (struct atmel_lcdfb_config*)
of_match_device(atmel_lcdfb_dt_ids, dev)->data;
@@ -1072,28 +1071,22 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
 
INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
-   for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
-   gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
-  i, );
-   if (gpio < 0)
+   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   gpiod = devm_gpiod_get_index(dev, "atmel,power-control",
+i, GPIOD_ASIS);
+   if (IS_ERR(gpiod))
continue;
 
og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
if (!og)
goto put_display_node;
 
-   og->gpio = gpio;
-   og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+   og->gpiod = gpiod;
is_gpio_power = true;
-   ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
-   if (ret) {
-   dev_err(dev, "request gpio %d failed\n", gpio);
-   goto put_display_node;
-   }
 
-   ret = gpio_direction_output(gpio, og->active_low);
+   ret = gpiod_direction_output(gpiod, gpiod_is_active_low(gpiod));
if (ret) {
-   dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
+   dev_err(dev, "set direction output gpio 
atmel,power-control[%d] failed\n", i);
goto put_display_node;
}
list_add(>list, >pwr_gpios);
-- 
2.12.2

[PATCH V2] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.

Signed-off-by: Ludovic Desroches 
Acked-by: Nicolas Ferre 
Reviewed-by: Linus Walleij 
Reviewed-by: Andy Shevchenko 
---
Changes
- V2:
  - remove of_gpio.h.
  - move gpiod declaration to preserve reversed tree style.
  - use devm_gpiod_get_index instead of devm_gpiod_get_index_optional
  since all errors are treated in the same way.

 drivers/video/fbdev/atmel_lcdfb.c | 31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 3dee267d7c75..076d24afbd72 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -18,10 +18,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -61,8 +61,7 @@ struct atmel_lcdfb_info {
 };
 
 struct atmel_lcdfb_power_ctrl_gpio {
-   int gpio;
-   int active_low;
+   struct gpio_desc *gpiod;
 
struct list_head list;
 };
@@ -1018,7 +1017,7 @@ static void atmel_lcdfb_power_control_gpio(struct 
atmel_lcdfb_pdata *pdata, int
struct atmel_lcdfb_power_ctrl_gpio *og;
 
list_for_each_entry(og, >pwr_gpios, list)
-   gpio_set_value(og->gpio, on);
+   gpiod_set_value(og->gpiod, on);
 }
 
 static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
@@ -1031,11 +1030,11 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
struct device_node *display_np;
struct device_node *timings_np;
struct display_timings *timings;
-   enum of_gpio_flags flags;
struct atmel_lcdfb_power_ctrl_gpio *og;
bool is_gpio_power = false;
+   struct gpio_desc *gpiod;
int ret = -ENOENT;
-   int i, gpio;
+   int i;
 
sinfo->config = (struct atmel_lcdfb_config*)
of_match_device(atmel_lcdfb_dt_ids, dev)->data;
@@ -1072,28 +1071,22 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
 
INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
-   for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
-   gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
-  i, );
-   if (gpio < 0)
+   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   gpiod = devm_gpiod_get_index(dev, "atmel,power-control",
+i, GPIOD_ASIS);
+   if (IS_ERR(gpiod))
continue;
 
og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
if (!og)
goto put_display_node;
 
-   og->gpio = gpio;
-   og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+   og->gpiod = gpiod;
is_gpio_power = true;
-   ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
-   if (ret) {
-   dev_err(dev, "request gpio %d failed\n", gpio);
-   goto put_display_node;
-   }
 
-   ret = gpio_direction_output(gpio, og->active_low);
+   ret = gpiod_direction_output(gpiod, gpiod_is_active_low(gpiod));
if (ret) {
-   dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
+   dev_err(dev, "set direction output gpio 
atmel,power-control[%d] failed\n", i);
goto put_display_node;
}
list_add(>list, >pwr_gpios);
-- 
2.12.2

[PATCH v2 6/7] arm64: tegra: Add Tegra194 chip device tree

[Mikko Perttunen]

Add the chip-level device tree, including binding headers, for the
NVIDIA Tegra194 "Xavier" system-on-chip. Only a small subset of devices
are initially available, enough to boot to UART console.

Signed-off-by: Mikko Perttunen 
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi   | 342 +
 include/dt-bindings/clock/tegra194-clock.h | 664 +
 include/dt-bindings/gpio/tegra194-gpio.h   |  59 +++
 include/dt-bindings/power/tegra194-powergate.h |  49 ++
 include/dt-bindings/reset/tegra194-reset.h | 166 +++
 5 files changed, 1280 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194.dtsi
 create mode 100644 include/dt-bindings/clock/tegra194-clock.h
 create mode 100644 include/dt-bindings/gpio/tegra194-gpio.h
 create mode 100644 include/dt-bindings/power/tegra194-powergate.h
 create mode 100644 include/dt-bindings/reset/tegra194-reset.h

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
new file mode 100644
index ..dda28d758cab
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "nvidia,tegra194";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   /* control backbone */
+   cbb {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x0 0x4000>;
+
+   uarta: serial@310 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0310 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTA>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTA>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   uartb: serial@311 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0311 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTB>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTB>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   uartd: serial@313 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0313 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTD>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTD>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   uarte: serial@314 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0314 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTE>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTE>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   uartf: serial@315 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0315 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTF>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTF>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   gen1_i2c: i2c@316 {
+   compatible = "nvidia,tegra194-i2c", 
"nvidia,tegra114-i2c";
+   reg = <0x0316 0x1>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < TEGRA194_CLK_I2C1>;
+   clock-names = "div-clk";
+   resets = < TEGRA194_RESET_I2C1>;
+   reset-names = "i2c";
+   status = "disabled";
+   };
+
+   uarth: serial@317 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = 

[PATCH v2 6/7] arm64: tegra: Add Tegra194 chip device tree

[Mikko Perttunen]

Add the chip-level device tree, including binding headers, for the
NVIDIA Tegra194 "Xavier" system-on-chip. Only a small subset of devices
are initially available, enough to boot to UART console.

Signed-off-by: Mikko Perttunen 
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi   | 342 +
 include/dt-bindings/clock/tegra194-clock.h | 664 +
 include/dt-bindings/gpio/tegra194-gpio.h   |  59 +++
 include/dt-bindings/power/tegra194-powergate.h |  49 ++
 include/dt-bindings/reset/tegra194-reset.h | 166 +++
 5 files changed, 1280 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194.dtsi
 create mode 100644 include/dt-bindings/clock/tegra194-clock.h
 create mode 100644 include/dt-bindings/gpio/tegra194-gpio.h
 create mode 100644 include/dt-bindings/power/tegra194-powergate.h
 create mode 100644 include/dt-bindings/reset/tegra194-reset.h

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
new file mode 100644
index ..dda28d758cab
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "nvidia,tegra194";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   /* control backbone */
+   cbb {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x0 0x4000>;
+
+   uarta: serial@310 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0310 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTA>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTA>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   uartb: serial@311 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0311 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTB>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTB>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   uartd: serial@313 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0313 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTD>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTD>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   uarte: serial@314 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0314 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTE>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTE>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   uartf: serial@315 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0315 0x40>;
+   reg-shift = <2>;
+   interrupts = ;
+   clocks = < TEGRA194_CLK_UARTF>;
+   clock-names = "serial";
+   resets = < TEGRA194_RESET_UARTF>;
+   reset-names = "serial";
+   status = "disabled";
+   };
+
+   gen1_i2c: i2c@316 {
+   compatible = "nvidia,tegra194-i2c", 
"nvidia,tegra114-i2c";
+   reg = <0x0316 0x1>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < TEGRA194_CLK_I2C1>;
+   clock-names = "div-clk";
+   resets = < TEGRA194_RESET_I2C1>;
+   reset-names = "i2c";
+   status = "disabled";
+   };
+
+   uarth: serial@317 {
+   compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
+   reg = <0x0317 0x40>;
+ 

[PATCH v2 1/7] firmware: tegra: Simplify channel management

[Mikko Perttunen]

The Tegra194 BPMP only implements 5 channels (4 to BPMP, 1 to CCPLEX),
and they are not placed contiguously in memory. The current channel
management in the BPMP driver does not support this.

Simplify and refactor the channel management such that only one atomic
transmit channel and one receive channel are supported, and channels
are not required to be placed contiguously in memory. The same
configuration also works on T186 so we end up with less code.

Signed-off-by: Mikko Perttunen 
---
 drivers/firmware/tegra/bpmp.c | 142 +++---
 include/soc/tegra/bpmp.h  |   4 +-
 2 files changed, 66 insertions(+), 80 deletions(-)

diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index a7f461f2e650..81bc2dce8626 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -70,57 +70,20 @@ void tegra_bpmp_put(struct tegra_bpmp *bpmp)
 }
 EXPORT_SYMBOL_GPL(tegra_bpmp_put);
 
-static int tegra_bpmp_channel_get_index(struct tegra_bpmp_channel *channel)
-{
-   return channel - channel->bpmp->channels;
-}
-
 static int
 tegra_bpmp_channel_get_thread_index(struct tegra_bpmp_channel *channel)
 {
struct tegra_bpmp *bpmp = channel->bpmp;
-   unsigned int offset, count;
+   unsigned int count;
int index;
 
-   offset = bpmp->soc->channels.thread.offset;
count = bpmp->soc->channels.thread.count;
 
-   index = tegra_bpmp_channel_get_index(channel);
-   if (index < 0)
-   return index;
-
-   if (index < offset || index >= offset + count)
+   index = channel - channel->bpmp->threaded_channels;
+   if (index < 0 || index >= count)
return -EINVAL;
 
-   return index - offset;
-}
-
-static struct tegra_bpmp_channel *
-tegra_bpmp_channel_get_thread(struct tegra_bpmp *bpmp, unsigned int index)
-{
-   unsigned int offset = bpmp->soc->channels.thread.offset;
-   unsigned int count = bpmp->soc->channels.thread.count;
-
-   if (index >= count)
-   return NULL;
-
-   return >channels[offset + index];
-}
-
-static struct tegra_bpmp_channel *
-tegra_bpmp_channel_get_tx(struct tegra_bpmp *bpmp)
-{
-   unsigned int offset = bpmp->soc->channels.cpu_tx.offset;
-
-   return >channels[offset + smp_processor_id()];
-}
-
-static struct tegra_bpmp_channel *
-tegra_bpmp_channel_get_rx(struct tegra_bpmp *bpmp)
-{
-   unsigned int offset = bpmp->soc->channels.cpu_rx.offset;
-
-   return >channels[offset];
+   return index;
 }
 
 static bool tegra_bpmp_message_valid(const struct tegra_bpmp_message *msg)
@@ -271,11 +234,7 @@ tegra_bpmp_write_threaded(struct tegra_bpmp *bpmp, 
unsigned int mrq,
goto unlock;
}
 
-   channel = tegra_bpmp_channel_get_thread(bpmp, index);
-   if (!channel) {
-   err = -EINVAL;
-   goto unlock;
-   }
+   channel = >threaded_channels[index];
 
if (!tegra_bpmp_master_free(channel)) {
err = -EBUSY;
@@ -328,12 +287,18 @@ int tegra_bpmp_transfer_atomic(struct tegra_bpmp *bpmp,
if (!tegra_bpmp_message_valid(msg))
return -EINVAL;
 
-   channel = tegra_bpmp_channel_get_tx(bpmp);
+   channel = bpmp->tx_channel;
+
+   spin_lock(>atomic_tx_lock);
 
err = tegra_bpmp_channel_write(channel, msg->mrq, MSG_ACK,
   msg->tx.data, msg->tx.size);
-   if (err < 0)
+   if (err < 0) {
+   spin_unlock(>atomic_tx_lock);
return err;
+   }
+
+   spin_unlock(>atomic_tx_lock);
 
err = mbox_send_message(bpmp->mbox.channel, NULL);
if (err < 0)
@@ -607,7 +572,7 @@ static void tegra_bpmp_handle_rx(struct mbox_client 
*client, void *data)
unsigned int i, count;
unsigned long *busy;
 
-   channel = tegra_bpmp_channel_get_rx(bpmp);
+   channel = bpmp->rx_channel;
count = bpmp->soc->channels.thread.count;
busy = bpmp->threaded.busy;
 
@@ -619,9 +584,7 @@ static void tegra_bpmp_handle_rx(struct mbox_client 
*client, void *data)
for_each_set_bit(i, busy, count) {
struct tegra_bpmp_channel *channel;
 
-   channel = tegra_bpmp_channel_get_thread(bpmp, i);
-   if (!channel)
-   continue;
+   channel = >threaded_channels[i];
 
if (tegra_bpmp_master_acked(channel)) {
tegra_bpmp_channel_signal(channel);
@@ -698,7 +661,6 @@ static void tegra_bpmp_channel_cleanup(struct 
tegra_bpmp_channel *channel)
 
 static int tegra_bpmp_probe(struct platform_device *pdev)
 {
-   struct tegra_bpmp_channel *channel;
struct tegra_bpmp *bpmp;
unsigned int i;
char tag[32];
@@ -758,24 +720,45 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
goto free_rx;
}
 
-   bpmp->num_channels = 

[PATCH v2 5/7] dt-bindings: tegra: Add documentation for nvidia,tegra194-pmc

[Mikko Perttunen]

The Tegra194 power management controller has one additional register
aperture to be specified in the device tree node.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt 
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt
index 078a58b0302f..5a3bf7c5a7a0 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt
@@ -3,6 +3,7 @@ NVIDIA Tegra Power Management Controller (PMC)
 Required properties:
 - compatible: Should contain one of the following:
   - "nvidia,tegra186-pmc": for Tegra186
+  - "nvidia,tegra194-pmc": for Tegra194
 - reg: Must contain an (offset, length) pair of the register set for each
   entry in reg-names.
 - reg-names: Must include the following entries:
@@ -10,6 +11,7 @@ Required properties:
   - "wake"
   - "aotag"
   - "scratch"
+  - "misc" (Only for Tegra194)
 
 Optional properties:
 - nvidia,invert-interrupt: If present, inverts the PMU interrupt signal.
-- 
2.1.4

[PATCH v2 1/7] firmware: tegra: Simplify channel management

[Mikko Perttunen]

The Tegra194 BPMP only implements 5 channels (4 to BPMP, 1 to CCPLEX),
and they are not placed contiguously in memory. The current channel
management in the BPMP driver does not support this.

Simplify and refactor the channel management such that only one atomic
transmit channel and one receive channel are supported, and channels
are not required to be placed contiguously in memory. The same
configuration also works on T186 so we end up with less code.

Signed-off-by: Mikko Perttunen 
---
 drivers/firmware/tegra/bpmp.c | 142 +++---
 include/soc/tegra/bpmp.h  |   4 +-
 2 files changed, 66 insertions(+), 80 deletions(-)

diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index a7f461f2e650..81bc2dce8626 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -70,57 +70,20 @@ void tegra_bpmp_put(struct tegra_bpmp *bpmp)
 }
 EXPORT_SYMBOL_GPL(tegra_bpmp_put);
 
-static int tegra_bpmp_channel_get_index(struct tegra_bpmp_channel *channel)
-{
-   return channel - channel->bpmp->channels;
-}
-
 static int
 tegra_bpmp_channel_get_thread_index(struct tegra_bpmp_channel *channel)
 {
struct tegra_bpmp *bpmp = channel->bpmp;
-   unsigned int offset, count;
+   unsigned int count;
int index;
 
-   offset = bpmp->soc->channels.thread.offset;
count = bpmp->soc->channels.thread.count;
 
-   index = tegra_bpmp_channel_get_index(channel);
-   if (index < 0)
-   return index;
-
-   if (index < offset || index >= offset + count)
+   index = channel - channel->bpmp->threaded_channels;
+   if (index < 0 || index >= count)
return -EINVAL;
 
-   return index - offset;
-}
-
-static struct tegra_bpmp_channel *
-tegra_bpmp_channel_get_thread(struct tegra_bpmp *bpmp, unsigned int index)
-{
-   unsigned int offset = bpmp->soc->channels.thread.offset;
-   unsigned int count = bpmp->soc->channels.thread.count;
-
-   if (index >= count)
-   return NULL;
-
-   return >channels[offset + index];
-}
-
-static struct tegra_bpmp_channel *
-tegra_bpmp_channel_get_tx(struct tegra_bpmp *bpmp)
-{
-   unsigned int offset = bpmp->soc->channels.cpu_tx.offset;
-
-   return >channels[offset + smp_processor_id()];
-}
-
-static struct tegra_bpmp_channel *
-tegra_bpmp_channel_get_rx(struct tegra_bpmp *bpmp)
-{
-   unsigned int offset = bpmp->soc->channels.cpu_rx.offset;
-
-   return >channels[offset];
+   return index;
 }
 
 static bool tegra_bpmp_message_valid(const struct tegra_bpmp_message *msg)
@@ -271,11 +234,7 @@ tegra_bpmp_write_threaded(struct tegra_bpmp *bpmp, 
unsigned int mrq,
goto unlock;
}
 
-   channel = tegra_bpmp_channel_get_thread(bpmp, index);
-   if (!channel) {
-   err = -EINVAL;
-   goto unlock;
-   }
+   channel = >threaded_channels[index];
 
if (!tegra_bpmp_master_free(channel)) {
err = -EBUSY;
@@ -328,12 +287,18 @@ int tegra_bpmp_transfer_atomic(struct tegra_bpmp *bpmp,
if (!tegra_bpmp_message_valid(msg))
return -EINVAL;
 
-   channel = tegra_bpmp_channel_get_tx(bpmp);
+   channel = bpmp->tx_channel;
+
+   spin_lock(>atomic_tx_lock);
 
err = tegra_bpmp_channel_write(channel, msg->mrq, MSG_ACK,
   msg->tx.data, msg->tx.size);
-   if (err < 0)
+   if (err < 0) {
+   spin_unlock(>atomic_tx_lock);
return err;
+   }
+
+   spin_unlock(>atomic_tx_lock);
 
err = mbox_send_message(bpmp->mbox.channel, NULL);
if (err < 0)
@@ -607,7 +572,7 @@ static void tegra_bpmp_handle_rx(struct mbox_client 
*client, void *data)
unsigned int i, count;
unsigned long *busy;
 
-   channel = tegra_bpmp_channel_get_rx(bpmp);
+   channel = bpmp->rx_channel;
count = bpmp->soc->channels.thread.count;
busy = bpmp->threaded.busy;
 
@@ -619,9 +584,7 @@ static void tegra_bpmp_handle_rx(struct mbox_client 
*client, void *data)
for_each_set_bit(i, busy, count) {
struct tegra_bpmp_channel *channel;
 
-   channel = tegra_bpmp_channel_get_thread(bpmp, i);
-   if (!channel)
-   continue;
+   channel = >threaded_channels[i];
 
if (tegra_bpmp_master_acked(channel)) {
tegra_bpmp_channel_signal(channel);
@@ -698,7 +661,6 @@ static void tegra_bpmp_channel_cleanup(struct 
tegra_bpmp_channel *channel)
 
 static int tegra_bpmp_probe(struct platform_device *pdev)
 {
-   struct tegra_bpmp_channel *channel;
struct tegra_bpmp *bpmp;
unsigned int i;
char tag[32];
@@ -758,24 +720,45 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
goto free_rx;
}
 
-   bpmp->num_channels = bpmp->soc->channels.cpu_tx.count +
-   

[PATCH v2 5/7] dt-bindings: tegra: Add documentation for nvidia,tegra194-pmc

[Mikko Perttunen]

The Tegra194 power management controller has one additional register
aperture to be specified in the device tree node.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt 
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt
index 078a58b0302f..5a3bf7c5a7a0 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt
@@ -3,6 +3,7 @@ NVIDIA Tegra Power Management Controller (PMC)
 Required properties:
 - compatible: Should contain one of the following:
   - "nvidia,tegra186-pmc": for Tegra186
+  - "nvidia,tegra194-pmc": for Tegra194
 - reg: Must contain an (offset, length) pair of the register set for each
   entry in reg-names.
 - reg-names: Must include the following entries:
@@ -10,6 +11,7 @@ Required properties:
   - "wake"
   - "aotag"
   - "scratch"
+  - "misc" (Only for Tegra194)
 
 Optional properties:
 - nvidia,invert-interrupt: If present, inverts the PMU interrupt signal.
-- 
2.1.4

[PATCH v2 0/7] Initial support for NVIDIA Tegra194

[Mikko Perttunen]

Hello everyone,

this series adds initial support for the NVIDIA Tegra194 "Xavier"
system-on-chip. Initially UART, I2C, SDMMC, as well as the PMIC
are supported, allowing booting to a console.

The changes consist almost completely of the new device trees,
however some fixes are required in the BPMP driver to support the
new channel layout in Tegra194.

The series has been tested on Tegra186 (Jetson TX2) and Tegra194
(P2972).

Cheers,
Mikko

Mikko Perttunen (7):
  firmware: tegra: Simplify channel management
  soc/tegra: Add Tegra194 SoC configuration option
  soc/tegra: pmc: Add Tegra194 compatibility string
  dt-bindings: tegra: Add missing chips and NVIDIA boards
  dt-bindings: tegra: Add documentation for nvidia,tegra194-pmc
  arm64: tegra: Add Tegra194 chip device tree
  arm64: tegra: Add device tree for the Tegra194 P2972- board

 Documentation/devicetree/bindings/arm/tegra.txt|  16 +
 .../bindings/arm/tegra/nvidia,tegra186-pmc.txt |   2 +
 arch/arm64/boot/dts/nvidia/Makefile|   1 +
 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 248 
 arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts |  16 +
 arch/arm64/boot/dts/nvidia/tegra194.dtsi   | 342 +++
 arch/arm64/configs/defconfig   |   1 +
 drivers/firmware/tegra/bpmp.c  | 142 ++---
 drivers/soc/tegra/Kconfig  |  10 +
 drivers/soc/tegra/pmc.c|   1 +
 include/dt-bindings/clock/tegra194-clock.h | 664 +
 include/dt-bindings/gpio/tegra194-gpio.h   |  59 ++
 include/dt-bindings/power/tegra194-powergate.h |  49 ++
 include/dt-bindings/reset/tegra194-reset.h | 166 ++
 include/soc/tegra/bpmp.h   |   4 +-
 15 files changed, 1641 insertions(+), 80 deletions(-)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194.dtsi
 create mode 100644 include/dt-bindings/clock/tegra194-clock.h
 create mode 100644 include/dt-bindings/gpio/tegra194-gpio.h
 create mode 100644 include/dt-bindings/power/tegra194-powergate.h
 create mode 100644 include/dt-bindings/reset/tegra194-reset.h

-- 
2.1.4

[PATCH v2 4/7] dt-bindings: tegra: Add missing chips and NVIDIA boards

[Mikko Perttunen]

Add compatibility strings for supported but undocumented Tegra chips
(Tegra114/124/132/210/186/194) and reference boards.

Signed-off-by: Mikko Perttunen 
---

Notes:
v2:
- add patch

 Documentation/devicetree/bindings/arm/tegra.txt | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/tegra.txt 
b/Documentation/devicetree/bindings/arm/tegra.txt
index 7f1411bbabf7..32f62bb7006d 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -9,6 +9,12 @@ following compatible values:
 
   nvidia,tegra20
   nvidia,tegra30
+  nvidia,tegra114
+  nvidia,tegra124
+  nvidia,tegra132
+  nvidia,tegra210
+  nvidia,tegra186
+  nvidia,tegra194
 
 Boards
 ---
@@ -26,8 +32,18 @@ board-specific compatible values:
   nvidia,cardhu
   nvidia,cardhu-a02
   nvidia,cardhu-a04
+  nvidia,dalmore
   nvidia,harmony
+  nvidia,jetson-tk1
+  nvidia,norrin
+  nvidia,p2371-
+  nvidia,p2371-2180
+  nvidia,p2571
+  nvidia,p2771-
+  nvidia,p2972-
+  nvidia,roth
   nvidia,seaboard
+  nvidia,tn7
   nvidia,ventana
   toradex,apalis_t30
   toradex,apalis_t30-eval
-- 
2.1.4

[PATCH v2 7/7] arm64: tegra: Add device tree for the Tegra194 P2972-0000 board

[Mikko Perttunen]

Add device tree files for the Tegra194 P2972- development board.
The board consists of the P2888 compute module and the P2822 baseboard.

Signed-off-by: Mikko Perttunen 
---
 arch/arm64/boot/dts/nvidia/Makefile|   1 +
 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 248 +
 arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts |  16 ++
 3 files changed, 265 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts

diff --git a/arch/arm64/boot/dts/nvidia/Makefile 
b/arch/arm64/boot/dts/nvidia/Makefile
index 676aa2f238d1..7c13d7df484e 100644
--- a/arch/arm64/boot/dts/nvidia/Makefile
+++ b/arch/arm64/boot/dts/nvidia/Makefile
@@ -5,3 +5,4 @@ dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-2180.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2571.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-smaug.dtb
 dtb-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186-p2771-.dtb
+dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-p2972-.dtb
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
new file mode 100644
index ..ecb034177fc2
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "tegra194.dtsi"
+
+#include 
+
+/ {
+   model = "NVIDIA Tegra194 P2888 Processor Module";
+   compatible = "nvidia,p2888", "nvidia,tegra194";
+
+   aliases {
+   sdhci0 = "/cbb/sdhci@346";
+   sdhci1 = "/cbb/sdhci@340";
+   serial0 = 
+   i2c0 = "/bpmp/i2c";
+   i2c1 = "/cbb/i2c@316";
+   i2c2 = "/cbb/i2c@c24";
+   i2c3 = "/cbb/i2c@318";
+   i2c4 = "/cbb/i2c@319";
+   i2c5 = "/cbb/i2c@31c";
+   i2c6 = "/cbb/i2c@c25";
+   i2c7 = "/cbb/i2c@31e";
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,115200n8";
+   stdout-path = "serial0:115200n8";
+   };
+
+   cbb {
+   serial@311 {
+   status = "okay";
+   };
+
+   /* SDMMC1 (SD/MMC) */
+   sdhci@340 {
+/*
+   cd-gpios = < TEGRA194_MAIN_GPIO(A, 0) 
GPIO_ACTIVE_LOW>;
+*/
+   };
+
+   /* SDMMC4 (eMMC) */
+   sdhci@346 {
+   status = "okay";
+   bus-width = <8>;
+   non-removable;
+
+   vqmmc-supply = <_1v8ls>;
+   vmmc-supply = <_emmc_3v3>;
+   };
+
+   pmc@c36 {
+   nvidia,invert-interrupt;
+   };
+   };
+
+   bpmp {
+   i2c {
+   status = "okay";
+
+   pmic: pmic@3c {
+   compatible = "maxim,max20024";
+   reg = <0x3c>;
+
+   interrupts = ;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+
+   #gpio-cells = <2>;
+   gpio-controller;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_default>;
+
+   max20024_default: pinmux {
+   gpio0 {
+   pins = "gpio0";
+   function = "gpio";
+   };
+
+   gpio1 {
+   pins = "gpio1";
+   function = "fps-out";
+   maxim,active-fps-source = 
;
+   };
+
+   gpio2 {
+   pins = "gpio2";
+   function = "fps-out";
+   maxim,active-fps-source = 
;
+   };
+
+   gpio3 {
+   pins = "gpio3";
+   function = "fps-out";
+   maxim,active-fps-source = 
;
+   };
+
+   gpio4 {
+   pins = "gpio4";
+   function = "32k-out1";
+   drive-push-pull = <1>;
+   };
+
+  

[PATCH v2 0/7] Initial support for NVIDIA Tegra194

[Mikko Perttunen]

Hello everyone,

this series adds initial support for the NVIDIA Tegra194 "Xavier"
system-on-chip. Initially UART, I2C, SDMMC, as well as the PMIC
are supported, allowing booting to a console.

The changes consist almost completely of the new device trees,
however some fixes are required in the BPMP driver to support the
new channel layout in Tegra194.

The series has been tested on Tegra186 (Jetson TX2) and Tegra194
(P2972).

Cheers,
Mikko

Mikko Perttunen (7):
  firmware: tegra: Simplify channel management
  soc/tegra: Add Tegra194 SoC configuration option
  soc/tegra: pmc: Add Tegra194 compatibility string
  dt-bindings: tegra: Add missing chips and NVIDIA boards
  dt-bindings: tegra: Add documentation for nvidia,tegra194-pmc
  arm64: tegra: Add Tegra194 chip device tree
  arm64: tegra: Add device tree for the Tegra194 P2972- board

 Documentation/devicetree/bindings/arm/tegra.txt|  16 +
 .../bindings/arm/tegra/nvidia,tegra186-pmc.txt |   2 +
 arch/arm64/boot/dts/nvidia/Makefile|   1 +
 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 248 
 arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts |  16 +
 arch/arm64/boot/dts/nvidia/tegra194.dtsi   | 342 +++
 arch/arm64/configs/defconfig   |   1 +
 drivers/firmware/tegra/bpmp.c  | 142 ++---
 drivers/soc/tegra/Kconfig  |  10 +
 drivers/soc/tegra/pmc.c|   1 +
 include/dt-bindings/clock/tegra194-clock.h | 664 +
 include/dt-bindings/gpio/tegra194-gpio.h   |  59 ++
 include/dt-bindings/power/tegra194-powergate.h |  49 ++
 include/dt-bindings/reset/tegra194-reset.h | 166 ++
 include/soc/tegra/bpmp.h   |   4 +-
 15 files changed, 1641 insertions(+), 80 deletions(-)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194.dtsi
 create mode 100644 include/dt-bindings/clock/tegra194-clock.h
 create mode 100644 include/dt-bindings/gpio/tegra194-gpio.h
 create mode 100644 include/dt-bindings/power/tegra194-powergate.h
 create mode 100644 include/dt-bindings/reset/tegra194-reset.h

-- 
2.1.4

[PATCH v2 4/7] dt-bindings: tegra: Add missing chips and NVIDIA boards

[Mikko Perttunen]

Add compatibility strings for supported but undocumented Tegra chips
(Tegra114/124/132/210/186/194) and reference boards.

Signed-off-by: Mikko Perttunen 
---

Notes:
v2:
- add patch

 Documentation/devicetree/bindings/arm/tegra.txt | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/tegra.txt 
b/Documentation/devicetree/bindings/arm/tegra.txt
index 7f1411bbabf7..32f62bb7006d 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -9,6 +9,12 @@ following compatible values:
 
   nvidia,tegra20
   nvidia,tegra30
+  nvidia,tegra114
+  nvidia,tegra124
+  nvidia,tegra132
+  nvidia,tegra210
+  nvidia,tegra186
+  nvidia,tegra194
 
 Boards
 ---
@@ -26,8 +32,18 @@ board-specific compatible values:
   nvidia,cardhu
   nvidia,cardhu-a02
   nvidia,cardhu-a04
+  nvidia,dalmore
   nvidia,harmony
+  nvidia,jetson-tk1
+  nvidia,norrin
+  nvidia,p2371-
+  nvidia,p2371-2180
+  nvidia,p2571
+  nvidia,p2771-
+  nvidia,p2972-
+  nvidia,roth
   nvidia,seaboard
+  nvidia,tn7
   nvidia,ventana
   toradex,apalis_t30
   toradex,apalis_t30-eval
-- 
2.1.4

[PATCH v2 7/7] arm64: tegra: Add device tree for the Tegra194 P2972-0000 board

[Mikko Perttunen]

Add device tree files for the Tegra194 P2972- development board.
The board consists of the P2888 compute module and the P2822 baseboard.

Signed-off-by: Mikko Perttunen 
---
 arch/arm64/boot/dts/nvidia/Makefile|   1 +
 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 248 +
 arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts |  16 ++
 3 files changed, 265 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts

diff --git a/arch/arm64/boot/dts/nvidia/Makefile 
b/arch/arm64/boot/dts/nvidia/Makefile
index 676aa2f238d1..7c13d7df484e 100644
--- a/arch/arm64/boot/dts/nvidia/Makefile
+++ b/arch/arm64/boot/dts/nvidia/Makefile
@@ -5,3 +5,4 @@ dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-2180.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2571.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-smaug.dtb
 dtb-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186-p2771-.dtb
+dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-p2972-.dtb
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
new file mode 100644
index ..ecb034177fc2
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "tegra194.dtsi"
+
+#include 
+
+/ {
+   model = "NVIDIA Tegra194 P2888 Processor Module";
+   compatible = "nvidia,p2888", "nvidia,tegra194";
+
+   aliases {
+   sdhci0 = "/cbb/sdhci@346";
+   sdhci1 = "/cbb/sdhci@340";
+   serial0 = 
+   i2c0 = "/bpmp/i2c";
+   i2c1 = "/cbb/i2c@316";
+   i2c2 = "/cbb/i2c@c24";
+   i2c3 = "/cbb/i2c@318";
+   i2c4 = "/cbb/i2c@319";
+   i2c5 = "/cbb/i2c@31c";
+   i2c6 = "/cbb/i2c@c25";
+   i2c7 = "/cbb/i2c@31e";
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,115200n8";
+   stdout-path = "serial0:115200n8";
+   };
+
+   cbb {
+   serial@311 {
+   status = "okay";
+   };
+
+   /* SDMMC1 (SD/MMC) */
+   sdhci@340 {
+/*
+   cd-gpios = < TEGRA194_MAIN_GPIO(A, 0) 
GPIO_ACTIVE_LOW>;
+*/
+   };
+
+   /* SDMMC4 (eMMC) */
+   sdhci@346 {
+   status = "okay";
+   bus-width = <8>;
+   non-removable;
+
+   vqmmc-supply = <_1v8ls>;
+   vmmc-supply = <_emmc_3v3>;
+   };
+
+   pmc@c36 {
+   nvidia,invert-interrupt;
+   };
+   };
+
+   bpmp {
+   i2c {
+   status = "okay";
+
+   pmic: pmic@3c {
+   compatible = "maxim,max20024";
+   reg = <0x3c>;
+
+   interrupts = ;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+
+   #gpio-cells = <2>;
+   gpio-controller;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_default>;
+
+   max20024_default: pinmux {
+   gpio0 {
+   pins = "gpio0";
+   function = "gpio";
+   };
+
+   gpio1 {
+   pins = "gpio1";
+   function = "fps-out";
+   maxim,active-fps-source = 
;
+   };
+
+   gpio2 {
+   pins = "gpio2";
+   function = "fps-out";
+   maxim,active-fps-source = 
;
+   };
+
+   gpio3 {
+   pins = "gpio3";
+   function = "fps-out";
+   maxim,active-fps-source = 
;
+   };
+
+   gpio4 {
+   pins = "gpio4";
+   function = "32k-out1";
+   drive-push-pull = <1>;
+   };
+
+ 

[PATCH v2 3/7] soc/tegra: pmc: Add Tegra194 compatibility string

[Mikko Perttunen]

The Tegra194 PMC is mostly compatible with Tegra186, including in all
currently supported features. As such, add a new compatibility string
but point to the existing Tegra186 SoC data for now.

Signed-off-by: Mikko Perttunen 
---
 drivers/soc/tegra/pmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index ce62a47a6647..a2df230bf51a 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -1920,6 +1920,7 @@ static const struct tegra_pmc_soc tegra186_pmc_soc = {
 };
 
 static const struct of_device_id tegra_pmc_match[] = {
+   { .compatible = "nvidia,tegra194-pmc", .data = _pmc_soc },
{ .compatible = "nvidia,tegra186-pmc", .data = _pmc_soc },
{ .compatible = "nvidia,tegra210-pmc", .data = _pmc_soc },
{ .compatible = "nvidia,tegra132-pmc", .data = _pmc_soc },
-- 
2.1.4

[PATCH v2 3/7] soc/tegra: pmc: Add Tegra194 compatibility string

[Mikko Perttunen]

The Tegra194 PMC is mostly compatible with Tegra186, including in all
currently supported features. As such, add a new compatibility string
but point to the existing Tegra186 SoC data for now.

Signed-off-by: Mikko Perttunen 
---
 drivers/soc/tegra/pmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index ce62a47a6647..a2df230bf51a 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -1920,6 +1920,7 @@ static const struct tegra_pmc_soc tegra186_pmc_soc = {
 };
 
 static const struct of_device_id tegra_pmc_match[] = {
+   { .compatible = "nvidia,tegra194-pmc", .data = _pmc_soc },
{ .compatible = "nvidia,tegra186-pmc", .data = _pmc_soc },
{ .compatible = "nvidia,tegra210-pmc", .data = _pmc_soc },
{ .compatible = "nvidia,tegra132-pmc", .data = _pmc_soc },
-- 
2.1.4

[PATCH v2 2/7] soc/tegra: Add Tegra194 SoC configuration option

[Mikko Perttunen]

Add the configuration option to enable support for the Tegra194
system-on-chip, and enable it by default in the arm64 defconfig.

Signed-off-by: Mikko Perttunen 
---
 arch/arm64/configs/defconfig |  1 +
 drivers/soc/tegra/Kconfig| 10 ++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 78f669a21a9b..5a8f15baa850 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -537,6 +537,7 @@ CONFIG_ROCKCHIP_PM_DOMAINS=y
 CONFIG_ARCH_TEGRA_132_SOC=y
 CONFIG_ARCH_TEGRA_210_SOC=y
 CONFIG_ARCH_TEGRA_186_SOC=y
+CONFIG_ARCH_TEGRA_194_SOC=y
 CONFIG_EXTCON_USB_GPIO=y
 CONFIG_IIO=y
 CONFIG_EXYNOS_ADC=y
diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index 89ebe22a3e27..fe4481676da6 100644
--- a/drivers/soc/tegra/Kconfig
+++ b/drivers/soc/tegra/Kconfig
@@ -104,6 +104,16 @@ config ARCH_TEGRA_186_SOC
  multi-format support, ISP for image capture processing and BPMP for
  power management.
 
+config ARCH_TEGRA_194_SOC
+   bool "NVIDIA Tegra194 SoC"
+   select MAILBOX
+   select TEGRA_BPMP
+   select TEGRA_HSP_MBOX
+   select TEGRA_IVC
+   select SOC_TEGRA_PMC
+   help
+ Enable support for the NVIDIA Tegra194 SoC.
+
 endif
 endif
 
-- 
2.1.4

[PATCH v2 2/7] soc/tegra: Add Tegra194 SoC configuration option

[Mikko Perttunen]

Add the configuration option to enable support for the Tegra194
system-on-chip, and enable it by default in the arm64 defconfig.

Signed-off-by: Mikko Perttunen 
---
 arch/arm64/configs/defconfig |  1 +
 drivers/soc/tegra/Kconfig| 10 ++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 78f669a21a9b..5a8f15baa850 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -537,6 +537,7 @@ CONFIG_ROCKCHIP_PM_DOMAINS=y
 CONFIG_ARCH_TEGRA_132_SOC=y
 CONFIG_ARCH_TEGRA_210_SOC=y
 CONFIG_ARCH_TEGRA_186_SOC=y
+CONFIG_ARCH_TEGRA_194_SOC=y
 CONFIG_EXTCON_USB_GPIO=y
 CONFIG_IIO=y
 CONFIG_EXYNOS_ADC=y
diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index 89ebe22a3e27..fe4481676da6 100644
--- a/drivers/soc/tegra/Kconfig
+++ b/drivers/soc/tegra/Kconfig
@@ -104,6 +104,16 @@ config ARCH_TEGRA_186_SOC
  multi-format support, ISP for image capture processing and BPMP for
  power management.
 
+config ARCH_TEGRA_194_SOC
+   bool "NVIDIA Tegra194 SoC"
+   select MAILBOX
+   select TEGRA_BPMP
+   select TEGRA_HSP_MBOX
+   select TEGRA_IVC
+   select SOC_TEGRA_PMC
+   help
+ Enable support for the NVIDIA Tegra194 SoC.
+
 endif
 endif
 
-- 
2.1.4

Re: [PATCH v3 3/3] x86/entry: Clear registers for compat syscalls

[Ingo Molnar]

* Dan Williams  wrote:

> From: Andi Kleen 
> 
> At entry userspace may have populated registers with values that could
> be useful in a speculative execution attack. Clear them to minimize the
> kernel's attack surface.
> 
> [djbw: interleave the clearing with setting up the stack ]
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: Andy Lutomirski 
> Signed-off-by: Andi Kleen 
> Signed-off-by: Dan Williams 
> ---
>  arch/x86/entry/entry_64_compat.S |   30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/x86/entry/entry_64_compat.S 
> b/arch/x86/entry/entry_64_compat.S
> index 98d5358e4041..fd65e016e413 100644
> --- a/arch/x86/entry/entry_64_compat.S
> +++ b/arch/x86/entry/entry_64_compat.S
> @@ -85,15 +85,25 @@ ENTRY(entry_SYSENTER_compat)
>   pushq   %rcx/* pt_regs->cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
> + xorq%r8, %r8/* nospec   r8 */
>   pushq   $0  /* pt_regs->r9  = 0 */
> + xorq%r9, %r9/* nospec   r9 */
>   pushq   $0  /* pt_regs->r10 = 0 */
> + xorq%r10, %r10  /* nospec   r10 */
>   pushq   $0  /* pt_regs->r11 = 0 */
> + xorq%r11, %r11  /* nospec   r11 */
>   pushq   %rbx/* pt_regs->rbx */
> + xorl%ebx, %ebx  /* nospec   rbx */
>   pushq   %rbp/* pt_regs->rbp (will be overwritten) */
> + xorl%ebp, %ebp  /* nospec   rbp */
>   pushq   $0  /* pt_regs->r12 = 0 */
> + xorq%r12, %r12  /* nospec   r12 */
>   pushq   $0  /* pt_regs->r13 = 0 */
> + xorq%r13, %r13  /* nospec   r13 */
>   pushq   $0  /* pt_regs->r14 = 0 */
> + xorq%r14, %r14  /* nospec   r14 */
>   pushq   $0  /* pt_regs->r15 = 0 */
> + xorq%r15, %r15  /* nospec   r15 */
>   cld
>  
>   /*
> @@ -214,15 +224,25 @@ GLOBAL(entry_SYSCALL_compat_after_hwframe)
>   pushq   %rbp/* pt_regs->cx (stashed in bp) */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
> + xorq%r8, %r8/* nospec   r8 */
>   pushq   $0  /* pt_regs->r9  = 0 */
> + xorq%r9, %r9/* nospec   r9 */
>   pushq   $0  /* pt_regs->r10 = 0 */
> + xorq%r10, %r10  /* nospec   r10 */
>   pushq   $0  /* pt_regs->r11 = 0 */
> + xorq%r11, %r11  /* nospec   r11 */
>   pushq   %rbx/* pt_regs->rbx */
> + xorl%ebx, %ebx  /* nospec   rbx */
>   pushq   %rbp/* pt_regs->rbp (will be overwritten) */
> + xorl%ebp, %ebp  /* nospec   rbp */
>   pushq   $0  /* pt_regs->r12 = 0 */
> + xorq%r12, %r12  /* nospec   r12 */
>   pushq   $0  /* pt_regs->r13 = 0 */
> + xorq%r13, %r13  /* nospec   r13 */
>   pushq   $0  /* pt_regs->r14 = 0 */
> + xorq%r14, %r14  /* nospec   r14 */
>   pushq   $0  /* pt_regs->r15 = 0 */
> + xorq%r15, %r15  /* nospec   r15 */

I really love it how you've aligned the comment fields vertically - nice!

>   /*
>* User mode is traced as though IRQs are on, and SYSENTER
> @@ -338,15 +358,25 @@ ENTRY(entry_INT80_compat)
>   pushq   %rcx/* pt_regs->cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
> + xorq%r8, %r8/* nospec   r8 */
>   pushq   $0  /* pt_regs->r9  = 0 */
> + xorq%r9, %r9/* nospec   r9 */
>   pushq   $0  /* pt_regs->r10 = 0 */
> + xorq%r10, %r10  /* nospec   r10 */
>   pushq   $0  /* pt_regs->r11 = 0 */
> + xorq%r11, %r11  /* nospec   r11 */
>   pushq   %rbx/* pt_regs->rbx */
> + xorl%ebx, %ebx  /* nospec   rbx */
>   pushq   %rbp/* pt_regs->rbp */
> + xorl%ebp, %ebp  /* nospec   rbp */
>   pushq   %r12/* pt_regs->r12 */
> + xorq%r12, %r12  /* nospec   r12 */
>   pushq   %r13 

Re: [PATCH] sched/deadline: Make update_curr_dl() more accurate

[Juri Lelli]

Hi,

On 06/02/18 09:55, Wen Yang wrote:
> rq->clock_task may be updated between the two calls of
> rq_clock_task() in update_curr_dl(). Calling rq_clock_task() only
> once makes it more accurate and efficient, taking update_curr() as
> reference.
> 
> Signed-off-by: Wen Yang 
> Reviewed-by: Jiang Biao 
> Suggested-by: Peter Zijlstra 

Acked-by: Juri Lelli 

Thanks!

- Juri

Re: [PATCH v3 3/3] x86/entry: Clear registers for compat syscalls

[Ingo Molnar]

* Dan Williams  wrote:

> From: Andi Kleen 
> 
> At entry userspace may have populated registers with values that could
> be useful in a speculative execution attack. Clear them to minimize the
> kernel's attack surface.
> 
> [djbw: interleave the clearing with setting up the stack ]
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: Andy Lutomirski 
> Signed-off-by: Andi Kleen 
> Signed-off-by: Dan Williams 
> ---
>  arch/x86/entry/entry_64_compat.S |   30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/x86/entry/entry_64_compat.S 
> b/arch/x86/entry/entry_64_compat.S
> index 98d5358e4041..fd65e016e413 100644
> --- a/arch/x86/entry/entry_64_compat.S
> +++ b/arch/x86/entry/entry_64_compat.S
> @@ -85,15 +85,25 @@ ENTRY(entry_SYSENTER_compat)
>   pushq   %rcx/* pt_regs->cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
> + xorq%r8, %r8/* nospec   r8 */
>   pushq   $0  /* pt_regs->r9  = 0 */
> + xorq%r9, %r9/* nospec   r9 */
>   pushq   $0  /* pt_regs->r10 = 0 */
> + xorq%r10, %r10  /* nospec   r10 */
>   pushq   $0  /* pt_regs->r11 = 0 */
> + xorq%r11, %r11  /* nospec   r11 */
>   pushq   %rbx/* pt_regs->rbx */
> + xorl%ebx, %ebx  /* nospec   rbx */
>   pushq   %rbp/* pt_regs->rbp (will be overwritten) */
> + xorl%ebp, %ebp  /* nospec   rbp */
>   pushq   $0  /* pt_regs->r12 = 0 */
> + xorq%r12, %r12  /* nospec   r12 */
>   pushq   $0  /* pt_regs->r13 = 0 */
> + xorq%r13, %r13  /* nospec   r13 */
>   pushq   $0  /* pt_regs->r14 = 0 */
> + xorq%r14, %r14  /* nospec   r14 */
>   pushq   $0  /* pt_regs->r15 = 0 */
> + xorq%r15, %r15  /* nospec   r15 */
>   cld
>  
>   /*
> @@ -214,15 +224,25 @@ GLOBAL(entry_SYSCALL_compat_after_hwframe)
>   pushq   %rbp/* pt_regs->cx (stashed in bp) */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
> + xorq%r8, %r8/* nospec   r8 */
>   pushq   $0  /* pt_regs->r9  = 0 */
> + xorq%r9, %r9/* nospec   r9 */
>   pushq   $0  /* pt_regs->r10 = 0 */
> + xorq%r10, %r10  /* nospec   r10 */
>   pushq   $0  /* pt_regs->r11 = 0 */
> + xorq%r11, %r11  /* nospec   r11 */
>   pushq   %rbx/* pt_regs->rbx */
> + xorl%ebx, %ebx  /* nospec   rbx */
>   pushq   %rbp/* pt_regs->rbp (will be overwritten) */
> + xorl%ebp, %ebp  /* nospec   rbp */
>   pushq   $0  /* pt_regs->r12 = 0 */
> + xorq%r12, %r12  /* nospec   r12 */
>   pushq   $0  /* pt_regs->r13 = 0 */
> + xorq%r13, %r13  /* nospec   r13 */
>   pushq   $0  /* pt_regs->r14 = 0 */
> + xorq%r14, %r14  /* nospec   r14 */
>   pushq   $0  /* pt_regs->r15 = 0 */
> + xorq%r15, %r15  /* nospec   r15 */

I really love it how you've aligned the comment fields vertically - nice!

>   /*
>* User mode is traced as though IRQs are on, and SYSENTER
> @@ -338,15 +358,25 @@ ENTRY(entry_INT80_compat)
>   pushq   %rcx/* pt_regs->cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
> + xorq%r8, %r8/* nospec   r8 */
>   pushq   $0  /* pt_regs->r9  = 0 */
> + xorq%r9, %r9/* nospec   r9 */
>   pushq   $0  /* pt_regs->r10 = 0 */
> + xorq%r10, %r10  /* nospec   r10 */
>   pushq   $0  /* pt_regs->r11 = 0 */
> + xorq%r11, %r11  /* nospec   r11 */
>   pushq   %rbx/* pt_regs->rbx */
> + xorl%ebx, %ebx  /* nospec   rbx */
>   pushq   %rbp/* pt_regs->rbp */
> + xorl%ebp, %ebp  /* nospec   rbp */
>   pushq   %r12/* pt_regs->r12 */
> + xorq%r12, %r12  /* nospec   r12 */
>   pushq   %r13/* pt_regs->r13 */
> + xorq%r13, %r13  /* nospec   r13 */
>   pushq   %r14/* pt_regs->r14 */
> + xorq

Re: [PATCH] sched/deadline: Make update_curr_dl() more accurate

[Juri Lelli]

Hi,

On 06/02/18 09:55, Wen Yang wrote:
> rq->clock_task may be updated between the two calls of
> rq_clock_task() in update_curr_dl(). Calling rq_clock_task() only
> once makes it more accurate and efficient, taking update_curr() as
> reference.
> 
> Signed-off-by: Wen Yang 
> Reviewed-by: Jiang Biao 
> Suggested-by: Peter Zijlstra 

Acked-by: Juri Lelli 

Thanks!

- Juri

[PATCH v2] Documentation/ABI: update infiniband sysfs interfaces

[Aishwarya Pant]

Add documentation for core and hardware specific infiniband interfaces.
The descriptions have been collected from git commit logs, reading
through code and data sheets. Some drivers have incomplete doc and are
annotated with the comment '[to be documented]'.

Signed-off-by: Aishwarya Pant 
---
Changes in v2:
- Move infiniband interface from testing to stable
- Fix typos
- Update description of cap_mask, port_xmit_constraint_errors and
  port_rcv_constraint_errors
- Add doc for hw_counters
- Remove old documentation

 Documentation/ABI/stable/sysfs-class-infiniband  | 818 +++
 Documentation/ABI/testing/sysfs-class-infiniband |  16 -
 Documentation/infiniband/sysfs.txt   | 129 +---
 3 files changed, 820 insertions(+), 143 deletions(-)
 create mode 100644 Documentation/ABI/stable/sysfs-class-infiniband
 delete mode 100644 Documentation/ABI/testing/sysfs-class-infiniband

diff --git a/Documentation/ABI/stable/sysfs-class-infiniband 
b/Documentation/ABI/stable/sysfs-class-infiniband
new file mode 100644
index ..f9c709a8d0ab
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-class-infiniband
@@ -0,0 +1,818 @@
+sysfs interface common for all infiniband devices
+-
+
+What:  /sys/class/infiniband//node_type
+What:  /sys/class/infiniband//node_guid
+What:  /sys/class/infiniband//sys_image_guid
+Date:  Apr, 2005
+KernelVersion: v2.6.12
+Contact:   linux-r...@vger.kernel.org
+Description:
+   node_type:  (RO) Node type (CA, RNIC, usNIC, usNIC UDP,
+   switch or router)
+
+   node_guid:  (RO) Node GUID
+
+   sys_image_guid: (RO) System image GUID
+
+
+What:  /sys/class/infiniband//node_desc
+Date:  Feb, 2006
+KernelVersion: v2.6.17
+Contact:   linux-r...@vger.kernel.org
+Description:
+   (RW) Update the node description with information such as the
+   node's hostname, so that IB network management software can tie
+   its view to the real world.
+
+
+What:  /sys/class/infiniband//fw_ver
+Date:  Jun, 2016
+KernelVersion: v4.10
+Contact:   linux-r...@vger.kernel.org
+Description:
+   (RO) Display firmware version
+
+
+What:  /sys/class/infiniband//ports//lid
+What:  /sys/class/infiniband//ports//rate
+What:  /sys/class/infiniband//ports//lid_mask_count
+What:  /sys/class/infiniband//ports//sm_sl
+What:  /sys/class/infiniband//ports//sm_lid
+What:  /sys/class/infiniband//ports//state
+What:  /sys/class/infiniband//ports//phys_state
+What:  /sys/class/infiniband//ports//cap_mask
+Date:  Apr, 2005
+KernelVersion: v2.6.12
+Contact:   linux-r...@vger.kernel.org
+Description:
+
+   lid:(RO) Port LID
+
+   rate:   (RO) Port data rate (active width * active
+   speed)
+
+   lid_mask_count: (RO) Port LID mask count
+
+   sm_sl:  (RO) Subnet manager SL for port's subnet
+
+   sm_lid: (RO) Subnet manager LID for port's subnet
+
+   state:  (RO) Port state (DOWN, INIT, ARMED, ACTIVE or
+   ACTIVE_DEFER)
+
+   phys_state: (RO) Port physical state (Sleep, Polling,
+   LinkUp, etc)
+
+   cap_mask:   (RO) Port capability mask. 2 bits here are
+   settable- IsCommunicationManagementSupported
+   (set when CM module is loaded) and IsSM (set via
+   open of issmN file).
+
+
+What:  /sys/class/infiniband//ports//link_layer
+Date:  Oct, 2010
+KernelVersion: v2.6.37
+Contact:   linux-r...@vger.kernel.org
+Description:
+   (RO) Link layer type information (Infiniband or Ethernet type)
+
+
+What:  
/sys/class/infiniband//ports//counters/symbol_error
+What:  
/sys/class/infiniband//ports//counters/port_rcv_errors
+What:  
/sys/class/infiniband//ports//counters/port_rcv_remote_physical_errors
+What:  
/sys/class/infiniband//ports//counters/port_rcv_switch_relay_errors
+What:  
/sys/class/infiniband//ports//counters/link_error_recovery
+What:  
/sys/class/infiniband//ports//counters/port_xmit_constraint_errors
+What:  
/sys/class/infiniband//ports//counters/port_rcv_contraint_errors
+What:  
/sys/class/infiniband//ports//counters/local_link_integrity_errors
+What:  
/sys/class/infiniband//ports//counters/excessive_buffer_overrun_errors
+What:  
/sys/class/infiniband//ports//counters/port_xmit_data
+What:  
/sys/class/infiniband//ports//counters/port_rcv_data
+What:  
/sys/class/infiniband//ports//counters/port_xmit_packets
+What: 

[PATCH v2] Documentation/ABI: update infiniband sysfs interfaces

[Aishwarya Pant]

Add documentation for core and hardware specific infiniband interfaces.
The descriptions have been collected from git commit logs, reading
through code and data sheets. Some drivers have incomplete doc and are
annotated with the comment '[to be documented]'.

Signed-off-by: Aishwarya Pant 
---
Changes in v2:
- Move infiniband interface from testing to stable
- Fix typos
- Update description of cap_mask, port_xmit_constraint_errors and
  port_rcv_constraint_errors
- Add doc for hw_counters
- Remove old documentation

 Documentation/ABI/stable/sysfs-class-infiniband  | 818 +++
 Documentation/ABI/testing/sysfs-class-infiniband |  16 -
 Documentation/infiniband/sysfs.txt   | 129 +---
 3 files changed, 820 insertions(+), 143 deletions(-)
 create mode 100644 Documentation/ABI/stable/sysfs-class-infiniband
 delete mode 100644 Documentation/ABI/testing/sysfs-class-infiniband

diff --git a/Documentation/ABI/stable/sysfs-class-infiniband 
b/Documentation/ABI/stable/sysfs-class-infiniband
new file mode 100644
index ..f9c709a8d0ab
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-class-infiniband
@@ -0,0 +1,818 @@
+sysfs interface common for all infiniband devices
+-
+
+What:  /sys/class/infiniband//node_type
+What:  /sys/class/infiniband//node_guid
+What:  /sys/class/infiniband//sys_image_guid
+Date:  Apr, 2005
+KernelVersion: v2.6.12
+Contact:   linux-r...@vger.kernel.org
+Description:
+   node_type:  (RO) Node type (CA, RNIC, usNIC, usNIC UDP,
+   switch or router)
+
+   node_guid:  (RO) Node GUID
+
+   sys_image_guid: (RO) System image GUID
+
+
+What:  /sys/class/infiniband//node_desc
+Date:  Feb, 2006
+KernelVersion: v2.6.17
+Contact:   linux-r...@vger.kernel.org
+Description:
+   (RW) Update the node description with information such as the
+   node's hostname, so that IB network management software can tie
+   its view to the real world.
+
+
+What:  /sys/class/infiniband//fw_ver
+Date:  Jun, 2016
+KernelVersion: v4.10
+Contact:   linux-r...@vger.kernel.org
+Description:
+   (RO) Display firmware version
+
+
+What:  /sys/class/infiniband//ports//lid
+What:  /sys/class/infiniband//ports//rate
+What:  /sys/class/infiniband//ports//lid_mask_count
+What:  /sys/class/infiniband//ports//sm_sl
+What:  /sys/class/infiniband//ports//sm_lid
+What:  /sys/class/infiniband//ports//state
+What:  /sys/class/infiniband//ports//phys_state
+What:  /sys/class/infiniband//ports//cap_mask
+Date:  Apr, 2005
+KernelVersion: v2.6.12
+Contact:   linux-r...@vger.kernel.org
+Description:
+
+   lid:(RO) Port LID
+
+   rate:   (RO) Port data rate (active width * active
+   speed)
+
+   lid_mask_count: (RO) Port LID mask count
+
+   sm_sl:  (RO) Subnet manager SL for port's subnet
+
+   sm_lid: (RO) Subnet manager LID for port's subnet
+
+   state:  (RO) Port state (DOWN, INIT, ARMED, ACTIVE or
+   ACTIVE_DEFER)
+
+   phys_state: (RO) Port physical state (Sleep, Polling,
+   LinkUp, etc)
+
+   cap_mask:   (RO) Port capability mask. 2 bits here are
+   settable- IsCommunicationManagementSupported
+   (set when CM module is loaded) and IsSM (set via
+   open of issmN file).
+
+
+What:  /sys/class/infiniband//ports//link_layer
+Date:  Oct, 2010
+KernelVersion: v2.6.37
+Contact:   linux-r...@vger.kernel.org
+Description:
+   (RO) Link layer type information (Infiniband or Ethernet type)
+
+
+What:  
/sys/class/infiniband//ports//counters/symbol_error
+What:  
/sys/class/infiniband//ports//counters/port_rcv_errors
+What:  
/sys/class/infiniband//ports//counters/port_rcv_remote_physical_errors
+What:  
/sys/class/infiniband//ports//counters/port_rcv_switch_relay_errors
+What:  
/sys/class/infiniband//ports//counters/link_error_recovery
+What:  
/sys/class/infiniband//ports//counters/port_xmit_constraint_errors
+What:  
/sys/class/infiniband//ports//counters/port_rcv_contraint_errors
+What:  
/sys/class/infiniband//ports//counters/local_link_integrity_errors
+What:  
/sys/class/infiniband//ports//counters/excessive_buffer_overrun_errors
+What:  
/sys/class/infiniband//ports//counters/port_xmit_data
+What:  
/sys/class/infiniband//ports//counters/port_rcv_data
+What:  
/sys/class/infiniband//ports//counters/port_xmit_packets
+What:  

Re: [PATCH v4] ACPI / tables: Add IORT to injectable table list

[Hanjun Guo]

On 2018/2/6 14:37, Yang Shunyong wrote:
> Loading IORT table from initrd can be used to fix severe firmware
> IORT defects temporarily before platform/BIOS vendor releases an
> upgraded BIOS binary.
> 
> Moreover, it is very powerful to debug SMMU node/device probe, MSI
> allocation, stream id translation and IORT table from firmware.
> 
> It is also very useful to enable SMMU and devices behind SMMU before
> firmware is ready.
> 
> This patch adds ACPI_SIG_IORT to the table, which enables IORT
> from initrd to override which from firmware.
> 
> Cc: Joey Zheng 
> Cc: Wang Dongsheng 
> Cc: Jiang Yutang 
> Cc: Hanjun Guo 
> Signed-off-by: Yang Shunyong 

Acked-by: Hanjun Guo 

Thanks
Hanjun

Re: [PATCH v4] ACPI / tables: Add IORT to injectable table list

[Hanjun Guo]

On 2018/2/6 14:37, Yang Shunyong wrote:
> Loading IORT table from initrd can be used to fix severe firmware
> IORT defects temporarily before platform/BIOS vendor releases an
> upgraded BIOS binary.
> 
> Moreover, it is very powerful to debug SMMU node/device probe, MSI
> allocation, stream id translation and IORT table from firmware.
> 
> It is also very useful to enable SMMU and devices behind SMMU before
> firmware is ready.
> 
> This patch adds ACPI_SIG_IORT to the table, which enables IORT
> from initrd to override which from firmware.
> 
> Cc: Joey Zheng 
> Cc: Wang Dongsheng 
> Cc: Jiang Yutang 
> Cc: Hanjun Guo 
> Signed-off-by: Yang Shunyong 

Acked-by: Hanjun Guo 

Thanks
Hanjun

Re: [PATCH v2 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels

[Ingo Molnar]

* Andi Kleen  wrote:

> >  - There's various conditional pieces of entry code that run before any 
> >RBP-clobbering C function is called. While none of them has an 
> > exploitable 
> >Spectre 'gadget' at the moment, we'd have to consider this for every 
> > future
> >change.
> 
> The Frame Pointer is always set up in assembler too, just in another macro.

As I replied to Andy, that's not universally true: there are code paths where 
RBP 
is not set before calling C code or going into the more complex parts of the 
kernel entry code.

This RBP value leak in fact demonstrates the validity of my robustness argument:

> >   I.e. we cannot universally rely on RBP being sanitized. In _practice_ it 
> >   will be sanitized, but we don't know for sure without expending quite 
> > some 
> >   effort to think through all the cases.

Thanks,

Ingo

Re: [PATCH v2 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels

[Ingo Molnar]

* Andi Kleen  wrote:

> >  - There's various conditional pieces of entry code that run before any 
> >RBP-clobbering C function is called. While none of them has an 
> > exploitable 
> >Spectre 'gadget' at the moment, we'd have to consider this for every 
> > future
> >change.
> 
> The Frame Pointer is always set up in assembler too, just in another macro.

As I replied to Andy, that's not universally true: there are code paths where 
RBP 
is not set before calling C code or going into the more complex parts of the 
kernel entry code.

This RBP value leak in fact demonstrates the validity of my robustness argument:

> >   I.e. we cannot universally rely on RBP being sanitized. In _practice_ it 
> >   will be sanitized, but we don't know for sure without expending quite 
> > some 
> >   effort to think through all the cases.

Thanks,

Ingo

Re: [PATCH v6 1/2] staging: fsl-mc: Move core bus out of staging

[Horia Geantă]

On 2/5/2018 4:08 PM, Bogdan Purcareata wrote:
> Move the source files out of staging into their final locations:
>   -mc.h include file in drivers/staging/fsl-mc/include go to include/linux/fsl
>   -source files in drivers/staging/fsl-mc/bus go to drivers/bus/fsl-mc
>   -overview.rst, providing an overview of DPAA2, goes to
>Documentation/networking/dpaa2/overview.rst
[...]
>  rename {drivers/staging/fsl-mc => 
> Documentation/networking/dpaa2}/overview.rst (100%)

Is this the proper location for documentation?
The doc focuses on networking, however there's also information about fsl mc
bus, dpio.

In the future, we might want to add doc for other dpaa2 objects sitting on the
fsl mc bus:
-dpseci ("Data Path SEC Interface" - abstraction for the crypto engine)
-dpdcei ("Data Path Decompression and Compression Engine Interface")

Would these fit under networking doc folder too?

Thanks,
Horia

Re: [PATCH v6 1/2] staging: fsl-mc: Move core bus out of staging

[Horia Geantă]

On 2/5/2018 4:08 PM, Bogdan Purcareata wrote:
> Move the source files out of staging into their final locations:
>   -mc.h include file in drivers/staging/fsl-mc/include go to include/linux/fsl
>   -source files in drivers/staging/fsl-mc/bus go to drivers/bus/fsl-mc
>   -overview.rst, providing an overview of DPAA2, goes to
>Documentation/networking/dpaa2/overview.rst
[...]
>  rename {drivers/staging/fsl-mc => 
> Documentation/networking/dpaa2}/overview.rst (100%)

Is this the proper location for documentation?
The doc focuses on networking, however there's also information about fsl mc
bus, dpio.

In the future, we might want to add doc for other dpaa2 objects sitting on the
fsl mc bus:
-dpseci ("Data Path SEC Interface" - abstraction for the crypto engine)
-dpdcei ("Data Path Decompression and Compression Engine Interface")

Would these fit under networking doc folder too?

Thanks,
Horia

Re: [RFC] tracing: Improve design of preemptirq tracepoints and its users

[Joel Fernandes]

On Mon, Feb 5, 2018 at 6:39 PM, Joel Fernandes  wrote:
> This patch detaches the preemptirq tracepoints from the tracers and
> keeps it separate. With this, several ifdefs are cleaner, and lockdep
> and other users can use the preemptirq tracepoints by registering probes
> onto them. This makes it much cleaner, but not just that: PROVE_LOCKING
> and CONFIG_IRQSOFF_TRACER can be enabled now at the same time and we
> get rid of all the horrific ifdeferry around PROVE_LOCKING.
>

Sorry for the misstatement, irqsoff tracer and PROVE_LOCKING can still
be used at the same time (without this patch). I will correct the
commit message in the next rev. However this patch avoids the
complication that arises when enabling the 2 together, by eliminating
time_hardirqs_on/off.

thanks,

- Joel

Re: [RFC] tracing: Improve design of preemptirq tracepoints and its users

[Joel Fernandes]

On Mon, Feb 5, 2018 at 6:39 PM, Joel Fernandes  wrote:
> This patch detaches the preemptirq tracepoints from the tracers and
> keeps it separate. With this, several ifdefs are cleaner, and lockdep
> and other users can use the preemptirq tracepoints by registering probes
> onto them. This makes it much cleaner, but not just that: PROVE_LOCKING
> and CONFIG_IRQSOFF_TRACER can be enabled now at the same time and we
> get rid of all the horrific ifdeferry around PROVE_LOCKING.
>

Sorry for the misstatement, irqsoff tracer and PROVE_LOCKING can still
be used at the same time (without this patch). I will correct the
commit message in the next rev. However this patch avoids the
complication that arises when enabling the 2 together, by eliminating
time_hardirqs_on/off.

thanks,

- Joel

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

[Wu Hao]

On Mon, Feb 05, 2018 at 10:25:54PM -0600, Alan Tull wrote:
> On Mon, Feb 5, 2018 at 7:47 PM, Wu Hao  wrote:
> > On Mon, Feb 05, 2018 at 10:36:45AM -0800, Luebbers, Enno wrote:
> >> Hi Hao,
> >>
> >> On Sun, Feb 04, 2018 at 05:37:06PM +0800, Wu Hao wrote:
> >> > On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote:
> >> > > Hi Hao, Alan,
> >> > >
> >> > > On Fri, Feb 02, 2018 at 05:42:13PM +0800, Wu Hao wrote:
> >> > > > On Thu, Feb 01, 2018 at 04:00:36PM -0600, Alan Tull wrote:
> >> > > > > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao  wrote:
> >> > > > >
> >> > > > > Hi Hao,
> >> > > > >
> >> > > > > A few comments below.   Besides that, looks good.
> >> > > > >
> >> > > > > > This patch adds fpga manager driver for FPGA Management Engine 
> >> > > > > > (FME). It
> >> > > > > > implements fpga_manager_ops for FPGA Partial Reconfiguration 
> >> > > > > > function.
> >> > > > > >
> >> > > > > > Signed-off-by: Tim Whisonant 
> >> > > > > > Signed-off-by: Enno Luebbers 
> >> > > > > > Signed-off-by: Shiva Rao 
> >> > > > > > Signed-off-by: Christopher Rauer 
> >> > > > > > Signed-off-by: Kang Luwei 
> >> > > > > > Signed-off-by: Xiao Guangrong 
> >> > > > > > Signed-off-by: Wu Hao 
> >> > > > > > 
> >> > > > > > v3: rename driver to dfl-fpga-fme-mgr
> >> > > > > > implemented status callback for fpga manager
> >> > > > > > rebased due to fpga api changes
> >> > > > > > ---
> >> > > > > >  .../ABI/testing/sysfs-platform-fpga-dfl-fme-mgr|   8 +
> >> > > > > >  drivers/fpga/Kconfig   |   6 +
> >> > > > > >  drivers/fpga/Makefile  |   1 +
> >> > > > > >  drivers/fpga/fpga-dfl-fme-mgr.c| 318 
> >> > > > > > +
> >> > > > > >  drivers/fpga/fpga-dfl.h|  39 ++-
> >> > > > > >  5 files changed, 371 insertions(+), 1 deletion(-)
> >> > > > > >  create mode 100644 
> >> > > > > > Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> > > > > >  create mode 100644 drivers/fpga/fpga-dfl-fme-mgr.c
> >> > > > > >
> >> > > > > > diff --git 
> >> > > > > > a/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr 
> >> > > > > > b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> > > > > > new file mode 100644
> >> > > > > > index 000..2d4f917
> >> > > > > > --- /dev/null
> >> > > > > > +++ b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> > > > > > @@ -0,0 +1,8 @@
> >> > > > > > +What:  
> >> > > > > > /sys/bus/platform/devices/fpga-dfl-fme-mgr.0/interface_id
> >> > > > > > +Date:  November 2017
> >> > > > > > +KernelVersion:  4.15
> >> > > > > > +Contact:   Wu Hao 
> >> > > > > > +Description:   Read-only. It returns interface id of partial 
> >> > > > > > reconfiguration
> >> > > > > > +   hardware. Userspace could use this information 
> >> > > > > > to check if
> >> > > > > > +   current hardware is compatible with given image 
> >> > > > > > before FPGA
> >> > > > > > +   programming.
> >> > > > >
> >> > > > > I'm a little confused by this.  I can understand that the PR 
> >> > > > > bitstream
> >> > > > > has a dependency on the FPGA's static image, but I don't understand
> >> > > > > the dependency of the bistream on the hardware that is used to 
> >> > > > > program
> >> > > > > the bitstream to the FPGA.
> >> > > >
> >> > > > Sorry for the confusion, the interface_id is used to indicate the 
> >> > > > version of
> >> > > > the hardware for partial reconfiguration (it's part of the static 
> >> > > > image of
> >> > > > the FPGA device). Will improve the description on this.
> >> > > >
> >> > >
> >> > > The interface_id expresses the compatibility of the static region with 
> >> > > PR
> >> > > bitstreams generated for it. It changes every time a new static region 
> >> > > is
> >> > > generated.
> >> > >
> >> > > Would it make more sense to have the interface_id exposed as part of 
> >> > > the FME
> >> > > device (which represents the static region)? I'm not sure - it kind of 
> >> > > also
> >> > > makes sense here, where you would have all the information in one 
> >> > > place (if the
> >> > > interface_id matches, I can use this component to program a bitstream).
> >> >
> >> > Hi Enno
> >> >
> >> > Yes, this interface is under fpga-dfl-fme-mgr.0, and fpga-dfl-fme-mgr.0 
> >> > is
> >> > under fpga-dfl-fme.0. It's part of the FME device for sure. From another
> >> > point of view, it means if anyone wants to do PR on this Intel FPGA 
> >> > device,
> >> > he needs to find the FME device firstly, and then check if any fpga 
> >> > manager
> >> > created under this FME device, if yes, check the interface_id before PR 
> >> > via
> >> > the FME device 

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

[Wu Hao]

On Mon, Feb 05, 2018 at 10:25:54PM -0600, Alan Tull wrote:
> On Mon, Feb 5, 2018 at 7:47 PM, Wu Hao  wrote:
> > On Mon, Feb 05, 2018 at 10:36:45AM -0800, Luebbers, Enno wrote:
> >> Hi Hao,
> >>
> >> On Sun, Feb 04, 2018 at 05:37:06PM +0800, Wu Hao wrote:
> >> > On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote:
> >> > > Hi Hao, Alan,
> >> > >
> >> > > On Fri, Feb 02, 2018 at 05:42:13PM +0800, Wu Hao wrote:
> >> > > > On Thu, Feb 01, 2018 at 04:00:36PM -0600, Alan Tull wrote:
> >> > > > > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao  wrote:
> >> > > > >
> >> > > > > Hi Hao,
> >> > > > >
> >> > > > > A few comments below.   Besides that, looks good.
> >> > > > >
> >> > > > > > This patch adds fpga manager driver for FPGA Management Engine 
> >> > > > > > (FME). It
> >> > > > > > implements fpga_manager_ops for FPGA Partial Reconfiguration 
> >> > > > > > function.
> >> > > > > >
> >> > > > > > Signed-off-by: Tim Whisonant 
> >> > > > > > Signed-off-by: Enno Luebbers 
> >> > > > > > Signed-off-by: Shiva Rao 
> >> > > > > > Signed-off-by: Christopher Rauer 
> >> > > > > > Signed-off-by: Kang Luwei 
> >> > > > > > Signed-off-by: Xiao Guangrong 
> >> > > > > > Signed-off-by: Wu Hao 
> >> > > > > > 
> >> > > > > > v3: rename driver to dfl-fpga-fme-mgr
> >> > > > > > implemented status callback for fpga manager
> >> > > > > > rebased due to fpga api changes
> >> > > > > > ---
> >> > > > > >  .../ABI/testing/sysfs-platform-fpga-dfl-fme-mgr|   8 +
> >> > > > > >  drivers/fpga/Kconfig   |   6 +
> >> > > > > >  drivers/fpga/Makefile  |   1 +
> >> > > > > >  drivers/fpga/fpga-dfl-fme-mgr.c| 318 
> >> > > > > > +
> >> > > > > >  drivers/fpga/fpga-dfl.h|  39 ++-
> >> > > > > >  5 files changed, 371 insertions(+), 1 deletion(-)
> >> > > > > >  create mode 100644 
> >> > > > > > Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> > > > > >  create mode 100644 drivers/fpga/fpga-dfl-fme-mgr.c
> >> > > > > >
> >> > > > > > diff --git 
> >> > > > > > a/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr 
> >> > > > > > b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> > > > > > new file mode 100644
> >> > > > > > index 000..2d4f917
> >> > > > > > --- /dev/null
> >> > > > > > +++ b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> > > > > > @@ -0,0 +1,8 @@
> >> > > > > > +What:  
> >> > > > > > /sys/bus/platform/devices/fpga-dfl-fme-mgr.0/interface_id
> >> > > > > > +Date:  November 2017
> >> > > > > > +KernelVersion:  4.15
> >> > > > > > +Contact:   Wu Hao 
> >> > > > > > +Description:   Read-only. It returns interface id of partial 
> >> > > > > > reconfiguration
> >> > > > > > +   hardware. Userspace could use this information 
> >> > > > > > to check if
> >> > > > > > +   current hardware is compatible with given image 
> >> > > > > > before FPGA
> >> > > > > > +   programming.
> >> > > > >
> >> > > > > I'm a little confused by this.  I can understand that the PR 
> >> > > > > bitstream
> >> > > > > has a dependency on the FPGA's static image, but I don't understand
> >> > > > > the dependency of the bistream on the hardware that is used to 
> >> > > > > program
> >> > > > > the bitstream to the FPGA.
> >> > > >
> >> > > > Sorry for the confusion, the interface_id is used to indicate the 
> >> > > > version of
> >> > > > the hardware for partial reconfiguration (it's part of the static 
> >> > > > image of
> >> > > > the FPGA device). Will improve the description on this.
> >> > > >
> >> > >
> >> > > The interface_id expresses the compatibility of the static region with 
> >> > > PR
> >> > > bitstreams generated for it. It changes every time a new static region 
> >> > > is
> >> > > generated.
> >> > >
> >> > > Would it make more sense to have the interface_id exposed as part of 
> >> > > the FME
> >> > > device (which represents the static region)? I'm not sure - it kind of 
> >> > > also
> >> > > makes sense here, where you would have all the information in one 
> >> > > place (if the
> >> > > interface_id matches, I can use this component to program a bitstream).
> >> >
> >> > Hi Enno
> >> >
> >> > Yes, this interface is under fpga-dfl-fme-mgr.0, and fpga-dfl-fme-mgr.0 
> >> > is
> >> > under fpga-dfl-fme.0. It's part of the FME device for sure. From another
> >> > point of view, it means if anyone wants to do PR on this Intel FPGA 
> >> > device,
> >> > he needs to find the FME device firstly, and then check if any fpga 
> >> > manager
> >> > created under this FME device, if yes, check the interface_id before PR 
> >> > via
> >> > the FME device node ioctl.
> >>
> >> That sounds good, thank you!
> >>
> >> >
> >> > >
> >> > > Sorry for my limited understanding of the infrastructure - would this 
> >> > > same
> >> > > "fpga-dfl-fme-mgr.0" be used for PR if we had 

[PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

[Huang, Ying]

From: Huang Ying 

It was reported by Sergey Senozhatsky that if THP (Transparent Huge
Page) and frontswap (via zswap) are both enabled, when memory goes low
so that swap is triggered, segfault and memory corruption will occur
in random user space applications as follow,

kernel: urxvt[338]: segfault at 20 ip 7fc08889ae0d sp 7ffc73a7fc40 
error 6 in libc-2.26.so[7fc08881a000+1ae000]
 #0  0x7fc08889ae0d _int_malloc (libc.so.6)
 #1  0x7fc08889c2f3 malloc (libc.so.6)
 #2  0x560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
 #3  0x560e6005e75c n/a (urxvt)
 #4  0x560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez 
(urxvt)
 #5  0x560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
 #6  0x560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
 #7  0x560e6005c10f _Z17ev_invoke_pendingv (urxvt)
 #8  0x560e6005cb55 ev_run (urxvt)
 #9  0x560e6003b9b9 main (urxvt)
 #10 0x7fc08883af4a __libc_start_main (libc.so.6)
 #11 0x560e6003f9da _start (urxvt)

After bisection, it was found the first bad commit is
bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped
out").

The root cause is as follow.

When the pages are written to storage device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages
instead to improve the performance.  But zswap (frontswap) will treat
THP as normal page, so only the head page is saved.  After swapping
in, tail pages will not be restored to its original contents, so cause
the memory corruption in the applications.

This is fixed via splitting THP at the begin of swapping out if
frontswap is enabled.  To avoid frontswap to be enabled at runtime,
whether the page is THP is checked before using frontswap during
swapping out too.

Reported-and-tested-by: Sergey Senozhatsky 
Signed-off-by: "Huang, Ying" 
Cc: Konrad Rzeszutek Wilk 
Cc: Dan Streetman 
Cc: Seth Jennings 
Cc: Minchan Kim 
Cc: Tetsuo Handa 
Cc: Shaohua Li 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Shakeel Butt 
Cc: sta...@vger.kernel.org # 4.14
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped 
out")
---
 mm/page_io.c |  2 +-
 mm/vmscan.c  | 16 +---
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/mm/page_io.c b/mm/page_io.c
index b41cf9644585..6dca817ae7a0 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -250,7 +250,7 @@ int swap_writepage(struct page *page, struct 
writeback_control *wbc)
unlock_page(page);
goto out;
}
-   if (frontswap_store(page) == 0) {
+   if (!PageTransHuge(page) && frontswap_store(page) == 0) {
set_page_writeback(page);
unlock_page(page);
end_page_writeback(page);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index bee53495a829..d1c1e00b08bb 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -55,6 +55,7 @@
 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -1063,14 +1064,23 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
/* cannot split THP, skip it */
if (!can_split_huge_page(page, NULL))
goto activate_locked;
+   /*
+* Split THP if frontswap enabled,
+* because it cannot process THP
+*/
+   if (frontswap_enabled()) {
+   if (split_huge_page_to_list(
+   page, page_list))
+   goto activate_locked;
+   }
/*
 * Split pages without a PMD map right
 * away. Chances are some or all of the
 * tail pages can be freed without IO.
 */
-   if (!compound_mapcount(page) &&
-   split_huge_page_to_list(page,
-   page_list))
+   else if (!compound_mapcount(page) &&
+split_huge_page_to_list(page,
+   page_list))
goto activate_locked;
   

[PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

[Huang, Ying]

From: Huang Ying 

It was reported by Sergey Senozhatsky that if THP (Transparent Huge
Page) and frontswap (via zswap) are both enabled, when memory goes low
so that swap is triggered, segfault and memory corruption will occur
in random user space applications as follow,

kernel: urxvt[338]: segfault at 20 ip 7fc08889ae0d sp 7ffc73a7fc40 
error 6 in libc-2.26.so[7fc08881a000+1ae000]
 #0  0x7fc08889ae0d _int_malloc (libc.so.6)
 #1  0x7fc08889c2f3 malloc (libc.so.6)
 #2  0x560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
 #3  0x560e6005e75c n/a (urxvt)
 #4  0x560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez 
(urxvt)
 #5  0x560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
 #6  0x560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
 #7  0x560e6005c10f _Z17ev_invoke_pendingv (urxvt)
 #8  0x560e6005cb55 ev_run (urxvt)
 #9  0x560e6003b9b9 main (urxvt)
 #10 0x7fc08883af4a __libc_start_main (libc.so.6)
 #11 0x560e6003f9da _start (urxvt)

After bisection, it was found the first bad commit is
bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped
out").

The root cause is as follow.

When the pages are written to storage device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages
instead to improve the performance.  But zswap (frontswap) will treat
THP as normal page, so only the head page is saved.  After swapping
in, tail pages will not be restored to its original contents, so cause
the memory corruption in the applications.

This is fixed via splitting THP at the begin of swapping out if
frontswap is enabled.  To avoid frontswap to be enabled at runtime,
whether the page is THP is checked before using frontswap during
swapping out too.

Reported-and-tested-by: Sergey Senozhatsky 
Signed-off-by: "Huang, Ying" 
Cc: Konrad Rzeszutek Wilk 
Cc: Dan Streetman 
Cc: Seth Jennings 
Cc: Minchan Kim 
Cc: Tetsuo Handa 
Cc: Shaohua Li 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Shakeel Butt 
Cc: sta...@vger.kernel.org # 4.14
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped 
out")
---
 mm/page_io.c |  2 +-
 mm/vmscan.c  | 16 +---
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/mm/page_io.c b/mm/page_io.c
index b41cf9644585..6dca817ae7a0 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -250,7 +250,7 @@ int swap_writepage(struct page *page, struct 
writeback_control *wbc)
unlock_page(page);
goto out;
}
-   if (frontswap_store(page) == 0) {
+   if (!PageTransHuge(page) && frontswap_store(page) == 0) {
set_page_writeback(page);
unlock_page(page);
end_page_writeback(page);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index bee53495a829..d1c1e00b08bb 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -55,6 +55,7 @@
 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -1063,14 +1064,23 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
/* cannot split THP, skip it */
if (!can_split_huge_page(page, NULL))
goto activate_locked;
+   /*
+* Split THP if frontswap enabled,
+* because it cannot process THP
+*/
+   if (frontswap_enabled()) {
+   if (split_huge_page_to_list(
+   page, page_list))
+   goto activate_locked;
+   }
/*
 * Split pages without a PMD map right
 * away. Chances are some or all of the
 * tail pages can be freed without IO.
 */
-   if (!compound_mapcount(page) &&
-   split_huge_page_to_list(page,
-   page_list))
+   else if (!compound_mapcount(page) &&
+split_huge_page_to_list(page,
+   page_list))
goto activate_locked;
}
if (!add_to_swap(page)) {
-- 
2.15.1

Re: [RESEND PATCH] sched/fair: consider RT/IRQ pressure in select_idle_sibling

[Joel Fernandes]

On Mon, Feb 5, 2018 at 10:50 PM, Joel Fernandes  wrote:
> On Wed, Jan 31, 2018 at 9:50 AM, Rohit Jain  wrote:
>>kernel/sched/fair.c | 38 --
>>1 file changed, 28 insertions(+), 10 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 26a71eb..ce5ccf8 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5625,6 +5625,11 @@ static unsigned long capacity_orig_of(int cpu)
>>   return cpu_rq(cpu)->cpu_capacity_orig;
>>}
>>
>> +static inline bool full_capacity(int cpu)
>> +{
>> +   return capacity_of(cpu) >= (capacity_orig_of(cpu)*3)/4;
>> +}
>> +
>>static unsigned long cpu_avg_load_per_task(int cpu)
>>{
>>   struct rq *rq = cpu_rq(cpu);
>> @@ -6081,7 +6086,7 @@ static int select_idle_core(struct task_struct
>> *p,
>> struct sched_domain *sd, int
>>
>>   for_each_cpu(cpu, cpu_smt_mask(core)) {
>>   cpumask_clear_cpu(cpu, cpus);
>> -   if (!idle_cpu(cpu))
>> +   if (!idle_cpu(cpu) || !full_capacity(cpu))
>>   idle = false;
>>   }
>
> There's some difference in logic between select_idle_core and
> select_idle_cpu as far as the full_capacity stuff you're adding goes.
> In select_idle_core, if all CPUs are !full_capacity, you're returning
> -1. But in select_idle_cpu you're returning the best idle CPU that's
> the most cap among the !full_capacity ones. Why there is this
> different in logic? Did I miss something?
>
>>
>> 
>>
>>> Dude :) That is hardly an answer to the question I asked. Hint:
>>> *different in logic*.
>>
>>
>> Let me re-try :)
>>
>> For select_idle_core, we are doing a search for a fully idle and full
>> capacity core, the fail-safe is select_idle_cpu because we will re-scan
>> the CPUs. The notion is to select an idle CPU no matter what, because
>> being on an idle CPU is better than waiting on a non-idle one. In
>> select_idle_core you can be slightly picky about the core because
>> select_idle_cpu is a fail safe. I measured the performance impact of
>> choosing the "best among low cap" vs the code changes I have (for
>> select_idle_core) and could not find a statistically significant impact,
>> hence went with the simpler code changes.
>
> That's Ok with me. Just that I remember Peter messing with this path
> and that it was expensive to scan too much for some systems. The other
> thing is you're really doing to do a "fail safe" as you call it search

I meant to say here, "you're NOT really going to be doing a 'fail
safe' search here as you call it"

thanks,

- Joel

Re: [RESEND PATCH] sched/fair: consider RT/IRQ pressure in select_idle_sibling

[Joel Fernandes]

On Mon, Feb 5, 2018 at 10:50 PM, Joel Fernandes  wrote:
> On Wed, Jan 31, 2018 at 9:50 AM, Rohit Jain  wrote:
>>kernel/sched/fair.c | 38 --
>>1 file changed, 28 insertions(+), 10 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 26a71eb..ce5ccf8 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5625,6 +5625,11 @@ static unsigned long capacity_orig_of(int cpu)
>>   return cpu_rq(cpu)->cpu_capacity_orig;
>>}
>>
>> +static inline bool full_capacity(int cpu)
>> +{
>> +   return capacity_of(cpu) >= (capacity_orig_of(cpu)*3)/4;
>> +}
>> +
>>static unsigned long cpu_avg_load_per_task(int cpu)
>>{
>>   struct rq *rq = cpu_rq(cpu);
>> @@ -6081,7 +6086,7 @@ static int select_idle_core(struct task_struct
>> *p,
>> struct sched_domain *sd, int
>>
>>   for_each_cpu(cpu, cpu_smt_mask(core)) {
>>   cpumask_clear_cpu(cpu, cpus);
>> -   if (!idle_cpu(cpu))
>> +   if (!idle_cpu(cpu) || !full_capacity(cpu))
>>   idle = false;
>>   }
>
> There's some difference in logic between select_idle_core and
> select_idle_cpu as far as the full_capacity stuff you're adding goes.
> In select_idle_core, if all CPUs are !full_capacity, you're returning
> -1. But in select_idle_cpu you're returning the best idle CPU that's
> the most cap among the !full_capacity ones. Why there is this
> different in logic? Did I miss something?
>
>>
>> 
>>
>>> Dude :) That is hardly an answer to the question I asked. Hint:
>>> *different in logic*.
>>
>>
>> Let me re-try :)
>>
>> For select_idle_core, we are doing a search for a fully idle and full
>> capacity core, the fail-safe is select_idle_cpu because we will re-scan
>> the CPUs. The notion is to select an idle CPU no matter what, because
>> being on an idle CPU is better than waiting on a non-idle one. In
>> select_idle_core you can be slightly picky about the core because
>> select_idle_cpu is a fail safe. I measured the performance impact of
>> choosing the "best among low cap" vs the code changes I have (for
>> select_idle_core) and could not find a statistically significant impact,
>> hence went with the simpler code changes.
>
> That's Ok with me. Just that I remember Peter messing with this path
> and that it was expensive to scan too much for some systems. The other
> thing is you're really doing to do a "fail safe" as you call it search

I meant to say here, "you're NOT really going to be doing a 'fail
safe' search here as you call it"

thanks,

- Joel

Re: [RESEND PATCH] sched/fair: consider RT/IRQ pressure in select_idle_sibling

[Joel Fernandes]

On Wed, Jan 31, 2018 at 9:50 AM, Rohit Jain  wrote:
>kernel/sched/fair.c | 38 --
>1 file changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 26a71eb..ce5ccf8 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5625,6 +5625,11 @@ static unsigned long capacity_orig_of(int cpu)
>   return cpu_rq(cpu)->cpu_capacity_orig;
>}
>
> +static inline bool full_capacity(int cpu)
> +{
> +   return capacity_of(cpu) >= (capacity_orig_of(cpu)*3)/4;
> +}
> +
>static unsigned long cpu_avg_load_per_task(int cpu)
>{
>   struct rq *rq = cpu_rq(cpu);
> @@ -6081,7 +6086,7 @@ static int select_idle_core(struct task_struct
> *p,
> struct sched_domain *sd, int
>
>   for_each_cpu(cpu, cpu_smt_mask(core)) {
>   cpumask_clear_cpu(cpu, cpus);
> -   if (!idle_cpu(cpu))
> +   if (!idle_cpu(cpu) || !full_capacity(cpu))
>   idle = false;
>   }

 There's some difference in logic between select_idle_core and
 select_idle_cpu as far as the full_capacity stuff you're adding goes.
 In select_idle_core, if all CPUs are !full_capacity, you're returning
 -1. But in select_idle_cpu you're returning the best idle CPU that's
 the most cap among the !full_capacity ones. Why there is this
 different in logic? Did I miss something?

>
> 
>
>> Dude :) That is hardly an answer to the question I asked. Hint:
>> *different in logic*.
>
>
> Let me re-try :)
>
> For select_idle_core, we are doing a search for a fully idle and full
> capacity core, the fail-safe is select_idle_cpu because we will re-scan
> the CPUs. The notion is to select an idle CPU no matter what, because
> being on an idle CPU is better than waiting on a non-idle one. In
> select_idle_core you can be slightly picky about the core because
> select_idle_cpu is a fail safe. I measured the performance impact of
> choosing the "best among low cap" vs the code changes I have (for
> select_idle_core) and could not find a statistically significant impact,
> hence went with the simpler code changes.

That's Ok with me. Just that I remember Peter messing with this path
and that it was expensive to scan too much for some systems. The other
thing is you're really doing to do a "fail safe" as you call it search
here with SIS_PROP set. Do you see a difference in perf when doing the
same approach as you took in select_idle_core?

Peter, are you with the approach Rohit has adopted to pick best
capacity idle CPU in select_idle_cpu? I guess nr--; will bail out
early if we have SIS_PROP set, incase the scan cost gets too much but
then again we might end scanning too few CPUs.

thanks,

- Joel

Re: [RESEND PATCH] sched/fair: consider RT/IRQ pressure in select_idle_sibling

[Joel Fernandes]

On Wed, Jan 31, 2018 at 9:50 AM, Rohit Jain  wrote:
>kernel/sched/fair.c | 38 --
>1 file changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 26a71eb..ce5ccf8 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5625,6 +5625,11 @@ static unsigned long capacity_orig_of(int cpu)
>   return cpu_rq(cpu)->cpu_capacity_orig;
>}
>
> +static inline bool full_capacity(int cpu)
> +{
> +   return capacity_of(cpu) >= (capacity_orig_of(cpu)*3)/4;
> +}
> +
>static unsigned long cpu_avg_load_per_task(int cpu)
>{
>   struct rq *rq = cpu_rq(cpu);
> @@ -6081,7 +6086,7 @@ static int select_idle_core(struct task_struct
> *p,
> struct sched_domain *sd, int
>
>   for_each_cpu(cpu, cpu_smt_mask(core)) {
>   cpumask_clear_cpu(cpu, cpus);
> -   if (!idle_cpu(cpu))
> +   if (!idle_cpu(cpu) || !full_capacity(cpu))
>   idle = false;
>   }

 There's some difference in logic between select_idle_core and
 select_idle_cpu as far as the full_capacity stuff you're adding goes.
 In select_idle_core, if all CPUs are !full_capacity, you're returning
 -1. But in select_idle_cpu you're returning the best idle CPU that's
 the most cap among the !full_capacity ones. Why there is this
 different in logic? Did I miss something?

>
> 
>
>> Dude :) That is hardly an answer to the question I asked. Hint:
>> *different in logic*.
>
>
> Let me re-try :)
>
> For select_idle_core, we are doing a search for a fully idle and full
> capacity core, the fail-safe is select_idle_cpu because we will re-scan
> the CPUs. The notion is to select an idle CPU no matter what, because
> being on an idle CPU is better than waiting on a non-idle one. In
> select_idle_core you can be slightly picky about the core because
> select_idle_cpu is a fail safe. I measured the performance impact of
> choosing the "best among low cap" vs the code changes I have (for
> select_idle_core) and could not find a statistically significant impact,
> hence went with the simpler code changes.

That's Ok with me. Just that I remember Peter messing with this path
and that it was expensive to scan too much for some systems. The other
thing is you're really doing to do a "fail safe" as you call it search
here with SIS_PROP set. Do you see a difference in perf when doing the
same approach as you took in select_idle_core?

Peter, are you with the approach Rohit has adopted to pick best
capacity idle CPU in select_idle_cpu? I guess nr--; will bail out
early if we have SIS_PROP set, incase the scan cost gets too much but
then again we might end scanning too few CPUs.

thanks,

- Joel

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

[Moritz Fischer]

On Mon, Feb 05, 2018 at 10:25:27PM -0600, Alan Tull wrote:
> On Mon, Feb 5, 2018 at 8:17 PM, Wu Hao  wrote:
> > On Mon, Feb 05, 2018 at 11:21:52AM -0600, Alan Tull wrote:
> >> On Sun, Feb 4, 2018 at 4:05 AM, Wu Hao  wrote:
> >> > On Sat, Feb 03, 2018 at 11:41:24AM +0100, Moritz Fischer wrote:
> >> >> Hi Hao,
> >> >>
> >> >> On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote:
> >> >> > Hi Hao, Alan,
> >> >> >
> >> >> > On Fri, Feb 02, 2018 at 05:42:13PM +0800, Wu Hao wrote:
> >> >> > > On Thu, Feb 01, 2018 at 04:00:36PM -0600, Alan Tull wrote:
> >> >> > > > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao  wrote:
> >> >> > > >
> >> >> > > > Hi Hao,
> >> >> > > >
> >> >> > > > A few comments below.   Besides that, looks good.
> >> >> > > >
> >> >> > > > > This patch adds fpga manager driver for FPGA Management Engine 
> >> >> > > > > (FME). It
> >> >> > > > > implements fpga_manager_ops for FPGA Partial Reconfiguration 
> >> >> > > > > function.
> >> >> > > > >
> >> >> > > > > Signed-off-by: Tim Whisonant 
> >> >> > > > > Signed-off-by: Enno Luebbers 
> >> >> > > > > Signed-off-by: Shiva Rao 
> >> >> > > > > Signed-off-by: Christopher Rauer 
> >> >> > > > > Signed-off-by: Kang Luwei 
> >> >> > > > > Signed-off-by: Xiao Guangrong 
> >> >> > > > > Signed-off-by: Wu Hao 
> >> >> > > > > 
> >> >> > > > > v3: rename driver to dfl-fpga-fme-mgr
> >> >> > > > > implemented status callback for fpga manager
> >> >> > > > > rebased due to fpga api changes
> >> >> > > > > ---
> >> >> > > > >  .../ABI/testing/sysfs-platform-fpga-dfl-fme-mgr|   8 +
> >> >> > > > >  drivers/fpga/Kconfig   |   6 +
> >> >> > > > >  drivers/fpga/Makefile  |   1 +
> >> >> > > > >  drivers/fpga/fpga-dfl-fme-mgr.c| 318 
> >> >> > > > > +
> >> >> > > > >  drivers/fpga/fpga-dfl.h|  39 ++-
> >> >> > > > >  5 files changed, 371 insertions(+), 1 deletion(-)
> >> >> > > > >  create mode 100644 
> >> >> > > > > Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > >  create mode 100644 drivers/fpga/fpga-dfl-fme-mgr.c
> >> >> > > > >
> >> >> > > > > diff --git 
> >> >> > > > > a/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr 
> >> >> > > > > b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > > new file mode 100644
> >> >> > > > > index 000..2d4f917
> >> >> > > > > --- /dev/null
> >> >> > > > > +++ b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > > @@ -0,0 +1,8 @@
> >> >> > > > > +What:  
> >> >> > > > > /sys/bus/platform/devices/fpga-dfl-fme-mgr.0/interface_id
> >> >> > > > > +Date:  November 2017
> >> >> > > > > +KernelVersion:  4.15
> >> >> > > > > +Contact:   Wu Hao 
> >> >> > > > > +Description:   Read-only. It returns interface id of partial 
> >> >> > > > > reconfiguration
> >> >> > > > > +   hardware. Userspace could use this information 
> >> >> > > > > to check if
> >> >> > > > > +   current hardware is compatible with given image 
> >> >> > > > > before FPGA
> >> >> > > > > +   programming.
> >> >> > > >
> >> >> > > > I'm a little confused by this.  I can understand that the PR 
> >> >> > > > bitstream
> >> >> > > > has a dependency on the FPGA's static image, but I don't 
> >> >> > > > understand
> >> >> > > > the dependency of the bistream on the hardware that is used to 
> >> >> > > > program
> >> >> > > > the bitstream to the FPGA.
> >> >> > >
> >> >> > > Sorry for the confusion, the interface_id is used to indicate the 
> >> >> > > version of
> >> >> > > the hardware for partial reconfiguration (it's part of the static 
> >> >> > > image of
> >> >> > > the FPGA device). Will improve the description on this.
> >> >>
> >> >> I'm not sure userland should be making the call on whether what you're
> >> >> trying to load is compatible or not.

I guess I was worried that you might take down a PR region that you
could've avoided. On second thought unless the kernel could extract that
info somehow from the bitstream before programming this is probably
anyway not possible, since the only one that knows the id -> bitstream
mapping is userland.

Hao's comments further down outline well enough that the hardware can
deal with incompatible bitstreams. So ignore my comments ;-)

> >>
> >> Could you explain more about what your concern was about this (unless
> >> Hao has covered it below)?
> >>
> >> It makes sense to me in this use case at least since userspace has a
> >> pile of images and is choosing which one to load.
> >>
> >> >> Isn't there a way to check this in
> >> >> your PR reconfiguration handler in-kernel?
> >> >
> >> > Hi 

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

[Moritz Fischer]

On Mon, Feb 05, 2018 at 10:25:27PM -0600, Alan Tull wrote:
> On Mon, Feb 5, 2018 at 8:17 PM, Wu Hao  wrote:
> > On Mon, Feb 05, 2018 at 11:21:52AM -0600, Alan Tull wrote:
> >> On Sun, Feb 4, 2018 at 4:05 AM, Wu Hao  wrote:
> >> > On Sat, Feb 03, 2018 at 11:41:24AM +0100, Moritz Fischer wrote:
> >> >> Hi Hao,
> >> >>
> >> >> On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote:
> >> >> > Hi Hao, Alan,
> >> >> >
> >> >> > On Fri, Feb 02, 2018 at 05:42:13PM +0800, Wu Hao wrote:
> >> >> > > On Thu, Feb 01, 2018 at 04:00:36PM -0600, Alan Tull wrote:
> >> >> > > > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao  wrote:
> >> >> > > >
> >> >> > > > Hi Hao,
> >> >> > > >
> >> >> > > > A few comments below.   Besides that, looks good.
> >> >> > > >
> >> >> > > > > This patch adds fpga manager driver for FPGA Management Engine 
> >> >> > > > > (FME). It
> >> >> > > > > implements fpga_manager_ops for FPGA Partial Reconfiguration 
> >> >> > > > > function.
> >> >> > > > >
> >> >> > > > > Signed-off-by: Tim Whisonant 
> >> >> > > > > Signed-off-by: Enno Luebbers 
> >> >> > > > > Signed-off-by: Shiva Rao 
> >> >> > > > > Signed-off-by: Christopher Rauer 
> >> >> > > > > Signed-off-by: Kang Luwei 
> >> >> > > > > Signed-off-by: Xiao Guangrong 
> >> >> > > > > Signed-off-by: Wu Hao 
> >> >> > > > > 
> >> >> > > > > v3: rename driver to dfl-fpga-fme-mgr
> >> >> > > > > implemented status callback for fpga manager
> >> >> > > > > rebased due to fpga api changes
> >> >> > > > > ---
> >> >> > > > >  .../ABI/testing/sysfs-platform-fpga-dfl-fme-mgr|   8 +
> >> >> > > > >  drivers/fpga/Kconfig   |   6 +
> >> >> > > > >  drivers/fpga/Makefile  |   1 +
> >> >> > > > >  drivers/fpga/fpga-dfl-fme-mgr.c| 318 
> >> >> > > > > +
> >> >> > > > >  drivers/fpga/fpga-dfl.h|  39 ++-
> >> >> > > > >  5 files changed, 371 insertions(+), 1 deletion(-)
> >> >> > > > >  create mode 100644 
> >> >> > > > > Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > >  create mode 100644 drivers/fpga/fpga-dfl-fme-mgr.c
> >> >> > > > >
> >> >> > > > > diff --git 
> >> >> > > > > a/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr 
> >> >> > > > > b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > > new file mode 100644
> >> >> > > > > index 000..2d4f917
> >> >> > > > > --- /dev/null
> >> >> > > > > +++ b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > > @@ -0,0 +1,8 @@
> >> >> > > > > +What:  
> >> >> > > > > /sys/bus/platform/devices/fpga-dfl-fme-mgr.0/interface_id
> >> >> > > > > +Date:  November 2017
> >> >> > > > > +KernelVersion:  4.15
> >> >> > > > > +Contact:   Wu Hao 
> >> >> > > > > +Description:   Read-only. It returns interface id of partial 
> >> >> > > > > reconfiguration
> >> >> > > > > +   hardware. Userspace could use this information 
> >> >> > > > > to check if
> >> >> > > > > +   current hardware is compatible with given image 
> >> >> > > > > before FPGA
> >> >> > > > > +   programming.
> >> >> > > >
> >> >> > > > I'm a little confused by this.  I can understand that the PR 
> >> >> > > > bitstream
> >> >> > > > has a dependency on the FPGA's static image, but I don't 
> >> >> > > > understand
> >> >> > > > the dependency of the bistream on the hardware that is used to 
> >> >> > > > program
> >> >> > > > the bitstream to the FPGA.
> >> >> > >
> >> >> > > Sorry for the confusion, the interface_id is used to indicate the 
> >> >> > > version of
> >> >> > > the hardware for partial reconfiguration (it's part of the static 
> >> >> > > image of
> >> >> > > the FPGA device). Will improve the description on this.
> >> >>
> >> >> I'm not sure userland should be making the call on whether what you're
> >> >> trying to load is compatible or not.

I guess I was worried that you might take down a PR region that you
could've avoided. On second thought unless the kernel could extract that
info somehow from the bitstream before programming this is probably
anyway not possible, since the only one that knows the id -> bitstream
mapping is userland.

Hao's comments further down outline well enough that the hardware can
deal with incompatible bitstreams. So ignore my comments ;-)

> >>
> >> Could you explain more about what your concern was about this (unless
> >> Hao has covered it below)?
> >>
> >> It makes sense to me in this use case at least since userspace has a
> >> pile of images and is choosing which one to load.
> >>
> >> >> Isn't there a way to check this in
> >> >> your PR reconfiguration handler in-kernel?
> >> >
> >> > Hi Moritz
> >> >
> >> > Actually with current driver interface, doing a partial reconfiguration 
> >> > with an
> >> > incompatible image, then driver will report PR failure with error code
> >> > FPGA_MGR_STATUS_INCOMPATIBLE_IMAGE_ERR as hardware 

Re: [RESEND PATCH] sched/fair: consider RT/IRQ pressure in select_idle_sibling

[Joel Fernandes]

On Tue, Jan 30, 2018 at 11:47 AM, Rohit Jain  wrote:
[...]
>>> @@ -6102,7 +6107,8 @@ static int select_idle_core(struct task_struct *p,
>>> struct sched_domain *sd, int
>>>*/
>>>   static int select_idle_smt(struct task_struct *p, struct sched_domain
>>> *sd, int target)
>>>   {
>>> -   int cpu;
>>> +   int cpu, rcpu = -1;
>>> +   unsigned long max_cap = 0;
>>>
>>>  if (!static_branch_likely(_smt_present))
>>>  return -1;
>>> @@ -6110,11 +6116,13 @@ static int select_idle_smt(struct task_struct *p,
>>> struct sched_domain *sd, int t
>>>  for_each_cpu(cpu, cpu_smt_mask(target)) {
>>>  if (!cpumask_test_cpu(cpu, >cpus_allowed))
>>>  continue;
>>> -   if (idle_cpu(cpu))
>>> -   return cpu;
>>> +   if (idle_cpu(cpu) && (capacity_of(cpu) > max_cap)) {
>>> +   max_cap = capacity_of(cpu);
>>> +   rcpu = cpu;
>>
>> At the SMT level, do you need to bother with choosing best capacity
>> among threads? If RT is eating into one of the SMT thread's underlying
>> capacity, it would eat into the other's. Wondering what's the benefit
>> of doing this here.
>
>
> Yes, you are right because of SD_SHARE_CPUCAPACITY, however the benefit
> is that if don't do this check, we might end up picking a SMT thread
> which has "high" RT/IRQ activity and be on the run queue for a while,
> till the pull side can bail us out.

Do your tests show a difference in results though with such change
(for select_idle_smt)?

thanks,

- Joel

Re: [RESEND PATCH] sched/fair: consider RT/IRQ pressure in select_idle_sibling

[Joel Fernandes]

On Tue, Jan 30, 2018 at 11:47 AM, Rohit Jain  wrote:
[...]
>>> @@ -6102,7 +6107,8 @@ static int select_idle_core(struct task_struct *p,
>>> struct sched_domain *sd, int
>>>*/
>>>   static int select_idle_smt(struct task_struct *p, struct sched_domain
>>> *sd, int target)
>>>   {
>>> -   int cpu;
>>> +   int cpu, rcpu = -1;
>>> +   unsigned long max_cap = 0;
>>>
>>>  if (!static_branch_likely(_smt_present))
>>>  return -1;
>>> @@ -6110,11 +6116,13 @@ static int select_idle_smt(struct task_struct *p,
>>> struct sched_domain *sd, int t
>>>  for_each_cpu(cpu, cpu_smt_mask(target)) {
>>>  if (!cpumask_test_cpu(cpu, >cpus_allowed))
>>>  continue;
>>> -   if (idle_cpu(cpu))
>>> -   return cpu;
>>> +   if (idle_cpu(cpu) && (capacity_of(cpu) > max_cap)) {
>>> +   max_cap = capacity_of(cpu);
>>> +   rcpu = cpu;
>>
>> At the SMT level, do you need to bother with choosing best capacity
>> among threads? If RT is eating into one of the SMT thread's underlying
>> capacity, it would eat into the other's. Wondering what's the benefit
>> of doing this here.
>
>
> Yes, you are right because of SD_SHARE_CPUCAPACITY, however the benefit
> is that if don't do this check, we might end up picking a SMT thread
> which has "high" RT/IRQ activity and be on the run queue for a while,
> till the pull side can bail us out.

Do your tests show a difference in results though with such change
(for select_idle_smt)?

thanks,

- Joel

[PATCH v4] ACPI / tables: Add IORT to injectable table list

[Yang Shunyong]

Loading IORT table from initrd can be used to fix severe firmware
IORT defects temporarily before platform/BIOS vendor releases an
upgraded BIOS binary.

Moreover, it is very powerful to debug SMMU node/device probe, MSI
allocation, stream id translation and IORT table from firmware.

It is also very useful to enable SMMU and devices behind SMMU before
firmware is ready.

This patch adds ACPI_SIG_IORT to the table, which enables IORT
from initrd to override which from firmware.

Cc: Joey Zheng 
Cc: Wang Dongsheng 
Cc: Jiang Yutang 
Cc: Hanjun Guo 
Signed-off-by: Yang Shunyong 
---

v4:
Add more accurate description for fix operation in commit message
according to Dongsheng and Hangjun's suggestion.

v3:
Add more detailed commit message according to Hanjun's suggestion.

v2:
Change typo ACPI_SIG_PPTT to ACPI_SIG_IORT in commit message.

---

 drivers/acpi/tables.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 80ce2a7d224b..7bcb66f3 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -456,7 +456,8 @@ static u8 __init acpi_table_checksum(u8 *buffer, u32 length)
ACPI_SIG_SLIC, ACPI_SIG_SPCR, ACPI_SIG_SPMI, ACPI_SIG_TCPA,
ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
-   ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, NULL };
+   ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
+   NULL };
 
 #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
 
-- 
1.8.3.1

[PATCH v4] ACPI / tables: Add IORT to injectable table list

[Yang Shunyong]

Loading IORT table from initrd can be used to fix severe firmware
IORT defects temporarily before platform/BIOS vendor releases an
upgraded BIOS binary.

Moreover, it is very powerful to debug SMMU node/device probe, MSI
allocation, stream id translation and IORT table from firmware.

It is also very useful to enable SMMU and devices behind SMMU before
firmware is ready.

This patch adds ACPI_SIG_IORT to the table, which enables IORT
from initrd to override which from firmware.

Cc: Joey Zheng 
Cc: Wang Dongsheng 
Cc: Jiang Yutang 
Cc: Hanjun Guo 
Signed-off-by: Yang Shunyong 
---

v4:
Add more accurate description for fix operation in commit message
according to Dongsheng and Hangjun's suggestion.

v3:
Add more detailed commit message according to Hanjun's suggestion.

v2:
Change typo ACPI_SIG_PPTT to ACPI_SIG_IORT in commit message.

---

 drivers/acpi/tables.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 80ce2a7d224b..7bcb66f3 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -456,7 +456,8 @@ static u8 __init acpi_table_checksum(u8 *buffer, u32 length)
ACPI_SIG_SLIC, ACPI_SIG_SPCR, ACPI_SIG_SPMI, ACPI_SIG_TCPA,
ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
-   ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, NULL };
+   ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
+   NULL };
 
 #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
 
-- 
1.8.3.1

Re: [PATCH v6 20/36] nds32: Signal handling support

[Vincent Chen]

Thanks, I got it.

After referring to arm64 and risc-v, we try to refine our code, such as
removing unneeded checking and refining syscall restart flow. We
hope these modifications can enhance the reliability and readability.
However, the following 2 files which you had acked are included in
this modification.
1. arch/nds32/include/asm/nds32.h
(patch: Assembly macros and definitions)
 The definition of  macro tbl and why are removed.
   - Now, we use pt_reg->syscallno instead of 'why' to determine
 whether entering kernel is via syscall or not. Therefore, macro
 'why' is unneeded.

--- a/arch/nds32/include/asm/nds32.h
+++ b/arch/nds32/include/asm/nds32.h
@@ -66,10 +66,6 @@ static inline unsigned long CACHE_LINE_SIZE

 #endif /* __ASSEMBLY__ */

-/* tbl and why is used in ex-scall.S and ex-exit.S */
-#define tbl $r8
-#define why $r8
-
 #define IVB_BASE   PHYS_OFFSET


2. arch/nds32/kernel/ex-scall.S(patch: System calls handling)
a. Define macro tbl
- The marco tbl is used only in this file. So, I move its definition
  from arch/nds32/include/asm/nds32.h to here.
b. Remove 'set why = 0'  when issuing syscall number is invalid
c. Adjust input arguments of syscall_trace_enter

--- a/arch/nds32/kernel/ex-scall.S
+++ b/arch/nds32/kernel/ex-scall.S
...
+#define tbl $r8

 /*
  * $r7 will be writen as syscall nr
- * by retrieving from $ITYPE 'SWID' bitfiled
  */
.macro  get_scno
lwi $r7, [$sp + R15_OFFSET]
@@ -54,7 +49,6 @@ ENTRY(eh_syscall)
get_scno
gie_enable

-ENTRY(eh_syscall_phase_2)
lwi $p0, [tsk+#TSK_TI_FLAGS]

andi$p1, $p0, #_TIF_WORK_SYSCALL_ENTRY
@@ -71,7 +65,6 @@ jmp_systbl:
jr  $p1 ! no return

 _SCNO_EXCEED:
-   moviwhy, 0
ori $r0, $r7, #0
ori$r1, $sp, #0
b   bad_syscall
@@ -81,8 +74,7 @@ _SCNO_EXCEED:
  * context switches, and waiting for our parent to respond.
  */
 __sys_trace:
-   move$r1, $sp
-   move$r0, $r7! trace entry [IP = 0]
+   move$r0, $sp
bal syscall_trace_enter
move$r7, $r0
la  $lp, __sys_trace_return ! return address


If you think these modifications in acked files are not permitted,
we will recover it.

We verify all modifications by LTP 2017 related cases and glibc
2.26 testsuite. We plan to add it in the next version patch and
hope you can give us some comments as before.

Thanks

Vincent



2018-01-24 19:13 GMT+08:00 Arnd Bergmann :
> On Wed, Jan 24, 2018 at 1:56 AM, Vincent Chen  wrote:
>> 2018-01-18 18:30 GMT+08:00 Arnd Bergmann :
>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu  wrote:
 From: Greentime Hu 

 This patch adds support for signal handling.

 Signed-off-by: Vincent Chen 
 Signed-off-by: Greentime Hu 
>>>
>>> I never feel qualified enough to properly review signal handling code, so
>>> no Ack from me for this code even though I don't see anything wrong with it.
>>> Hopefully someone else can give an Ack after looking more closely.
>>>
>>
>> Dear Arnd:
>>
>> We'd be glad to improve signal handling code to meet your requirement.
>> Could you
>> tell us which part we need to refine or which implementation is good
>> for us to refer?
>
> No, as I said, the problem is on my side, I just don't understand enough of 
> it.
> I would assume that the arm64 and risc-v implementations are the most
> thoroughly reviewed, but haven't looked at those in enough detail either.
> If your code does something that risc-v doesn't do, try to understand whether
> there should be a difference or not.
>
>   Arnd

Re: [PATCH v6 20/36] nds32: Signal handling support

[Vincent Chen]

Thanks, I got it.

After referring to arm64 and risc-v, we try to refine our code, such as
removing unneeded checking and refining syscall restart flow. We
hope these modifications can enhance the reliability and readability.
However, the following 2 files which you had acked are included in
this modification.
1. arch/nds32/include/asm/nds32.h
(patch: Assembly macros and definitions)
 The definition of  macro tbl and why are removed.
   - Now, we use pt_reg->syscallno instead of 'why' to determine
 whether entering kernel is via syscall or not. Therefore, macro
 'why' is unneeded.

--- a/arch/nds32/include/asm/nds32.h
+++ b/arch/nds32/include/asm/nds32.h
@@ -66,10 +66,6 @@ static inline unsigned long CACHE_LINE_SIZE

 #endif /* __ASSEMBLY__ */

-/* tbl and why is used in ex-scall.S and ex-exit.S */
-#define tbl $r8
-#define why $r8
-
 #define IVB_BASE   PHYS_OFFSET


2. arch/nds32/kernel/ex-scall.S(patch: System calls handling)
a. Define macro tbl
- The marco tbl is used only in this file. So, I move its definition
  from arch/nds32/include/asm/nds32.h to here.
b. Remove 'set why = 0'  when issuing syscall number is invalid
c. Adjust input arguments of syscall_trace_enter

--- a/arch/nds32/kernel/ex-scall.S
+++ b/arch/nds32/kernel/ex-scall.S
...
+#define tbl $r8

 /*
  * $r7 will be writen as syscall nr
- * by retrieving from $ITYPE 'SWID' bitfiled
  */
.macro  get_scno
lwi $r7, [$sp + R15_OFFSET]
@@ -54,7 +49,6 @@ ENTRY(eh_syscall)
get_scno
gie_enable

-ENTRY(eh_syscall_phase_2)
lwi $p0, [tsk+#TSK_TI_FLAGS]

andi$p1, $p0, #_TIF_WORK_SYSCALL_ENTRY
@@ -71,7 +65,6 @@ jmp_systbl:
jr  $p1 ! no return

 _SCNO_EXCEED:
-   moviwhy, 0
ori $r0, $r7, #0
ori$r1, $sp, #0
b   bad_syscall
@@ -81,8 +74,7 @@ _SCNO_EXCEED:
  * context switches, and waiting for our parent to respond.
  */
 __sys_trace:
-   move$r1, $sp
-   move$r0, $r7! trace entry [IP = 0]
+   move$r0, $sp
bal syscall_trace_enter
move$r7, $r0
la  $lp, __sys_trace_return ! return address


If you think these modifications in acked files are not permitted,
we will recover it.

We verify all modifications by LTP 2017 related cases and glibc
2.26 testsuite. We plan to add it in the next version patch and
hope you can give us some comments as before.

Thanks

Vincent



2018-01-24 19:13 GMT+08:00 Arnd Bergmann :
> On Wed, Jan 24, 2018 at 1:56 AM, Vincent Chen  wrote:
>> 2018-01-18 18:30 GMT+08:00 Arnd Bergmann :
>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu  wrote:
 From: Greentime Hu 

 This patch adds support for signal handling.

 Signed-off-by: Vincent Chen 
 Signed-off-by: Greentime Hu 
>>>
>>> I never feel qualified enough to properly review signal handling code, so
>>> no Ack from me for this code even though I don't see anything wrong with it.
>>> Hopefully someone else can give an Ack after looking more closely.
>>>
>>
>> Dear Arnd:
>>
>> We'd be glad to improve signal handling code to meet your requirement.
>> Could you
>> tell us which part we need to refine or which implementation is good
>> for us to refer?
>
> No, as I said, the problem is on my side, I just don't understand enough of 
> it.
> I would assume that the arm64 and risc-v implementations are the most
> thoroughly reviewed, but haven't looked at those in enough detail either.
> If your code does something that risc-v doesn't do, try to understand whether
> there should be a difference or not.
>
>   Arnd

Re: [PATCH 09/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c3 board file

[Sricharan R]

Hi Abhishek,

On 2/3/2018 5:07 PM, Abhishek Sahu wrote:
> On 2018-01-29 10:41, Sricharan R wrote:
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/boot/dts/Makefile  |  1 +
>>  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts | 14 ++
>>  2 files changed, 15 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 68e4b15..0104ba2 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -727,6 +727,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>>  qcom-ipq4019-ap.dk01.1-c2.dtb \
>>  qcom-ipq4019-ap.dk04.1-c1.dtb \
>>  qcom-ipq4019-ap.dk04.1-c5.dtb \
>> +    qcom-ipq4019-ap.dk04.1-c3.dtb \
>>  qcom-ipq8064-ap148.dtb \
>>  qcom-msm8660-surf.dtb \
>>  qcom-msm8960-cdp.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
>> b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
>> new file mode 100644
>> index 000..7a93fc4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
>> @@ -0,0 +1,14 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2017, The Linux Foundation. All rights reserved.
>> +
>> +#include "qcom-ipq4019-ap.dk04.1.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C3";
>> +
>> +    soc {
>> +    nand: qpic-nand@79b {
>> +    status = "disabled";
>> +    };
> 
>  Normally we need to disable in base dtsi and enable in
>  board dtsi so that base dtsi will always work in all the
>  boards. Now If We load the base dtsi in any DK04 board
>  other than C1, then nand failure will come.

 Hmm, qpic nand is not there only on C3 and available in rest
 of dk04-c* variants. So it should work, downstream also
 does it in same way. Anyways, from a readability point, feel that
 better to make these uncommon configurations in each board file
 specifically rather than putting in common file and changing like this.

Regards,
 Sricharan


-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 09/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c3 board file

[Sricharan R]

Hi Abhishek,

On 2/3/2018 5:07 PM, Abhishek Sahu wrote:
> On 2018-01-29 10:41, Sricharan R wrote:
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/boot/dts/Makefile  |  1 +
>>  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts | 14 ++
>>  2 files changed, 15 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 68e4b15..0104ba2 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -727,6 +727,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>>  qcom-ipq4019-ap.dk01.1-c2.dtb \
>>  qcom-ipq4019-ap.dk04.1-c1.dtb \
>>  qcom-ipq4019-ap.dk04.1-c5.dtb \
>> +    qcom-ipq4019-ap.dk04.1-c3.dtb \
>>  qcom-ipq8064-ap148.dtb \
>>  qcom-msm8660-surf.dtb \
>>  qcom-msm8960-cdp.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
>> b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
>> new file mode 100644
>> index 000..7a93fc4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
>> @@ -0,0 +1,14 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2017, The Linux Foundation. All rights reserved.
>> +
>> +#include "qcom-ipq4019-ap.dk04.1.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C3";
>> +
>> +    soc {
>> +    nand: qpic-nand@79b {
>> +    status = "disabled";
>> +    };
> 
>  Normally we need to disable in base dtsi and enable in
>  board dtsi so that base dtsi will always work in all the
>  boards. Now If We load the base dtsi in any DK04 board
>  other than C1, then nand failure will come.

 Hmm, qpic nand is not there only on C3 and available in rest
 of dk04-c* variants. So it should work, downstream also
 does it in same way. Anyways, from a readability point, feel that
 better to make these uncommon configurations in each board file
 specifically rather than putting in common file and changing like this.

Regards,
 Sricharan


-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 07/15] ARM: dts: ipq4019: Add ipq4019-ap.dk04.1-c1 board file

[Sricharan R]

Hi Abhishek,

On 2/3/2018 5:00 PM, Abhishek Sahu wrote:
> On 2018-01-29 10:41, Sricharan R wrote:
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/boot/dts/Makefile  | 1 +
>>  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts | 8 
>>  2 files changed, 9 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 21ed56d..1a8ab050 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -725,6 +725,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>>  qcom-apq8084-mtp.dtb \
>>  qcom-ipq4019-ap.dk01.1-c1.dtb \
>>  qcom-ipq4019-ap.dk01.1-c2.dtb \
>> +    qcom-ipq4019-ap.dk04.1-c1.dtb \
>>  qcom-ipq8064-ap148.dtb \
>>  qcom-msm8660-surf.dtb \
>>  qcom-msm8960-cdp.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
>> b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
>> new file mode 100644
>> index 000..41123be
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
>> @@ -0,0 +1,8 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2017, The Linux Foundation. All rights reserved.
>> +
>> +#include "qcom-ipq4019-ap.dk04.1.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C1";
>> +};
> 
>  It seems major diff between DK01 C1 and other variants is
>  qpic nand. qpic nand is only available in C1 so do we need
>  to disable the nand is base dk04 dtsi and enable it in this
>  C1 dts only. same for qpic bam.

 C1 - Has QPIC NAND, spi 78b5000-> cs0 -> spi_nor
 C5 - Has QPIC NAND, spi 78b5000-> cs0 -> spi_nor, cs1 -> spi_nand
 C2 - Has QPIC NAND, spi 78b5000-> cs0 -> spi_nor ( Audio board, yet to be 
posted for pending audio drivers)
 C3 - spi 78b5000-> cs0 -> spi_nor

 So C3 is the board where it is disabled and enabled in the rest. But from a
 readability point, feels better to touch this only in each board specific file.
 So will remove this from the common 04.dtsi and move it to each board file.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 07/15] ARM: dts: ipq4019: Add ipq4019-ap.dk04.1-c1 board file

[Sricharan R]

Hi Abhishek,

On 2/3/2018 5:00 PM, Abhishek Sahu wrote:
> On 2018-01-29 10:41, Sricharan R wrote:
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/boot/dts/Makefile  | 1 +
>>  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts | 8 
>>  2 files changed, 9 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 21ed56d..1a8ab050 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -725,6 +725,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>>  qcom-apq8084-mtp.dtb \
>>  qcom-ipq4019-ap.dk01.1-c1.dtb \
>>  qcom-ipq4019-ap.dk01.1-c2.dtb \
>> +    qcom-ipq4019-ap.dk04.1-c1.dtb \
>>  qcom-ipq8064-ap148.dtb \
>>  qcom-msm8660-surf.dtb \
>>  qcom-msm8960-cdp.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
>> b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
>> new file mode 100644
>> index 000..41123be
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
>> @@ -0,0 +1,8 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2017, The Linux Foundation. All rights reserved.
>> +
>> +#include "qcom-ipq4019-ap.dk04.1.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C1";
>> +};
> 
>  It seems major diff between DK01 C1 and other variants is
>  qpic nand. qpic nand is only available in C1 so do we need
>  to disable the nand is base dk04 dtsi and enable it in this
>  C1 dts only. same for qpic bam.

 C1 - Has QPIC NAND, spi 78b5000-> cs0 -> spi_nor
 C5 - Has QPIC NAND, spi 78b5000-> cs0 -> spi_nor, cs1 -> spi_nand
 C2 - Has QPIC NAND, spi 78b5000-> cs0 -> spi_nor ( Audio board, yet to be 
posted for pending audio drivers)
 C3 - spi 78b5000-> cs0 -> spi_nor

 So C3 is the board where it is disabled and enabled in the rest. But from a
 readability point, feels better to touch this only in each board specific file.
 So will remove this from the common 04.dtsi and move it to each board file.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 06/15] ARM: dts: ipq4019: Add ipq4019-ap.dk04.dtsi

[Sricharan R]

Hi Abhishek,

On 2/3/2018 4:47 PM, Abhishek Sahu wrote:
> On 2018-01-29 10:41, Sricharan R wrote:
>> Add the common parts for the dk04 boards.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 147
> 
>  
>> +
>> +    nand_pins: nand_pins {
>> +    pullups {
>> +    pins = "gpio52", "gpio53",
>> "gpio58",
>> +    "gpio59";
>> +    function = "qpic";
>> +    bias-pull-up;
>> +    };
>> +
>> +    pulldowns {
>> +    pins = "gpio54", "gpio55",
>> "gpio56",
>> +    "gpio57", "gpio60",
>> "gpio61",
>> +    "gpio62", "gpio63",
>> "gpio64",
>> +    "gpio65", "gpio66",
>> "gpio67",
>> +    "gpio68", "gpio69";
>> +    function = "qpic";
>> +    bias-pull-down;
>> +    };
>> +    };
> 
>  Can you please check once why do we need pull-up and
>  pull-down for NAND pins. The NAND chip will be mounted
>  over board itself so board design should take care of
>  required pull up and pull downs.
> 

  Mostly because, these are always **weak** pull up/down as defaults
  and should be overridden by the ones in the board (if there).


>  Also, some of the above pins like gpio52 will be only used
>  for LCD so we can remove those pins. Later on, when LCD
>  support will be added, we can add those pins.
 ok

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 06/15] ARM: dts: ipq4019: Add ipq4019-ap.dk04.dtsi

[Sricharan R]

Hi Abhishek,

On 2/3/2018 4:47 PM, Abhishek Sahu wrote:
> On 2018-01-29 10:41, Sricharan R wrote:
>> Add the common parts for the dk04 boards.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 147
> 
>  
>> +
>> +    nand_pins: nand_pins {
>> +    pullups {
>> +    pins = "gpio52", "gpio53",
>> "gpio58",
>> +    "gpio59";
>> +    function = "qpic";
>> +    bias-pull-up;
>> +    };
>> +
>> +    pulldowns {
>> +    pins = "gpio54", "gpio55",
>> "gpio56",
>> +    "gpio57", "gpio60",
>> "gpio61",
>> +    "gpio62", "gpio63",
>> "gpio64",
>> +    "gpio65", "gpio66",
>> "gpio67",
>> +    "gpio68", "gpio69";
>> +    function = "qpic";
>> +    bias-pull-down;
>> +    };
>> +    };
> 
>  Can you please check once why do we need pull-up and
>  pull-down for NAND pins. The NAND chip will be mounted
>  over board itself so board design should take care of
>  required pull up and pull downs.
> 

  Mostly because, these are always **weak** pull up/down as defaults
  and should be overridden by the ones in the board (if there).


>  Also, some of the above pins like gpio52 will be only used
>  for LCD so we can remove those pins. Later on, when LCD
>  support will be added, we can add those pins.
 ok

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 05/15] ARM: dts: ipq4019: Add ipq4019-ap-dk01-c2 board file

[Sricharan R]

Hi Abhishek,

On 2/3/2018 4:25 PM, Abhishek Sahu wrote:
> On 2018-01-29 10:41, Sricharan R wrote:
>> The board has a spi-nand interface on spi0 bus chipselect1.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/boot/dts/Makefile  |  1 +
>>  arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts | 25
>> +
>>  2 files changed, 26 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index d0381e9..21ed56d 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -724,6 +724,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>>  qcom-apq8084-ifc6540.dtb \
>>  qcom-apq8084-mtp.dtb \
>>  qcom-ipq4019-ap.dk01.1-c1.dtb \
>> +    qcom-ipq4019-ap.dk01.1-c2.dtb \
>>  qcom-ipq8064-ap148.dtb \
>>  qcom-msm8660-surf.dtb \
>>  qcom-msm8960-cdp.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
>> b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
>> new file mode 100644
>> index 000..e3442da
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
>> @@ -0,0 +1,25 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2017, The Linux Foundation. All rights reserved.
>> +
>> +#include "qcom-ipq4019-ap.dk01.1.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C2";
> 
>  s/IPQ40xx/IPQ4019
> 
 ok

>> +
>> +    soc {
>> +    spi_0: spi@78b5000 { /* BLSP1 QUP1 */
>> +    status = "ok";
>> +    cs-gpios = < 54 0>, < 59 0>;
> 
>  the base dk01 file has pinmux for 54 only.
>  for 59 pin, we need to add pinmux entry also.
> 

 ok. btw, infact think that 59 should be removed.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 05/15] ARM: dts: ipq4019: Add ipq4019-ap-dk01-c2 board file

[Sricharan R]

Hi Abhishek,

On 2/3/2018 4:25 PM, Abhishek Sahu wrote:
> On 2018-01-29 10:41, Sricharan R wrote:
>> The board has a spi-nand interface on spi0 bus chipselect1.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/boot/dts/Makefile  |  1 +
>>  arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts | 25
>> +
>>  2 files changed, 26 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index d0381e9..21ed56d 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -724,6 +724,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>>  qcom-apq8084-ifc6540.dtb \
>>  qcom-apq8084-mtp.dtb \
>>  qcom-ipq4019-ap.dk01.1-c1.dtb \
>> +    qcom-ipq4019-ap.dk01.1-c2.dtb \
>>  qcom-ipq8064-ap148.dtb \
>>  qcom-msm8660-surf.dtb \
>>  qcom-msm8960-cdp.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
>> b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
>> new file mode 100644
>> index 000..e3442da
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
>> @@ -0,0 +1,25 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2017, The Linux Foundation. All rights reserved.
>> +
>> +#include "qcom-ipq4019-ap.dk01.1.dtsi"
>> +
>> +/ {
>> +    model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C2";
> 
>  s/IPQ40xx/IPQ4019
> 
 ok

>> +
>> +    soc {
>> +    spi_0: spi@78b5000 { /* BLSP1 QUP1 */
>> +    status = "ok";
>> +    cs-gpios = < 54 0>, < 59 0>;
> 
>  the base dk01 file has pinmux for 54 only.
>  for 59 pin, we need to add pinmux entry also.
> 

 ok. btw, infact think that 59 should be removed.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v11 3/3] mm, x86: display pkey in smaps only if arch supports pkeys

[Michael Ellerman]

Ram Pai  writes:

> On Fri, Feb 02, 2018 at 12:27:27PM +0800, kbuild test robot wrote:
>> Hi Ram,
>> 
>> Thank you for the patch! Yet something to improve:
>> 
>> [auto build test ERROR on linus/master]
>> [also build test ERROR on v4.15 next-20180201]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improve the system]
>> 
>> url:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux_commits_Ram-2DPai_mm-2Dx86-2Dpowerpc-2DEnhancements-2Dto-2DMemory-2DProtection-2DKeys_20180202-2D120004=DwIBAg=jf_iaSHvJObTbx-siA1ZOg=m-UrKChQVkZtnPpjbF6YY99NbT8FBByQ-E-ygV8luxw=Fv3tEHet1bTUrDjOnzEhXvGM_4tGlkYhJHPBnWNWgVA=Z1W6CV2tfPmLYU8lVv1oDRl2cAyQA76KE2P064A2CQY=
>> config: x86_64-randconfig-x005-201804 (attached as .config)
>> compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64 
>> 
>> All error/warnings (new ones prefixed by >>):
>> 
>>In file included from arch/x86/include/asm/mmu_context.h:8:0,
>> from arch/x86/events/core.c:36:
>> >> include/linux/pkeys.h:16:23: error: expected identifier or '(' before 
>> >> numeric constant
>> #define vma_pkey(vma) 0
>>   ^
>> >> arch/x86/include/asm/mmu_context.h:298:19: note: in expansion of macro 
>> >> 'vma_pkey'
>> static inline int vma_pkey(struct vm_area_struct *vma)
>>   ^~~~
>> 
>> vim +16 include/linux/pkeys.h
>> 
>>  7   
>>  8   #ifdef CONFIG_ARCH_HAS_PKEYS
>>  9   #include 
>> 10   #else /* ! CONFIG_ARCH_HAS_PKEYS */
>> 11   #define arch_max_pkey() (1)
>> 12   #define execute_only_pkey(mm) (0)
>> 13   #define arch_override_mprotect_pkey(vma, prot, pkey) (0)
>> 14   #define PKEY_DEDICATED_EXECUTE_ONLY 0
>> 15   #define ARCH_VM_PKEY_FLAGS 0
>>   > 16   #define vma_pkey(vma) 0
>
> Oops. Thanks for catching the issue. The following fix will resolve the error.
>
> diff --git a/arch/x86/include/asm/mmu_context.h
> b/arch/x86/include/asm/mmu_context.h
> index 6d16d15..c1aeb19 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -238,11 +238,6 @@ static inline int vma_pkey(struct vm_area_struct
>   *vma)
>  
> return (vma->vm_flags & vma_pkey_mask) >> VM_PKEY_SHIFT;
> }
> -#else
> -static inline int vma_pkey(struct vm_area_struct *vma)
> -{
> -   return 0;
> -}
>  #endif

That's not working for me (i386_defconfig):

  In file included from ../include/linux/pkeys.h:6:0,
   from ../arch/x86/kernel/fpu/xstate.c:9:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../fs/proc/task_mmu.c:21:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../mm/mmap.c:46:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../mm/mprotect.c:27:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../arch/x86/kernel/fpu/core.c:15:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~

cheers

Re: [PATCH v11 3/3] mm, x86: display pkey in smaps only if arch supports pkeys

[Michael Ellerman]

Ram Pai  writes:

> On Fri, Feb 02, 2018 at 12:27:27PM +0800, kbuild test robot wrote:
>> Hi Ram,
>> 
>> Thank you for the patch! Yet something to improve:
>> 
>> [auto build test ERROR on linus/master]
>> [also build test ERROR on v4.15 next-20180201]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improve the system]
>> 
>> url:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux_commits_Ram-2DPai_mm-2Dx86-2Dpowerpc-2DEnhancements-2Dto-2DMemory-2DProtection-2DKeys_20180202-2D120004=DwIBAg=jf_iaSHvJObTbx-siA1ZOg=m-UrKChQVkZtnPpjbF6YY99NbT8FBByQ-E-ygV8luxw=Fv3tEHet1bTUrDjOnzEhXvGM_4tGlkYhJHPBnWNWgVA=Z1W6CV2tfPmLYU8lVv1oDRl2cAyQA76KE2P064A2CQY=
>> config: x86_64-randconfig-x005-201804 (attached as .config)
>> compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64 
>> 
>> All error/warnings (new ones prefixed by >>):
>> 
>>In file included from arch/x86/include/asm/mmu_context.h:8:0,
>> from arch/x86/events/core.c:36:
>> >> include/linux/pkeys.h:16:23: error: expected identifier or '(' before 
>> >> numeric constant
>> #define vma_pkey(vma) 0
>>   ^
>> >> arch/x86/include/asm/mmu_context.h:298:19: note: in expansion of macro 
>> >> 'vma_pkey'
>> static inline int vma_pkey(struct vm_area_struct *vma)
>>   ^~~~
>> 
>> vim +16 include/linux/pkeys.h
>> 
>>  7   
>>  8   #ifdef CONFIG_ARCH_HAS_PKEYS
>>  9   #include 
>> 10   #else /* ! CONFIG_ARCH_HAS_PKEYS */
>> 11   #define arch_max_pkey() (1)
>> 12   #define execute_only_pkey(mm) (0)
>> 13   #define arch_override_mprotect_pkey(vma, prot, pkey) (0)
>> 14   #define PKEY_DEDICATED_EXECUTE_ONLY 0
>> 15   #define ARCH_VM_PKEY_FLAGS 0
>>   > 16   #define vma_pkey(vma) 0
>
> Oops. Thanks for catching the issue. The following fix will resolve the error.
>
> diff --git a/arch/x86/include/asm/mmu_context.h
> b/arch/x86/include/asm/mmu_context.h
> index 6d16d15..c1aeb19 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -238,11 +238,6 @@ static inline int vma_pkey(struct vm_area_struct
>   *vma)
>  
> return (vma->vm_flags & vma_pkey_mask) >> VM_PKEY_SHIFT;
> }
> -#else
> -static inline int vma_pkey(struct vm_area_struct *vma)
> -{
> -   return 0;
> -}
>  #endif

That's not working for me (i386_defconfig):

  In file included from ../include/linux/pkeys.h:6:0,
   from ../arch/x86/kernel/fpu/xstate.c:9:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../fs/proc/task_mmu.c:21:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../mm/mmap.c:46:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../mm/mprotect.c:27:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../arch/x86/kernel/fpu/core.c:15:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~

cheers

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

[Ryder Lee]

On Tue, 2018-02-06 at 15:50 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2018-02-06 at 12:31 +0800, Ryder Lee wrote:
> > On Tue, 2018-02-06 at 15:05 +1100, Benjamin Herrenschmidt wrote:
> > > On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote:
> > > > 
> > > > I think the code should look at the bridge address <0x0800 ...> we list
> > > > in bindings for resolving interrupts in this case, but it seems like it
> > > > use the 'pdev->defvn << 8' which is not really we want and will lead to
> > > > mismatch.
> > > > 
> > > > interrupt-map-mask = <0xf800 0 0 7>;
> > > > interrupt-map = <0x 0 0 1 ...>,
> > > > <0x 0 0 2 ...>,
> > > > <0x 0 0 3 ...>,
> > > > <0x 0 0 4 ...>,
> > > > 
> > > >  0x0800 0 0 1 ...>,
> > > >  0x0800 0 0 2 ...>,
> > > >  0x0800 0 0 3 ...>,
> > > >  0x0800 0 0 4 ...>;
> > > > ...
> > > > pcie@1,0 {
> > > > reg = <0x0800 0 0 0 0>;
> > > > ...
> > > > };
> > > > 
> > > > 
> > > > Or, alternatively, we could add a interrupt-map property in both child
> > > > and root node to solve this. The below example is my original version as
> > > > I don't want to change that function either.
> > > 
> > > The code looks at devfn because it's meant to work for PCI including
> > > when the devices dont have a device node in the DT.
> > > 
> > > What I'm trying to figure out is what is it that your parent and
> > > children are representing here. Which is/are the root complex ?
> > 
> > This is a single root complex with 2 root port (children in DT).
> > 
> > > What is the actual topology as visible on the PCIe bus (is lspci output
> > > basically) and how does that map to your representation ?
> > 
> > # lspci
> > 00:00.0 Class 0604: 14c3:0801 //1st slot - pcie@0,0
> > 00:01.0 Class 0604: 14c3:0801 //2nd slot - pcie@1,0
> > 
> > 01:00.0 Class 0280: 14c3:7603 //A device which is connected to 1st slot
> > 02:00.0 Class 0200: 8086:1521 //A 4 func device which is connected to
> > 2nd slot
> > 02:00.1 Class 0200: 8086:1521
> > 02:00.2 Class 0200: 8086:1521
> > 02:00.3 Class 0200: 8086:1521
> 
> Ok so that's a rather standard setup. The "devfn << 8" of your root
> ports should be the exact same thing as their first reg property entry,
> I'm not sure why you have a mismatch here.

I've added some log after 'for loop':

pr_err("busn=0x%x, devfn=0x%x, reg=0x%x\n", pdev->bus->number, pdev->devfn, 
of_pci_get_devfn(ppnode));

and got these:

[5.651836] busn=0x0, devfn=0x0, reg=0x0
[5.651936] pcieport :00:00.0: assign IRQ: got 213
...
[5.652398] busn=0x0, devfn=0x8, reg=0x0
[5.652487] pcieport :00:01.0: assign IRQ: got 214

...
[5.653025] busn=0x2, devfn=0x0, reg=0x8
[5.653058] igb :02:00.0: assign IRQ: got 213

[5.724582] busn=0x2, devfn=0x1, reg=0x8
[5.724634] igb :02:00.1: assign IRQ: got 213

> However, that map only represents the INTA..D lines going to the root
> ports, not how these get mapped to children of the root ports.
> 
> of_irq_parse_pci() will implement standard swizzling if you don't have
> nodes for your devices at all. If you do, however, the code assumes
> you have a correct and complete interrupt tree in the device-tree.
> 
> That means that you need in each "p2p bridge", including your root
> ports, an interrupt-map that will map the children INTA...D of that
> bridge to the parent INTA...D of that bridge.
> 
> Alternatively, you can make the maps in the root ports point directly
> to the parent PIC. If you chose to do that, then the interrupt-map in
> your root complex becomes only useful to represent the root ports own
> interrutps (hotplug, AER,...) and could be replaced by just having
> interrupt-parent & interrupts in those root port nodes.
> 

Thanks for explanation.

So I guess the better way to achieve my aim - one IRQ per slot that is
connected to all INTx and get propagated through the bridges (and for
those root ports own interrupts (PME ..)} is to add interrupt-map
properties in both parent and root port nodes.

Something like this: https://patchwork.kernel.org/patch/9970923/ ,right?

Ryder

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

[Ryder Lee]

On Tue, 2018-02-06 at 15:50 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2018-02-06 at 12:31 +0800, Ryder Lee wrote:
> > On Tue, 2018-02-06 at 15:05 +1100, Benjamin Herrenschmidt wrote:
> > > On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote:
> > > > 
> > > > I think the code should look at the bridge address <0x0800 ...> we list
> > > > in bindings for resolving interrupts in this case, but it seems like it
> > > > use the 'pdev->defvn << 8' which is not really we want and will lead to
> > > > mismatch.
> > > > 
> > > > interrupt-map-mask = <0xf800 0 0 7>;
> > > > interrupt-map = <0x 0 0 1 ...>,
> > > > <0x 0 0 2 ...>,
> > > > <0x 0 0 3 ...>,
> > > > <0x 0 0 4 ...>,
> > > > 
> > > >  0x0800 0 0 1 ...>,
> > > >  0x0800 0 0 2 ...>,
> > > >  0x0800 0 0 3 ...>,
> > > >  0x0800 0 0 4 ...>;
> > > > ...
> > > > pcie@1,0 {
> > > > reg = <0x0800 0 0 0 0>;
> > > > ...
> > > > };
> > > > 
> > > > 
> > > > Or, alternatively, we could add a interrupt-map property in both child
> > > > and root node to solve this. The below example is my original version as
> > > > I don't want to change that function either.
> > > 
> > > The code looks at devfn because it's meant to work for PCI including
> > > when the devices dont have a device node in the DT.
> > > 
> > > What I'm trying to figure out is what is it that your parent and
> > > children are representing here. Which is/are the root complex ?
> > 
> > This is a single root complex with 2 root port (children in DT).
> > 
> > > What is the actual topology as visible on the PCIe bus (is lspci output
> > > basically) and how does that map to your representation ?
> > 
> > # lspci
> > 00:00.0 Class 0604: 14c3:0801 //1st slot - pcie@0,0
> > 00:01.0 Class 0604: 14c3:0801 //2nd slot - pcie@1,0
> > 
> > 01:00.0 Class 0280: 14c3:7603 //A device which is connected to 1st slot
> > 02:00.0 Class 0200: 8086:1521 //A 4 func device which is connected to
> > 2nd slot
> > 02:00.1 Class 0200: 8086:1521
> > 02:00.2 Class 0200: 8086:1521
> > 02:00.3 Class 0200: 8086:1521
> 
> Ok so that's a rather standard setup. The "devfn << 8" of your root
> ports should be the exact same thing as their first reg property entry,
> I'm not sure why you have a mismatch here.

I've added some log after 'for loop':

pr_err("busn=0x%x, devfn=0x%x, reg=0x%x\n", pdev->bus->number, pdev->devfn, 
of_pci_get_devfn(ppnode));

and got these:

[5.651836] busn=0x0, devfn=0x0, reg=0x0
[5.651936] pcieport :00:00.0: assign IRQ: got 213
...
[5.652398] busn=0x0, devfn=0x8, reg=0x0
[5.652487] pcieport :00:01.0: assign IRQ: got 214

...
[5.653025] busn=0x2, devfn=0x0, reg=0x8
[5.653058] igb :02:00.0: assign IRQ: got 213

[5.724582] busn=0x2, devfn=0x1, reg=0x8
[5.724634] igb :02:00.1: assign IRQ: got 213

> However, that map only represents the INTA..D lines going to the root
> ports, not how these get mapped to children of the root ports.
> 
> of_irq_parse_pci() will implement standard swizzling if you don't have
> nodes for your devices at all. If you do, however, the code assumes
> you have a correct and complete interrupt tree in the device-tree.
> 
> That means that you need in each "p2p bridge", including your root
> ports, an interrupt-map that will map the children INTA...D of that
> bridge to the parent INTA...D of that bridge.
> 
> Alternatively, you can make the maps in the root ports point directly
> to the parent PIC. If you chose to do that, then the interrupt-map in
> your root complex becomes only useful to represent the root ports own
> interrutps (hotplug, AER,...) and could be replaced by just having
> interrupt-parent & interrupts in those root port nodes.
> 

Thanks for explanation.

So I guess the better way to achieve my aim - one IRQ per slot that is
connected to all INTx and get propagated through the bridges (and for
those root ports own interrupts (PME ..)} is to add interrupt-map
properties in both parent and root port nodes.

Something like this: https://patchwork.kernel.org/patch/9970923/ ,right?

Ryder

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

[Wu Hao]

On Mon, Feb 05, 2018 at 10:25:27PM -0600, Alan Tull wrote:
> On Mon, Feb 5, 2018 at 8:17 PM, Wu Hao  wrote:
> > On Mon, Feb 05, 2018 at 11:21:52AM -0600, Alan Tull wrote:
> >> On Sun, Feb 4, 2018 at 4:05 AM, Wu Hao  wrote:
> >> > On Sat, Feb 03, 2018 at 11:41:24AM +0100, Moritz Fischer wrote:
> >> >> Hi Hao,
> >> >>
> >> >> On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote:
> >> >> > Hi Hao, Alan,
> >> >> >
> >> >> > On Fri, Feb 02, 2018 at 05:42:13PM +0800, Wu Hao wrote:
> >> >> > > On Thu, Feb 01, 2018 at 04:00:36PM -0600, Alan Tull wrote:
> >> >> > > > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao  wrote:
> >> >> > > >
> >> >> > > > Hi Hao,
> >> >> > > >
> >> >> > > > A few comments below.   Besides that, looks good.
> >> >> > > >
> >> >> > > > > This patch adds fpga manager driver for FPGA Management Engine 
> >> >> > > > > (FME). It
> >> >> > > > > implements fpga_manager_ops for FPGA Partial Reconfiguration 
> >> >> > > > > function.
> >> >> > > > >
> >> >> > > > > Signed-off-by: Tim Whisonant 
> >> >> > > > > Signed-off-by: Enno Luebbers 
> >> >> > > > > Signed-off-by: Shiva Rao 
> >> >> > > > > Signed-off-by: Christopher Rauer 
> >> >> > > > > Signed-off-by: Kang Luwei 
> >> >> > > > > Signed-off-by: Xiao Guangrong 
> >> >> > > > > Signed-off-by: Wu Hao 
> >> >> > > > > 
> >> >> > > > > v3: rename driver to dfl-fpga-fme-mgr
> >> >> > > > > implemented status callback for fpga manager
> >> >> > > > > rebased due to fpga api changes
> >> >> > > > > ---
> >> >> > > > >  .../ABI/testing/sysfs-platform-fpga-dfl-fme-mgr|   8 +
> >> >> > > > >  drivers/fpga/Kconfig   |   6 +
> >> >> > > > >  drivers/fpga/Makefile  |   1 +
> >> >> > > > >  drivers/fpga/fpga-dfl-fme-mgr.c| 318 
> >> >> > > > > +
> >> >> > > > >  drivers/fpga/fpga-dfl.h|  39 ++-
> >> >> > > > >  5 files changed, 371 insertions(+), 1 deletion(-)
> >> >> > > > >  create mode 100644 
> >> >> > > > > Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > >  create mode 100644 drivers/fpga/fpga-dfl-fme-mgr.c
> >> >> > > > >
> >> >> > > > > diff --git 
> >> >> > > > > a/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr 
> >> >> > > > > b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > > new file mode 100644
> >> >> > > > > index 000..2d4f917
> >> >> > > > > --- /dev/null
> >> >> > > > > +++ b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > > @@ -0,0 +1,8 @@
> >> >> > > > > +What:  
> >> >> > > > > /sys/bus/platform/devices/fpga-dfl-fme-mgr.0/interface_id
> >> >> > > > > +Date:  November 2017
> >> >> > > > > +KernelVersion:  4.15
> >> >> > > > > +Contact:   Wu Hao 
> >> >> > > > > +Description:   Read-only. It returns interface id of partial 
> >> >> > > > > reconfiguration
> >> >> > > > > +   hardware. Userspace could use this information 
> >> >> > > > > to check if
> >> >> > > > > +   current hardware is compatible with given image 
> >> >> > > > > before FPGA
> >> >> > > > > +   programming.
> >> >> > > >
> >> >> > > > I'm a little confused by this.  I can understand that the PR 
> >> >> > > > bitstream
> >> >> > > > has a dependency on the FPGA's static image, but I don't 
> >> >> > > > understand
> >> >> > > > the dependency of the bistream on the hardware that is used to 
> >> >> > > > program
> >> >> > > > the bitstream to the FPGA.
> >> >> > >
> >> >> > > Sorry for the confusion, the interface_id is used to indicate the 
> >> >> > > version of
> >> >> > > the hardware for partial reconfiguration (it's part of the static 
> >> >> > > image of
> >> >> > > the FPGA device). Will improve the description on this.
> >> >>
> >> >> I'm not sure userland should be making the call on whether what you're
> >> >> trying to load is compatible or not.
> >>
> >> Could you explain more about what your concern was about this (unless
> >> Hao has covered it below)?
> >>
> >> It makes sense to me in this use case at least since userspace has a
> >> pile of images and is choosing which one to load.
> >>
> >> >> Isn't there a way to check this in
> >> >> your PR reconfiguration handler in-kernel?
> >> >
> >> > Hi Moritz
> >> >
> >> > Actually with current driver interface, doing a partial reconfiguration 
> >> > with an
> >> > incompatible image, then driver will report PR failure with error code
> >> > FPGA_MGR_STATUS_INCOMPATIBLE_IMAGE_ERR as hardware checks it, but anyway 
> >> > user
> >> > needs to know hardware interface_id information to find or re-generated 
> >> > correct
> >> > images. I think it's more flexible to leave it to 

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

[Wu Hao]

On Mon, Feb 05, 2018 at 10:25:27PM -0600, Alan Tull wrote:
> On Mon, Feb 5, 2018 at 8:17 PM, Wu Hao  wrote:
> > On Mon, Feb 05, 2018 at 11:21:52AM -0600, Alan Tull wrote:
> >> On Sun, Feb 4, 2018 at 4:05 AM, Wu Hao  wrote:
> >> > On Sat, Feb 03, 2018 at 11:41:24AM +0100, Moritz Fischer wrote:
> >> >> Hi Hao,
> >> >>
> >> >> On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote:
> >> >> > Hi Hao, Alan,
> >> >> >
> >> >> > On Fri, Feb 02, 2018 at 05:42:13PM +0800, Wu Hao wrote:
> >> >> > > On Thu, Feb 01, 2018 at 04:00:36PM -0600, Alan Tull wrote:
> >> >> > > > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao  wrote:
> >> >> > > >
> >> >> > > > Hi Hao,
> >> >> > > >
> >> >> > > > A few comments below.   Besides that, looks good.
> >> >> > > >
> >> >> > > > > This patch adds fpga manager driver for FPGA Management Engine 
> >> >> > > > > (FME). It
> >> >> > > > > implements fpga_manager_ops for FPGA Partial Reconfiguration 
> >> >> > > > > function.
> >> >> > > > >
> >> >> > > > > Signed-off-by: Tim Whisonant 
> >> >> > > > > Signed-off-by: Enno Luebbers 
> >> >> > > > > Signed-off-by: Shiva Rao 
> >> >> > > > > Signed-off-by: Christopher Rauer 
> >> >> > > > > Signed-off-by: Kang Luwei 
> >> >> > > > > Signed-off-by: Xiao Guangrong 
> >> >> > > > > Signed-off-by: Wu Hao 
> >> >> > > > > 
> >> >> > > > > v3: rename driver to dfl-fpga-fme-mgr
> >> >> > > > > implemented status callback for fpga manager
> >> >> > > > > rebased due to fpga api changes
> >> >> > > > > ---
> >> >> > > > >  .../ABI/testing/sysfs-platform-fpga-dfl-fme-mgr|   8 +
> >> >> > > > >  drivers/fpga/Kconfig   |   6 +
> >> >> > > > >  drivers/fpga/Makefile  |   1 +
> >> >> > > > >  drivers/fpga/fpga-dfl-fme-mgr.c| 318 
> >> >> > > > > +
> >> >> > > > >  drivers/fpga/fpga-dfl.h|  39 ++-
> >> >> > > > >  5 files changed, 371 insertions(+), 1 deletion(-)
> >> >> > > > >  create mode 100644 
> >> >> > > > > Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > >  create mode 100644 drivers/fpga/fpga-dfl-fme-mgr.c
> >> >> > > > >
> >> >> > > > > diff --git 
> >> >> > > > > a/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr 
> >> >> > > > > b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > > new file mode 100644
> >> >> > > > > index 000..2d4f917
> >> >> > > > > --- /dev/null
> >> >> > > > > +++ b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >> >> > > > > @@ -0,0 +1,8 @@
> >> >> > > > > +What:  
> >> >> > > > > /sys/bus/platform/devices/fpga-dfl-fme-mgr.0/interface_id
> >> >> > > > > +Date:  November 2017
> >> >> > > > > +KernelVersion:  4.15
> >> >> > > > > +Contact:   Wu Hao 
> >> >> > > > > +Description:   Read-only. It returns interface id of partial 
> >> >> > > > > reconfiguration
> >> >> > > > > +   hardware. Userspace could use this information 
> >> >> > > > > to check if
> >> >> > > > > +   current hardware is compatible with given image 
> >> >> > > > > before FPGA
> >> >> > > > > +   programming.
> >> >> > > >
> >> >> > > > I'm a little confused by this.  I can understand that the PR 
> >> >> > > > bitstream
> >> >> > > > has a dependency on the FPGA's static image, but I don't 
> >> >> > > > understand
> >> >> > > > the dependency of the bistream on the hardware that is used to 
> >> >> > > > program
> >> >> > > > the bitstream to the FPGA.
> >> >> > >
> >> >> > > Sorry for the confusion, the interface_id is used to indicate the 
> >> >> > > version of
> >> >> > > the hardware for partial reconfiguration (it's part of the static 
> >> >> > > image of
> >> >> > > the FPGA device). Will improve the description on this.
> >> >>
> >> >> I'm not sure userland should be making the call on whether what you're
> >> >> trying to load is compatible or not.
> >>
> >> Could you explain more about what your concern was about this (unless
> >> Hao has covered it below)?
> >>
> >> It makes sense to me in this use case at least since userspace has a
> >> pile of images and is choosing which one to load.
> >>
> >> >> Isn't there a way to check this in
> >> >> your PR reconfiguration handler in-kernel?
> >> >
> >> > Hi Moritz
> >> >
> >> > Actually with current driver interface, doing a partial reconfiguration 
> >> > with an
> >> > incompatible image, then driver will report PR failure with error code
> >> > FPGA_MGR_STATUS_INCOMPATIBLE_IMAGE_ERR as hardware checks it, but anyway 
> >> > user
> >> > needs to know hardware interface_id information to find or re-generated 
> >> > correct
> >> > images. I think it's more flexible to leave it to userspace on using this
> >> > information exposed by driver. : )
> >> >
> >> > Thanks
> >> > Hao
> >> >
> >> >>
> >> >> > >
> >> >> >
> >> >> > The interface_id expresses the compatibility of the static region 
> >> >> > with PR
> >> >> > bitstreams 

Re: [PATCH v3 0/7] ARM: dts: imx6q: engicam LVDS panel changes

[Jagan Teki]

On Mon, Feb 5, 2018 at 4:28 PM, Shawn Guo  wrote:
> On Sun, Feb 04, 2018 at 11:19:24PM +0530, Jagan Teki wrote:
>> Series adda LVDS panel attributes on panel drivers instead of defining
>> them in dts nodes, and also added new icorem6 engicam boards.
>>
>> Jagan Teki (7):
>>   drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
>>   ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple
>>   ARM: dts: imx6dl-icore: Add LVDS node
>>   drm/panel: simple: Add support for KEO TX31D200VM0BAA
>>   ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple
>>   ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7
>> initial support
>>   ARM: dts: imx6q: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit
>> support
>>
>>  .../display/panel/ampire,am-800480aytzqw-00h.txt   | 25 +
>>  .../bindings/display/panel/koe,tx31d200vm0baa.txt  | 25 +
> ...
>>  drivers/gpu/drm/panel/panel-simple.c   | 54 ++
>
> The dts files should really be sent only after above bindings doc and
> driver changes get merged first.

OK, I will send drm/panel changes first.

Re: [PATCH v3 0/7] ARM: dts: imx6q: engicam LVDS panel changes

[Jagan Teki]

On Mon, Feb 5, 2018 at 4:28 PM, Shawn Guo  wrote:
> On Sun, Feb 04, 2018 at 11:19:24PM +0530, Jagan Teki wrote:
>> Series adda LVDS panel attributes on panel drivers instead of defining
>> them in dts nodes, and also added new icorem6 engicam boards.
>>
>> Jagan Teki (7):
>>   drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
>>   ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple
>>   ARM: dts: imx6dl-icore: Add LVDS node
>>   drm/panel: simple: Add support for KEO TX31D200VM0BAA
>>   ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple
>>   ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7
>> initial support
>>   ARM: dts: imx6q: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit
>> support
>>
>>  .../display/panel/ampire,am-800480aytzqw-00h.txt   | 25 +
>>  .../bindings/display/panel/koe,tx31d200vm0baa.txt  | 25 +
> ...
>>  drivers/gpu/drm/panel/panel-simple.c   | 54 ++
>
> The dts files should really be sent only after above bindings doc and
> driver changes get merged first.

OK, I will send drm/panel changes first.

[PATCH v2 07/10] ARM: sun8i: h3: add SY8113B regulator used by Orange Pi One board

[Icenowy Zheng]

Orange Pi One board has a SY8113B regulator, which is controlled via
GPIO and capable of outputing 1.1V when the PL6 GPIO is set to output 0
or 1.3V when the PL6 GPIO is set to input or output 1, and the output is
the power supply of the ARM cores in H3 SoC.

Add the device tree node of this regulator and set the cpu's cpu-supply
property to it.

Signed-off-by: Icenowy Zheng 
---
New patch in v2.

 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 82e5d28cd698..d8250aacfda1 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -88,6 +88,27 @@
gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
};
};
+
+   reg_sy8113b: gpio-regulator {
+   compatible = "regulator-gpio";
+   regulator-name = "vdd-cpux";
+   regulator-type = "voltage";
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <130>;
+   regulator-ramp-delay = <50>; /* 4ms */
+
+   gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+   enable-active-high;
+   gpios-states = <0x1>;
+   states = <110 0x0
+ 130 0x1>;
+   };
+};
+
+ {
+   cpu-supply = <_sy8113b>;
 };
 
  {
-- 
2.15.1

[PATCH v2 07/10] ARM: sun8i: h3: add SY8113B regulator used by Orange Pi One board

[Icenowy Zheng]

Orange Pi One board has a SY8113B regulator, which is controlled via
GPIO and capable of outputing 1.1V when the PL6 GPIO is set to output 0
or 1.3V when the PL6 GPIO is set to input or output 1, and the output is
the power supply of the ARM cores in H3 SoC.

Add the device tree node of this regulator and set the cpu's cpu-supply
property to it.

Signed-off-by: Icenowy Zheng 
---
New patch in v2.

 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 82e5d28cd698..d8250aacfda1 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -88,6 +88,27 @@
gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
};
};
+
+   reg_sy8113b: gpio-regulator {
+   compatible = "regulator-gpio";
+   regulator-name = "vdd-cpux";
+   regulator-type = "voltage";
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <130>;
+   regulator-ramp-delay = <50>; /* 4ms */
+
+   gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+   enable-active-high;
+   gpios-states = <0x1>;
+   states = <110 0x0
+ 130 0x1>;
+   };
+};
+
+ {
+   cpu-supply = <_sy8113b>;
 };
 
  {
-- 
2.15.1

[PATCH v2 08/10] ARM: sun8i: h3: Add SY8106A regulator to Orange Pi PC

[Icenowy Zheng]

From: Ondrej Jirman 

Add SY8106A regulator to r_i2c bus and enable the r_i2c bus on
Orange Pi PC, then set the power supply of the ARM cores to this
regulator, in order to enable DVFS.

Signed-off-by: Ondrej Jirman 
[Icenowy: Enable DVFS in this patch, slight changes and change commit
 message]
Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Reduce maximum voltage to 1.3V.
- Slightly changed the comment at 1.0V minimum voltage for taking BSP
  DVFS table instead of Armbian one.

 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index d22546df1b82..ded9d8d6d008 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -98,6 +98,10 @@
status = "okay";
 };
 
+ {
+   cpu-supply = <_sy8106a>;
+};
+
  {
status = "okay";
 };
@@ -160,6 +164,29 @@
};
 };
 
+_i2c {
+   status = "okay";
+
+   reg_sy8106a: regulator@65 {
+   compatible = "silergy,sy8106a";
+   reg = <0x65>;
+   regulator-name = "vdd-cpux";
+   /*
+* The datasheet uses 1.1V as the minimum value of VDD-CPUX,
+* however both the Armbian DVFS table and the official one
+* have operating points with voltage under 1.1V, and both
+* DVFS table are known to work properly at the lowest
+* operating point.
+*
+* Use 1.0V as the minimum voltage instead.
+*/
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
 _pio {
leds_r_opc: led_pins {
pins = "PL10";
-- 
2.15.1

[PATCH v2 08/10] ARM: sun8i: h3: Add SY8106A regulator to Orange Pi PC

[Icenowy Zheng]

From: Ondrej Jirman 

Add SY8106A regulator to r_i2c bus and enable the r_i2c bus on
Orange Pi PC, then set the power supply of the ARM cores to this
regulator, in order to enable DVFS.

Signed-off-by: Ondrej Jirman 
[Icenowy: Enable DVFS in this patch, slight changes and change commit
 message]
Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Reduce maximum voltage to 1.3V.
- Slightly changed the comment at 1.0V minimum voltage for taking BSP
  DVFS table instead of Armbian one.

 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index d22546df1b82..ded9d8d6d008 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -98,6 +98,10 @@
status = "okay";
 };
 
+ {
+   cpu-supply = <_sy8106a>;
+};
+
  {
status = "okay";
 };
@@ -160,6 +164,29 @@
};
 };
 
+_i2c {
+   status = "okay";
+
+   reg_sy8106a: regulator@65 {
+   compatible = "silergy,sy8106a";
+   reg = <0x65>;
+   regulator-name = "vdd-cpux";
+   /*
+* The datasheet uses 1.1V as the minimum value of VDD-CPUX,
+* however both the Armbian DVFS table and the official one
+* have operating points with voltage under 1.1V, and both
+* DVFS table are known to work properly at the lowest
+* operating point.
+*
+* Use 1.0V as the minimum voltage instead.
+*/
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
 _pio {
leds_r_opc: led_pins {
pins = "PL10";
-- 
2.15.1

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

[Benjamin Herrenschmidt]

On Tue, 2018-02-06 at 12:31 +0800, Ryder Lee wrote:
> On Tue, 2018-02-06 at 15:05 +1100, Benjamin Herrenschmidt wrote:
> > On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote:
> > > 
> > > I think the code should look at the bridge address <0x0800 ...> we list
> > > in bindings for resolving interrupts in this case, but it seems like it
> > > use the 'pdev->defvn << 8' which is not really we want and will lead to
> > > mismatch.
> > > 
> > >   interrupt-map-mask = <0xf800 0 0 7>;
> > >   interrupt-map = <0x 0 0 1 ...>,
> > >   <0x 0 0 2 ...>,
> > >   <0x 0 0 3 ...>,
> > >   <0x 0 0 4 ...>,
> > > 
> > >0x0800 0 0 1 ...>,
> > >0x0800 0 0 2 ...>,
> > >0x0800 0 0 3 ...>,
> > >0x0800 0 0 4 ...>;
> > >   ...
> > >   pcie@1,0 {
> > >   reg = <0x0800 0 0 0 0>;
> > >   ...
> > >   };
> > > 
> > > 
> > > Or, alternatively, we could add a interrupt-map property in both child
> > > and root node to solve this. The below example is my original version as
> > > I don't want to change that function either.
> > 
> > The code looks at devfn because it's meant to work for PCI including
> > when the devices dont have a device node in the DT.
> > 
> > What I'm trying to figure out is what is it that your parent and
> > children are representing here. Which is/are the root complex ?
> 
> This is a single root complex with 2 root port (children in DT).
> 
> > What is the actual topology as visible on the PCIe bus (is lspci output
> > basically) and how does that map to your representation ?
> 
> # lspci
> 00:00.0 Class 0604: 14c3:0801 //1st slot - pcie@0,0
> 00:01.0 Class 0604: 14c3:0801 //2nd slot - pcie@1,0
> 
> 01:00.0 Class 0280: 14c3:7603 //A device which is connected to 1st slot
> 02:00.0 Class 0200: 8086:1521 //A 4 func device which is connected to
> 2nd slot
> 02:00.1 Class 0200: 8086:1521
> 02:00.2 Class 0200: 8086:1521
> 02:00.3 Class 0200: 8086:1521

Ok so that's a rather standard setup. The "devfn << 8" of your root
ports should be the exact same thing as their first reg property entry,
I'm not sure why you have a mismatch here.

However, that map only represents the INTA..D lines going to the root
ports, not how these get mapped to children of the root ports.

of_irq_parse_pci() will implement standard swizzling if you don't have
nodes for your devices at all. If you do, however, the code assumes
you have a correct and complete interrupt tree in the device-tree.

That means that you need in each "p2p bridge", including your root
ports, an interrupt-map that will map the children INTA...D of that
bridge to the parent INTA...D of that bridge.

Alternatively, you can make the maps in the root ports point directly
to the parent PIC. If you chose to do that, then the interrupt-map in
your root complex becomes only useful to represent the root ports own
interrutps (hotplug, AER,...) and could be replaced by just having
interrupt-parent & interrupts in those root port nodes.

Cheers,
Ben.

[PATCH v2 10/10] ARM: sun8i: h3: set the cpu-supply to VDD-CPUX on ALL-H3-CC H3 ver

[Icenowy Zheng]

The ALL-H3-CC has a fixed VDD-CPUX voltage at 1.2V, which is supplied
by a regulator.

Set the CPU's cpu-supply property to the VDD-CPUX regulator.

Signed-off-by: Icenowy Zheng 
---
New patch in v2.

 arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts 
b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
index ca974d872357..02eb50b91a8f 100644
--- a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
@@ -112,6 +112,10 @@
};
 };
 
+ {
+   cpu-supply = <_vdd_cpux>;
+};
+
  {
allwinner,audio-routing =
"Line Out", "LINEOUT",
-- 
2.15.1

[PATCH v2 10/10] ARM: sun8i: h3: set the cpu-supply to VDD-CPUX on ALL-H3-CC H3 ver

[Icenowy Zheng]

The ALL-H3-CC has a fixed VDD-CPUX voltage at 1.2V, which is supplied
by a regulator.

Set the CPU's cpu-supply property to the VDD-CPUX regulator.

Signed-off-by: Icenowy Zheng 
---
New patch in v2.

 arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts 
b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
index ca974d872357..02eb50b91a8f 100644
--- a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
@@ -112,6 +112,10 @@
};
 };
 
+ {
+   cpu-supply = <_vdd_cpux>;
+};
+
  {
allwinner,audio-routing =
"Line Out", "LINEOUT",
-- 
2.15.1

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

[Benjamin Herrenschmidt]

On Tue, 2018-02-06 at 12:31 +0800, Ryder Lee wrote:
> On Tue, 2018-02-06 at 15:05 +1100, Benjamin Herrenschmidt wrote:
> > On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote:
> > > 
> > > I think the code should look at the bridge address <0x0800 ...> we list
> > > in bindings for resolving interrupts in this case, but it seems like it
> > > use the 'pdev->defvn << 8' which is not really we want and will lead to
> > > mismatch.
> > > 
> > >   interrupt-map-mask = <0xf800 0 0 7>;
> > >   interrupt-map = <0x 0 0 1 ...>,
> > >   <0x 0 0 2 ...>,
> > >   <0x 0 0 3 ...>,
> > >   <0x 0 0 4 ...>,
> > > 
> > >0x0800 0 0 1 ...>,
> > >0x0800 0 0 2 ...>,
> > >0x0800 0 0 3 ...>,
> > >0x0800 0 0 4 ...>;
> > >   ...
> > >   pcie@1,0 {
> > >   reg = <0x0800 0 0 0 0>;
> > >   ...
> > >   };
> > > 
> > > 
> > > Or, alternatively, we could add a interrupt-map property in both child
> > > and root node to solve this. The below example is my original version as
> > > I don't want to change that function either.
> > 
> > The code looks at devfn because it's meant to work for PCI including
> > when the devices dont have a device node in the DT.
> > 
> > What I'm trying to figure out is what is it that your parent and
> > children are representing here. Which is/are the root complex ?
> 
> This is a single root complex with 2 root port (children in DT).
> 
> > What is the actual topology as visible on the PCIe bus (is lspci output
> > basically) and how does that map to your representation ?
> 
> # lspci
> 00:00.0 Class 0604: 14c3:0801 //1st slot - pcie@0,0
> 00:01.0 Class 0604: 14c3:0801 //2nd slot - pcie@1,0
> 
> 01:00.0 Class 0280: 14c3:7603 //A device which is connected to 1st slot
> 02:00.0 Class 0200: 8086:1521 //A 4 func device which is connected to
> 2nd slot
> 02:00.1 Class 0200: 8086:1521
> 02:00.2 Class 0200: 8086:1521
> 02:00.3 Class 0200: 8086:1521

Ok so that's a rather standard setup. The "devfn << 8" of your root
ports should be the exact same thing as their first reg property entry,
I'm not sure why you have a mismatch here.

However, that map only represents the INTA..D lines going to the root
ports, not how these get mapped to children of the root ports.

of_irq_parse_pci() will implement standard swizzling if you don't have
nodes for your devices at all. If you do, however, the code assumes
you have a correct and complete interrupt tree in the device-tree.

That means that you need in each "p2p bridge", including your root
ports, an interrupt-map that will map the children INTA...D of that
bridge to the parent INTA...D of that bridge.

Alternatively, you can make the maps in the root ports point directly
to the parent PIC. If you chose to do that, then the interrupt-map in
your root complex becomes only useful to represent the root ports own
interrutps (hotplug, AER,...) and could be replaced by just having
interrupt-parent & interrupts in those root port nodes.

Cheers,
Ben.

[PATCH v2 06/10] ARM: sun8i: h2+: add SY8113B regulator used by Orange Pi Zero board

[Icenowy Zheng]

Orange Pi Zero board has a SY8113B regulator, which is controlled via
GPIO and capable of outputing 1.1V when the PL6 GPIO is set to output 0
or 1.3V when the PL6 GPIO is set to input or output 1, and the output is
the power supply of the ARM cores in H2+ SoC.

Add the device tree node of this regulator and set the cpu's cpu-supply
property to it.

Signed-off-by: Icenowy Zheng 
---
No changes in v2.

 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index 6713d0f2b3f4..34fc35737090 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -94,6 +94,27 @@
reset-gpios = <_pio 0 7 GPIO_ACTIVE_LOW>;
post-power-on-delay-ms = <200>;
};
+
+   reg_sy8113b: gpio-regulator {
+   compatible = "regulator-gpio";
+   regulator-name = "vdd-cpux";
+   regulator-type = "voltage";
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <130>;
+   regulator-ramp-delay = <50>; /* 4ms */
+
+   gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+   enable-active-high;
+   gpios-states = <0x1>;
+   states = <110 0x0
+ 130 0x1>;
+   };
+};
+
+ {
+   cpu-supply = <_sy8113b>;
 };
 
  {
-- 
2.15.1

[PATCH v2 06/10] ARM: sun8i: h2+: add SY8113B regulator used by Orange Pi Zero board

[Icenowy Zheng]

Orange Pi Zero board has a SY8113B regulator, which is controlled via
GPIO and capable of outputing 1.1V when the PL6 GPIO is set to output 0
or 1.3V when the PL6 GPIO is set to input or output 1, and the output is
the power supply of the ARM cores in H2+ SoC.

Add the device tree node of this regulator and set the cpu's cpu-supply
property to it.

Signed-off-by: Icenowy Zheng 
---
No changes in v2.

 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index 6713d0f2b3f4..34fc35737090 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -94,6 +94,27 @@
reset-gpios = <_pio 0 7 GPIO_ACTIVE_LOW>;
post-power-on-delay-ms = <200>;
};
+
+   reg_sy8113b: gpio-regulator {
+   compatible = "regulator-gpio";
+   regulator-name = "vdd-cpux";
+   regulator-type = "voltage";
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <130>;
+   regulator-ramp-delay = <50>; /* 4ms */
+
+   gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+   enable-active-high;
+   gpios-states = <0x1>;
+   states = <110 0x0
+ 130 0x1>;
+   };
+};
+
+ {
+   cpu-supply = <_sy8113b>;
 };
 
  {
-- 
2.15.1

[PATCH v2 05/10] ARM: sun8i: h3: add operating-points-v2 table for CPU

[Icenowy Zheng]

The CPU on Allwinner H3 can do dynamic frequency scaling.

Add a DVFS table based on the one shipped with Allwinner's H3 SDK. The
voltage-frequency relationship seems to be conservative, and Armbian has
another DVFS table which uses lower voltage at a certain frequency.
However, the official one is chosen for safety.

Frequencies higher than 1008MHz are temporarily dropped in the table, as
they may lead to over voltage on boards without proper regulator
settings or over temperature on boards with proper regulator settings.
They will be added back once regulator settings are ready and thermal
sensor driver is merged.

In order to satisfy all different regulators (SY8106A which is 50mV per
level, SY8113B which have two states: 1.1V and 1.3V, and some board with
non-tweakable regulators), all the OPPs are defined with a range which has
the target value as the minimum allowed value, and 1.3V (the highest
VDD-CPUX voltage suggested by the datasheet) as the maximum allowed value.
It's proven to work well with a board with SY8113B.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Switch to BSP OPP table, which is more conservative.

 arch/arm/boot/dts/sun8i-h3.dtsi | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 8495deecedad..36608c03f02b 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -43,32 +43,62 @@
 #include "sunxi-h3-h5.dtsi"
 
 / {
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@64800 {
+   opp-hz = /bits/ 64 <64800>;
+   opp-microvolt = <104 104 130>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp@81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <110 110 130>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp@100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <120 120 130>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
+   clocks = < CLK_CPUX>;
+   clock-names = "cpu";
+   operating-points-v2 = <_opp_table>;
+   #cooling-cells = <0x2>;
};
 
cpu@1 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+   operating-points-v2 = <_opp_table>;
};
 
cpu@2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+   operating-points-v2 = <_opp_table>;
};
 
cpu@3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+   operating-points-v2 = <_opp_table>;
};
};
 
-- 
2.15.1

[PATCH v2 05/10] ARM: sun8i: h3: add operating-points-v2 table for CPU

[Icenowy Zheng]

The CPU on Allwinner H3 can do dynamic frequency scaling.

Add a DVFS table based on the one shipped with Allwinner's H3 SDK. The
voltage-frequency relationship seems to be conservative, and Armbian has
another DVFS table which uses lower voltage at a certain frequency.
However, the official one is chosen for safety.

Frequencies higher than 1008MHz are temporarily dropped in the table, as
they may lead to over voltage on boards without proper regulator
settings or over temperature on boards with proper regulator settings.
They will be added back once regulator settings are ready and thermal
sensor driver is merged.

In order to satisfy all different regulators (SY8106A which is 50mV per
level, SY8113B which have two states: 1.1V and 1.3V, and some board with
non-tweakable regulators), all the OPPs are defined with a range which has
the target value as the minimum allowed value, and 1.3V (the highest
VDD-CPUX voltage suggested by the datasheet) as the maximum allowed value.
It's proven to work well with a board with SY8113B.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Switch to BSP OPP table, which is more conservative.

 arch/arm/boot/dts/sun8i-h3.dtsi | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 8495deecedad..36608c03f02b 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -43,32 +43,62 @@
 #include "sunxi-h3-h5.dtsi"
 
 / {
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@64800 {
+   opp-hz = /bits/ 64 <64800>;
+   opp-microvolt = <104 104 130>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp@81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <110 110 130>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp@100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <120 120 130>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
+   clocks = < CLK_CPUX>;
+   clock-names = "cpu";
+   operating-points-v2 = <_opp_table>;
+   #cooling-cells = <0x2>;
};
 
cpu@1 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+   operating-points-v2 = <_opp_table>;
};
 
cpu@2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+   operating-points-v2 = <_opp_table>;
};
 
cpu@3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+   operating-points-v2 = <_opp_table>;
};
};
 
-- 
2.15.1

[PATCH v2 09/10] ARM: sun8i: h3: fix ALL-H3-CC H3 ver VDD-CPUX voltage

[Icenowy Zheng]

The VDD-CPUX voltage of ALL-H3-CC H3 ver should be 1.2V, not the 3.3V
currently defined in the device tree.

Fix the voltage in the device tree.

Fixes: 6ca358645d4d ("ARM: dts: sun8i: h3: Add dts file for Libre Computer 
Board ALL-H3-CC H3 ver.")
Signed-off-by: Icenowy Zheng 
---
New patch in v2.

 arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts 
b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
index d406571a0dd6..ca974d872357 100644
--- a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
@@ -102,8 +102,8 @@
reg_vdd_cpux: vdd-cpux {
compatible = "regulator-fixed";
regulator-name = "vdd-cpux";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
regulator-always-on;
regulator-boot-on;
vin-supply = <_vcc5v0>;
-- 
2.15.1

[PATCH v2 09/10] ARM: sun8i: h3: fix ALL-H3-CC H3 ver VDD-CPUX voltage

[Icenowy Zheng]

The VDD-CPUX voltage of ALL-H3-CC H3 ver should be 1.2V, not the 3.3V
currently defined in the device tree.

Fix the voltage in the device tree.

Fixes: 6ca358645d4d ("ARM: dts: sun8i: h3: Add dts file for Libre Computer 
Board ALL-H3-CC H3 ver.")
Signed-off-by: Icenowy Zheng 
---
New patch in v2.

 arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts 
b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
index d406571a0dd6..ca974d872357 100644
--- a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
@@ -102,8 +102,8 @@
reg_vdd_cpux: vdd-cpux {
compatible = "regulator-fixed";
regulator-name = "vdd-cpux";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
regulator-always-on;
regulator-boot-on;
vin-supply = <_vcc5v0>;
-- 
2.15.1