Re: [PATCH] dt-bindings: irqchip: renesas-irqc: Document R-Car M3-N support

[Simon Horman]

On Mon, Feb 26, 2018 at 04:25:12PM +0100, Geert Uytterhoeven wrote:
> Document support for the Interrupt Controller for Externel Devices
> (INTC-EX) in the Renesas M3-N (r8a77965) SoC.
> 
> No driver update is needed.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

Re: [PATCH] dt-bindings: irqchip: renesas-irqc: Document R-Car M3-N support

[Simon Horman]

On Mon, Feb 26, 2018 at 04:25:12PM +0100, Geert Uytterhoeven wrote:
> Document support for the Interrupt Controller for Externel Devices
> (INTC-EX) in the Renesas M3-N (r8a77965) SoC.
> 
> No driver update is needed.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

[PATCH] sched: label attributes require a ';'

[Norbert Manthey]

Due to using gcc defines for configuration, some labels might be unused in
certain configurations. While adding a __maybe_unused to the label is
fine in general, the line has to be terminated with ';'. This is also
reflected in the gcc documentation, but gcc parsed the previous variant
without an error message.

This has been spotted while compiling with goto-cc, the compiler for the
CPROVER tool suite.

Signed-off-by: Norbert Manthey 
Signed-off-by: Michael Tautschnig 

Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
 kernel/sched/fair.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 26a71eb..3af8fb6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6716,7 +6716,7 @@ pick_next_task_fair(struct rq *rq, struct task_struct 
*prev, struct rq_flags *rf
 
p = task_of(se);
 
-done: __maybe_unused
+done: __maybe_unused;
 #ifdef CONFIG_SMP
/*
 * Move the next running task to the front of
-- 
2.7.4

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

[PATCH] sched: label attributes require a ';'

[Norbert Manthey]

Due to using gcc defines for configuration, some labels might be unused in
certain configurations. While adding a __maybe_unused to the label is
fine in general, the line has to be terminated with ';'. This is also
reflected in the gcc documentation, but gcc parsed the previous variant
without an error message.

This has been spotted while compiling with goto-cc, the compiler for the
CPROVER tool suite.

Signed-off-by: Norbert Manthey 
Signed-off-by: Michael Tautschnig 

Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
 kernel/sched/fair.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 26a71eb..3af8fb6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6716,7 +6716,7 @@ pick_next_task_fair(struct rq *rq, struct task_struct 
*prev, struct rq_flags *rf
 
p = task_of(se);
 
-done: __maybe_unused
+done: __maybe_unused;
 #ifdef CONFIG_SMP
/*
 * Move the next running task to the front of
-- 
2.7.4

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

Re: [RFC] vfio iommu type1: improve memory pinning process for raw PFN mapping

[Jason Cai (Xiang Feng)]

On 27 Feb 2018, at 3:19 AM, Alex Williamson  wrote:

> On Sat, 24 Feb 2018 13:44:07 +0800
> jason  wrote:
> 
>> When using vfio to pass through a PCIe device (e.g. a GPU card) that
>> has a huge BAR (e.g. 16GB), a lot of cycles are wasted on memory
>> pinning because PFNs of PCI BAR are not backed by struct page, and
>> the corresponding VMA has flags VM_IO|VM_PFNMAP.
>> 
>> With this change, memory pinning process will firstly try to figure
>> out whether the corresponding region is a raw PFN mapping, and if so
>> it can skip unnecessary user memory pinning process.
>> 
>> Even though it commes with a little overhead, finding vma and testing
>> flags, on each call, it can significantly improve VM's boot up time
>> when passing through devices via VFIO.
> 
> Needs a Sign-off, see Documentation/process/submitting-patches.rst
> 
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 22 ++
>> 1 file changed, 22 insertions(+)
>> 
>> diff --git a/drivers/vfio/vfio_iommu_type1.c 
>> b/drivers/vfio/vfio_iommu_type1.c
>> index e30e29ae4819..1a471ece3f9c 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -374,6 +374,24 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
>> long vaddr,
>>return ret;
>> }
>> 
>> +static int try_io_pfnmap(struct mm_struct *mm, unsigned long vaddr, long 
>> npage,
>> +unsigned long *pfn)
>> +{
>> +   struct vm_area_struct *vma;
>> +   int pinned = 0;
>> +
>> +   down_read(>mmap_sem);
>> +   vma = find_vma_intersection(mm, vaddr, vaddr + 1);
>> +   if (vma && vma->vm_flags & (VM_IO | VM_PFNMAP)) {
>> +   *pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + 
>> vma->vm_pgoff;
>> +   if (is_invalid_reserved_pfn(*pfn))
>> +   pinned = min(npage, (long)vma_pages(vma));
>> +   }
>> +   up_read(>mmap_sem);
>> +
>> +   return pinned;
>> +}
>> +
>> /*
>>  * Attempt to pin pages.  We really don't want to track all the pfns and
>>  * the iommu can only map chunks of consecutive pfns anyway, so get the
>> @@ -392,6 +410,10 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
>> unsigned long vaddr,
>>if (!current->mm)
>>return -ENODEV;
>> 
>> +   ret = try_io_pfnmap(current->mm, vaddr, npage, pfn_base);
>> +   if (ret)
>> +   return ret;
>> +
>>ret = vaddr_get_pfn(current->mm, vaddr, dma->prot, pfn_base);
>>if (ret)
>>return ret;
> 
> I like the idea, but couldn't we integrated it better?  For instance,
> does it really make sense to test for this first, the majority of users
> are going to have more regular mappings than PFNMAP mappings.  If we
> were to do the above optimization, doesn't the rsvd bits in the
> remainder of the code become cruft?  What if we optimized from the point
> where we test the return of vaddr_get_pfn() for a reserved/invalid page?
> Perhaps something like the below (untested, uncompiled) patch.  Also
> curious why the above tests VM_IO|VM_PFNMAP while vaddr_get_pfn() only
> tests VM_PFNMAP, we should at least be consistent, but also correct the
> existing function if it's missing a case. Thanks,
> 
> Alex
> 

Good points! The patch has been updated according to these points.
And I’ve also tested with it. Please see it at the end. Thanks.

> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index e113b2c43be2..425922393316 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -399,7 +399,6 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
> unsigned long vaddr,
> {
>   unsigned long pfn = 0;
>   long ret, pinned = 0, lock_acct = 0;
> - bool rsvd;
>   dma_addr_t iova = vaddr - dma->vaddr + dma->iova;
> 
>   /* This code path is only user initiated */
> @@ -410,14 +409,23 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
> unsigned long vaddr,
>   if (ret)
>   return ret;
> 
> + if (is_invalid_reserved_pfn(*pfn_base)) {
> + struct vm_area_struct *vma;
> +
> + down_read(>mmap_sem);
> + vma = find_vma_intersection(mm, vaddr, vaddr + 1);
> + pinned = min(npage, (long)vma_pages(vma));
> + up_read(>mmap_sem);
> + return pinned;
> + }
> +
>   pinned++;
> - rsvd = is_invalid_reserved_pfn(*pfn_base);
> 
>   /*
>* Reserved pages aren't counted against the user, externally pinned
>* pages are already counted against the user.
>*/
> - if (!rsvd && !vfio_find_vpfn(dma, iova)) {
> + if (!vfio_find_vpfn(dma, iova)) {
>   if (!lock_cap && current->mm->locked_vm + 1 > limit) {
>   put_pfn(*pfn_base, dma->prot);
>   pr_warn("%s: RLIMIT_MEMLOCK (%ld) exceeded\n", __func__,
> @@ -437,13 +445,12 @@ 

Re: [RFC] vfio iommu type1: improve memory pinning process for raw PFN mapping

[Jason Cai (Xiang Feng)]

On 27 Feb 2018, at 3:19 AM, Alex Williamson  wrote:

> On Sat, 24 Feb 2018 13:44:07 +0800
> jason  wrote:
> 
>> When using vfio to pass through a PCIe device (e.g. a GPU card) that
>> has a huge BAR (e.g. 16GB), a lot of cycles are wasted on memory
>> pinning because PFNs of PCI BAR are not backed by struct page, and
>> the corresponding VMA has flags VM_IO|VM_PFNMAP.
>> 
>> With this change, memory pinning process will firstly try to figure
>> out whether the corresponding region is a raw PFN mapping, and if so
>> it can skip unnecessary user memory pinning process.
>> 
>> Even though it commes with a little overhead, finding vma and testing
>> flags, on each call, it can significantly improve VM's boot up time
>> when passing through devices via VFIO.
> 
> Needs a Sign-off, see Documentation/process/submitting-patches.rst
> 
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 22 ++
>> 1 file changed, 22 insertions(+)
>> 
>> diff --git a/drivers/vfio/vfio_iommu_type1.c 
>> b/drivers/vfio/vfio_iommu_type1.c
>> index e30e29ae4819..1a471ece3f9c 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -374,6 +374,24 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
>> long vaddr,
>>return ret;
>> }
>> 
>> +static int try_io_pfnmap(struct mm_struct *mm, unsigned long vaddr, long 
>> npage,
>> +unsigned long *pfn)
>> +{
>> +   struct vm_area_struct *vma;
>> +   int pinned = 0;
>> +
>> +   down_read(>mmap_sem);
>> +   vma = find_vma_intersection(mm, vaddr, vaddr + 1);
>> +   if (vma && vma->vm_flags & (VM_IO | VM_PFNMAP)) {
>> +   *pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + 
>> vma->vm_pgoff;
>> +   if (is_invalid_reserved_pfn(*pfn))
>> +   pinned = min(npage, (long)vma_pages(vma));
>> +   }
>> +   up_read(>mmap_sem);
>> +
>> +   return pinned;
>> +}
>> +
>> /*
>>  * Attempt to pin pages.  We really don't want to track all the pfns and
>>  * the iommu can only map chunks of consecutive pfns anyway, so get the
>> @@ -392,6 +410,10 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
>> unsigned long vaddr,
>>if (!current->mm)
>>return -ENODEV;
>> 
>> +   ret = try_io_pfnmap(current->mm, vaddr, npage, pfn_base);
>> +   if (ret)
>> +   return ret;
>> +
>>ret = vaddr_get_pfn(current->mm, vaddr, dma->prot, pfn_base);
>>if (ret)
>>return ret;
> 
> I like the idea, but couldn't we integrated it better?  For instance,
> does it really make sense to test for this first, the majority of users
> are going to have more regular mappings than PFNMAP mappings.  If we
> were to do the above optimization, doesn't the rsvd bits in the
> remainder of the code become cruft?  What if we optimized from the point
> where we test the return of vaddr_get_pfn() for a reserved/invalid page?
> Perhaps something like the below (untested, uncompiled) patch.  Also
> curious why the above tests VM_IO|VM_PFNMAP while vaddr_get_pfn() only
> tests VM_PFNMAP, we should at least be consistent, but also correct the
> existing function if it's missing a case. Thanks,
> 
> Alex
> 

Good points! The patch has been updated according to these points.
And I’ve also tested with it. Please see it at the end. Thanks.

> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index e113b2c43be2..425922393316 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -399,7 +399,6 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
> unsigned long vaddr,
> {
>   unsigned long pfn = 0;
>   long ret, pinned = 0, lock_acct = 0;
> - bool rsvd;
>   dma_addr_t iova = vaddr - dma->vaddr + dma->iova;
> 
>   /* This code path is only user initiated */
> @@ -410,14 +409,23 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
> unsigned long vaddr,
>   if (ret)
>   return ret;
> 
> + if (is_invalid_reserved_pfn(*pfn_base)) {
> + struct vm_area_struct *vma;
> +
> + down_read(>mmap_sem);
> + vma = find_vma_intersection(mm, vaddr, vaddr + 1);
> + pinned = min(npage, (long)vma_pages(vma));
> + up_read(>mmap_sem);
> + return pinned;
> + }
> +
>   pinned++;
> - rsvd = is_invalid_reserved_pfn(*pfn_base);
> 
>   /*
>* Reserved pages aren't counted against the user, externally pinned
>* pages are already counted against the user.
>*/
> - if (!rsvd && !vfio_find_vpfn(dma, iova)) {
> + if (!vfio_find_vpfn(dma, iova)) {
>   if (!lock_cap && current->mm->locked_vm + 1 > limit) {
>   put_pfn(*pfn_base, dma->prot);
>   pr_warn("%s: RLIMIT_MEMLOCK (%ld) exceeded\n", __func__,
> @@ -437,13 +445,12 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 

Re: [PATCH] i2c-stm32f4: remove redundant initialization of pointer reg

[Alexandre Torgue]

Hi,

On 02/26/2018 09:06 PM, Wolfram Sang wrote:

On Tue, Jan 16, 2018 at 05:44:04PM +, Colin King wrote:

From: Colin Ian King 

The pointer reg is assigned a value that is never read, it is later
overwritten with a new value, hence the redundant initialization can
be removed.

Cleans up clang warning:
drivers/i2c/busses/i2c-stm32f4.c:352:16: warning: Value stored to 'reg'
during its initialization is never read

Signed-off-by: Colin Ian King 


Maxime? Alexandre? Are you OK with this patch?


Sorry for delay.

Acked-by: Alexandre TORGUE 

regards
alex




---
  drivers/i2c/busses/i2c-stm32f4.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
index 47c8d00de53f..ba600d77a3f8 100644
--- a/drivers/i2c/busses/i2c-stm32f4.c
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -349,7 +349,7 @@ static void stm32f4_i2c_read_msg(struct stm32f4_i2c_dev 
*i2c_dev)
  static void stm32f4_i2c_terminate_xfer(struct stm32f4_i2c_dev *i2c_dev)
  {
struct stm32f4_i2c_msg *msg = _dev->msg;
-   void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+   void __iomem *reg;
  
  	stm32f4_i2c_disable_irq(i2c_dev);
  
--

2.15.1

Re: [PATCH] i2c-stm32f4: remove redundant initialization of pointer reg

[Alexandre Torgue]

Hi,

On 02/26/2018 09:06 PM, Wolfram Sang wrote:

On Tue, Jan 16, 2018 at 05:44:04PM +, Colin King wrote:

From: Colin Ian King 

The pointer reg is assigned a value that is never read, it is later
overwritten with a new value, hence the redundant initialization can
be removed.

Cleans up clang warning:
drivers/i2c/busses/i2c-stm32f4.c:352:16: warning: Value stored to 'reg'
during its initialization is never read

Signed-off-by: Colin Ian King 


Maxime? Alexandre? Are you OK with this patch?


Sorry for delay.

Acked-by: Alexandre TORGUE 

regards
alex




---
  drivers/i2c/busses/i2c-stm32f4.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
index 47c8d00de53f..ba600d77a3f8 100644
--- a/drivers/i2c/busses/i2c-stm32f4.c
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -349,7 +349,7 @@ static void stm32f4_i2c_read_msg(struct stm32f4_i2c_dev 
*i2c_dev)
  static void stm32f4_i2c_terminate_xfer(struct stm32f4_i2c_dev *i2c_dev)
  {
struct stm32f4_i2c_msg *msg = _dev->msg;
-   void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+   void __iomem *reg;
  
  	stm32f4_i2c_disable_irq(i2c_dev);
  
--

2.15.1

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

[Mathieu Malaterre]

On Tue, Feb 27, 2018 at 8:33 AM, Christophe LEROY
 wrote:
>
>
> Le 27/02/2018 à 08:25, Mathieu Malaterre a écrit :
>>
>> On Mon, Feb 26, 2018 at 3:45 PM, Andy Shevchenko
>>  wrote:
>>>
>>> On Mon, Feb 26, 2018 at 4:44 PM, Andy Shevchenko
>>>  wrote:

 On Sun, Feb 25, 2018 at 7:22 PM, Mathieu Malaterre 
 wrote:
>>>
>>>
>   static void __init check_cpu_feature_properties(unsigned long node)
>   {
> -   unsigned long i;
>  struct feature_property *fp = feature_properties;
>  const __be32 *prop;
>

 Much simpler is just add

 if (ARRAY_SIZE() == 0)
   return;

> -   for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
> +   for (; fp != feature_properties +
> ARRAY_SIZE(feature_properties); ++fp) {
>>>
>>>
>>> ...or convert to while(), which will be more readable.
>>
>>
>> So you'd prefer something like:
>>
>> while (fp < feature_properties + ARRAY_SIZE(feature_properties)) {
>>...
>>++fp;
>> }
>>
>> right ?
>>
>
>
> Why not do as suggested by Segher, ie just replace < by != in the original
> form ?

I can do that.

> Or add in front:
> if (!ARRAY_SIZE(feature_properties))
> return;

(not tested) I believe the compiler still go over the for() loop and
will complain about the original unsigned comparison.

> Christophe

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

[Mathieu Malaterre]

On Tue, Feb 27, 2018 at 8:33 AM, Christophe LEROY
 wrote:
>
>
> Le 27/02/2018 à 08:25, Mathieu Malaterre a écrit :
>>
>> On Mon, Feb 26, 2018 at 3:45 PM, Andy Shevchenko
>>  wrote:
>>>
>>> On Mon, Feb 26, 2018 at 4:44 PM, Andy Shevchenko
>>>  wrote:

 On Sun, Feb 25, 2018 at 7:22 PM, Mathieu Malaterre 
 wrote:
>>>
>>>
>   static void __init check_cpu_feature_properties(unsigned long node)
>   {
> -   unsigned long i;
>  struct feature_property *fp = feature_properties;
>  const __be32 *prop;
>

 Much simpler is just add

 if (ARRAY_SIZE() == 0)
   return;

> -   for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
> +   for (; fp != feature_properties +
> ARRAY_SIZE(feature_properties); ++fp) {
>>>
>>>
>>> ...or convert to while(), which will be more readable.
>>
>>
>> So you'd prefer something like:
>>
>> while (fp < feature_properties + ARRAY_SIZE(feature_properties)) {
>>...
>>++fp;
>> }
>>
>> right ?
>>
>
>
> Why not do as suggested by Segher, ie just replace < by != in the original
> form ?

I can do that.

> Or add in front:
> if (!ARRAY_SIZE(feature_properties))
> return;

(not tested) I believe the compiler still go over the for() loop and
will complain about the original unsigned comparison.

> Christophe

Re: [LKP] [lkp-robot] [iversion] c0cef30e4f: aim7.jobs-per-min -18.0% regression

[kemi]

On 2018年02月26日 20:33, Jeff Layton wrote:
> On Mon, 2018-02-26 at 06:43 -0500, Jeff Layton wrote:
>> On Mon, 2018-02-26 at 16:38 +0800, Ye Xiaolong wrote:
>>> On 02/25, Jeff Layton wrote:
 On Sun, 2018-02-25 at 23:05 +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -18.0% regression of aim7.jobs-per-min due to commit:
>
>
> commit: c0cef30e4ff0dc025f4a1660b8f0ba43ed58426e ("iversion: make 
> inode_cmp_iversion{+raw} return bool instead of s64")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: aim7
> on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz 
> with 384G memory
> with following parameters:
>
>   disk: 4BRD_12G
>   md: RAID0
>   fs: xfs
>   test: disk_src
>   load: 3000
>   cpufreq_governor: performance
>
> test-description: AIM7 is a traditional UNIX system level benchmark suite 
> which is used to test and measure the performance of multiuser system.
> test-url: https://sourceforge.net/projects/aimbench/files/aim-suite7/
>
>

 I'm a bit suspicious of this result.

 This patch only changes inode_cmp_iversion{+raw} (since renamed to
 inode_eq_iversion{+raw}), and that neither should ever be called from
 xfs. The patch is fairly trivial too, and I wouldn't expect a big
 performance hit.
>>>
>>> I tried to queue 4 more times test for both commit c0cef30e4f and its 
>>> parent,
>>> the result seems quite stable.
>>>
>>> c0cef30e4ff0dc025f4a1660b8f0ba43ed58426e:
>>>  "aim7.jobs-per-min": [
>>> 32964.01,
>>> 32938.68,
>>> 33068.18,
>>> 32886.32,
>>> 32843.72,
>>> 32798.83,
>>> 32898.34,
>>> 32952.55
>>>   ],
>>>
>>> 3da90b159b146672f830bcd2489dd3a1f4e9e089:
>>>   "aim7.jobs-per-min": [
>>> 40239.65,
>>> 40163.33,
>>> 40353.32,
>>> 39976.9,
>>> 40185.75,
>>> 40411.3,
>>> 40213.58,
>>> 39900.69
>>>   ],
>>>
>>> Any other test data you may need?
>>>

 Is IMA involved here at all? I didn't see any evidence of it, but the
 kernel config did have it enabled.

>>>
>>> Sorry, not quite familiar with IMA, could you tell more about how to check 
>>> it?
>>>
>>
>> Thanks for retesting it, but I'm at a loss for why we're seeing this:
>>
>> IMA is the the integrity management subsystem. It will use the iversion
>> field to determine whether to remeasure files during remeasurement.  It
>> looks like the kernel config has it enabled, but it doesn't look like
>> it's in use, based on the info in the initial report.
>>
>> This patch only affects two inlined functions inode_cmp_iversion and
>> inode_cmp_iversion_raw. The patch is pretty trivial (as Linus points
>> out). These functions are only called from IMA and fs-specific code
>> (usually in readdir implementations to detect directory changes).
>>
>> XFS does not call either of these functions however, so I'm a little
>> unclear on how this patch could slow anything down on this test. The
>> only thing I can think to do here would be to profile this and see what
>> stands out.
>>
>> Note that we do need to keep this in perspective too. This 18%
>> regression on this test follows around a ~230% improvement that occurred
>> when we merged the bulk of these patches. It's should still be quite a
>> bit faster than the v4.15 in this regard.
>>
>> Still, it'd be good to understand what's going on here.
>>
>>
> 
> Could we see the dmesg from this boot? It'd be good to confirm that IMA
> is not involved here, as that's the only place that I can see that would
> call into this code at all here.
> 

See attachment for info on dmesg/perf-profile/compare_result.
Feel free to let Xiaolong or me know if anything else you would like to check.

> Thanks,
> Jeff
> 
> 
>>> Thanks,
>>> Xiaolong

>
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
>
> =
> compiler/cpufreq_governor/disk/fs/kconfig/load/md/rootfs/tbox_group/test/testcase:
>   
> gcc-7/performance/4BRD_12G/xfs/x86_64-rhel-7.2/3000/RAID0/debian-x86_64-2016-08-31.cgz/lkp-ivb-ep01/disk_src/aim7
>
> commit: 
>   3da90b159b (" f2fs-for-4.16-rc1")
>   c0cef30e4f ("iversion: make inode_cmp_iversion{+raw} return bool 
> instead of s64")
>
> 3da90b159b146672 c0cef30e4ff0dc025f4a1660b8 
>  -- 
>  %stddev %change %stddev
>  \  |\  
>  40183   -18.0%  32964  

Re: [LKP] [lkp-robot] [iversion] c0cef30e4f: aim7.jobs-per-min -18.0% regression

[kemi]

On 2018年02月26日 20:33, Jeff Layton wrote:
> On Mon, 2018-02-26 at 06:43 -0500, Jeff Layton wrote:
>> On Mon, 2018-02-26 at 16:38 +0800, Ye Xiaolong wrote:
>>> On 02/25, Jeff Layton wrote:
 On Sun, 2018-02-25 at 23:05 +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -18.0% regression of aim7.jobs-per-min due to commit:
>
>
> commit: c0cef30e4ff0dc025f4a1660b8f0ba43ed58426e ("iversion: make 
> inode_cmp_iversion{+raw} return bool instead of s64")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: aim7
> on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz 
> with 384G memory
> with following parameters:
>
>   disk: 4BRD_12G
>   md: RAID0
>   fs: xfs
>   test: disk_src
>   load: 3000
>   cpufreq_governor: performance
>
> test-description: AIM7 is a traditional UNIX system level benchmark suite 
> which is used to test and measure the performance of multiuser system.
> test-url: https://sourceforge.net/projects/aimbench/files/aim-suite7/
>
>

 I'm a bit suspicious of this result.

 This patch only changes inode_cmp_iversion{+raw} (since renamed to
 inode_eq_iversion{+raw}), and that neither should ever be called from
 xfs. The patch is fairly trivial too, and I wouldn't expect a big
 performance hit.
>>>
>>> I tried to queue 4 more times test for both commit c0cef30e4f and its 
>>> parent,
>>> the result seems quite stable.
>>>
>>> c0cef30e4ff0dc025f4a1660b8f0ba43ed58426e:
>>>  "aim7.jobs-per-min": [
>>> 32964.01,
>>> 32938.68,
>>> 33068.18,
>>> 32886.32,
>>> 32843.72,
>>> 32798.83,
>>> 32898.34,
>>> 32952.55
>>>   ],
>>>
>>> 3da90b159b146672f830bcd2489dd3a1f4e9e089:
>>>   "aim7.jobs-per-min": [
>>> 40239.65,
>>> 40163.33,
>>> 40353.32,
>>> 39976.9,
>>> 40185.75,
>>> 40411.3,
>>> 40213.58,
>>> 39900.69
>>>   ],
>>>
>>> Any other test data you may need?
>>>

 Is IMA involved here at all? I didn't see any evidence of it, but the
 kernel config did have it enabled.

>>>
>>> Sorry, not quite familiar with IMA, could you tell more about how to check 
>>> it?
>>>
>>
>> Thanks for retesting it, but I'm at a loss for why we're seeing this:
>>
>> IMA is the the integrity management subsystem. It will use the iversion
>> field to determine whether to remeasure files during remeasurement.  It
>> looks like the kernel config has it enabled, but it doesn't look like
>> it's in use, based on the info in the initial report.
>>
>> This patch only affects two inlined functions inode_cmp_iversion and
>> inode_cmp_iversion_raw. The patch is pretty trivial (as Linus points
>> out). These functions are only called from IMA and fs-specific code
>> (usually in readdir implementations to detect directory changes).
>>
>> XFS does not call either of these functions however, so I'm a little
>> unclear on how this patch could slow anything down on this test. The
>> only thing I can think to do here would be to profile this and see what
>> stands out.
>>
>> Note that we do need to keep this in perspective too. This 18%
>> regression on this test follows around a ~230% improvement that occurred
>> when we merged the bulk of these patches. It's should still be quite a
>> bit faster than the v4.15 in this regard.
>>
>> Still, it'd be good to understand what's going on here.
>>
>>
> 
> Could we see the dmesg from this boot? It'd be good to confirm that IMA
> is not involved here, as that's the only place that I can see that would
> call into this code at all here.
> 

See attachment for info on dmesg/perf-profile/compare_result.
Feel free to let Xiaolong or me know if anything else you would like to check.

> Thanks,
> Jeff
> 
> 
>>> Thanks,
>>> Xiaolong

>
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
>
> =
> compiler/cpufreq_governor/disk/fs/kconfig/load/md/rootfs/tbox_group/test/testcase:
>   
> gcc-7/performance/4BRD_12G/xfs/x86_64-rhel-7.2/3000/RAID0/debian-x86_64-2016-08-31.cgz/lkp-ivb-ep01/disk_src/aim7
>
> commit: 
>   3da90b159b (" f2fs-for-4.16-rc1")
>   c0cef30e4f ("iversion: make inode_cmp_iversion{+raw} return bool 
> instead of s64")
>
> 3da90b159b146672 c0cef30e4ff0dc025f4a1660b8 
>  -- 
>  %stddev %change %stddev
>  \  |\  
>  40183   -18.0%  32964  

Re: [v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains

[Juergen Gross]

On 26/02/18 17:01, Pavel Tatashin wrote:
> Juergen Gross noticed that commit
> f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap")
> broke XEN PV domains when deferred struct page initialization is enabled.
> 
> This is because the xen's PagePinned() flag is getting erased from struct
> pages when they are initialized later in boot.
> 
> Juergen fixed this problem by disabling deferred pages on xen pv domains.
> It is desirable, however, to have this feature available as it reduces boot
> time. This fix re-enables the feature for pv-dmains, and fixes the problem
> the following way:
> 
> The fix is to delay setting PagePinned flag until struct pages for all
> allocated memory are initialized, i.e. until after free_all_bootmem().
> 
> A new x86_init.hyper op init_after_bootmem() is called to let xen know
> that boot allocator is done, and hence struct pages for all the allocated
> memory are now initialized. If deferred page initialization is enabled, the
> rest of struct pages are going to be initialized later in boot once
> page_alloc_init_late() is called.
> 
> xen_after_bootmem() walks page table's pages and marks them pinned.
> 
> Signed-off-by: Pavel Tatashin 

Verified to work on a system where the original issue caused a crash.

Reviewed-by: Juergen Gross 
Tested-by: Juergen Gross 


Juergen

Re: [v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains

[Juergen Gross]

On 26/02/18 17:01, Pavel Tatashin wrote:
> Juergen Gross noticed that commit
> f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap")
> broke XEN PV domains when deferred struct page initialization is enabled.
> 
> This is because the xen's PagePinned() flag is getting erased from struct
> pages when they are initialized later in boot.
> 
> Juergen fixed this problem by disabling deferred pages on xen pv domains.
> It is desirable, however, to have this feature available as it reduces boot
> time. This fix re-enables the feature for pv-dmains, and fixes the problem
> the following way:
> 
> The fix is to delay setting PagePinned flag until struct pages for all
> allocated memory are initialized, i.e. until after free_all_bootmem().
> 
> A new x86_init.hyper op init_after_bootmem() is called to let xen know
> that boot allocator is done, and hence struct pages for all the allocated
> memory are now initialized. If deferred page initialization is enabled, the
> rest of struct pages are going to be initialized later in boot once
> page_alloc_init_late() is called.
> 
> xen_after_bootmem() walks page table's pages and marks them pinned.
> 
> Signed-off-by: Pavel Tatashin 

Verified to work on a system where the original issue caused a crash.

Reviewed-by: Juergen Gross 
Tested-by: Juergen Gross 


Juergen

Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

[H. Nikolaus Schaller]

Hi Johan,

> Am 27.02.2018 um 08:04 schrieb Johan Hovold :
> 
> On Mon, Feb 12, 2018 at 04:26:18PM +0100, Pavel Machek wrote:
>> Hi!
>> 
 Let's restart this discussion and focus on the main roadblock (others
 are minor details which can be sorted out later).
 
 If it feels like a hack, the key issue seems to me to be the choice of
 the API to present the GPS data to user space. Right?
>>> 
>>> Or even more fundamentally, does this belong in the kernel at all?
>> 
>> Yes, it does.

Thanks, Pavel for supporting our view.

> 
> But not necessarily in its current form.

Is this a "yes after some code fixes"?

Pavel mentioned an example where such an evolutionary approach was taken.

> 
>>> Now, if we'd ever have a proper GPS framework that handled everything in
>>> kernel space (i.e. no more gpsd) then we would be able to write kernel
>>> drivers that also take care of PM. But perhaps that's unlikely to ever
>>> be realised given the state of things (proprietary protocols, numerous
>>> quirky implementations, etc).
>> 
>> That is what needs to happen.
>> 
>>> The kernel is probably not the place to be working around issues like
>>> that, even if serdev at least allows for such hacks to be fairly
>>> isolated in drivers (unlike some of the earlier proposals touching core
>>> code).
>> 
>> Oh, kernel is indeed right place to provide hardware abstraction --
>> and that includes bug workarounds.
> 
> Right, at least when such hacks can be confined to a driver and not be
> spread all over the place.

It seems that you forgot that the driver we propose is not spread all over
the place. It *is* confined to a single driver thanks to the serdev api.

BR and thanks,
Nikolaus

Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

[H. Nikolaus Schaller]

Hi Johan,

> Am 27.02.2018 um 08:04 schrieb Johan Hovold :
> 
> On Mon, Feb 12, 2018 at 04:26:18PM +0100, Pavel Machek wrote:
>> Hi!
>> 
 Let's restart this discussion and focus on the main roadblock (others
 are minor details which can be sorted out later).
 
 If it feels like a hack, the key issue seems to me to be the choice of
 the API to present the GPS data to user space. Right?
>>> 
>>> Or even more fundamentally, does this belong in the kernel at all?
>> 
>> Yes, it does.

Thanks, Pavel for supporting our view.

> 
> But not necessarily in its current form.

Is this a "yes after some code fixes"?

Pavel mentioned an example where such an evolutionary approach was taken.

> 
>>> Now, if we'd ever have a proper GPS framework that handled everything in
>>> kernel space (i.e. no more gpsd) then we would be able to write kernel
>>> drivers that also take care of PM. But perhaps that's unlikely to ever
>>> be realised given the state of things (proprietary protocols, numerous
>>> quirky implementations, etc).
>> 
>> That is what needs to happen.
>> 
>>> The kernel is probably not the place to be working around issues like
>>> that, even if serdev at least allows for such hacks to be fairly
>>> isolated in drivers (unlike some of the earlier proposals touching core
>>> code).
>> 
>> Oh, kernel is indeed right place to provide hardware abstraction --
>> and that includes bug workarounds.
> 
> Right, at least when such hacks can be confined to a driver and not be
> spread all over the place.

It seems that you forgot that the driver we propose is not spread all over
the place. It *is* confined to a single driver thanks to the serdev api.

BR and thanks,
Nikolaus

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

[Christophe LEROY]

Le 27/02/2018 à 08:25, Mathieu Malaterre a écrit :

On Mon, Feb 26, 2018 at 3:45 PM, Andy Shevchenko
 wrote:

On Mon, Feb 26, 2018 at 4:44 PM, Andy Shevchenko
 wrote:

On Sun, Feb 25, 2018 at 7:22 PM, Mathieu Malaterre  wrote:



  static void __init check_cpu_feature_properties(unsigned long node)
  {
-   unsigned long i;
 struct feature_property *fp = feature_properties;
 const __be32 *prop;



Much simpler is just add

if (ARRAY_SIZE() == 0)
  return;


-   for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
+   for (; fp != feature_properties + ARRAY_SIZE(feature_properties); ++fp) 
{


...or convert to while(), which will be more readable.


So you'd prefer something like:

while (fp < feature_properties + ARRAY_SIZE(feature_properties)) {
   ...
   ++fp;
}

right ?




Why not do as suggested by Segher, ie just replace < by != in the 
original form ?

Or add in front:
if (!ARRAY_SIZE(feature_properties))
return;

Christophe

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

[Christophe LEROY]

Le 27/02/2018 à 08:25, Mathieu Malaterre a écrit :

On Mon, Feb 26, 2018 at 3:45 PM, Andy Shevchenko
 wrote:

On Mon, Feb 26, 2018 at 4:44 PM, Andy Shevchenko
 wrote:

On Sun, Feb 25, 2018 at 7:22 PM, Mathieu Malaterre  wrote:



  static void __init check_cpu_feature_properties(unsigned long node)
  {
-   unsigned long i;
 struct feature_property *fp = feature_properties;
 const __be32 *prop;



Much simpler is just add

if (ARRAY_SIZE() == 0)
  return;


-   for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
+   for (; fp != feature_properties + ARRAY_SIZE(feature_properties); ++fp) 
{


...or convert to while(), which will be more readable.


So you'd prefer something like:

while (fp < feature_properties + ARRAY_SIZE(feature_properties)) {
   ...
   ++fp;
}

right ?




Why not do as suggested by Segher, ie just replace < by != in the 
original form ?

Or add in front:
if (!ARRAY_SIZE(feature_properties))
return;

Christophe

Re: [PATCH v2] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.

[Hans Verkuil]

On 02/27/2018 02:53 AM, Quytelda Kahja wrote:
> Hans,
> 
> Thank you very much for your input on the patch; however this patch
> has already been applied to the staging tree.  Additionally:

I have no record of this being applied through linux-media. Did someone
else pick this up? Greg perhaps?

>> What coding style problem? You should give a short description of
>> what you are fixing.
> The subject of the patch (which becomes the subject of the email when
> using `git format-patch`) describes the change more fully: "Staging:
> bcm2048: Fix function argument alignment in radio-bcm2048.c".  It's a
> really trivial patch, so there's not too much to say.  That extra
> comment is just redundant, I suppose.

Usually you just show the warnings that gcc or sparse or whatever
produced.

> 
>> Just drop this change: it will replace one warning (non-aligned) with
>> another (> 80 cols).
> Breaking the 80 character line limit is arguably excusable for this
> code because of the 36 character function name and 30 character
> constant name; additionally, it has been said that the 80 character
> line limit will probably be increased in the future since we run
> modern machines that aren't limited to 80 character terminals anymore,
> so this warning may soon be irrelevant anyway.

I know people who would be very annoyed if the 80 char limit is lifted.

Anyway, in the end you look at whether a patch is worth it or not,
and this part isn't.

But if it is already applied by someone then this is all moot.

Regards,

Hans

> 
> Thank you,
> Quytelda Kahja
> 
> On Mon, Feb 26, 2018 at 5:51 AM, Hans Verkuil  wrote:
>> On 02/20/2018 07:53 AM, Quytelda Kahja wrote:
>>> Fix a coding style problem.
>>
>> What coding style problem? You should give a short description of
>> what you are fixing.
>>
>>>
>>> Signed-off-by: Quytelda Kahja 
>>> ---
>>> This is the patch without the unnecessary fixes for line length.
>>>
>>>  drivers/staging/media/bcm2048/radio-bcm2048.c | 22 +++---
>>>  1 file changed, 11 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
>>> b/drivers/staging/media/bcm2048/radio-bcm2048.c
>>> index 06d1920150da..f38a4f2acdde 100644
>>> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
>>> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
>>> @@ -1864,7 +1864,7 @@ static int bcm2048_probe(struct bcm2048_device *bdev)
>>>   goto unlock;
>>>
>>>   err = bcm2048_set_fm_search_rssi_threshold(bdev,
>>> - BCM2048_DEFAULT_RSSI_THRESHOLD);
>>> +
>>> BCM2048_DEFAULT_RSSI_THRESHOLD);
>>>   if (err < 0)
>>>   goto unlock;
>>>
>>
>> Just drop this change: it will replace one warning (non-aligned) with
>> another (> 80 cols).
>>
>> This code is fine as it is.
>>
>> Regards,
>>
>> Hans
>>
>>> @@ -1942,9 +1942,9 @@ static irqreturn_t bcm2048_handler(int irq, void *dev)
>>>   */
>>>  #define property_write(prop, type, mask, check)
>>>   \
>>>  static ssize_t bcm2048_##prop##_write(struct device *dev,\
>>> - struct device_attribute *attr,  \
>>> - const char *buf,\
>>> - size_t count)   \
>>> +   struct device_attribute *attr,\
>>> +   const char *buf,  \
>>> +   size_t count) \
>>>  {\
>>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>>   type value; \
>>> @@ -1966,8 +1966,8 @@ static ssize_t bcm2048_##prop##_write(struct device 
>>> *dev,   \
>>>
>>>  #define property_read(prop, mask)\
>>>  static ssize_t bcm2048_##prop##_read(struct device *dev, \
>>> - struct device_attribute *attr,  \
>>> - char *buf)  \
>>> +  struct device_attribute *attr, \
>>> +  char *buf) \
>>>  {\
>>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>>   int value;  \
>>> @@ -1985,8 +1985,8 @@ static ssize_t bcm2048_##prop##_read(struct device 
>>> *dev,\
>>>
>>>  #define property_signed_read(prop, size, mask) 
>>>   \
>>>  static ssize_t bcm2048_##prop##_read(struct device *dev, \
>>> - 

Re: [PATCH v2] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.

[Hans Verkuil]

On 02/27/2018 02:53 AM, Quytelda Kahja wrote:
> Hans,
> 
> Thank you very much for your input on the patch; however this patch
> has already been applied to the staging tree.  Additionally:

I have no record of this being applied through linux-media. Did someone
else pick this up? Greg perhaps?

>> What coding style problem? You should give a short description of
>> what you are fixing.
> The subject of the patch (which becomes the subject of the email when
> using `git format-patch`) describes the change more fully: "Staging:
> bcm2048: Fix function argument alignment in radio-bcm2048.c".  It's a
> really trivial patch, so there's not too much to say.  That extra
> comment is just redundant, I suppose.

Usually you just show the warnings that gcc or sparse or whatever
produced.

> 
>> Just drop this change: it will replace one warning (non-aligned) with
>> another (> 80 cols).
> Breaking the 80 character line limit is arguably excusable for this
> code because of the 36 character function name and 30 character
> constant name; additionally, it has been said that the 80 character
> line limit will probably be increased in the future since we run
> modern machines that aren't limited to 80 character terminals anymore,
> so this warning may soon be irrelevant anyway.

I know people who would be very annoyed if the 80 char limit is lifted.

Anyway, in the end you look at whether a patch is worth it or not,
and this part isn't.

But if it is already applied by someone then this is all moot.

Regards,

Hans

> 
> Thank you,
> Quytelda Kahja
> 
> On Mon, Feb 26, 2018 at 5:51 AM, Hans Verkuil  wrote:
>> On 02/20/2018 07:53 AM, Quytelda Kahja wrote:
>>> Fix a coding style problem.
>>
>> What coding style problem? You should give a short description of
>> what you are fixing.
>>
>>>
>>> Signed-off-by: Quytelda Kahja 
>>> ---
>>> This is the patch without the unnecessary fixes for line length.
>>>
>>>  drivers/staging/media/bcm2048/radio-bcm2048.c | 22 +++---
>>>  1 file changed, 11 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
>>> b/drivers/staging/media/bcm2048/radio-bcm2048.c
>>> index 06d1920150da..f38a4f2acdde 100644
>>> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
>>> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
>>> @@ -1864,7 +1864,7 @@ static int bcm2048_probe(struct bcm2048_device *bdev)
>>>   goto unlock;
>>>
>>>   err = bcm2048_set_fm_search_rssi_threshold(bdev,
>>> - BCM2048_DEFAULT_RSSI_THRESHOLD);
>>> +
>>> BCM2048_DEFAULT_RSSI_THRESHOLD);
>>>   if (err < 0)
>>>   goto unlock;
>>>
>>
>> Just drop this change: it will replace one warning (non-aligned) with
>> another (> 80 cols).
>>
>> This code is fine as it is.
>>
>> Regards,
>>
>> Hans
>>
>>> @@ -1942,9 +1942,9 @@ static irqreturn_t bcm2048_handler(int irq, void *dev)
>>>   */
>>>  #define property_write(prop, type, mask, check)
>>>   \
>>>  static ssize_t bcm2048_##prop##_write(struct device *dev,\
>>> - struct device_attribute *attr,  \
>>> - const char *buf,\
>>> - size_t count)   \
>>> +   struct device_attribute *attr,\
>>> +   const char *buf,  \
>>> +   size_t count) \
>>>  {\
>>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>>   type value; \
>>> @@ -1966,8 +1966,8 @@ static ssize_t bcm2048_##prop##_write(struct device 
>>> *dev,   \
>>>
>>>  #define property_read(prop, mask)\
>>>  static ssize_t bcm2048_##prop##_read(struct device *dev, \
>>> - struct device_attribute *attr,  \
>>> - char *buf)  \
>>> +  struct device_attribute *attr, \
>>> +  char *buf) \
>>>  {\
>>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>>   int value;  \
>>> @@ -1985,8 +1985,8 @@ static ssize_t bcm2048_##prop##_read(struct device 
>>> *dev,\
>>>
>>>  #define property_signed_read(prop, size, mask) 
>>>   \
>>>  static ssize_t bcm2048_##prop##_read(struct device *dev, \
>>> - struct device_attribute *attr,  \
>>> -

[PATCH v3] crypto: add zBeWalgo compression for zram

[Benjamin Warnke]

Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM
compresses each page individually. As a result the compression algorithm is
forced to use a very small sliding window. None of the available compression
algorithms is designed to achieve high compression ratios with small inputs.

This patch adds a new compression algorithm 'zBeWalgo' to the crypto api. This
algorithm focusses on increasing the capacity of the compressed block-device
created by ZRAM. The choice of compression algorithms is always a tradeoff
between speed and compression ratio.

If faster algorithms like 'lz4' are chosen the compression ratio is often
lower than the ratio of zBeWalgo as shown in the following benchmarks. Due to
the lower compression ratio, ZRAM needs to fall back to backing_devices
earlier. If backing_devices are required, the effective speed of ZRAM is a
weighted average of de/compression time and writing/reading from the
backing_device. This should be considered when comparing the speeds in the
benchmarks.

There are different kinds of backing_devices, each with its own drawbacks.
1. HDDs: This kind of backing device is very slow. If the compression ratio 
of an algorithm is much lower than the ratio of zBeWalgo, it might be faster
to use zBewalgo instead.
2. SSDs: I tested a swap partition on my NVME-SSD. The speed is even higher
than zram with lz4, but after about 5 Minutes the SSD is blocking all
read/write requests due to overheating. This is definitly not an option.



zBeWalgo is a completely new algorithm - Currently it is not published
somewhere else right now, googleing it would not show up any results. The
following section describes how the algorithm works.

zBeWalgo itself is a container compression algorithm, which can execute
multiple different compression and transformation algorithms after each other.
The execution of different compression algorithms after each other will be
called 'combination' in this description and in the code. Additionally to be
able to execute combinations of algorithms, zBeWalgo can try different
combinations on the same input. This allows high compression ratios on
completely different datasets, which would otherwise require its own
algorithm each. Executing all known combinations on each input page would be
very slow. Therefore the data is compressed at first with that combination,
which was already successful on the last input page. If the compressed data
size of the current page is similar to that of the last page, the compressed
data is returned immediately without even trying the other combinations. Even
if there is no guarantee that consecutive calls to the algorithm belong to
each other, the speed improvement is obvious.

ZRAM uses zsmalloc for the management of the compressed pages. The largest
size-class in zsmalloc is 3264 Bytes. If the compressed data is larger than
that threshold, ZRAM ignores the compression and writes the uncompressed page
instead. As a consequence it is useless to continue compression, if the
algorithm detects, that the data can not be compressed using the current
combination. The threshold for aborting compression can be changed via sysfs at
any time, even if the algorithm is currently in use. If a combination fails to
compress the data, zBeWalgo tries the next combination. If no combination is
able to reduce the data in size, zBeWalgo returns a negative value.

Each combination consists of up to 7 compression and transformation steps.
Combinations can be added and removed at any time via sysfs. Already compressed
Data can always be decompressed, even if the combination used to produce it
does not exist anymore. Technically the user could add up to 256 combinations
concurrently, but that would be very time consuming if the data can not be
compressed.

To be able to build combinations and call different algorithms, all those
algorithms are implementing the same interface. This enables the user to
specify additional combinations while ZRAM is running.

Within the combinations many different algorithms can be used. Some of those
algorithms are published. This patch adds the following algorithms to be used
within the combinations:
- bwt: The Burrows-Wheeler-Transformation was published by 'M. Burrows' and
  'D. J. Wheeler' in 1994. This implementation uses counting sort for
  sorting the data. Their original paper is online available at:
  http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-124.pdf
- mtf: The Move-To-Front algorithm as described by 'M. Burrows' and
  'D. J. Wheeler' in the same paper as bwt.
- jbe: j-bit-encoding as proposed by 'I Made Agus Dwi Suarjaya' in 2012.
  https://arxiv.org/pdf/1209.1045.pdf
- jbe2: A minor modification of jbe. Swapping groups of 4 Bit in consecutive
  Bytes can increase the compression ratio, if for example the first
  4 Bits of each Byte are zero. If jbe2 is called after mtf, this
  happens ofthen.
- rle: Run Length Encoding
- huffman: Huffman encoding
- 

[PATCH v3] crypto: add zBeWalgo compression for zram

[Benjamin Warnke]

Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM
compresses each page individually. As a result the compression algorithm is
forced to use a very small sliding window. None of the available compression
algorithms is designed to achieve high compression ratios with small inputs.

This patch adds a new compression algorithm 'zBeWalgo' to the crypto api. This
algorithm focusses on increasing the capacity of the compressed block-device
created by ZRAM. The choice of compression algorithms is always a tradeoff
between speed and compression ratio.

If faster algorithms like 'lz4' are chosen the compression ratio is often
lower than the ratio of zBeWalgo as shown in the following benchmarks. Due to
the lower compression ratio, ZRAM needs to fall back to backing_devices
earlier. If backing_devices are required, the effective speed of ZRAM is a
weighted average of de/compression time and writing/reading from the
backing_device. This should be considered when comparing the speeds in the
benchmarks.

There are different kinds of backing_devices, each with its own drawbacks.
1. HDDs: This kind of backing device is very slow. If the compression ratio 
of an algorithm is much lower than the ratio of zBeWalgo, it might be faster
to use zBewalgo instead.
2. SSDs: I tested a swap partition on my NVME-SSD. The speed is even higher
than zram with lz4, but after about 5 Minutes the SSD is blocking all
read/write requests due to overheating. This is definitly not an option.



zBeWalgo is a completely new algorithm - Currently it is not published
somewhere else right now, googleing it would not show up any results. The
following section describes how the algorithm works.

zBeWalgo itself is a container compression algorithm, which can execute
multiple different compression and transformation algorithms after each other.
The execution of different compression algorithms after each other will be
called 'combination' in this description and in the code. Additionally to be
able to execute combinations of algorithms, zBeWalgo can try different
combinations on the same input. This allows high compression ratios on
completely different datasets, which would otherwise require its own
algorithm each. Executing all known combinations on each input page would be
very slow. Therefore the data is compressed at first with that combination,
which was already successful on the last input page. If the compressed data
size of the current page is similar to that of the last page, the compressed
data is returned immediately without even trying the other combinations. Even
if there is no guarantee that consecutive calls to the algorithm belong to
each other, the speed improvement is obvious.

ZRAM uses zsmalloc for the management of the compressed pages. The largest
size-class in zsmalloc is 3264 Bytes. If the compressed data is larger than
that threshold, ZRAM ignores the compression and writes the uncompressed page
instead. As a consequence it is useless to continue compression, if the
algorithm detects, that the data can not be compressed using the current
combination. The threshold for aborting compression can be changed via sysfs at
any time, even if the algorithm is currently in use. If a combination fails to
compress the data, zBeWalgo tries the next combination. If no combination is
able to reduce the data in size, zBeWalgo returns a negative value.

Each combination consists of up to 7 compression and transformation steps.
Combinations can be added and removed at any time via sysfs. Already compressed
Data can always be decompressed, even if the combination used to produce it
does not exist anymore. Technically the user could add up to 256 combinations
concurrently, but that would be very time consuming if the data can not be
compressed.

To be able to build combinations and call different algorithms, all those
algorithms are implementing the same interface. This enables the user to
specify additional combinations while ZRAM is running.

Within the combinations many different algorithms can be used. Some of those
algorithms are published. This patch adds the following algorithms to be used
within the combinations:
- bwt: The Burrows-Wheeler-Transformation was published by 'M. Burrows' and
  'D. J. Wheeler' in 1994. This implementation uses counting sort for
  sorting the data. Their original paper is online available at:
  http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-124.pdf
- mtf: The Move-To-Front algorithm as described by 'M. Burrows' and
  'D. J. Wheeler' in the same paper as bwt.
- jbe: j-bit-encoding as proposed by 'I Made Agus Dwi Suarjaya' in 2012.
  https://arxiv.org/pdf/1209.1045.pdf
- jbe2: A minor modification of jbe. Swapping groups of 4 Bit in consecutive
  Bytes can increase the compression ratio, if for example the first
  4 Bits of each Byte are zero. If jbe2 is called after mtf, this
  happens ofthen.
- rle: Run Length Encoding
- huffman: Huffman encoding
- 

Re: [RFC REBASED 4/5] powerpc/mm/slice: Use const pointers to cached slice masks where possible

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> The slice_mask cache was a basic conversion which copied the slice
> mask into caller's structures, because that's how the original code
> worked. In most cases the pointer can be used directly instead, saving
> a copy and an on-stack structure.
>
> This also converts the slice_mask bit operation helpers to be the usual
> 3-operand kind, which is clearer to work with. And we remove some
> unnecessary intermediate bitmaps, reducing stack and copy overhead
> further.

Can we move the reduce unncessary intermediate bitmaps as another patch?

>
> Signed-off-by: Nicholas Piggin 
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/include/asm/book3s/64/slice.h |  7 +++
>  arch/powerpc/include/asm/nohash/32/slice.h |  6 +++
>  arch/powerpc/mm/slice.c| 77 
> ++
>  3 files changed, 59 insertions(+), 31 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/slice.h 
> b/arch/powerpc/include/asm/book3s/64/slice.h
> index f9a2c8bd7a77..be1ce8e91ad1 100644
> --- a/arch/powerpc/include/asm/book3s/64/slice.h
> +++ b/arch/powerpc/include/asm/book3s/64/slice.h
> @@ -63,6 +63,13 @@ static inline void slice_bitmap_set(unsigned long *map, 
> unsigned int start,
>  {
>   bitmap_set(map, start, nbits);
>  }
> +
> +static inline void slice_bitmap_copy(unsigned long *dst,
> +  const unsigned long *src,
> +  unsigned int nbits)
> +{
> + bitmap_copy(dst, src, nbits);
> +}
>  #endif /* __ASSEMBLY__ */
>  
>  #else /* CONFIG_PPC_MM_SLICES */
> diff --git a/arch/powerpc/include/asm/nohash/32/slice.h 
> b/arch/powerpc/include/asm/nohash/32/slice.h
> index bcb4924f7d22..38f041e01a0a 100644
> --- a/arch/powerpc/include/asm/nohash/32/slice.h
> +++ b/arch/powerpc/include/asm/nohash/32/slice.h
> @@ -58,6 +58,12 @@ static inline void slice_bitmap_set(unsigned long *map, 
> unsigned int start,
>   unsigned int nbits)
>  {
>  }
> +
> +static inline void slice_bitmap_copy(unsigned long *dst,
> +  const unsigned long *src,
> +  unsigned int nbits)
> +{
> +}
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* CONFIG_PPC_MM_SLICES */
> diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
> index 311168ca3939..b8b691369c29 100644
> --- a/arch/powerpc/mm/slice.c
> +++ b/arch/powerpc/mm/slice.c
> @@ -468,21 +468,30 @@ static unsigned long slice_find_area(struct mm_struct 
> *mm, unsigned long len,
>   return slice_find_area_bottomup(mm, len, mask, psize, 
> high_limit);
>  }
>  
> -static inline void slice_or_mask(struct slice_mask *dst,
> +static inline void slice_copy_mask(struct slice_mask *dst,
>   const struct slice_mask *src)
>  {
> - dst->low_slices |= src->low_slices;
> - slice_bitmap_or(dst->high_slices, dst->high_slices, src->high_slices,
> + dst->low_slices = src->low_slices;
> + slice_bitmap_copy(dst->high_slices, src->high_slices, SLICE_NUM_HIGH);
> +}
> +
> +static inline void slice_or_mask(struct slice_mask *dst,
> +  const struct slice_mask *src1,
> +  const struct slice_mask *src2)
> +{
> + dst->low_slices = src1->low_slices | src2->low_slices;
> + slice_bitmap_or(dst->high_slices, src1->high_slices, src2->high_slices,
>   SLICE_NUM_HIGH);
>  }
>  
>  static inline void slice_andnot_mask(struct slice_mask *dst,
> - const struct slice_mask *src)
> +  const struct slice_mask *src1,
> +  const struct slice_mask *src2)
>  {
> - dst->low_slices &= ~src->low_slices;
> + dst->low_slices = src1->low_slices & ~src2->low_slices;
>  
> - slice_bitmap_andnot(dst->high_slices, dst->high_slices,
> - src->high_slices, SLICE_NUM_HIGH);
> + slice_bitmap_andnot(dst->high_slices, src1->high_slices,
> + src2->high_slices, SLICE_NUM_HIGH);
>  }
>  
>  #ifdef CONFIG_PPC_64K_PAGES
> @@ -495,10 +504,10 @@ unsigned long slice_get_unmapped_area(unsigned long 
> addr, unsigned long len,
> unsigned long flags, unsigned int psize,
> int topdown)
>  {
> - struct slice_mask mask;
>   struct slice_mask good_mask;
>   struct slice_mask potential_mask;
> - struct slice_mask compat_mask;
> + const struct slice_mask *maskp;
> + const struct slice_mask *compat_maskp = NULL;
>   int fixed = (flags & MAP_FIXED);
>   int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT);
>   unsigned long page_size = 1UL << pshift;
> @@ -537,9 +546,6 @@ unsigned long slice_get_unmapped_area(unsigned long addr, 
> unsigned long len,
>   

Re: [RFC REBASED 4/5] powerpc/mm/slice: Use const pointers to cached slice masks where possible

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> The slice_mask cache was a basic conversion which copied the slice
> mask into caller's structures, because that's how the original code
> worked. In most cases the pointer can be used directly instead, saving
> a copy and an on-stack structure.
>
> This also converts the slice_mask bit operation helpers to be the usual
> 3-operand kind, which is clearer to work with. And we remove some
> unnecessary intermediate bitmaps, reducing stack and copy overhead
> further.

Can we move the reduce unncessary intermediate bitmaps as another patch?

>
> Signed-off-by: Nicholas Piggin 
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/include/asm/book3s/64/slice.h |  7 +++
>  arch/powerpc/include/asm/nohash/32/slice.h |  6 +++
>  arch/powerpc/mm/slice.c| 77 
> ++
>  3 files changed, 59 insertions(+), 31 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/slice.h 
> b/arch/powerpc/include/asm/book3s/64/slice.h
> index f9a2c8bd7a77..be1ce8e91ad1 100644
> --- a/arch/powerpc/include/asm/book3s/64/slice.h
> +++ b/arch/powerpc/include/asm/book3s/64/slice.h
> @@ -63,6 +63,13 @@ static inline void slice_bitmap_set(unsigned long *map, 
> unsigned int start,
>  {
>   bitmap_set(map, start, nbits);
>  }
> +
> +static inline void slice_bitmap_copy(unsigned long *dst,
> +  const unsigned long *src,
> +  unsigned int nbits)
> +{
> + bitmap_copy(dst, src, nbits);
> +}
>  #endif /* __ASSEMBLY__ */
>  
>  #else /* CONFIG_PPC_MM_SLICES */
> diff --git a/arch/powerpc/include/asm/nohash/32/slice.h 
> b/arch/powerpc/include/asm/nohash/32/slice.h
> index bcb4924f7d22..38f041e01a0a 100644
> --- a/arch/powerpc/include/asm/nohash/32/slice.h
> +++ b/arch/powerpc/include/asm/nohash/32/slice.h
> @@ -58,6 +58,12 @@ static inline void slice_bitmap_set(unsigned long *map, 
> unsigned int start,
>   unsigned int nbits)
>  {
>  }
> +
> +static inline void slice_bitmap_copy(unsigned long *dst,
> +  const unsigned long *src,
> +  unsigned int nbits)
> +{
> +}
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* CONFIG_PPC_MM_SLICES */
> diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
> index 311168ca3939..b8b691369c29 100644
> --- a/arch/powerpc/mm/slice.c
> +++ b/arch/powerpc/mm/slice.c
> @@ -468,21 +468,30 @@ static unsigned long slice_find_area(struct mm_struct 
> *mm, unsigned long len,
>   return slice_find_area_bottomup(mm, len, mask, psize, 
> high_limit);
>  }
>  
> -static inline void slice_or_mask(struct slice_mask *dst,
> +static inline void slice_copy_mask(struct slice_mask *dst,
>   const struct slice_mask *src)
>  {
> - dst->low_slices |= src->low_slices;
> - slice_bitmap_or(dst->high_slices, dst->high_slices, src->high_slices,
> + dst->low_slices = src->low_slices;
> + slice_bitmap_copy(dst->high_slices, src->high_slices, SLICE_NUM_HIGH);
> +}
> +
> +static inline void slice_or_mask(struct slice_mask *dst,
> +  const struct slice_mask *src1,
> +  const struct slice_mask *src2)
> +{
> + dst->low_slices = src1->low_slices | src2->low_slices;
> + slice_bitmap_or(dst->high_slices, src1->high_slices, src2->high_slices,
>   SLICE_NUM_HIGH);
>  }
>  
>  static inline void slice_andnot_mask(struct slice_mask *dst,
> - const struct slice_mask *src)
> +  const struct slice_mask *src1,
> +  const struct slice_mask *src2)
>  {
> - dst->low_slices &= ~src->low_slices;
> + dst->low_slices = src1->low_slices & ~src2->low_slices;
>  
> - slice_bitmap_andnot(dst->high_slices, dst->high_slices,
> - src->high_slices, SLICE_NUM_HIGH);
> + slice_bitmap_andnot(dst->high_slices, src1->high_slices,
> + src2->high_slices, SLICE_NUM_HIGH);
>  }
>  
>  #ifdef CONFIG_PPC_64K_PAGES
> @@ -495,10 +504,10 @@ unsigned long slice_get_unmapped_area(unsigned long 
> addr, unsigned long len,
> unsigned long flags, unsigned int psize,
> int topdown)
>  {
> - struct slice_mask mask;
>   struct slice_mask good_mask;
>   struct slice_mask potential_mask;
> - struct slice_mask compat_mask;
> + const struct slice_mask *maskp;
> + const struct slice_mask *compat_maskp = NULL;
>   int fixed = (flags & MAP_FIXED);
>   int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT);
>   unsigned long page_size = 1UL << pshift;
> @@ -537,9 +546,6 @@ unsigned long slice_get_unmapped_area(unsigned long addr, 
> unsigned long len,
>   potential_mask.low_slices = 0;
>   

Re: [PATCH 2/6] pci: Scan all functions when probing while running over Jailhouse

[Jan Kiszka]

On 2018-02-22 21:57, Bjorn Helgaas wrote:
> On Mon, Jan 22, 2018 at 07:12:46AM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka 
>>
>> PCI and PCIBIOS probing only scans devices at function number 0/8/16/...
>> Subdevices (e.g. multiqueue) have function numbers which are not a
>> multiple of 8.
> 
> Suggested text:
> 
>   Per PCIe r4.0, sec 7.5.1.1.9, multi-function devices are required to
>   have a function 0.  Therefore, Linux scans for devices at function 0
>   (devfn 0/8/16/...) and only scans for other functions if function 0
>   has its Multi-Function Device bit set or ARI or SR-IOV indicate
>   there are more functions.
>   
>   The Jailhouse hypervisor may pass individual functions of a
>   multi-function device to a guest without passing function 0, which
>   means a Linux guest won't find them.
> 
>   Change Linux PCI probing so it scans all function numbers when
>   running as a guest over Jailhouse.
>   
>   This is technically prohibited by the spec, so it is possible that
>   PCI devices without the Multi-Function Device bit set may have
>   unexpected behavior in response to this probe.
> 
>> The simple hypervisor Jailhouse passes subdevices directly w/o providing
>> a virtual PCI topology like KVM. As a consequence a PCI passthrough from
>> Jailhouse to a guest will not be detected by Linux.
>>
>> Based on patch by Benedikt Spranger, adding Jailhouse probing to avoid
>> changing the behavior in the absence of the hypervisor.
>>
>> CC: Benedikt Spranger 
>> Signed-off-by: Jan Kiszka 
> 
> With subject change to:
> 
>   PCI: Scan all functions when running over Jailhouse
> 
> Acked-by: Bjorn Helgaas 
> 

Thanks, all suggestions picked up for next round.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 2/6] pci: Scan all functions when probing while running over Jailhouse

[Jan Kiszka]

On 2018-02-22 21:57, Bjorn Helgaas wrote:
> On Mon, Jan 22, 2018 at 07:12:46AM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka 
>>
>> PCI and PCIBIOS probing only scans devices at function number 0/8/16/...
>> Subdevices (e.g. multiqueue) have function numbers which are not a
>> multiple of 8.
> 
> Suggested text:
> 
>   Per PCIe r4.0, sec 7.5.1.1.9, multi-function devices are required to
>   have a function 0.  Therefore, Linux scans for devices at function 0
>   (devfn 0/8/16/...) and only scans for other functions if function 0
>   has its Multi-Function Device bit set or ARI or SR-IOV indicate
>   there are more functions.
>   
>   The Jailhouse hypervisor may pass individual functions of a
>   multi-function device to a guest without passing function 0, which
>   means a Linux guest won't find them.
> 
>   Change Linux PCI probing so it scans all function numbers when
>   running as a guest over Jailhouse.
>   
>   This is technically prohibited by the spec, so it is possible that
>   PCI devices without the Multi-Function Device bit set may have
>   unexpected behavior in response to this probe.
> 
>> The simple hypervisor Jailhouse passes subdevices directly w/o providing
>> a virtual PCI topology like KVM. As a consequence a PCI passthrough from
>> Jailhouse to a guest will not be detected by Linux.
>>
>> Based on patch by Benedikt Spranger, adding Jailhouse probing to avoid
>> changing the behavior in the absence of the hypervisor.
>>
>> CC: Benedikt Spranger 
>> Signed-off-by: Jan Kiszka 
> 
> With subject change to:
> 
>   PCI: Scan all functions when running over Jailhouse
> 
> Acked-by: Bjorn Helgaas 
> 

Thanks, all suggestions picked up for next round.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

inconsistent lock state with usbnet/asix usb ethernet and xhci

[Marek Szyprowski]

Hi

I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No
special activity is needed to reproduce this issue, it happens almost
on every boot. ASIX USB ethernet is connected to XHCI USB host controller
on that board. Is it a known issue? Frankly I have no idea where to look
to fix it. The same adapter connected to EHCI ports on other boards based
on the same SoC works fine without any warnings.

Here are some more information from that board:
# lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 0b95:772b ASIX Electronics Corp. AX88772B
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 2232:1056 Silicon Motion
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=asix, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M
    |__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M


And the log with mentioned warning:

[   17.768040] 
[   17.772239] WARNING: inconsistent lock state
[   17.776511] 4.16.0-rc3-next-20180227-7-g876c53a7493c #453 Not tainted
[   17.783329] 
[   17.787580] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[   17.793607] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   17.798751]  (>seq#5){?.-.}, at: [<9b22e5f0>] 
asix_rx_fixup_internal+0x188/0x288

[   17.806790] {IN-HARDIRQ-W} state was registered at:
[   17.811677]   tx_complete+0x100/0x208
[   17.815319]   __usb_hcd_giveback_urb+0x60/0xf0
[   17.819770]   xhci_giveback_urb_in_irq+0xa8/0x240
[   17.824469]   xhci_td_cleanup+0xf4/0x16c
[   17.828367]   xhci_irq+0xe74/0x2240
[   17.831827]   usb_hcd_irq+0x24/0x38
[   17.835343]   __handle_irq_event_percpu+0x98/0x510
[   17.840111]   handle_irq_event_percpu+0x1c/0x58
[   17.844623]   handle_irq_event+0x38/0x5c
[   17.848519]   handle_fasteoi_irq+0xa4/0x138
[   17.852681]   generic_handle_irq+0x18/0x28
[   17.856760]   __handle_domain_irq+0x6c/0xe4
[   17.860941]   gic_handle_irq+0x54/0xa0
[   17.864666]   __irq_svc+0x70/0xb0
[   17.867964]   arch_cpu_idle+0x20/0x3c
[   17.871578]   arch_cpu_idle+0x20/0x3c
[   17.875190]   do_idle+0x144/0x218
[   17.878468]   cpu_startup_entry+0x18/0x1c
[   17.882454]   start_kernel+0x394/0x400
[   17.886177] irq event stamp: 161912
[   17.889616] hardirqs last  enabled at (161912): [<7bedfacf>] 
__netdev_alloc_skb+0xcc/0x140
[   17.897893] hardirqs last disabled at (161911): [] 
__netdev_alloc_skb+0x94/0x140

[   17.904903] exynos5-hsi2c 12ca.i2c: tx timeout
[   17.906116] softirqs last  enabled at (161904): [<387102ff>] 
irq_enter+0x78/0x80
[   17.906123] softirqs last disabled at (161905): [] 
irq_exit+0x134/0x158

[   17.925722].
[   17.925722] other info that might help us debug this:
[   17.933435]  Possible unsafe locking scenario:
[   17.933435].
[   17.940331]    CPU0
[   17.942488]    
[   17.944894]   lock(>seq#5);
[   17.948274]   
[   17.950847] lock(>seq#5);
[   17.954386].
[   17.954386]  *** DEADLOCK ***
[   17.954386].
[   17.962422] no locks held by swapper/0/0.
[   17.966011].
[   17.966011] stack backtrace:
[   17.971333] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.16.0-rc3-next-20180227-7-g876c53a7493c #453

[   17.980312] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   17.986380] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   17.994128] [] (show_stack) from [] 
(dump_stack+0x90/0xc8)
[   18.001339] [] (dump_stack) from [] 
(print_usage_bug+0x25c/0x2cc)
[   18.009161] [] (print_usage_bug) from [] 
(mark_lock+0x290/0x698)

[   18.014952] exynos5-hsi2c 12ca.i2c: tx timeout
[   18.016899] [] (mark_lock) from [] 
(__lock_acquire+0x454/0x1850)
[   18.029449] [] (__lock_acquire) from [] 
(lock_acquire+0xc8/0x2b8)
[   18.037272] [] (lock_acquire) from [] 
(usbnet_skb_return+0x7c/0x1a0)
[   18.045356] [] (usbnet_skb_return) from [] 
(asix_rx_fixup_internal+0x188/0x288)
[   18.054420] [] (asix_rx_fixup_internal) from [] 
(usbnet_bh+0xf8/0x2e4)
[   18.062694] [] (usbnet_bh) from [] 
(tasklet_action+0x8c/0x13c)
[   18.070259] [] (tasklet_action) from [] 
(__do_softirq+0xd4/0x6d4)
[   18.078089] [] (__do_softirq) from [] 
(irq_exit+0x134/0x158)
[   18.085480] [] (irq_exit) from [] 

inconsistent lock state with usbnet/asix usb ethernet and xhci

[Marek Szyprowski]

Hi

I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No
special activity is needed to reproduce this issue, it happens almost
on every boot. ASIX USB ethernet is connected to XHCI USB host controller
on that board. Is it a known issue? Frankly I have no idea where to look
to fix it. The same adapter connected to EHCI ports on other boards based
on the same SoC works fine without any warnings.

Here are some more information from that board:
# lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 0b95:772b ASIX Electronics Corp. AX88772B
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 2232:1056 Silicon Motion
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=asix, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M
    |__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M


And the log with mentioned warning:

[   17.768040] 
[   17.772239] WARNING: inconsistent lock state
[   17.776511] 4.16.0-rc3-next-20180227-7-g876c53a7493c #453 Not tainted
[   17.783329] 
[   17.787580] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[   17.793607] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   17.798751]  (>seq#5){?.-.}, at: [<9b22e5f0>] 
asix_rx_fixup_internal+0x188/0x288

[   17.806790] {IN-HARDIRQ-W} state was registered at:
[   17.811677]   tx_complete+0x100/0x208
[   17.815319]   __usb_hcd_giveback_urb+0x60/0xf0
[   17.819770]   xhci_giveback_urb_in_irq+0xa8/0x240
[   17.824469]   xhci_td_cleanup+0xf4/0x16c
[   17.828367]   xhci_irq+0xe74/0x2240
[   17.831827]   usb_hcd_irq+0x24/0x38
[   17.835343]   __handle_irq_event_percpu+0x98/0x510
[   17.840111]   handle_irq_event_percpu+0x1c/0x58
[   17.844623]   handle_irq_event+0x38/0x5c
[   17.848519]   handle_fasteoi_irq+0xa4/0x138
[   17.852681]   generic_handle_irq+0x18/0x28
[   17.856760]   __handle_domain_irq+0x6c/0xe4
[   17.860941]   gic_handle_irq+0x54/0xa0
[   17.864666]   __irq_svc+0x70/0xb0
[   17.867964]   arch_cpu_idle+0x20/0x3c
[   17.871578]   arch_cpu_idle+0x20/0x3c
[   17.875190]   do_idle+0x144/0x218
[   17.878468]   cpu_startup_entry+0x18/0x1c
[   17.882454]   start_kernel+0x394/0x400
[   17.886177] irq event stamp: 161912
[   17.889616] hardirqs last  enabled at (161912): [<7bedfacf>] 
__netdev_alloc_skb+0xcc/0x140
[   17.897893] hardirqs last disabled at (161911): [] 
__netdev_alloc_skb+0x94/0x140

[   17.904903] exynos5-hsi2c 12ca.i2c: tx timeout
[   17.906116] softirqs last  enabled at (161904): [<387102ff>] 
irq_enter+0x78/0x80
[   17.906123] softirqs last disabled at (161905): [] 
irq_exit+0x134/0x158

[   17.925722].
[   17.925722] other info that might help us debug this:
[   17.933435]  Possible unsafe locking scenario:
[   17.933435].
[   17.940331]    CPU0
[   17.942488]    
[   17.944894]   lock(>seq#5);
[   17.948274]   
[   17.950847] lock(>seq#5);
[   17.954386].
[   17.954386]  *** DEADLOCK ***
[   17.954386].
[   17.962422] no locks held by swapper/0/0.
[   17.966011].
[   17.966011] stack backtrace:
[   17.971333] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.16.0-rc3-next-20180227-7-g876c53a7493c #453

[   17.980312] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   17.986380] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   17.994128] [] (show_stack) from [] 
(dump_stack+0x90/0xc8)
[   18.001339] [] (dump_stack) from [] 
(print_usage_bug+0x25c/0x2cc)
[   18.009161] [] (print_usage_bug) from [] 
(mark_lock+0x290/0x698)

[   18.014952] exynos5-hsi2c 12ca.i2c: tx timeout
[   18.016899] [] (mark_lock) from [] 
(__lock_acquire+0x454/0x1850)
[   18.029449] [] (__lock_acquire) from [] 
(lock_acquire+0xc8/0x2b8)
[   18.037272] [] (lock_acquire) from [] 
(usbnet_skb_return+0x7c/0x1a0)
[   18.045356] [] (usbnet_skb_return) from [] 
(asix_rx_fixup_internal+0x188/0x288)
[   18.054420] [] (asix_rx_fixup_internal) from [] 
(usbnet_bh+0xf8/0x2e4)
[   18.062694] [] (usbnet_bh) from [] 
(tasklet_action+0x8c/0x13c)
[   18.070259] [] (tasklet_action) from [] 
(__do_softirq+0xd4/0x6d4)
[   18.078089] [] (__do_softirq) from [] 
(irq_exit+0x134/0x158)
[   18.085480] [] (irq_exit) from [] 

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

[Mathieu Malaterre]

On Mon, Feb 26, 2018 at 3:45 PM, Andy Shevchenko
 wrote:
> On Mon, Feb 26, 2018 at 4:44 PM, Andy Shevchenko
>  wrote:
>> On Sun, Feb 25, 2018 at 7:22 PM, Mathieu Malaterre  wrote:
>
>>>  static void __init check_cpu_feature_properties(unsigned long node)
>>>  {
>>> -   unsigned long i;
>>> struct feature_property *fp = feature_properties;
>>> const __be32 *prop;
>>>
>>
>> Much simpler is just add
>>
>> if (ARRAY_SIZE() == 0)
>>  return;
>>
>>> -   for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
>>> +   for (; fp != feature_properties + ARRAY_SIZE(feature_properties); 
>>> ++fp) {
>
> ...or convert to while(), which will be more readable.

So you'd prefer something like:

while (fp < feature_properties + ARRAY_SIZE(feature_properties)) {
  ...
  ++fp;
}

right ?

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

[Mathieu Malaterre]

On Mon, Feb 26, 2018 at 3:45 PM, Andy Shevchenko
 wrote:
> On Mon, Feb 26, 2018 at 4:44 PM, Andy Shevchenko
>  wrote:
>> On Sun, Feb 25, 2018 at 7:22 PM, Mathieu Malaterre  wrote:
>
>>>  static void __init check_cpu_feature_properties(unsigned long node)
>>>  {
>>> -   unsigned long i;
>>> struct feature_property *fp = feature_properties;
>>> const __be32 *prop;
>>>
>>
>> Much simpler is just add
>>
>> if (ARRAY_SIZE() == 0)
>>  return;
>>
>>> -   for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
>>> +   for (; fp != feature_properties + ARRAY_SIZE(feature_properties); 
>>> ++fp) {
>
> ...or convert to while(), which will be more readable.

So you'd prefer something like:

while (fp < feature_properties + ARRAY_SIZE(feature_properties)) {
  ...
  ++fp;
}

right ?

Re: [PATCH v8 2/2] media: V3s: Add support for Allwinner CSI.

[Maxime Ripard]

On Tue, Feb 27, 2018 at 10:12:46AM +0800, Yong Deng wrote:
> Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
> interface and CSI1 is used for parallel interface. This is not
> documented in datasheet but by test and guess.
> 
> This patch implement a v4l2 framework driver for it.
> 
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
> 
> Tested-by: Maxime Ripard 
> Signed-off-by: Yong Deng 

Reviewed-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v8 2/2] media: V3s: Add support for Allwinner CSI.

[Maxime Ripard]

On Tue, Feb 27, 2018 at 10:12:46AM +0800, Yong Deng wrote:
> Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
> interface and CSI1 is used for parallel interface. This is not
> documented in datasheet but by test and guess.
> 
> This patch implement a v4l2 framework driver for it.
> 
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
> 
> Tested-by: Maxime Ripard 
> Signed-off-by: Yong Deng 

Reviewed-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 2/6] pci: Scan all functions when probing while running over Jailhouse

[Jan Kiszka]

On 2018-02-23 14:23, Andy Shevchenko wrote:
> On Mon, Jan 22, 2018 at 8:12 AM, Jan Kiszka  wrote:
> 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
> 
> Keep it in order?
> 

Done.

> 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
> 
> Ditto.
> 

Despite the context suggesting it, this file has no ordering.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 2/6] pci: Scan all functions when probing while running over Jailhouse

[Jan Kiszka]

On 2018-02-23 14:23, Andy Shevchenko wrote:
> On Mon, Jan 22, 2018 at 8:12 AM, Jan Kiszka  wrote:
> 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
> 
> Keep it in order?
> 

Done.

> 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
> 
> Ditto.
> 

Despite the context suggesting it, this file has no ordering.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

[Ard Biesheuvel]

Hi Jonathan,

On 27 February 2018 at 06:05, Jonathan Toppins  wrote:
> This patch allows a user to configure ACPI to be preferred over
> device-tree.
>

This comes up once a year or so, and the consensus has been so far
that it is not up to the kernel to reason about whether DT or ACPI
should be preferred if both are supplied, Instead, it is up to the
firmware to ensure that only one of those is provided, and we added a
generic driver to EDK2 that implements this.

> Currently for ACPI to be used a user either has to set acpi=on on the
> kernel command line or make sure any device tree passed to the kernel
> is empty. If the dtb passed to the kernel is non-empty then device-tree
> will be chosen as the boot method of choice even if it is not correct.

Your firmware is terminally broken if it provides an incorrect DT, and
we should not be fixing it in the kernel.

> To prevent this situation where a system is only intended to be booted
> via ACPI a user can set this kernel configuration so it ignores
> device-tree settings unless ACPI table checks fail.
>

'only intended to be booted via ACPI' is a property of the system, not
of the OS. If you need this functionality for development, you can
append 'acpi=on' to the kernel command line via kconfig.


> Signed-off-by: Jonathan Toppins 
> ---
>
>  arch/arm64/Kconfig   | 13 +
>  arch/arm64/kernel/acpi.c |  2 +-
>  2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7381eeb7ef8e..da8d9ab62825 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1170,6 +1170,19 @@ config ARM64_ACPI_PARKING_PROTOCOL
>   protocol even if the corresponding data is present in the ACPI
>   MADT table.
>
> +config ARM64_PREFER_ACPI
> +   bool "Prefer usage of ACPI boot tables over device-tree"
> +   depends on ACPI
> +   help
> + Normally device-tree is preferred over ACPI on arm64 unless
> + explicitly preferred via kernel command line, something like: 
> acpi=on
> + This configuration changes this default behaviour by pretending
> + the user set acpi=on on the command line. This configuration still
> + allows the user to turn acpi table parsing off via acpi=off. If
> + for some reason the table checks fail the system will still fall
> + back to using device-tree unless the user explicitly sets acpi=force
> + on the command line.
> +
>  config CMDLINE
> string "Default kernel command string"
> default ""
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 7b09487ff8fb..315b001c45f1 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -44,7 +44,7 @@ int acpi_pci_disabled = 1;/* skip ACPI PCI scan and IRQ 
> initialization */
>  EXPORT_SYMBOL(acpi_pci_disabled);
>
>  static bool param_acpi_off __initdata;
> -static bool param_acpi_on __initdata;
> +static bool param_acpi_on __initdata = IS_ENABLED(CONFIG_ARM64_PREFER_ACPI);
>  static bool param_acpi_force __initdata;
>
>  static int __init parse_acpi(char *arg)
> --
> 2.13.6
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

[Ard Biesheuvel]

Hi Jonathan,

On 27 February 2018 at 06:05, Jonathan Toppins  wrote:
> This patch allows a user to configure ACPI to be preferred over
> device-tree.
>

This comes up once a year or so, and the consensus has been so far
that it is not up to the kernel to reason about whether DT or ACPI
should be preferred if both are supplied, Instead, it is up to the
firmware to ensure that only one of those is provided, and we added a
generic driver to EDK2 that implements this.

> Currently for ACPI to be used a user either has to set acpi=on on the
> kernel command line or make sure any device tree passed to the kernel
> is empty. If the dtb passed to the kernel is non-empty then device-tree
> will be chosen as the boot method of choice even if it is not correct.

Your firmware is terminally broken if it provides an incorrect DT, and
we should not be fixing it in the kernel.

> To prevent this situation where a system is only intended to be booted
> via ACPI a user can set this kernel configuration so it ignores
> device-tree settings unless ACPI table checks fail.
>

'only intended to be booted via ACPI' is a property of the system, not
of the OS. If you need this functionality for development, you can
append 'acpi=on' to the kernel command line via kconfig.


> Signed-off-by: Jonathan Toppins 
> ---
>
>  arch/arm64/Kconfig   | 13 +
>  arch/arm64/kernel/acpi.c |  2 +-
>  2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7381eeb7ef8e..da8d9ab62825 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1170,6 +1170,19 @@ config ARM64_ACPI_PARKING_PROTOCOL
>   protocol even if the corresponding data is present in the ACPI
>   MADT table.
>
> +config ARM64_PREFER_ACPI
> +   bool "Prefer usage of ACPI boot tables over device-tree"
> +   depends on ACPI
> +   help
> + Normally device-tree is preferred over ACPI on arm64 unless
> + explicitly preferred via kernel command line, something like: 
> acpi=on
> + This configuration changes this default behaviour by pretending
> + the user set acpi=on on the command line. This configuration still
> + allows the user to turn acpi table parsing off via acpi=off. If
> + for some reason the table checks fail the system will still fall
> + back to using device-tree unless the user explicitly sets acpi=force
> + on the command line.
> +
>  config CMDLINE
> string "Default kernel command string"
> default ""
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 7b09487ff8fb..315b001c45f1 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -44,7 +44,7 @@ int acpi_pci_disabled = 1;/* skip ACPI PCI scan and IRQ 
> initialization */
>  EXPORT_SYMBOL(acpi_pci_disabled);
>
>  static bool param_acpi_off __initdata;
> -static bool param_acpi_on __initdata;
> +static bool param_acpi_on __initdata = IS_ENABLED(CONFIG_ARM64_PREFER_ACPI);
>  static bool param_acpi_force __initdata;
>
>  static int __init parse_acpi(char *arg)
> --
> 2.13.6
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/6] x86: Consolidate PCI_MMCONFIG configs

[Jan Kiszka]

On 2018-01-28 18:26, Andy Shevchenko wrote:
> On Mon, Jan 22, 2018 at 8:12 AM, Jan Kiszka  wrote:
>> From: Jan Kiszka 
>>
>> Not sure if those two worked by design or just by chance so far. In any
>> case, it's at least cleaner and clearer to express this in a single
>> config statement.
> 
> Congrats! You found by the way a bug in
> 
> commit e279b6c1d329e50b766bce96aacc197eae8a053b
> Author: Sam Ravnborg 
> Date:   Tue Nov 6 20:41:05 2007 +0100
> 
>x86: start unification of arch/x86/Kconfig.*
> 
> ...and proper fix seems to split PCI stuff to common + X86_32 only + X86_64 
> only
> 

Hmm, is that a change request on this patch?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 4/6] x86: Consolidate PCI_MMCONFIG configs

[Jan Kiszka]

On 2018-01-28 18:26, Andy Shevchenko wrote:
> On Mon, Jan 22, 2018 at 8:12 AM, Jan Kiszka  wrote:
>> From: Jan Kiszka 
>>
>> Not sure if those two worked by design or just by chance so far. In any
>> case, it's at least cleaner and clearer to express this in a single
>> config statement.
> 
> Congrats! You found by the way a bug in
> 
> commit e279b6c1d329e50b766bce96aacc197eae8a053b
> Author: Sam Ravnborg 
> Date:   Tue Nov 6 20:41:05 2007 +0100
> 
>x86: start unification of arch/x86/Kconfig.*
> 
> ...and proper fix seems to split PCI stuff to common + X86_32 only + X86_64 
> only
> 

Hmm, is that a change request on this patch?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [RFC REBASED 3/5] powerpc/mm/slice: implement slice_check_range_fits

[Aneesh Kumar K.V]

Christophe Leroy  writes:
 +  if ((start + len) > SLICE_LOW_TOP) {
> + unsigned long start_index = GET_HIGH_SLICE_INDEX(start);
> + unsigned long align_end = ALIGN(end, (1UL << SLICE_HIGH_SHIFT));
> + unsigned long count = GET_HIGH_SLICE_INDEX(align_end) - 
> start_index;
> + unsigned long i;
>  
> - slice_bitmap_and(result, mask->high_slices, available->high_slices,
> -  slice_count);
> + for (i = start_index; i < start_index + count; i++) {
> + if (!test_bit(i, available->high_slices))
> + return false;
> + }
> + }

why not bitmap_equal here instead of test_bit in loop?
>  
> - return (mask->low_slices & available->low_slices) == mask->low_slices &&
> - slice_bitmap_equal(result, mask->high_slices, slice_count);
> + return true;
>  }

-aneesh

Re: [RFC REBASED 3/5] powerpc/mm/slice: implement slice_check_range_fits

[Aneesh Kumar K.V]

Christophe Leroy  writes:
 +  if ((start + len) > SLICE_LOW_TOP) {
> + unsigned long start_index = GET_HIGH_SLICE_INDEX(start);
> + unsigned long align_end = ALIGN(end, (1UL << SLICE_HIGH_SHIFT));
> + unsigned long count = GET_HIGH_SLICE_INDEX(align_end) - 
> start_index;
> + unsigned long i;
>  
> - slice_bitmap_and(result, mask->high_slices, available->high_slices,
> -  slice_count);
> + for (i = start_index; i < start_index + count; i++) {
> + if (!test_bit(i, available->high_slices))
> + return false;
> + }
> + }

why not bitmap_equal here instead of test_bit in loop?
>  
> - return (mask->low_slices & available->low_slices) == mask->low_slices &&
> - slice_bitmap_equal(result, mask->high_slices, slice_count);
> + return true;
>  }

-aneesh

[PATCH] perf machine: Fix load kernel symbol with '-k' option

[Leo Yan]

On Hikey arm64 octa A53 platform, when use command './perf report -v
-k vmlinux --stdio' it outputs below error info, and it skips to load
kernel symbol and doesn't print symbol for event:
Failed to open [kernel.kallsyms]_text, continuing without symbols.

The regression is introduced by commit ("8c7f1bb37b29 perf machine: Move
kernel mmap name into struct machine"), which changes the logic for
machine mmap_name by removing function machine__mmap_name() and always
use 'machine->mmap_name'.  Comparing difference between
machine__mmap_name() and 'machine->mmap_name', the later one includes
the string for specified kernel vmlinux string with option '-k' in
command, but the old function machine__mmap_name() ignores vmlinux
path string.  As result, event's mmap file name doesn't match with
machine mmap file name anymore and it skips to load kernel symbol from
vmlinux file.

To resolve this issue, this patch adds extra checking for
'machine->mmap_name', when its start char is not '[' then we can know
it includes vmlinux path string specified for option '-k'. For this
case it sets 'is_kernel_mmap = true' and run into flow to load kernel
symbol from vmlinux.

This patch has been verified with two commands: './perf report -v
-k vmlinux --stdio' and './perf script -v -F cpu,event,ip,sym,symoff
-k vmlinux'.

Signed-off-by: Leo Yan 
---
 tools/perf/util/machine.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 12b7427..ffd709d 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1299,9 +1299,18 @@ static int machine__process_kernel_mmap_event(struct 
machine *machine,
else
kernel_type = DSO_TYPE_GUEST_KERNEL;
 
-   is_kernel_mmap = memcmp(event->mmap.filename,
-   machine->mmap_name,
-   strlen(machine->mmap_name) - 1) == 0;
+   /*
+* If machine mmap_name doesn't start with char '[', it includes
+* the specified kernel vmlinux name with option '-k'.  So set
+* is_kernel_mmap as true to create machine symbol map.
+*/
+   if (machine->mmap_name[0] != '[')
+   is_kernel_mmap = true;
+   else
+   is_kernel_mmap = memcmp(event->mmap.filename,
+   machine->mmap_name,
+   strlen(machine->mmap_name) - 1) == 0;
+
if (event->mmap.filename[0] == '/' ||
(!is_kernel_mmap && event->mmap.filename[0] == '[')) {
map = machine__findnew_module_map(machine, event->mmap.start,
-- 
2.7.4

[PATCH] perf machine: Fix load kernel symbol with '-k' option

[Leo Yan]

On Hikey arm64 octa A53 platform, when use command './perf report -v
-k vmlinux --stdio' it outputs below error info, and it skips to load
kernel symbol and doesn't print symbol for event:
Failed to open [kernel.kallsyms]_text, continuing without symbols.

The regression is introduced by commit ("8c7f1bb37b29 perf machine: Move
kernel mmap name into struct machine"), which changes the logic for
machine mmap_name by removing function machine__mmap_name() and always
use 'machine->mmap_name'.  Comparing difference between
machine__mmap_name() and 'machine->mmap_name', the later one includes
the string for specified kernel vmlinux string with option '-k' in
command, but the old function machine__mmap_name() ignores vmlinux
path string.  As result, event's mmap file name doesn't match with
machine mmap file name anymore and it skips to load kernel symbol from
vmlinux file.

To resolve this issue, this patch adds extra checking for
'machine->mmap_name', when its start char is not '[' then we can know
it includes vmlinux path string specified for option '-k'. For this
case it sets 'is_kernel_mmap = true' and run into flow to load kernel
symbol from vmlinux.

This patch has been verified with two commands: './perf report -v
-k vmlinux --stdio' and './perf script -v -F cpu,event,ip,sym,symoff
-k vmlinux'.

Signed-off-by: Leo Yan 
---
 tools/perf/util/machine.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 12b7427..ffd709d 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1299,9 +1299,18 @@ static int machine__process_kernel_mmap_event(struct 
machine *machine,
else
kernel_type = DSO_TYPE_GUEST_KERNEL;
 
-   is_kernel_mmap = memcmp(event->mmap.filename,
-   machine->mmap_name,
-   strlen(machine->mmap_name) - 1) == 0;
+   /*
+* If machine mmap_name doesn't start with char '[', it includes
+* the specified kernel vmlinux name with option '-k'.  So set
+* is_kernel_mmap as true to create machine symbol map.
+*/
+   if (machine->mmap_name[0] != '[')
+   is_kernel_mmap = true;
+   else
+   is_kernel_mmap = memcmp(event->mmap.filename,
+   machine->mmap_name,
+   strlen(machine->mmap_name) - 1) == 0;
+
if (event->mmap.filename[0] == '/' ||
(!is_kernel_mmap && event->mmap.filename[0] == '[')) {
map = machine__findnew_module_map(machine, event->mmap.start,
-- 
2.7.4

Re: [PATCH 4.4 00/22] 4.4.119-stable review

[Naresh Kamboju]

On 27 February 2018 at 01:46, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 4.4.119 release.
> There are 22 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:15:48 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.119-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.4.119-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: a6c6a3a6b5621c2507038cecf42c46727d327048
git describe: v4.4.118-23-ga6c6a3a6b562
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.118-23-ga6c6a3a6b562


No regressions (compared to build v4.4.118)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 34, skip: 29
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 53
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 998, skip: 152
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 33, skip: 29
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1052, skip: 98
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 48, skip: 32
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1030, skip: 120
* ltp-timers-tests - pass: 12, skip: 1

Hikey test results,

Summary


kernel: 4.4.119-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.119-rc1-hikey-20180226-143
git commit: 771d0ba89d9a09eaeca879730f10ebdd6954af6b
git describe: 4.4.119-rc1-hikey-20180226-143
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.119-rc1-hikey-20180226-143


No regressions (compared to build 4.4.118-rc1-hikey-20180224-141)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 31, skip: 32
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 53
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 996, skip: 154
* ltp-timers-tests - pass: 12, skip: 1

--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 4.4 00/22] 4.4.119-stable review

[Naresh Kamboju]

On 27 February 2018 at 01:46, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.4.119 release.
> There are 22 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:15:48 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.119-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.4.119-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: a6c6a3a6b5621c2507038cecf42c46727d327048
git describe: v4.4.118-23-ga6c6a3a6b562
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.118-23-ga6c6a3a6b562


No regressions (compared to build v4.4.118)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 34, skip: 29
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 53
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 998, skip: 152
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 33, skip: 29
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1052, skip: 98
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 48, skip: 32
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1030, skip: 120
* ltp-timers-tests - pass: 12, skip: 1

Hikey test results,

Summary


kernel: 4.4.119-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.119-rc1-hikey-20180226-143
git commit: 771d0ba89d9a09eaeca879730f10ebdd6954af6b
git describe: 4.4.119-rc1-hikey-20180226-143
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.119-rc1-hikey-20180226-143


No regressions (compared to build 4.4.118-rc1-hikey-20180224-141)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 31, skip: 32
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 53
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 996, skip: 154
* ltp-timers-tests - pass: 12, skip: 1

--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

[Alexander Kapshuk]

On Tue, Feb 27, 2018 at 6:45 AM, Tobin C. Harding  wrote:
> When the system is idle it is likely that most files under /proc/PID
> will be identical for various processes.  Scanning _all_ the PIDs under
> /proc is unnecessary and implies that we are thoroughly scanning /proc.
> This is _not_ the case because there may be ways userspace can trigger
> creation of /proc files that leak addresses but were not present during
> a scan.  For these two reasons we should exclude all PID directories
> under /proc except '1/'
>
> Exclude all /proc/PID except /proc/1.
>
> Signed-off-by: Tobin C. Harding 
> ---
>  scripts/leaking_addresses.pl | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
> index 6e5bc57caeaa..fb40e2828f43 100755
> --- a/scripts/leaking_addresses.pl
> +++ b/scripts/leaking_addresses.pl
> @@ -10,6 +10,14 @@
>  # Use --debug to output path before parsing, this is useful to find files 
> that
>  # cause the script to choke.
>
> +#
> +# When the system is idle it is likely that most files under /proc/PID will 
> be
> +# identical for various processes.  Scanning _all_ the PIDs under /proc is
> +# unnecessary and implies that we are thoroughly scanning /proc.  This is 
> _not_
> +# the case because there may be ways userspace can trigger creation of /proc
> +# files that leak addresses but were not present during a scan.  For these 
> two
> +# reasons we exclude all PID directories under /proc except '1/'
> +
>  use warnings;
>  use strict;
>  use POSIX;
> @@ -472,6 +480,9 @@ sub walk
> my $path = "$pwd/$file";
> next if (-l $path);
>
> +   # skip /proc/PID except /proc/1
> +   next if ($path =~ /\/proc\/(?:[2-9][0-9]*|1[0-9]+)/);
> +
> next if (skip($path));
>
> if (-d $path) {
> --
> 2.7.4
>

Would something like this do the trick?
perl -e 'foreach my $dir (`ls -d /proc/[0-9]*`){next if($dir !~
"/proc/1\$"); print $dir}'
/proc/1

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

[Alexander Kapshuk]

On Tue, Feb 27, 2018 at 6:45 AM, Tobin C. Harding  wrote:
> When the system is idle it is likely that most files under /proc/PID
> will be identical for various processes.  Scanning _all_ the PIDs under
> /proc is unnecessary and implies that we are thoroughly scanning /proc.
> This is _not_ the case because there may be ways userspace can trigger
> creation of /proc files that leak addresses but were not present during
> a scan.  For these two reasons we should exclude all PID directories
> under /proc except '1/'
>
> Exclude all /proc/PID except /proc/1.
>
> Signed-off-by: Tobin C. Harding 
> ---
>  scripts/leaking_addresses.pl | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
> index 6e5bc57caeaa..fb40e2828f43 100755
> --- a/scripts/leaking_addresses.pl
> +++ b/scripts/leaking_addresses.pl
> @@ -10,6 +10,14 @@
>  # Use --debug to output path before parsing, this is useful to find files 
> that
>  # cause the script to choke.
>
> +#
> +# When the system is idle it is likely that most files under /proc/PID will 
> be
> +# identical for various processes.  Scanning _all_ the PIDs under /proc is
> +# unnecessary and implies that we are thoroughly scanning /proc.  This is 
> _not_
> +# the case because there may be ways userspace can trigger creation of /proc
> +# files that leak addresses but were not present during a scan.  For these 
> two
> +# reasons we exclude all PID directories under /proc except '1/'
> +
>  use warnings;
>  use strict;
>  use POSIX;
> @@ -472,6 +480,9 @@ sub walk
> my $path = "$pwd/$file";
> next if (-l $path);
>
> +   # skip /proc/PID except /proc/1
> +   next if ($path =~ /\/proc\/(?:[2-9][0-9]*|1[0-9]+)/);
> +
> next if (skip($path));
>
> if (-d $path) {
> --
> 2.7.4
>

Would something like this do the trick?
perl -e 'foreach my $dir (`ls -d /proc/[0-9]*`){next if($dir !~
"/proc/1\$"); print $dir}'
/proc/1

Re: [PATCH 3/4 v2] fs: proc: use down_read_killable() in environ_read()

[Alexey Dobriyan]

On Tue, Feb 27, 2018 at 08:25:50AM +0800, Yang Shi wrote:
> Like reading /proc/*/cmdline, it is possible to be blocked for long time
> when reading /proc/*/environ when manipulating large mapping at the mean
> time. The environ reading process will be waiting for mmap_sem become
> available for a long time then it may cause the reading task hung.
> 
> Convert down_read() and access_remote_vm() to killable version.
> 
> Signed-off-by: Yang Shi 
> Suggested-by: Alexey Dobriyan 

Ehh, bloody tags.
I didn't suggest _killable() variants, they're quite ugly because API
multiplies. access_remote_vm() could be converted to down_read_killable().

> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -933,7 +933,9 @@ static ssize_t environ_read(struct file *file, char 
> __user *buf,
>   if (!mmget_not_zero(mm))
>   goto free;
>  
> - down_read(>mmap_sem);
> + ret = down_read_killable(>mmap_sem);
> + if (ret)
> + goto out_mmput;
>   env_start = mm->env_start;
>   env_end = mm->env_end;
>   up_read(>mmap_sem);
> @@ -950,7 +952,8 @@ static ssize_t environ_read(struct file *file, char 
> __user *buf,
>   max_len = min_t(size_t, PAGE_SIZE, count);
>   this_len = min(max_len, this_len);
>  
> - retval = access_remote_vm(mm, (env_start + src), page, 
> this_len, 0);
> + retval = access_remote_vm_killable(mm, (env_start + src),
> + page, this_len, 0);

Re: [PATCH 3/4 v2] fs: proc: use down_read_killable() in environ_read()

[Alexey Dobriyan]

On Tue, Feb 27, 2018 at 08:25:50AM +0800, Yang Shi wrote:
> Like reading /proc/*/cmdline, it is possible to be blocked for long time
> when reading /proc/*/environ when manipulating large mapping at the mean
> time. The environ reading process will be waiting for mmap_sem become
> available for a long time then it may cause the reading task hung.
> 
> Convert down_read() and access_remote_vm() to killable version.
> 
> Signed-off-by: Yang Shi 
> Suggested-by: Alexey Dobriyan 

Ehh, bloody tags.
I didn't suggest _killable() variants, they're quite ugly because API
multiplies. access_remote_vm() could be converted to down_read_killable().

> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -933,7 +933,9 @@ static ssize_t environ_read(struct file *file, char 
> __user *buf,
>   if (!mmget_not_zero(mm))
>   goto free;
>  
> - down_read(>mmap_sem);
> + ret = down_read_killable(>mmap_sem);
> + if (ret)
> + goto out_mmput;
>   env_start = mm->env_start;
>   env_end = mm->env_end;
>   up_read(>mmap_sem);
> @@ -950,7 +952,8 @@ static ssize_t environ_read(struct file *file, char 
> __user *buf,
>   max_len = min_t(size_t, PAGE_SIZE, count);
>   this_len = min(max_len, this_len);
>  
> - retval = access_remote_vm(mm, (env_start + src), page, 
> this_len, 0);
> + retval = access_remote_vm_killable(mm, (env_start + src),
> + page, this_len, 0);

[PATCH v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

OF graph describes MHL data lanes between MHL and respective USB
connector.

Signed-off-by: Andrzej Hajda 
---
v5: removed extra parenthesis (kbuild test robot)
v4: added missing reg property in connector's port node (Krzysztof)
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index f604f6b1a9c2..03453b822093 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -817,9 +817,22 @@
clocks = <_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <_con_to_mhl>;
+   };
};
};
};
@@ -842,6 +855,18 @@
 "usb-b-connector";
label = "micro-USB";
type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   musb_con_to_mhl: endpoint {
+   remote-endpoint = 
<_to_musb_con>;
+   };
+   };
+   };
};
};
 
-- 
2.16.2

[PATCH v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

OF graph describes MHL data lanes between MHL and respective USB
connector.

Signed-off-by: Andrzej Hajda 
---
v5: removed extra parenthesis (kbuild test robot)
v4: added missing reg property in connector's port node (Krzysztof)
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index f604f6b1a9c2..03453b822093 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -817,9 +817,22 @@
clocks = <_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <_con_to_mhl>;
+   };
};
};
};
@@ -842,6 +855,18 @@
 "usb-b-connector";
label = "micro-USB";
type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   musb_con_to_mhl: endpoint {
+   remote-endpoint = 
<_to_musb_con>;
+   };
+   };
+   };
};
};
 
-- 
2.16.2

Re: [PATCH 4.9 00/39] 4.9.85-stable review

[Naresh Kamboju]

On 27 February 2018 at 01:50, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.85 release.
> There are 39 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:16:31 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.85-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.9.85-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 8a6c3b05a45b5e6deea2156d191d1e90aec6d083
git describe: v4.9.84-40-g8a6c3b05a45b
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.84-40-g8a6c3b05a45b


No regressions (compared to build v4.9.84)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 41, skip: 24
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 42, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 39, skip: 25
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 54, skip: 27
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1

--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 4.9 00/39] 4.9.85-stable review

[Naresh Kamboju]

On 27 February 2018 at 01:50, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.85 release.
> There are 39 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:16:31 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.85-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.9.85-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 8a6c3b05a45b5e6deea2156d191d1e90aec6d083
git describe: v4.9.84-40-g8a6c3b05a45b
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.84-40-g8a6c3b05a45b


No regressions (compared to build v4.9.84)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 41, skip: 24
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 42, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 39, skip: 25
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 54, skip: 27
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1

--
Linaro QA (beta)
https://qa-reports.linaro.org

[PATCH v5 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda 
Acked-by: Chanwoo Choi 
---
v5: function renamed to extcon_find_edev_by_node (Andy)
v2: changed label to follow local convention (Chanwoo)
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..47a5ca9eb86d 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_find_edev_by_node - Find the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto out;
+   edev = ERR_PTR(-EPROBE_DEFER);
+out:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_find_edev_by_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_find_edev_by_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..7f033b1ea568 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_find_edev_by_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -283,6 +284,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_find_edev_by_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.16.2

[PATCH v5 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda 
Acked-by: Chanwoo Choi 
---
v5: function renamed to extcon_find_edev_by_node (Andy)
v2: changed label to follow local convention (Chanwoo)
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..47a5ca9eb86d 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_find_edev_by_node - Find the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto out;
+   edev = ERR_PTR(-EPROBE_DEFER);
+out:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_find_edev_by_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_find_edev_by_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..7f033b1ea568 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_find_edev_by_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -283,6 +284,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_find_edev_by_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.16.2

[PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski 

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski 
Signed-off-by: Andrzej Hajda 
---
v5: updated extcon API

This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
 1 file changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..62b0adabcac2 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
*ctx)
ctx->rc_dev = rc_dev;
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_get_next_parent(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_find_edev_by_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->dev)->irq);
-   sii8620_hw_off(ctx);
+   if (ctx->extcon) {
+   extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
+ 

Re: [RFC PATCH] ARM: configs: sunxi: Set ondemand govenor as default

[Maxime Ripard]

On Mon, Feb 26, 2018 at 10:29:29PM +0100, Philipp Rossak wrote:
> 
> 
> On 19.02.2018 09:10, Maxime Ripard wrote:
> > On Sat, Feb 17, 2018 at 03:22:35PM +0100, Philipp Rossak wrote:
> > > Right now the performance govenor is the default frequency govenor on
> > > sunxi devices. This causes some general problems.
> > > When the cpu is idle the cpu runs with its maximum frequency.
> > > This causes a higher cpu temperature in the idle state. When the cpu is
> > > now under load the cpu gets with that higher idle temperature now faster
> > > to its thermal limits.
> > > An other big problem of the performace govenor is the missing
> > > thermal throttling. Some tests with cpuburn resulted in a system crash
> > > when the soc reached its thermal limits since no thermal throttling
> > > occurred.
> > 
> > This won't change anything with cpuburn. While cpuburn will be
> > running, ondemand will increase the frequency of the cores to the
> > maximum frequency, putting yourself in the exact same situation.
>
> I see here a totally different behavior on the hardware (Bananapi M2, A31s).
> First ondemand increases the cpu frequency, when the maximum temperature is
> reached, then it throttles down the cpu step by step to its minimum.

This is the thermal throttling, not the cpufreq governor.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski 

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski 
Signed-off-by: Andrzej Hajda 
---
v5: updated extcon API

This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
 1 file changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..62b0adabcac2 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
*ctx)
ctx->rc_dev = rc_dev;
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_get_next_parent(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_find_edev_by_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->dev)->irq);
-   sii8620_hw_off(ctx);
+   if (ctx->extcon) {
+   extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
+  >extcon_nb);
+   flush_work(>extcon_wq);

Re: [RFC PATCH] ARM: configs: sunxi: Set ondemand govenor as default

[Maxime Ripard]

On Mon, Feb 26, 2018 at 10:29:29PM +0100, Philipp Rossak wrote:
> 
> 
> On 19.02.2018 09:10, Maxime Ripard wrote:
> > On Sat, Feb 17, 2018 at 03:22:35PM +0100, Philipp Rossak wrote:
> > > Right now the performance govenor is the default frequency govenor on
> > > sunxi devices. This causes some general problems.
> > > When the cpu is idle the cpu runs with its maximum frequency.
> > > This causes a higher cpu temperature in the idle state. When the cpu is
> > > now under load the cpu gets with that higher idle temperature now faster
> > > to its thermal limits.
> > > An other big problem of the performace govenor is the missing
> > > thermal throttling. Some tests with cpuburn resulted in a system crash
> > > when the soc reached its thermal limits since no thermal throttling
> > > occurred.
> > 
> > This won't change anything with cpuburn. While cpuburn will be
> > running, ondemand will increase the frequency of the cores to the
> > maximum frequency, putting yourself in the exact same situation.
>
> I see here a totally different behavior on the hardware (Bananapi M2, A31s).
> First ondemand increases the cpu frequency, when the maximum temperature is
> reached, then it throttles down the cpu step by step to its minimum.

This is the thermal throttling, not the cpufreq governor.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.

Signed-off-by: Andrzej Hajda 
---
v4:
- improved 'type' description (Rob),
- improved description of 2nd example (Rob).
v3:
- removed MHL port (samsung connector will have separate bindings),
- added 2nd example for USB-C,
- improved formatting.
v2:
- moved connector type(A,B,C) to compatible string (Rob),
- renamed size property to type (Rob),
- changed type description to be less confusing (Laurent),
- removed vendor specific compatibles (implied by graph port number),
- added requirement of connector being a child of IC (Rob),
- removed max-mode (subtly suggested by Rob, it should be detected anyway
  by USB Controller in runtime, downside is that device is not able to
  report its real capabilities, maybe better would be to make it optional(?)),
- assigned port numbers to data buses (Rob).

Regards
Andrzej
---
 .../bindings/connector/usb-connector.txt   | 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..e1463f14af38
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,75 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector",
+"usb-b-connector",
+"usb-c-connector".
+
+Optional properties:
+- label: symbolic name for the connector,
+- type: size of the connector, should be specified in case of USB-A, USB-B
+  non-fullsize connectors: "mini", "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS), present in all connectors,
+1: Super Speed (SS), present in SS capable connectors,
+2: Sideband use (SBU), present in USB-C.
+
+Examples
+
+
+1. Micro-USB connector with HS lines routed via controller (MUIC):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
+};
+
+2. USB-C connector attached to CC controller (s2mm005), HS lines routed
+to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
+DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
+
+ccic: s2mm005@33 {
+   ...
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   usb_con_hs: endpoint {
+   remote-endpoint = <_usbc_hs>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   usb_con_ss: endpoint {
+   remote-endpoint = <_phy_ss>;
+   };
+   };
+   port@2 {
+   reg = <2>;
+   usb_con_sbu: endpoint {
+   remote-endpoint = <_aux>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.2

[PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.

Signed-off-by: Andrzej Hajda 
---
v4:
- improved 'type' description (Rob),
- improved description of 2nd example (Rob).
v3:
- removed MHL port (samsung connector will have separate bindings),
- added 2nd example for USB-C,
- improved formatting.
v2:
- moved connector type(A,B,C) to compatible string (Rob),
- renamed size property to type (Rob),
- changed type description to be less confusing (Laurent),
- removed vendor specific compatibles (implied by graph port number),
- added requirement of connector being a child of IC (Rob),
- removed max-mode (subtly suggested by Rob, it should be detected anyway
  by USB Controller in runtime, downside is that device is not able to
  report its real capabilities, maybe better would be to make it optional(?)),
- assigned port numbers to data buses (Rob).

Regards
Andrzej
---
 .../bindings/connector/usb-connector.txt   | 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..e1463f14af38
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,75 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector",
+"usb-b-connector",
+"usb-c-connector".
+
+Optional properties:
+- label: symbolic name for the connector,
+- type: size of the connector, should be specified in case of USB-A, USB-B
+  non-fullsize connectors: "mini", "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS), present in all connectors,
+1: Super Speed (SS), present in SS capable connectors,
+2: Sideband use (SBU), present in USB-C.
+
+Examples
+
+
+1. Micro-USB connector with HS lines routed via controller (MUIC):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
+};
+
+2. USB-C connector attached to CC controller (s2mm005), HS lines routed
+to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
+DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
+
+ccic: s2mm005@33 {
+   ...
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   usb_con_hs: endpoint {
+   remote-endpoint = <_usbc_hs>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   usb_con_ss: endpoint {
+   remote-endpoint = <_phy_ss>;
+   };
+   };
+   port@2 {
+   reg = <2>;
+   usb_con_sbu: endpoint {
+   remote-endpoint = <_aux>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.2

[PATCH v5 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

[Andrzej Hajda]

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 0b61dda99569..f604f6b1a9c2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -836,6 +836,13 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   musb_con: musb_connector {
+   compatible = "samsung,usb-connector-11pin",
+"usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
};
 
regulators {
-- 
2.16.2

[PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi,

Thanks for reviews of previous iterations.

This patchset introduces USB physical connector bindings, together with
working example.
I have removed RFC prefix - the patchset seems to be heading
to a happy end :)

v5: fixed extra parenthesis in dts, renamed extcon function.
v4: improved binding descriptions, added missing reg in dts.
v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
example.
v2: I have addressed comments by Rob and Laurent, thanks 

Changes in datail are described in the patches.

Regards
Andrzej


Andrzej Hajda (5):
  dt-bindings: add bindings for USB physical connector
  dt-bindings: add bindings for Samsung micro-USB 11-pin connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  arm64: dts: exynos: add OF graph between MHL and USB connector
  extcon: add possibility to get extcon device by OF node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../connector/samsung,usb-connector-11pin.txt  | 49 +++
 .../bindings/connector/usb-connector.txt   | 75 +
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 38 -
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 97 +-
 include/linux/extcon.h |  6 ++
 6 files changed, 293 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

-- 
2.16.2

[PATCH v5 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

[Andrzej Hajda]

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 0b61dda99569..f604f6b1a9c2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -836,6 +836,13 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   musb_con: musb_connector {
+   compatible = "samsung,usb-connector-11pin",
+"usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
};
 
regulators {
-- 
2.16.2

[PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi,

Thanks for reviews of previous iterations.

This patchset introduces USB physical connector bindings, together with
working example.
I have removed RFC prefix - the patchset seems to be heading
to a happy end :)

v5: fixed extra parenthesis in dts, renamed extcon function.
v4: improved binding descriptions, added missing reg in dts.
v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
example.
v2: I have addressed comments by Rob and Laurent, thanks 

Changes in datail are described in the patches.

Regards
Andrzej


Andrzej Hajda (5):
  dt-bindings: add bindings for USB physical connector
  dt-bindings: add bindings for Samsung micro-USB 11-pin connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  arm64: dts: exynos: add OF graph between MHL and USB connector
  extcon: add possibility to get extcon device by OF node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../connector/samsung,usb-connector-11pin.txt  | 49 +++
 .../bindings/connector/usb-connector.txt   | 75 +
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 38 -
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 97 +-
 include/linux/extcon.h |  6 ++
 6 files changed, 293 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

-- 
2.16.2

[PATCH v5 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector

[Andrzej Hajda]

Samsung micro-USB 11-pin connector beside standard micro-USB pins,
has pins dedicated to route MHL traffic.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Rob Herring 
---
v4:
- removed description of property inherited from usb-connector (Rob),
- fixed example description.
---
 .../connector/samsung,usb-connector-11pin.txt  | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt

diff --git 
a/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
new file mode 100644
index ..22256e295a7a
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
@@ -0,0 +1,49 @@
+Samsung micro-USB 11-pin connector
+==
+
+Samsung micro-USB 11-pin connector is an extension of micro-USB connector.
+It is present in multiple Samsung mobile devices.
+It has additional pins to route MHL traffic simultanously with USB.
+
+The bindings are superset of usb-connector bindings for micro-USB connector[1].
+
+Required properties:
+- compatible: must be: "samsung,usb-connector-11pin", "usb-b-connector",
+- type: must be "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS),
+3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB.
+
+[1]: bindings/connector/usb-connector.txt
+
+Example
+---
+
+Micro-USB connector with HS lines routed via controller (MUIC) and MHL lines
+connected to HDMI-MHL bridge (sii8620):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "samsung,usb-connector-11pin", "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   usb_con_mhl: endpoint {
+   remote-endpoint = <_mhl>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.2

[PATCH v5 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector

[Andrzej Hajda]

Samsung micro-USB 11-pin connector beside standard micro-USB pins,
has pins dedicated to route MHL traffic.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Rob Herring 
---
v4:
- removed description of property inherited from usb-connector (Rob),
- fixed example description.
---
 .../connector/samsung,usb-connector-11pin.txt  | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt

diff --git 
a/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
new file mode 100644
index ..22256e295a7a
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
@@ -0,0 +1,49 @@
+Samsung micro-USB 11-pin connector
+==
+
+Samsung micro-USB 11-pin connector is an extension of micro-USB connector.
+It is present in multiple Samsung mobile devices.
+It has additional pins to route MHL traffic simultanously with USB.
+
+The bindings are superset of usb-connector bindings for micro-USB connector[1].
+
+Required properties:
+- compatible: must be: "samsung,usb-connector-11pin", "usb-b-connector",
+- type: must be "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS),
+3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB.
+
+[1]: bindings/connector/usb-connector.txt
+
+Example
+---
+
+Micro-USB connector with HS lines routed via controller (MUIC) and MHL lines
+connected to HDMI-MHL bridge (sii8620):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "samsung,usb-connector-11pin", "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   usb_con_mhl: endpoint {
+   remote-endpoint = <_mhl>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.2

Re: [OMPI devel] [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

[Mike Rapoport]

On Mon, Feb 26, 2018 at 09:38:19AM -0700, Nathan Hjelm wrote:
> All MPI implementations have support for using CMA to transfer data
> between local processes. The performance is fairly good (not as good as
> XPMEM) but the interface limits what we can do with to remote process
> memory (no atomics). I have not heard about this new proposal. What is
> the benefit of the proposed calls over the existing calls?

The proposed system call call that combines functionality of
process_vm_read and vmsplice [1] and it's particularly useful when one
needs to read the remote process memory and then write it to a file
descriptor. In this case a sequence of process_vm_read() + write() calls
that involves two copies of data can be replaced with process_vm_splice() +
splice() which does not involve copy at all.

[1] https://lkml.org/lkml/2018/1/9/32
 
> -Nathan
> 
> > On Feb 26, 2018, at 2:02 AM, Pavel Emelyanov  wrote:
> > 
> > On 02/21/2018 03:44 AM, Andrew Morton wrote:
> >> On Tue,  9 Jan 2018 08:30:49 +0200 Mike Rapoport  
> >> wrote:
> >> 
> >>> This patches introduces new process_vmsplice system call that combines
> >>> functionality of process_vm_read and vmsplice.
> >> 
> >> All seems fairly strightforward.  The big question is: do we know that
> >> people will actually use this, and get sufficient value from it to
> >> justify its addition?
> > 
> > Yes, that's what bothers us a lot too :) I've tried to start with finding 
> > out if anyone
> > used the sys_read/write_process_vm() calls, but failed :( Does anybody know 
> > how popular
> > these syscalls are? If its users operate on big amount of memory, they 
> > could benefit from
> > the proposed splice extension.
> > 
> > -- Pavel

-- 
Sincerely yours,
Mike.

Re: [OMPI devel] [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

[Mike Rapoport]

On Mon, Feb 26, 2018 at 09:38:19AM -0700, Nathan Hjelm wrote:
> All MPI implementations have support for using CMA to transfer data
> between local processes. The performance is fairly good (not as good as
> XPMEM) but the interface limits what we can do with to remote process
> memory (no atomics). I have not heard about this new proposal. What is
> the benefit of the proposed calls over the existing calls?

The proposed system call call that combines functionality of
process_vm_read and vmsplice [1] and it's particularly useful when one
needs to read the remote process memory and then write it to a file
descriptor. In this case a sequence of process_vm_read() + write() calls
that involves two copies of data can be replaced with process_vm_splice() +
splice() which does not involve copy at all.

[1] https://lkml.org/lkml/2018/1/9/32
 
> -Nathan
> 
> > On Feb 26, 2018, at 2:02 AM, Pavel Emelyanov  wrote:
> > 
> > On 02/21/2018 03:44 AM, Andrew Morton wrote:
> >> On Tue,  9 Jan 2018 08:30:49 +0200 Mike Rapoport  
> >> wrote:
> >> 
> >>> This patches introduces new process_vmsplice system call that combines
> >>> functionality of process_vm_read and vmsplice.
> >> 
> >> All seems fairly strightforward.  The big question is: do we know that
> >> people will actually use this, and get sufficient value from it to
> >> justify its addition?
> > 
> > Yes, that's what bothers us a lot too :) I've tried to start with finding 
> > out if anyone
> > used the sys_read/write_process_vm() calls, but failed :( Does anybody know 
> > how popular
> > these syscalls are? If its users operate on big amount of memory, they 
> > could benefit from
> > the proposed splice extension.
> > 
> > -- Pavel

-- 
Sincerely yours,
Mike.

Re: [PATCH 4.14 00/54] 4.14.23-stable review

[Naresh Kamboju]

On 27 February 2018 at 01:51, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.23 release.
> There are 54 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:21:22 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.23-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.14.23-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 5e118d0b219c87128794e0734ec357f68d2846cb
git describe: v4.14.22-55-g5e118d0b219c
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.22-55-g5e118d0b219c


No regressions (compared to build v4.14.22)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 48, skip: 17
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 48, skip: 17
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 45, skip: 19
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 61, skip: 19
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1

--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 4.14 00/54] 4.14.23-stable review

[Naresh Kamboju]

On 27 February 2018 at 01:51, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.23 release.
> There are 54 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:21:22 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.23-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.14.23-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 5e118d0b219c87128794e0734ec357f68d2846cb
git describe: v4.14.22-55-g5e118d0b219c
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.22-55-g5e118d0b219c


No regressions (compared to build v4.14.22)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 48, skip: 17
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 48, skip: 17
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 45, skip: 19
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 61, skip: 19
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1

--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

[Maxime Ripard]

On Tue, Feb 27, 2018 at 01:29:27PM +1100, Julian Calaby wrote:
> Hi Jernej,
> 
> On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec  
> wrote:
> > Hi,
> >
> > Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng 
> > napisal(a):
> >> 于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec"
> >  写到:
> >> >Hi Julian,
> >> >
> >> >Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby
> >> >
> >> >napisal(a):
> >> >> Hi Jernej,
> >> >>
> >> >> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
> >> >
> >> >
> >> >
> >> >wrote:
> >> >> > Enable HDMI output on all boards which have HDMI connector.
> >> >> >
> >> >> > Signed-off-by: Jernej Skrabec 
> >> >> > ---
> >> >> >
> >> >> >  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25
> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> >> >> >
> >> >> >   | 25 ++
> >> >> >
> >> >> >  arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25
> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> >> >> >
> >> >> >   | 25 ++
> >> >
> >> >arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> >> >
> >> >> > | 25 ++
> >> >> >
> >> >> >  arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   | 25
> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> >> >> >
> >> >> >   | 24 +
> >> >
> >> >arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> >> >
> >> >> >| 25 ++ 8 files changed, 199
> >> >
> >> >insertions(+)
> >> >
> >> >> As I understand it, the H2+ is just a slightly trimmed down H3. In
> >> >> terms of HDMI support, the difference is that the H2+ can't output
> >> >
> >> >4k.
> >> >
> >> >> If this code is compatible with the H2+, could you please add the
> >> >> necessary bits and pieces to the h2-plus DTSs too?
> >> >
> >> >There are only 3 H2+ boards in kernel and none of them has HDMI
> >> >connector, so
> >>
> >> BPi M2 Zero has miniHDMI connector.
> >
> > Ah, sorry, I missed that one. Since I don't have it (or any other board with
> > H2+) I'm not really comfortable including such patch. If anyone will test 
> > it,
> > I can include it in next revision.
> 
> I have one of those (this is why I'm interested in this patchset) so
> I'm willing to test, however I can't guarantee I'll get to it quickly.

Then I guess the best way forward will be to keep the current patch as
is, and you'll send a patch whenever you have the time to test it.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

[Maxime Ripard]

On Tue, Feb 27, 2018 at 01:29:27PM +1100, Julian Calaby wrote:
> Hi Jernej,
> 
> On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec  
> wrote:
> > Hi,
> >
> > Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng 
> > napisal(a):
> >> 于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec"
> >  写到:
> >> >Hi Julian,
> >> >
> >> >Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby
> >> >
> >> >napisal(a):
> >> >> Hi Jernej,
> >> >>
> >> >> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
> >> >
> >> >
> >> >
> >> >wrote:
> >> >> > Enable HDMI output on all boards which have HDMI connector.
> >> >> >
> >> >> > Signed-off-by: Jernej Skrabec 
> >> >> > ---
> >> >> >
> >> >> >  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25
> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> >> >> >
> >> >> >   | 25 ++
> >> >> >
> >> >> >  arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25
> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> >> >> >
> >> >> >   | 25 ++
> >> >
> >> >arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> >> >
> >> >> > | 25 ++
> >> >> >
> >> >> >  arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   | 25
> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> >> >> >
> >> >> >   | 24 +
> >> >
> >> >arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> >> >
> >> >> >| 25 ++ 8 files changed, 199
> >> >
> >> >insertions(+)
> >> >
> >> >> As I understand it, the H2+ is just a slightly trimmed down H3. In
> >> >> terms of HDMI support, the difference is that the H2+ can't output
> >> >
> >> >4k.
> >> >
> >> >> If this code is compatible with the H2+, could you please add the
> >> >> necessary bits and pieces to the h2-plus DTSs too?
> >> >
> >> >There are only 3 H2+ boards in kernel and none of them has HDMI
> >> >connector, so
> >>
> >> BPi M2 Zero has miniHDMI connector.
> >
> > Ah, sorry, I missed that one. Since I don't have it (or any other board with
> > H2+) I'm not really comfortable including such patch. If anyone will test 
> > it,
> > I can include it in next revision.
> 
> I have one of those (this is why I'm interested in this patchset) so
> I'm willing to test, however I can't guarantee I'll get to it quickly.

Then I guess the best way forward will be to keep the current patch as
is, and you'll send a patch whenever you have the time to test it.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 4.15 00/64] 4.15.7-stable review

[Naresh Kamboju]

On 27 February 2018 at 01:51, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.15.7 release.
> There are 64 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:21:30 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.7-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.15.7-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: 3d453a1a75bc48e16e118a9c08fec19c5b93ca59
git describe: v4.15.6-65-g3d453a1a75bc
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.6-65-g3d453a1a75bc


No regressions (compared to build v4.15.6)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 57, skip: 9
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 56, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 53, skip: 12
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, skip: 18
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 71, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1

Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 4.15 00/64] 4.15.7-stable review

[Naresh Kamboju]

On 27 February 2018 at 01:51, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.15.7 release.
> There are 64 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 28 20:21:30 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.7-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.15.7-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: 3d453a1a75bc48e16e118a9c08fec19c5b93ca59
git describe: v4.15.6-65-g3d453a1a75bc
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.6-65-g3d453a1a75bc


No regressions (compared to build v4.15.6)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 57, skip: 9
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 56, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 53, skip: 12
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, skip: 18
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 71, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1

Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

On 26.02.2018 16:21, Krzysztof Kozlowski wrote:
> On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda  wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> v4:
>> - added missing reg property in connector's port node (Krzysztof)
>> ---
>>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 32 
>> --
>>  1 file changed, 29 insertions(+), 3 deletions(-)
> You have a duplicated '};' so kbuild complains so I assume there will
> be next iteration of this. Beside that I am okay with both, so I will
> take next version when your bindings and driver changes get
> acked/accepted.

Yes, test robot already reported it, thanks for looking at it.
I have postponed next iteration in case anything new is spotted, but
since it is calm I will send it in few minutes.

Regards
Andrzej

>
> Best Regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

On 26.02.2018 16:21, Krzysztof Kozlowski wrote:
> On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda  wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> v4:
>> - added missing reg property in connector's port node (Krzysztof)
>> ---
>>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 32 
>> --
>>  1 file changed, 29 insertions(+), 3 deletions(-)
> You have a duplicated '};' so kbuild complains so I assume there will
> be next iteration of this. Beside that I am okay with both, so I will
> take next version when your bindings and driver changes get
> acked/accepted.

Yes, test robot already reported it, thanks for looking at it.
I have postponed next iteration in case anything new is spotted, but
since it is calm I will send it in few minutes.

Regards
Andrzej

>
> Best Regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

[Johan Hovold]

On Mon, Feb 12, 2018 at 04:26:18PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > Let's restart this discussion and focus on the main roadblock (others
> > > are minor details which can be sorted out later).
> > > 
> > > If it feels like a hack, the key issue seems to me to be the choice of
> > > the API to present the GPS data to user space. Right?
> > 
> > Or even more fundamentally, does this belong in the kernel at all?
> 
> Yes, it does.

But not necessarily in its current form.

> > Now, if we'd ever have a proper GPS framework that handled everything in
> > kernel space (i.e. no more gpsd) then we would be able to write kernel
> > drivers that also take care of PM. But perhaps that's unlikely to ever
> > be realised given the state of things (proprietary protocols, numerous
> > quirky implementations, etc).
> 
> That is what needs to happen.
> 
> > The kernel is probably not the place to be working around issues like
> > that, even if serdev at least allows for such hacks to be fairly
> > isolated in drivers (unlike some of the earlier proposals touching core
> > code).
> 
> Oh, kernel is indeed right place to provide hardware abstraction --
> and that includes bug workarounds.

Right, at least when such hacks can be confined to a driver and not be
spread all over the place.

Johan

Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

[Johan Hovold]

On Mon, Feb 12, 2018 at 04:26:18PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > Let's restart this discussion and focus on the main roadblock (others
> > > are minor details which can be sorted out later).
> > > 
> > > If it feels like a hack, the key issue seems to me to be the choice of
> > > the API to present the GPS data to user space. Right?
> > 
> > Or even more fundamentally, does this belong in the kernel at all?
> 
> Yes, it does.

But not necessarily in its current form.

> > Now, if we'd ever have a proper GPS framework that handled everything in
> > kernel space (i.e. no more gpsd) then we would be able to write kernel
> > drivers that also take care of PM. But perhaps that's unlikely to ever
> > be realised given the state of things (proprietary protocols, numerous
> > quirky implementations, etc).
> 
> That is what needs to happen.
> 
> > The kernel is probably not the place to be working around issues like
> > that, even if serdev at least allows for such hacks to be fairly
> > isolated in drivers (unlike some of the earlier proposals touching core
> > code).
> 
> Oh, kernel is indeed right place to provide hardware abstraction --
> and that includes bug workarounds.

Right, at least when such hacks can be confined to a driver and not be
spread all over the place.

Johan

Re: [v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains

[Ingo Molnar]

* Pavel Tatashin  wrote:

> Juergen Gross noticed that commit
> f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap")
> broke XEN PV domains when deferred struct page initialization is enabled.
> 
> This is because the xen's PagePinned() flag is getting erased from struct
> pages when they are initialized later in boot.
> 
> Juergen fixed this problem by disabling deferred pages on xen pv domains.
> It is desirable, however, to have this feature available as it reduces boot
> time. This fix re-enables the feature for pv-dmains, and fixes the problem
> the following way:
> 
> The fix is to delay setting PagePinned flag until struct pages for all
> allocated memory are initialized, i.e. until after free_all_bootmem().
> 
> A new x86_init.hyper op init_after_bootmem() is called to let xen know
> that boot allocator is done, and hence struct pages for all the allocated
> memory are now initialized. If deferred page initialization is enabled, the
> rest of struct pages are going to be initialized later in boot once
> page_alloc_init_late() is called.
> 
> xen_after_bootmem() walks page table's pages and marks them pinned.
> 
> Signed-off-by: Pavel Tatashin 
> ---
>  arch/x86/include/asm/x86_init.h |  2 ++
>  arch/x86/kernel/x86_init.c  |  1 +
>  arch/x86/mm/init_32.c   |  1 +
>  arch/x86/mm/init_64.c   |  1 +
>  arch/x86/xen/mmu_pv.c   | 38 ++
>  mm/page_alloc.c |  4 
>  6 files changed, 31 insertions(+), 16 deletions(-)

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains

[Ingo Molnar]

* Pavel Tatashin  wrote:

> Juergen Gross noticed that commit
> f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap")
> broke XEN PV domains when deferred struct page initialization is enabled.
> 
> This is because the xen's PagePinned() flag is getting erased from struct
> pages when they are initialized later in boot.
> 
> Juergen fixed this problem by disabling deferred pages on xen pv domains.
> It is desirable, however, to have this feature available as it reduces boot
> time. This fix re-enables the feature for pv-dmains, and fixes the problem
> the following way:
> 
> The fix is to delay setting PagePinned flag until struct pages for all
> allocated memory are initialized, i.e. until after free_all_bootmem().
> 
> A new x86_init.hyper op init_after_bootmem() is called to let xen know
> that boot allocator is done, and hence struct pages for all the allocated
> memory are now initialized. If deferred page initialization is enabled, the
> rest of struct pages are going to be initialized later in boot once
> page_alloc_init_late() is called.
> 
> xen_after_bootmem() walks page table's pages and marks them pinned.
> 
> Signed-off-by: Pavel Tatashin 
> ---
>  arch/x86/include/asm/x86_init.h |  2 ++
>  arch/x86/kernel/x86_init.c  |  1 +
>  arch/x86/mm/init_32.c   |  1 +
>  arch/x86/mm/init_64.c   |  1 +
>  arch/x86/xen/mmu_pv.c   | 38 ++
>  mm/page_alloc.c |  4 
>  6 files changed, 31 insertions(+), 16 deletions(-)

Acked-by: Ingo Molnar 

Thanks,

Ingo

[PATCH] KVM/X86: Check input sreg values before loading vcpu

[Tianyu Lan]

From: Lan Tianyu 

This patch is to check sreg value first and then load vcpu in order
to avoid redundant loading/putting vcpu.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/x86.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c8a0b54..46da9ec 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7671,6 +7671,10 @@ EXPORT_SYMBOL_GPL(kvm_task_switch);
 
 int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
 {
+   if (!guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) &&
+   (sregs->cr4 & X86_CR4_OSXSAVE))
+   return -EINVAL;
+
if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG)) {
/*
 * When EFER.LME and CR0.PG are set, the processor is in
@@ -7701,14 +7705,10 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
struct desc_ptr dt;
int ret = -EINVAL;
 
-   vcpu_load(vcpu);
-
-   if (!guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) &&
-   (sregs->cr4 & X86_CR4_OSXSAVE))
-   goto out;
-
if (kvm_valid_sregs(vcpu, sregs))
-   goto out;
+   return ret;
+
+   vcpu_load(vcpu);
 
apic_base_msr.data = sregs->apic_base;
apic_base_msr.host_initiated = true;
-- 
2.7.4

[PATCH] KVM/X86: Check input sreg values before loading vcpu

[Tianyu Lan]

From: Lan Tianyu 

This patch is to check sreg value first and then load vcpu in order
to avoid redundant loading/putting vcpu.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/x86.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c8a0b54..46da9ec 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7671,6 +7671,10 @@ EXPORT_SYMBOL_GPL(kvm_task_switch);
 
 int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
 {
+   if (!guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) &&
+   (sregs->cr4 & X86_CR4_OSXSAVE))
+   return -EINVAL;
+
if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG)) {
/*
 * When EFER.LME and CR0.PG are set, the processor is in
@@ -7701,14 +7705,10 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
struct desc_ptr dt;
int ret = -EINVAL;
 
-   vcpu_load(vcpu);
-
-   if (!guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) &&
-   (sregs->cr4 & X86_CR4_OSXSAVE))
-   goto out;
-
if (kvm_valid_sregs(vcpu, sregs))
-   goto out;
+   return ret;
+
+   vcpu_load(vcpu);
 
apic_base_msr.data = sregs->apic_base;
apic_base_msr.host_initiated = true;
-- 
2.7.4

[PATCH] init/Kconfig: make CHECKPOINT_RESTORE select PROC_PAGE_MONITOR

[Mike Rapoport]

Checkpointing a process requires knowledge about the process memory layout
which is obtained from /proc//smaps, /proc//pagemap etc.
Make sure these interfaces are available only when
CONFIG_CHECKPOINT_RESTORE=y

Signed-off-by: Mike Rapoport 
---
 init/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/init/Kconfig b/init/Kconfig
index e37f4b2a6445..63c1fd5bc360 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1328,6 +1328,7 @@ config MEMBARRIER
 config CHECKPOINT_RESTORE
bool "Checkpoint/restore support" if EXPERT
select PROC_CHILDREN
+   select PROC_PAGE_MONITOR
default n
help
  Enables additional kernel features in a sake of checkpoint/restore.
-- 
2.7.4

[PATCH] init/Kconfig: make CHECKPOINT_RESTORE select PROC_PAGE_MONITOR

[Mike Rapoport]

Checkpointing a process requires knowledge about the process memory layout
which is obtained from /proc//smaps, /proc//pagemap etc.
Make sure these interfaces are available only when
CONFIG_CHECKPOINT_RESTORE=y

Signed-off-by: Mike Rapoport 
---
 init/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/init/Kconfig b/init/Kconfig
index e37f4b2a6445..63c1fd5bc360 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1328,6 +1328,7 @@ config MEMBARRIER
 config CHECKPOINT_RESTORE
bool "Checkpoint/restore support" if EXPERT
select PROC_CHILDREN
+   select PROC_PAGE_MONITOR
default n
help
  Enables additional kernel features in a sake of checkpoint/restore.
-- 
2.7.4

Re: [PATCH] perf top: Fix annoying fallback message on older kernel

[Ingo Molnar]

* kan.li...@intel.com  wrote:

> From: Kan Liang 
> 
> On older (v4.4) kernels, the annoying fallback message can be observed
> in 'perf top'.
> 
> The 'perf top' has been changed to overwrite mode since
> 'commit ebebbf082357 ("perf top: Switch default mode to overwrite mode")'
> For the older kernels which don't have overwrite mode support, the 'perf
> top' will fall back to non-overwrite mode and print out the fallback
> message by ui__warning, which needs user's input to close.
> 
> The fallback message is not critical message for end users. Turning it
> to debug message which is printed when running with -vv.
> 
> Fixes: ebebbf082357 ("perf top: Switch default mode to overwrite mode")
> Reported-by: Ingo Molnar 
> Signed-off-by: Kan Liang 
> ---
>  tools/perf/builtin-top.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> index b7c823b..35ac016 100644
> --- a/tools/perf/builtin-top.c
> +++ b/tools/perf/builtin-top.c
> @@ -991,7 +991,7 @@ static int perf_top_overwrite_fallback(struct perf_top 
> *top,
>   evlist__for_each_entry(evlist, counter)
>   counter->attr.write_backward = false;
>   opts->overwrite = false;
> - ui__warning("fall back to non-overwrite mode\n");
> + pr_debug2("fall back to non-overwrite mode\n");
>   return 1;
>  }

Thanks!

Ingo

Re: [PATCH] perf top: Fix annoying fallback message on older kernel

[Ingo Molnar]

* kan.li...@intel.com  wrote:

> From: Kan Liang 
> 
> On older (v4.4) kernels, the annoying fallback message can be observed
> in 'perf top'.
> 
> The 'perf top' has been changed to overwrite mode since
> 'commit ebebbf082357 ("perf top: Switch default mode to overwrite mode")'
> For the older kernels which don't have overwrite mode support, the 'perf
> top' will fall back to non-overwrite mode and print out the fallback
> message by ui__warning, which needs user's input to close.
> 
> The fallback message is not critical message for end users. Turning it
> to debug message which is printed when running with -vv.
> 
> Fixes: ebebbf082357 ("perf top: Switch default mode to overwrite mode")
> Reported-by: Ingo Molnar 
> Signed-off-by: Kan Liang 
> ---
>  tools/perf/builtin-top.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> index b7c823b..35ac016 100644
> --- a/tools/perf/builtin-top.c
> +++ b/tools/perf/builtin-top.c
> @@ -991,7 +991,7 @@ static int perf_top_overwrite_fallback(struct perf_top 
> *top,
>   evlist__for_each_entry(evlist, counter)
>   counter->attr.write_backward = false;
>   opts->overwrite = false;
> - ui__warning("fall back to non-overwrite mode\n");
> + pr_debug2("fall back to non-overwrite mode\n");
>   return 1;
>  }

Thanks!

Ingo

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

[Oleksandr Andrushchenko]

On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:

On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:

On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+static struct xen_gem_object *gem_create(struct drm_device *dev,
size_t size)
+{
+struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+struct xen_gem_object *xen_obj;
+int ret;
+
+size = round_up(size, PAGE_SIZE);
+xen_obj = gem_create_obj(dev, size);
+if (IS_ERR_OR_NULL(xen_obj))
+return xen_obj;
+
+if (drm_info->cfg->be_alloc) {
+/*
+ * backend will allocate space for this buffer, so
+ * only allocate array of pointers to pages
+ */
+xen_obj->be_alloc = true;

If be_alloc is a flag (which I am not sure about) --- should it be set
to true *after* you've successfully allocated your things?

this is a configuration option telling about the way
the buffer gets allocated: either by the frontend or
backend (be_alloc -> buffer allocated by the backend)


I can see how drm_info->cfg->be_alloc might be a configuration option
but xen_obj->be_alloc is set here and that's not how configuration
options typically behave.

you are right, I will put be_alloc down the code and will slightly
rework error handling for this function



+ret = gem_alloc_pages_array(xen_obj, size);
+if (ret < 0) {
+gem_free_pages_array(xen_obj);
+goto fail;
+}
+
+ret = alloc_xenballooned_pages(xen_obj->num_pages,
+xen_obj->pages);

Why are you allocating balloon pages?

in this use-case we map pages provided by the backend
(yes, I know this can be a problem from both security
POV and that DomU can die holding pages of Dom0 forever:
but still it is a configuration option, so user decides
if her use-case needs this and takes responsibility for
such a decision).


Perhaps I am missing something here but when you say "I know this can be
a problem from both security POV ..." then there is something wrong with
your solution.

well, in this scenario there are actually 2 concerns:
1. If DomU dies the pages/grants from Dom0/DomD cannot be
reclaimed back
2. Misbehaving guest may send too many requests to the
backend exhausting grant references and memory of Dom0/DomD
(this is the only concern from security POV). Please see [1]

But, we are focusing on embedded use-cases,
so those systems we use are not that "dynamic" with respect to 2).
Namely: we have fixed number of domains and their functionality
is well known, so we can do rather precise assumption on resource
usage. This is why I try to warn on such a use-case and rely on
the end user who understands the caveats

I'll probably add more precise description of this use-case
clarifying what is that security POV, so there is no confusion

Hope this explanation answers your questions

-boris


Please see description of the buffering modes in xen_drm_front.h
specifically for backend allocated buffers:
  
***

  * 2. Buffers allocated by the backend
  
***

  *
  * This mode of operation is run-time configured via guest domain
configuration
  * through XenStore entries.
  *
  * For systems which do not provide IOMMU support, but having specific
  * requirements for display buffers it is possible to allocate such
buffers
  * at backend side and share those with the frontend.
  * For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting
  * physically contiguous memory, this allows implementing zero-copying
  * use-cases.


-boris


+if (ret < 0) {
+DRM_ERROR("Cannot allocate %zu ballooned pages: %d\n",
+xen_obj->num_pages, ret);
+goto fail;
+}
+
+return xen_obj;
+}
+/*
+ * need to allocate backing pages now, so we can share those
+ * with the backend
+ */
+xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
+xen_obj->pages = drm_gem_get_pages(_obj->base);
+if (IS_ERR_OR_NULL(xen_obj->pages)) {
+ret = PTR_ERR(xen_obj->pages);
+xen_obj->pages = NULL;
+goto fail;
+}
+
+return xen_obj;
+
+fail:
+DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
+return ERR_PTR(ret);
+}
+


Thank you,
Oleksandr

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03100.html

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

[Oleksandr Andrushchenko]

On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:

On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:

On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+static struct xen_gem_object *gem_create(struct drm_device *dev,
size_t size)
+{
+struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+struct xen_gem_object *xen_obj;
+int ret;
+
+size = round_up(size, PAGE_SIZE);
+xen_obj = gem_create_obj(dev, size);
+if (IS_ERR_OR_NULL(xen_obj))
+return xen_obj;
+
+if (drm_info->cfg->be_alloc) {
+/*
+ * backend will allocate space for this buffer, so
+ * only allocate array of pointers to pages
+ */
+xen_obj->be_alloc = true;

If be_alloc is a flag (which I am not sure about) --- should it be set
to true *after* you've successfully allocated your things?

this is a configuration option telling about the way
the buffer gets allocated: either by the frontend or
backend (be_alloc -> buffer allocated by the backend)


I can see how drm_info->cfg->be_alloc might be a configuration option
but xen_obj->be_alloc is set here and that's not how configuration
options typically behave.

you are right, I will put be_alloc down the code and will slightly
rework error handling for this function



+ret = gem_alloc_pages_array(xen_obj, size);
+if (ret < 0) {
+gem_free_pages_array(xen_obj);
+goto fail;
+}
+
+ret = alloc_xenballooned_pages(xen_obj->num_pages,
+xen_obj->pages);

Why are you allocating balloon pages?

in this use-case we map pages provided by the backend
(yes, I know this can be a problem from both security
POV and that DomU can die holding pages of Dom0 forever:
but still it is a configuration option, so user decides
if her use-case needs this and takes responsibility for
such a decision).


Perhaps I am missing something here but when you say "I know this can be
a problem from both security POV ..." then there is something wrong with
your solution.

well, in this scenario there are actually 2 concerns:
1. If DomU dies the pages/grants from Dom0/DomD cannot be
reclaimed back
2. Misbehaving guest may send too many requests to the
backend exhausting grant references and memory of Dom0/DomD
(this is the only concern from security POV). Please see [1]

But, we are focusing on embedded use-cases,
so those systems we use are not that "dynamic" with respect to 2).
Namely: we have fixed number of domains and their functionality
is well known, so we can do rather precise assumption on resource
usage. This is why I try to warn on such a use-case and rely on
the end user who understands the caveats

I'll probably add more precise description of this use-case
clarifying what is that security POV, so there is no confusion

Hope this explanation answers your questions

-boris


Please see description of the buffering modes in xen_drm_front.h
specifically for backend allocated buffers:
  
***

  * 2. Buffers allocated by the backend
  
***

  *
  * This mode of operation is run-time configured via guest domain
configuration
  * through XenStore entries.
  *
  * For systems which do not provide IOMMU support, but having specific
  * requirements for display buffers it is possible to allocate such
buffers
  * at backend side and share those with the frontend.
  * For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting
  * physically contiguous memory, this allows implementing zero-copying
  * use-cases.


-boris


+if (ret < 0) {
+DRM_ERROR("Cannot allocate %zu ballooned pages: %d\n",
+xen_obj->num_pages, ret);
+goto fail;
+}
+
+return xen_obj;
+}
+/*
+ * need to allocate backing pages now, so we can share those
+ * with the backend
+ */
+xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
+xen_obj->pages = drm_gem_get_pages(_obj->base);
+if (IS_ERR_OR_NULL(xen_obj->pages)) {
+ret = PTR_ERR(xen_obj->pages);
+xen_obj->pages = NULL;
+goto fail;
+}
+
+return xen_obj;
+
+fail:
+DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
+return ERR_PTR(ret);
+}
+


Thank you,
Oleksandr

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03100.html

Re: [PATCH] Revert "mfd: cros_ec: Add ACPI GPE handler for LID0 devices"

[Benson Leung]

On Thu, Feb 22, 2018 at 01:30:52PM -0800, Wenkai Du wrote:
> This reverts commit e04653a9dcf4d98defe2149c885382e5cc72082f.
> 
> It is no longer needed to install Chrome EC GPE handler to have
> GPE enabled in suspend to idle path. It is found that with this
> handler installed, EC wake up doesn't work because default EC
> event handler that can wake up system is not getting called.
> 
> Signed-off-by: Wenkai Du 

Acked-by: Benson Leung 

> ---
>  drivers/mfd/Makefile   |   1 -
>  drivers/mfd/cros_ec.c  |  15 ++
>  drivers/mfd/cros_ec_acpi_gpe.c | 103 
> -
>  include/linux/mfd/cros_ec.h|  18 ---
>  4 files changed, 3 insertions(+), 134 deletions(-)
>  delete mode 100644 drivers/mfd/cros_ec_acpi_gpe.c
> 
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index d9d2cf0d32ef..e9fd20dba18d 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -13,7 +13,6 @@ obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o
>  obj-$(CONFIG_MFD_BCM590XX)   += bcm590xx.o
>  obj-$(CONFIG_MFD_BD9571MWV)  += bd9571mwv.o
>  cros_ec_core-objs:= cros_ec.o
> -cros_ec_core-$(CONFIG_ACPI)  += cros_ec_acpi_gpe.o
>  obj-$(CONFIG_MFD_CROS_EC)+= cros_ec_core.o
>  obj-$(CONFIG_MFD_CROS_EC_I2C)+= cros_ec_i2c.o
>  obj-$(CONFIG_MFD_CROS_EC_SPI)+= cros_ec_spi.o
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index d61024141e2b..c221163d5b9e 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -173,8 +173,6 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>  
>   dev_info(dev, "Chrome EC device registered\n");
>  
> - cros_ec_acpi_install_gpe_handler(dev);
> -
>   return 0;
>  
>  fail_mfd:
> @@ -188,8 +186,6 @@ int cros_ec_remove(struct cros_ec_device *ec_dev)
>  {
>   mfd_remove_devices(ec_dev->dev);
>  
> - cros_ec_acpi_remove_gpe_handler();
> -
>   if (ec_dev->irq)
>   free_irq(ec_dev->irq, ec_dev);
>  
> @@ -204,14 +200,9 @@ int cros_ec_suspend(struct cros_ec_device *ec_dev)
>   int ret;
>   u8 sleep_event;
>  
> - if (!IS_ENABLED(CONFIG_ACPI) || pm_suspend_via_firmware()) {
> - sleep_event = HOST_SLEEP_EVENT_S3_SUSPEND;
> - } else {
> - sleep_event = HOST_SLEEP_EVENT_S0IX_SUSPEND;
> -
> - /* Clearing the GPE status for any pending event */
> - cros_ec_acpi_clear_gpe();
> - }
> + sleep_event = (!IS_ENABLED(CONFIG_ACPI) || pm_suspend_via_firmware()) ?
> +   HOST_SLEEP_EVENT_S3_SUSPEND :
> +   HOST_SLEEP_EVENT_S0IX_SUSPEND;
>  
>   ret = cros_ec_sleep_event(ec_dev, sleep_event);
>   if (ret < 0)
> diff --git a/drivers/mfd/cros_ec_acpi_gpe.c b/drivers/mfd/cros_ec_acpi_gpe.c
> deleted file mode 100644
> index 56d305dab2d4..
> --- a/drivers/mfd/cros_ec_acpi_gpe.c
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -/*
> - * ChromeOS EC multi-function device
> - *
> - * Copyright (C) 2017 Google, Inc
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * The ChromeOS EC multi function device is used to mux all the requests
> - * to the EC device for its multiple features: keyboard controller,
> - * battery charging and regulator control, firmware update.
> - */
> -#include 
> -
> -#define ACPI_LID_DEVICE  "LID0"
> -
> -static int ec_wake_gpe = -EINVAL;
> -
> -/*
> - * This handler indicates to ACPI core that this GPE should stay enabled for
> - * lid to work in suspend to idle path.
> - */
> -static u32 cros_ec_gpe_handler(acpi_handle gpe_device, u32 gpe_number,
> -void *data)
> -{
> - return ACPI_INTERRUPT_HANDLED | ACPI_REENABLE_GPE;
> -}
> -
> -/*
> - * Get ACPI GPE for LID0 device.
> - */
> -static int cros_ec_get_ec_wake_gpe(struct device *dev)
> -{
> - struct acpi_device *cros_acpi_dev;
> - struct acpi_device *adev;
> - acpi_handle handle;
> - acpi_status status;
> - int ret;
> -
> - cros_acpi_dev = ACPI_COMPANION(dev);
> -
> - if (!cros_acpi_dev || !cros_acpi_dev->parent ||
> -!cros_acpi_dev->parent->handle)
> - return -EINVAL;
> -
> - status = acpi_get_handle(cros_acpi_dev->parent->handle, ACPI_LID_DEVICE,
> -  );
> - if (ACPI_FAILURE(status))
> - return -EINVAL;
> -
> - ret = acpi_bus_get_device(handle, );
> - if (ret)
> - return ret;
> -
> - return adev->wakeup.gpe_number;
> -}
> -
> -int 

Re: [PATCH] Revert "mfd: cros_ec: Add ACPI GPE handler for LID0 devices"

[Benson Leung]

On Thu, Feb 22, 2018 at 01:30:52PM -0800, Wenkai Du wrote:
> This reverts commit e04653a9dcf4d98defe2149c885382e5cc72082f.
> 
> It is no longer needed to install Chrome EC GPE handler to have
> GPE enabled in suspend to idle path. It is found that with this
> handler installed, EC wake up doesn't work because default EC
> event handler that can wake up system is not getting called.
> 
> Signed-off-by: Wenkai Du 

Acked-by: Benson Leung 

> ---
>  drivers/mfd/Makefile   |   1 -
>  drivers/mfd/cros_ec.c  |  15 ++
>  drivers/mfd/cros_ec_acpi_gpe.c | 103 
> -
>  include/linux/mfd/cros_ec.h|  18 ---
>  4 files changed, 3 insertions(+), 134 deletions(-)
>  delete mode 100644 drivers/mfd/cros_ec_acpi_gpe.c
> 
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index d9d2cf0d32ef..e9fd20dba18d 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -13,7 +13,6 @@ obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o
>  obj-$(CONFIG_MFD_BCM590XX)   += bcm590xx.o
>  obj-$(CONFIG_MFD_BD9571MWV)  += bd9571mwv.o
>  cros_ec_core-objs:= cros_ec.o
> -cros_ec_core-$(CONFIG_ACPI)  += cros_ec_acpi_gpe.o
>  obj-$(CONFIG_MFD_CROS_EC)+= cros_ec_core.o
>  obj-$(CONFIG_MFD_CROS_EC_I2C)+= cros_ec_i2c.o
>  obj-$(CONFIG_MFD_CROS_EC_SPI)+= cros_ec_spi.o
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index d61024141e2b..c221163d5b9e 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -173,8 +173,6 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>  
>   dev_info(dev, "Chrome EC device registered\n");
>  
> - cros_ec_acpi_install_gpe_handler(dev);
> -
>   return 0;
>  
>  fail_mfd:
> @@ -188,8 +186,6 @@ int cros_ec_remove(struct cros_ec_device *ec_dev)
>  {
>   mfd_remove_devices(ec_dev->dev);
>  
> - cros_ec_acpi_remove_gpe_handler();
> -
>   if (ec_dev->irq)
>   free_irq(ec_dev->irq, ec_dev);
>  
> @@ -204,14 +200,9 @@ int cros_ec_suspend(struct cros_ec_device *ec_dev)
>   int ret;
>   u8 sleep_event;
>  
> - if (!IS_ENABLED(CONFIG_ACPI) || pm_suspend_via_firmware()) {
> - sleep_event = HOST_SLEEP_EVENT_S3_SUSPEND;
> - } else {
> - sleep_event = HOST_SLEEP_EVENT_S0IX_SUSPEND;
> -
> - /* Clearing the GPE status for any pending event */
> - cros_ec_acpi_clear_gpe();
> - }
> + sleep_event = (!IS_ENABLED(CONFIG_ACPI) || pm_suspend_via_firmware()) ?
> +   HOST_SLEEP_EVENT_S3_SUSPEND :
> +   HOST_SLEEP_EVENT_S0IX_SUSPEND;
>  
>   ret = cros_ec_sleep_event(ec_dev, sleep_event);
>   if (ret < 0)
> diff --git a/drivers/mfd/cros_ec_acpi_gpe.c b/drivers/mfd/cros_ec_acpi_gpe.c
> deleted file mode 100644
> index 56d305dab2d4..
> --- a/drivers/mfd/cros_ec_acpi_gpe.c
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -/*
> - * ChromeOS EC multi-function device
> - *
> - * Copyright (C) 2017 Google, Inc
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * The ChromeOS EC multi function device is used to mux all the requests
> - * to the EC device for its multiple features: keyboard controller,
> - * battery charging and regulator control, firmware update.
> - */
> -#include 
> -
> -#define ACPI_LID_DEVICE  "LID0"
> -
> -static int ec_wake_gpe = -EINVAL;
> -
> -/*
> - * This handler indicates to ACPI core that this GPE should stay enabled for
> - * lid to work in suspend to idle path.
> - */
> -static u32 cros_ec_gpe_handler(acpi_handle gpe_device, u32 gpe_number,
> -void *data)
> -{
> - return ACPI_INTERRUPT_HANDLED | ACPI_REENABLE_GPE;
> -}
> -
> -/*
> - * Get ACPI GPE for LID0 device.
> - */
> -static int cros_ec_get_ec_wake_gpe(struct device *dev)
> -{
> - struct acpi_device *cros_acpi_dev;
> - struct acpi_device *adev;
> - acpi_handle handle;
> - acpi_status status;
> - int ret;
> -
> - cros_acpi_dev = ACPI_COMPANION(dev);
> -
> - if (!cros_acpi_dev || !cros_acpi_dev->parent ||
> -!cros_acpi_dev->parent->handle)
> - return -EINVAL;
> -
> - status = acpi_get_handle(cros_acpi_dev->parent->handle, ACPI_LID_DEVICE,
> -  );
> - if (ACPI_FAILURE(status))
> - return -EINVAL;
> -
> - ret = acpi_bus_get_device(handle, );
> - if (ret)
> - return ret;
> -
> - return adev->wakeup.gpe_number;
> -}
> -
> -int cros_ec_acpi_install_gpe_handler(struct device 

Re: [PATCH v3 3/8] mfd: cros_ec: Don't try to grab log when suspended

[Benson Leung]

Hi Enric,

Thanks for sending this.

On Mon, Feb 26, 2018 at 11:26:01AM +0100, Enric Balletbo i Serra wrote:
> From: Douglas Anderson 
> 
> We should stop our worker thread while we're suspended.  If we don't
> then we'll get messages like:
> 
>   cros-ec-spi spi5.0: spi transfer failed: -108
>   cros-ec-spi spi5.0: cs-deassert spi transfer failed: -108
>   cros-ec-ctl cros-ec-ctl.0.auto: EC communication failed
> 
> Signed-off-by: Douglas Anderson 
> Signed-off-by: Enric Balletbo i Serra 
> Reviewed-by: Andy Shevchenko 
> ---
> 
> Changes in v3:
> - [3/8] Add Reviewed-by Andy Shevchenko.
> 
> Changes in v2:
> - [3/8] That patch is new in this series.
> 
>  drivers/mfd/cros_ec_dev.c |  4 
>  drivers/platform/chrome/cros_ec_debugfs.c | 20 
>  include/linux/mfd/cros_ec.h   |  2 ++

Looks like this will need an immutable branch between mfd and chrome-platform
again, Lee.

Do you want to do one, or should I?

Thanks,
Benson


-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH v3 3/8] mfd: cros_ec: Don't try to grab log when suspended

[Benson Leung]

Hi Enric,

Thanks for sending this.

On Mon, Feb 26, 2018 at 11:26:01AM +0100, Enric Balletbo i Serra wrote:
> From: Douglas Anderson 
> 
> We should stop our worker thread while we're suspended.  If we don't
> then we'll get messages like:
> 
>   cros-ec-spi spi5.0: spi transfer failed: -108
>   cros-ec-spi spi5.0: cs-deassert spi transfer failed: -108
>   cros-ec-ctl cros-ec-ctl.0.auto: EC communication failed
> 
> Signed-off-by: Douglas Anderson 
> Signed-off-by: Enric Balletbo i Serra 
> Reviewed-by: Andy Shevchenko 
> ---
> 
> Changes in v3:
> - [3/8] Add Reviewed-by Andy Shevchenko.
> 
> Changes in v2:
> - [3/8] That patch is new in this series.
> 
>  drivers/mfd/cros_ec_dev.c |  4 
>  drivers/platform/chrome/cros_ec_debugfs.c | 20 
>  include/linux/mfd/cros_ec.h   |  2 ++

Looks like this will need an immutable branch between mfd and chrome-platform
again, Lee.

Do you want to do one, or should I?

Thanks,
Benson


-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH 0/7] drm/virtio: Checkpatch cleanup for virtio

[Gerd Hoffmann]

On Thu, Feb 22, 2018 at 08:59:33PM -0300, Rodrigo Siqueira wrote:
> This patchset fixes warnings and errors found by checkpatch.pl in the
> drm/virtio:

Added to drm-qemu queue, will land in drm-misc soon.

thanks,
  Gerd

Re: [PATCH 0/7] drm/virtio: Checkpatch cleanup for virtio

[Gerd Hoffmann]

On Thu, Feb 22, 2018 at 08:59:33PM -0300, Rodrigo Siqueira wrote:
> This patchset fixes warnings and errors found by checkpatch.pl in the
> drm/virtio:

Added to drm-qemu queue, will land in drm-misc soon.

thanks,
  Gerd

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

[Tobin C. Harding]

On Mon, Feb 26, 2018 at 10:09:31PM -0700, Tycho Andersen wrote:
> Hi Tobin,
> 
> On Tue, Feb 27, 2018 at 03:45:09PM +1100, Tobin C. Harding wrote:
> > When the system is idle it is likely that most files under /proc/PID
> > will be identical for various processes.  Scanning _all_ the PIDs under
> > /proc is unnecessary and implies that we are thoroughly scanning /proc.
> > This is _not_ the case because there may be ways userspace can trigger
> > creation of /proc files that leak addresses but were not present during
> > a scan.  For these two reasons we should exclude all PID directories
> > under /proc except '1/'
> > 
> > Exclude all /proc/PID except /proc/1.
> > 
> > Signed-off-by: Tobin C. Harding 
> > ---
> >  scripts/leaking_addresses.pl | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
> > index 6e5bc57caeaa..fb40e2828f43 100755
> > --- a/scripts/leaking_addresses.pl
> > +++ b/scripts/leaking_addresses.pl
> > @@ -10,6 +10,14 @@
> >  # Use --debug to output path before parsing, this is useful to find files 
> > that
> >  # cause the script to choke.
> >  
> > +#
> > +# When the system is idle it is likely that most files under /proc/PID 
> > will be
> > +# identical for various processes.  Scanning _all_ the PIDs under /proc is
> > +# unnecessary and implies that we are thoroughly scanning /proc.  This is 
> > _not_
> > +# the case because there may be ways userspace can trigger creation of 
> > /proc
> > +# files that leak addresses but were not present during a scan.  For these 
> > two
> > +# reasons we exclude all PID directories under /proc except '1/'
> > +
> >  use warnings;
> >  use strict;
> >  use POSIX;
> > @@ -472,6 +480,9 @@ sub walk
> > my $path = "$pwd/$file";
> > next if (-l $path);
> >  
> > +   # skip /proc/PID except /proc/1
> > +   next if ($path =~ /\/proc\/(?:[2-9][0-9]*|1[0-9]+)/);
> 
> Can't we just do,
> 
> substr($path, 0, len("/proc/1/")) eq "/proc/1/" ?
> 
> seems much easier to read than the regex.

This is much better.  I guess it's true what they say, be careful after
reading a book about hammers, everything will look like a nail.


Tobin

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

[Tobin C. Harding]

On Mon, Feb 26, 2018 at 10:09:31PM -0700, Tycho Andersen wrote:
> Hi Tobin,
> 
> On Tue, Feb 27, 2018 at 03:45:09PM +1100, Tobin C. Harding wrote:
> > When the system is idle it is likely that most files under /proc/PID
> > will be identical for various processes.  Scanning _all_ the PIDs under
> > /proc is unnecessary and implies that we are thoroughly scanning /proc.
> > This is _not_ the case because there may be ways userspace can trigger
> > creation of /proc files that leak addresses but were not present during
> > a scan.  For these two reasons we should exclude all PID directories
> > under /proc except '1/'
> > 
> > Exclude all /proc/PID except /proc/1.
> > 
> > Signed-off-by: Tobin C. Harding 
> > ---
> >  scripts/leaking_addresses.pl | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
> > index 6e5bc57caeaa..fb40e2828f43 100755
> > --- a/scripts/leaking_addresses.pl
> > +++ b/scripts/leaking_addresses.pl
> > @@ -10,6 +10,14 @@
> >  # Use --debug to output path before parsing, this is useful to find files 
> > that
> >  # cause the script to choke.
> >  
> > +#
> > +# When the system is idle it is likely that most files under /proc/PID 
> > will be
> > +# identical for various processes.  Scanning _all_ the PIDs under /proc is
> > +# unnecessary and implies that we are thoroughly scanning /proc.  This is 
> > _not_
> > +# the case because there may be ways userspace can trigger creation of 
> > /proc
> > +# files that leak addresses but were not present during a scan.  For these 
> > two
> > +# reasons we exclude all PID directories under /proc except '1/'
> > +
> >  use warnings;
> >  use strict;
> >  use POSIX;
> > @@ -472,6 +480,9 @@ sub walk
> > my $path = "$pwd/$file";
> > next if (-l $path);
> >  
> > +   # skip /proc/PID except /proc/1
> > +   next if ($path =~ /\/proc\/(?:[2-9][0-9]*|1[0-9]+)/);
> 
> Can't we just do,
> 
> substr($path, 0, len("/proc/1/")) eq "/proc/1/" ?
> 
> seems much easier to read than the regex.

This is much better.  I guess it's true what they say, be careful after
reading a book about hammers, everything will look like a nail.


Tobin

[PATCH] Documentation: fix the wrong path in intel_rdt_ui.txt

[Li RongQing]

the note says "Move the cpus 4-7 over to p1", but echo command
writes f0 to p0/cpus

Signed-off-by: Li RongQing 
Cc: Fenghua Yu 
---
 Documentation/x86/intel_rdt_ui.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/x86/intel_rdt_ui.txt 
b/Documentation/x86/intel_rdt_ui.txt
index 756fd76b78a6..71c30984e94d 100644
--- a/Documentation/x86/intel_rdt_ui.txt
+++ b/Documentation/x86/intel_rdt_ui.txt
@@ -671,7 +671,7 @@ occupancy of the real time threads on these cores.
 # mkdir p1
 
 Move the cpus 4-7 over to p1
-# echo f0 > p0/cpus
+# echo f0 > p1/cpus
 
 View the llc occupancy snapshot
 
-- 
2.11.0

[PATCH] Documentation: fix the wrong path in intel_rdt_ui.txt

[Li RongQing]

the note says "Move the cpus 4-7 over to p1", but echo command
writes f0 to p0/cpus

Signed-off-by: Li RongQing 
Cc: Fenghua Yu 
---
 Documentation/x86/intel_rdt_ui.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/x86/intel_rdt_ui.txt 
b/Documentation/x86/intel_rdt_ui.txt
index 756fd76b78a6..71c30984e94d 100644
--- a/Documentation/x86/intel_rdt_ui.txt
+++ b/Documentation/x86/intel_rdt_ui.txt
@@ -671,7 +671,7 @@ occupancy of the real time threads on these cores.
 # mkdir p1
 
 Move the cpus 4-7 over to p1
-# echo f0 > p0/cpus
+# echo f0 > p1/cpus
 
 View the llc occupancy snapshot
 
-- 
2.11.0

[no subject]

[LIN]

Can i trust you with the following? I know and hoping, praying that you are
a person that has the intelligence to understand what I am getting myself
into. I cannot make you agree to this with me, but I can assume that when
you are in I can trust you completely.  The least I ask of you, is for you;
after hearing me, to honestly tell me if you are up for it or not, without
acting maliciously. I bear the full brunt of any risk involved in this, but
I cannot do it alone and you can be rest assured that you will be duly
compensated financially for your involvement. Only someone bearing your
surname will be able and can do this with me, I hope and pray you don't let
me down. It involves, returns on investment over period of years. I am
waiting to hear from you.

Yours faithfully,
Mr LIN


__

Sky Silk, http://aknet.kz

[no subject]

[LIN]

Can i trust you with the following? I know and hoping, praying that you are
a person that has the intelligence to understand what I am getting myself
into. I cannot make you agree to this with me, but I can assume that when
you are in I can trust you completely.  The least I ask of you, is for you;
after hearing me, to honestly tell me if you are up for it or not, without
acting maliciously. I bear the full brunt of any risk involved in this, but
I cannot do it alone and you can be rest assured that you will be duly
compensated financially for your involvement. Only someone bearing your
surname will be able and can do this with me, I hope and pray you don't let
me down. It involves, returns on investment over period of years. I am
waiting to hear from you.

Yours faithfully,
Mr LIN


__

Sky Silk, http://aknet.kz