Re: [PATCH] arm64: do not set dma masks that device connection can't handle

[Sergei Shtylyov]

Hello!

On 1/6/2017 5:45 PM, Nikita Yushchenko wrote:


It is possible that device is capable of 64-bit DMA addresses, and
device driver tries to set wide DMA mask, but bridge or bus used to
connect device to the system can't handle wide addresses.

With swiotlb, memory above 4G still can be used by drivers for streaming
DMA, but *dev->mask and dev->dma_coherent_mask must still keep values
that hardware handles physically.

This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.

Signed-off-by: Nikita Yushchenko 
CC: Arnd Bergmann 

[...]

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f..09c7900 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -352,6 +352,31 @@ static int __swiotlb_dma_supported(struct device *hwdev, 
u64 mask)
return 1;
 }

+static int __swiotlb_set_dma_mask(struct device *dev, u64 mask)
+{
+   /* device is not DMA capable */
+   if (!dev->dma_mask)
+   return -EIO;
+
+   /* mask is below swiotlb bounce buffer, so fail */
+   if (!swiotlb_dma_supported(dev, mask))
+   return -EIO;
+
+   /*
+* because of the swiotlb, we can return success for
+* larger masks, but need to ensure that bounce buffers
+* are used above parent_dma_mask, so set that as
+* the effective mask.
+*/
+   if (mask > dev->archdata.parent_dma_mask)
+   mask = dev->archdata.parent_dma_mask;
+
+


   One empty line is enough...


+   *dev->dma_mask = mask;
+
+   return 0;
+}
+
 static struct dma_map_ops swiotlb_dma_ops = {
.alloc = __dma_alloc,
.free = __dma_free,

[...]

@@ -957,6 +997,18 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, 
u64 size,
if (!dev->archdata.dma_ops)
dev->archdata.dma_ops = _dma_ops;

+   /*
+* we don't yet support buses that have a non-zero mapping.
+*  Let's hope we won't need it
+*/
+   WARN_ON(dma_base != 0);
+
+   /*
+* Whatever the parent bus can set. A device must not set
+* a DMA mask larger than this.
+*/
+   dev->archdata.parent_dma_mask = size;


   Not 'size - 1'?


+
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
 }


MBR, Sergei

Re: [PATCH] arm64: do not set dma masks that device connection can't handle

[Sergei Shtylyov]

Hello!

On 1/6/2017 5:45 PM, Nikita Yushchenko wrote:


It is possible that device is capable of 64-bit DMA addresses, and
device driver tries to set wide DMA mask, but bridge or bus used to
connect device to the system can't handle wide addresses.

With swiotlb, memory above 4G still can be used by drivers for streaming
DMA, but *dev->mask and dev->dma_coherent_mask must still keep values
that hardware handles physically.

This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.

Signed-off-by: Nikita Yushchenko 
CC: Arnd Bergmann 

[...]

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f..09c7900 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -352,6 +352,31 @@ static int __swiotlb_dma_supported(struct device *hwdev, 
u64 mask)
return 1;
 }

+static int __swiotlb_set_dma_mask(struct device *dev, u64 mask)
+{
+   /* device is not DMA capable */
+   if (!dev->dma_mask)
+   return -EIO;
+
+   /* mask is below swiotlb bounce buffer, so fail */
+   if (!swiotlb_dma_supported(dev, mask))
+   return -EIO;
+
+   /*
+* because of the swiotlb, we can return success for
+* larger masks, but need to ensure that bounce buffers
+* are used above parent_dma_mask, so set that as
+* the effective mask.
+*/
+   if (mask > dev->archdata.parent_dma_mask)
+   mask = dev->archdata.parent_dma_mask;
+
+


   One empty line is enough...


+   *dev->dma_mask = mask;
+
+   return 0;
+}
+
 static struct dma_map_ops swiotlb_dma_ops = {
.alloc = __dma_alloc,
.free = __dma_free,

[...]

@@ -957,6 +997,18 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, 
u64 size,
if (!dev->archdata.dma_ops)
dev->archdata.dma_ops = _dma_ops;

+   /*
+* we don't yet support buses that have a non-zero mapping.
+*  Let's hope we won't need it
+*/
+   WARN_ON(dma_base != 0);
+
+   /*
+* Whatever the parent bus can set. A device must not set
+* a DMA mask larger than this.
+*/
+   dev->archdata.parent_dma_mask = size;


   Not 'size - 1'?


+
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
 }


MBR, Sergei

Re: [PATCH] mm: stop leaking PageTables

[Aneesh Kumar K.V]

Hugh Dickins  writes:

> 4.10-rc loadtest (even on x86, even without THPCache) fails with
> "fork: Cannot allocate memory" or some such; and /proc/meminfo
> shows PageTables growing.
>
> rc1 removed the freeing of an unused preallocated pagetable after
> do_fault_around() has called map_pages(): which is usually a good
> optimization, so that the followup doesn't have to reallocate one;
> but it's not sufficient to shift the freeing into alloc_set_pte(),
> since there are failure cases (most commonly VM_FAULT_RETRY) which
> never reach finish_fault().
>
> Check and free it at the outer level in do_fault(), then we don't
> need to worry in alloc_set_pte(), and can restore that to how it was
> (I cannot find any reason to pte_free() under lock as it was doing).
>
> And fix a separate pagetable leak, or crash, introduced by the same
> change, that could only show up on some ppc64: why does do_set_pmd()'s
> failure case attempt to withdraw a pagetable when it never deposited
> one, at the same time overwriting (so leaking) the vmf->prealloc_pte?
> Residue of an earlier implementation, perhaps?  Delete it.

That change is part of -mm tree.

https://lkml.kernel.org/r/20161212163428.6780-1-aneesh.ku...@linux.vnet.ibm.com

>
> Fixes: 953c66c2b22a ("mm: THP page cache support for ppc64")
> Signed-off-by: Hugh Dickins 


Reviewed-by: Aneesh Kumar K.V 

> ---
>
>  mm/memory.c |   47 ---
>  1 file changed, 20 insertions(+), 27 deletions(-)
>
> --- 4.10-rc2/mm/memory.c  2016-12-25 18:40:50.830453384 -0800
> +++ linux/mm/memory.c 2017-01-07 13:34:29.373381551 -0800
> @@ -3008,13 +3008,6 @@ static int do_set_pmd(struct vm_fault *v
>   ret = 0;
>   count_vm_event(THP_FILE_MAPPED);
>  out:
> - /*
> -  * If we are going to fallback to pte mapping, do a
> -  * withdraw with pmd lock held.
> -  */
> - if (arch_needs_pgtable_deposit() && ret == VM_FAULT_FALLBACK)
> - vmf->prealloc_pte = pgtable_trans_huge_withdraw(vma->vm_mm,
> - vmf->pmd);
>   spin_unlock(vmf->ptl);
>   return ret;
>  }
> @@ -3055,20 +3048,18 @@ int alloc_set_pte(struct vm_fault *vmf,
>
>   ret = do_set_pmd(vmf, page);
>   if (ret != VM_FAULT_FALLBACK)
> - goto fault_handled;
> + return ret;
>   }
>
>   if (!vmf->pte) {
>   ret = pte_alloc_one_map(vmf);
>   if (ret)
> - goto fault_handled;
> + return ret;
>   }
>
>   /* Re-check under ptl */
> - if (unlikely(!pte_none(*vmf->pte))) {
> - ret = VM_FAULT_NOPAGE;
> - goto fault_handled;
> - }
> + if (unlikely(!pte_none(*vmf->pte)))
> + return VM_FAULT_NOPAGE;
>
>   flush_icache_page(vma, page);
>   entry = mk_pte(page, vma->vm_page_prot);
> @@ -3088,15 +3079,8 @@ int alloc_set_pte(struct vm_fault *vmf,
>
>   /* no need to invalidate: a not-present page won't be cached */
>   update_mmu_cache(vma, vmf->address, vmf->pte);
> - ret = 0;
>
> -fault_handled:
> - /* preallocated pagetable is unused: free it */
> - if (vmf->prealloc_pte) {
> - pte_free(vmf->vma->vm_mm, vmf->prealloc_pte);
> - vmf->prealloc_pte = 0;
> - }
> - return ret;
> + return 0;
>  }
>
>
> @@ -3360,15 +3344,24 @@ static int do_shared_fault(struct vm_fau
>  static int do_fault(struct vm_fault *vmf)
>  {
>   struct vm_area_struct *vma = vmf->vma;
> + int ret;
>
>   /* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND */
>   if (!vma->vm_ops->fault)
> - return VM_FAULT_SIGBUS;
> - if (!(vmf->flags & FAULT_FLAG_WRITE))
> - return do_read_fault(vmf);
> - if (!(vma->vm_flags & VM_SHARED))
> - return do_cow_fault(vmf);
> - return do_shared_fault(vmf);
> + ret = VM_FAULT_SIGBUS;
> + else if (!(vmf->flags & FAULT_FLAG_WRITE))
> + ret = do_read_fault(vmf);
> + else if (!(vma->vm_flags & VM_SHARED))
> + ret = do_cow_fault(vmf);
> + else
> + ret = do_shared_fault(vmf);
> +
> + /* preallocated pagetable is unused: free it */
> + if (vmf->prealloc_pte) {
> + pte_free(vma->vm_mm, vmf->prealloc_pte);
> + vmf->prealloc_pte = 0;
> + }
> + return ret;
>  }
>
>  static int numa_migrate_prep(struct page *page, struct vm_area_struct *vma,

Re: [PATCH] mm: stop leaking PageTables

[Aneesh Kumar K.V]

Hugh Dickins  writes:

> 4.10-rc loadtest (even on x86, even without THPCache) fails with
> "fork: Cannot allocate memory" or some such; and /proc/meminfo
> shows PageTables growing.
>
> rc1 removed the freeing of an unused preallocated pagetable after
> do_fault_around() has called map_pages(): which is usually a good
> optimization, so that the followup doesn't have to reallocate one;
> but it's not sufficient to shift the freeing into alloc_set_pte(),
> since there are failure cases (most commonly VM_FAULT_RETRY) which
> never reach finish_fault().
>
> Check and free it at the outer level in do_fault(), then we don't
> need to worry in alloc_set_pte(), and can restore that to how it was
> (I cannot find any reason to pte_free() under lock as it was doing).
>
> And fix a separate pagetable leak, or crash, introduced by the same
> change, that could only show up on some ppc64: why does do_set_pmd()'s
> failure case attempt to withdraw a pagetable when it never deposited
> one, at the same time overwriting (so leaking) the vmf->prealloc_pte?
> Residue of an earlier implementation, perhaps?  Delete it.

That change is part of -mm tree.

https://lkml.kernel.org/r/20161212163428.6780-1-aneesh.ku...@linux.vnet.ibm.com

>
> Fixes: 953c66c2b22a ("mm: THP page cache support for ppc64")
> Signed-off-by: Hugh Dickins 


Reviewed-by: Aneesh Kumar K.V 

> ---
>
>  mm/memory.c |   47 ---
>  1 file changed, 20 insertions(+), 27 deletions(-)
>
> --- 4.10-rc2/mm/memory.c  2016-12-25 18:40:50.830453384 -0800
> +++ linux/mm/memory.c 2017-01-07 13:34:29.373381551 -0800
> @@ -3008,13 +3008,6 @@ static int do_set_pmd(struct vm_fault *v
>   ret = 0;
>   count_vm_event(THP_FILE_MAPPED);
>  out:
> - /*
> -  * If we are going to fallback to pte mapping, do a
> -  * withdraw with pmd lock held.
> -  */
> - if (arch_needs_pgtable_deposit() && ret == VM_FAULT_FALLBACK)
> - vmf->prealloc_pte = pgtable_trans_huge_withdraw(vma->vm_mm,
> - vmf->pmd);
>   spin_unlock(vmf->ptl);
>   return ret;
>  }
> @@ -3055,20 +3048,18 @@ int alloc_set_pte(struct vm_fault *vmf,
>
>   ret = do_set_pmd(vmf, page);
>   if (ret != VM_FAULT_FALLBACK)
> - goto fault_handled;
> + return ret;
>   }
>
>   if (!vmf->pte) {
>   ret = pte_alloc_one_map(vmf);
>   if (ret)
> - goto fault_handled;
> + return ret;
>   }
>
>   /* Re-check under ptl */
> - if (unlikely(!pte_none(*vmf->pte))) {
> - ret = VM_FAULT_NOPAGE;
> - goto fault_handled;
> - }
> + if (unlikely(!pte_none(*vmf->pte)))
> + return VM_FAULT_NOPAGE;
>
>   flush_icache_page(vma, page);
>   entry = mk_pte(page, vma->vm_page_prot);
> @@ -3088,15 +3079,8 @@ int alloc_set_pte(struct vm_fault *vmf,
>
>   /* no need to invalidate: a not-present page won't be cached */
>   update_mmu_cache(vma, vmf->address, vmf->pte);
> - ret = 0;
>
> -fault_handled:
> - /* preallocated pagetable is unused: free it */
> - if (vmf->prealloc_pte) {
> - pte_free(vmf->vma->vm_mm, vmf->prealloc_pte);
> - vmf->prealloc_pte = 0;
> - }
> - return ret;
> + return 0;
>  }
>
>
> @@ -3360,15 +3344,24 @@ static int do_shared_fault(struct vm_fau
>  static int do_fault(struct vm_fault *vmf)
>  {
>   struct vm_area_struct *vma = vmf->vma;
> + int ret;
>
>   /* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND */
>   if (!vma->vm_ops->fault)
> - return VM_FAULT_SIGBUS;
> - if (!(vmf->flags & FAULT_FLAG_WRITE))
> - return do_read_fault(vmf);
> - if (!(vma->vm_flags & VM_SHARED))
> - return do_cow_fault(vmf);
> - return do_shared_fault(vmf);
> + ret = VM_FAULT_SIGBUS;
> + else if (!(vmf->flags & FAULT_FLAG_WRITE))
> + ret = do_read_fault(vmf);
> + else if (!(vma->vm_flags & VM_SHARED))
> + ret = do_cow_fault(vmf);
> + else
> + ret = do_shared_fault(vmf);
> +
> + /* preallocated pagetable is unused: free it */
> + if (vmf->prealloc_pte) {
> + pte_free(vma->vm_mm, vmf->prealloc_pte);
> + vmf->prealloc_pte = 0;
> + }
> + return ret;
>  }
>
>  static int numa_migrate_prep(struct page *page, struct vm_area_struct *vma,

Re: [PATCH v2 2/4] linux/const.h: move UL() macro to include/linux/const.h

[Masahiro Yamada]

Hi.

2017-01-06 19:45 GMT+09:00 David Howells :
> Masahiro Yamada  wrote:
>
>> diff --git a/include/uapi/linux/const.h b/include/uapi/linux/const.h
>> index c872bfd..76fb0f9 100644
>> --- a/include/uapi/linux/const.h
>> +++ b/include/uapi/linux/const.h
>> @@ -1,7 +1,7 @@
>>  /* const.h: Macros for dealing with constants.  */
>>
>> -#ifndef _LINUX_CONST_H
>> -#define _LINUX_CONST_H
>> +#ifndef _UAPI_LINUX_CONST_H
>> +#define _UAPI_LINUX_CONST_H
>
> You need to be very careful doing this.  Some userspace stuff depends on the
> guard macro names on the kernel header files.

Oh...

>>  /* Some constant macros are used in both assembler and
>>   * C code.  Therefore we cannot annotate them always with
>> @@ -21,7 +21,10 @@
>>  #define _AT(T,X) ((T)(X))
>>  #endif
>>
>> +#define _UL(x)   (_AC(x, UL))
>> +#define _ULL(x)  (_AC(x, ULL))
>
> How likely is this to collide with existing userspace code somewhere?  It
> looks like the sort of thing that could collide with a C library.

Sorry, I do not have enough insight to answer your questions.


Andrew,
If this seems dangerous, please feel free to drop the entire series
because it is not adding any value except some cleanups.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 2/4] linux/const.h: move UL() macro to include/linux/const.h

[Masahiro Yamada]

Hi.

2017-01-06 19:45 GMT+09:00 David Howells :
> Masahiro Yamada  wrote:
>
>> diff --git a/include/uapi/linux/const.h b/include/uapi/linux/const.h
>> index c872bfd..76fb0f9 100644
>> --- a/include/uapi/linux/const.h
>> +++ b/include/uapi/linux/const.h
>> @@ -1,7 +1,7 @@
>>  /* const.h: Macros for dealing with constants.  */
>>
>> -#ifndef _LINUX_CONST_H
>> -#define _LINUX_CONST_H
>> +#ifndef _UAPI_LINUX_CONST_H
>> +#define _UAPI_LINUX_CONST_H
>
> You need to be very careful doing this.  Some userspace stuff depends on the
> guard macro names on the kernel header files.

Oh...

>>  /* Some constant macros are used in both assembler and
>>   * C code.  Therefore we cannot annotate them always with
>> @@ -21,7 +21,10 @@
>>  #define _AT(T,X) ((T)(X))
>>  #endif
>>
>> +#define _UL(x)   (_AC(x, UL))
>> +#define _ULL(x)  (_AC(x, ULL))
>
> How likely is this to collide with existing userspace code somewhere?  It
> looks like the sort of thing that could collide with a C library.

Sorry, I do not have enough insight to answer your questions.


Andrew,
If this seems dangerous, please feel free to drop the entire series
because it is not adding any value except some cleanups.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

[Andi Shyti]

Hi Chanwoo,

> >> >> >>> +   touchkey@20 {
> >> >> >>> +   compatible = "samsung,tm2-touchkey";
> >> >> >>> +   reg = <0x20>;
> >> >> >>> +   interrupt-parent = <>;
> >> >> >>> +   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> >> >> >>> +   vcc-supply = <_reg>;
> >> >> >>> +   vdd-supply = <_reg>;
> >> >> >>> +   };
> >> >> >>> +};
> >> >> >>> +
> >> >> >>>  _reg {
> >> >> >>> regulator-name = "TSP_VDD_1.85V_AP";
> >> >> >>> regulator-min-microvolt = <185>;
> >> >>
> >> >> I repiled the touchkey driver against compatible name.
> >> >> Usually, when developing the device driver, we use the specific h/w name
> >> >> but in this patch, the touckey dt node uses the h/w board name instead 
> >> >> of
> >> >> original touckhey name.
> >> >
> >> > this should be a device specifically done for the tm2 and we are
> >> > not sure who is the manufacturer of the device. In order to not
> >>
> >> As I knew, this touchkey was made by Cypress semiconductor.
> >> But, for more correct information, you may try to find it.
> >
> > The Android Kernel says that this is the cy8cmbr3xxx. I
> > downloaded the datasheets, but it doesn't have any similarity
> > with the device. Which means that on tm2 we don't the
> > cy8cmbr3xxx bot something else that I even doubt comes from
> > cypress, but I strongly believe it's a dedicated hardware.
> 
> Although this device is a dedicated h/w, you should keep the principal.
> Did you check the schematic document of TM2? The schematic document
> might include the specific device name.
> 
> Sometimes, the downloaded datasheet does not include the
> all of information of device because of confidential information.
> But, I’m not sure. Just it is guess as my experience.
> 
> I want to check the manufacturer and name of device with you
> on next Monday.

Yes, I checked everything, but didn't find the exact device name.

Anyway, let's take this discussion offline and find the correct
way.

Andi

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

[Andi Shyti]

Hi Chanwoo,

> >> >> >>> +   touchkey@20 {
> >> >> >>> +   compatible = "samsung,tm2-touchkey";
> >> >> >>> +   reg = <0x20>;
> >> >> >>> +   interrupt-parent = <>;
> >> >> >>> +   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> >> >> >>> +   vcc-supply = <_reg>;
> >> >> >>> +   vdd-supply = <_reg>;
> >> >> >>> +   };
> >> >> >>> +};
> >> >> >>> +
> >> >> >>>  _reg {
> >> >> >>> regulator-name = "TSP_VDD_1.85V_AP";
> >> >> >>> regulator-min-microvolt = <185>;
> >> >>
> >> >> I repiled the touchkey driver against compatible name.
> >> >> Usually, when developing the device driver, we use the specific h/w name
> >> >> but in this patch, the touckey dt node uses the h/w board name instead 
> >> >> of
> >> >> original touckhey name.
> >> >
> >> > this should be a device specifically done for the tm2 and we are
> >> > not sure who is the manufacturer of the device. In order to not
> >>
> >> As I knew, this touchkey was made by Cypress semiconductor.
> >> But, for more correct information, you may try to find it.
> >
> > The Android Kernel says that this is the cy8cmbr3xxx. I
> > downloaded the datasheets, but it doesn't have any similarity
> > with the device. Which means that on tm2 we don't the
> > cy8cmbr3xxx bot something else that I even doubt comes from
> > cypress, but I strongly believe it's a dedicated hardware.
> 
> Although this device is a dedicated h/w, you should keep the principal.
> Did you check the schematic document of TM2? The schematic document
> might include the specific device name.
> 
> Sometimes, the downloaded datasheet does not include the
> all of information of device because of confidential information.
> But, I’m not sure. Just it is guess as my experience.
> 
> I want to check the manufacturer and name of device with you
> on next Monday.

Yes, I checked everything, but didn't find the exact device name.

Anyway, let's take this discussion offline and find the correct
way.

Andi

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

[Chanwoo Choi]

Hi Andi,

2017-01-08 14:45 GMT+09:00 Andi Shyti :
> Hi Chanwoo,
>
>> >> >>> +   touchkey@20 {
>> >> >>> +   compatible = "samsung,tm2-touchkey";
>> >> >>> +   reg = <0x20>;
>> >> >>> +   interrupt-parent = <>;
>> >> >>> +   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
>> >> >>> +   vcc-supply = <_reg>;
>> >> >>> +   vdd-supply = <_reg>;
>> >> >>> +   };
>> >> >>> +};
>> >> >>> +
>> >> >>>  _reg {
>> >> >>> regulator-name = "TSP_VDD_1.85V_AP";
>> >> >>> regulator-min-microvolt = <185>;
>> >>
>> >> I repiled the touchkey driver against compatible name.
>> >> Usually, when developing the device driver, we use the specific h/w name
>> >> but in this patch, the touckey dt node uses the h/w board name instead of
>> >> original touckhey name.
>> >
>> > this should be a device specifically done for the tm2 and we are
>> > not sure who is the manufacturer of the device. In order to not
>>
>> As I knew, this touchkey was made by Cypress semiconductor.
>> But, for more correct information, you may try to find it.
>
> The Android Kernel says that this is the cy8cmbr3xxx. I
> downloaded the datasheets, but it doesn't have any similarity
> with the device. Which means that on tm2 we don't the
> cy8cmbr3xxx bot something else that I even doubt comes from
> cypress, but I strongly believe it's a dedicated hardware.

Although this device is a dedicated h/w, you should keep the principal.
Did you check the schematic document of TM2? The schematic document
might include the specific device name.

Sometimes, the downloaded datasheet does not include the
all of information of device because of confidential information.
But, I’m not sure. Just it is guess as my experience.

I want to check the manufacturer and name of device with you
on next Monday.

>
> Now we have two choices:
>
> 1. drop support because we are not 100% sure on the device and
> supplier.
>
> 2. call it Samsung and provide support anyway as, at the end, it
> is a samsung hardware.
>
> With Jaechul we chose option 2.
>
>> > assign the device to the wrong manufacturer, we preferred calling
>> > it Samsung as it is in a Samsung device.
>>
>> As you mentioned, Samsung made not this touchkey device. It is
>> certainly wrong manufacturer. I have not seen to use the h/w board
>> name as the peripheral device name.
>>
>> I don't prefer to use the inaccurate manufacturer and device name.
>
> Eventually, Jaechul can assign the device to cypress, but the
> name has to remain tm2-touchkey. Something like this:
>
> compatible = "cypress,tm2-touchkey";
>
> What do you think?

If we never to find the correct device name, we might use your suggestion.
As I already said, I’d like to check it again with you.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

[Chanwoo Choi]

Hi Andi,

2017-01-08 14:45 GMT+09:00 Andi Shyti :
> Hi Chanwoo,
>
>> >> >>> +   touchkey@20 {
>> >> >>> +   compatible = "samsung,tm2-touchkey";
>> >> >>> +   reg = <0x20>;
>> >> >>> +   interrupt-parent = <>;
>> >> >>> +   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
>> >> >>> +   vcc-supply = <_reg>;
>> >> >>> +   vdd-supply = <_reg>;
>> >> >>> +   };
>> >> >>> +};
>> >> >>> +
>> >> >>>  _reg {
>> >> >>> regulator-name = "TSP_VDD_1.85V_AP";
>> >> >>> regulator-min-microvolt = <185>;
>> >>
>> >> I repiled the touchkey driver against compatible name.
>> >> Usually, when developing the device driver, we use the specific h/w name
>> >> but in this patch, the touckey dt node uses the h/w board name instead of
>> >> original touckhey name.
>> >
>> > this should be a device specifically done for the tm2 and we are
>> > not sure who is the manufacturer of the device. In order to not
>>
>> As I knew, this touchkey was made by Cypress semiconductor.
>> But, for more correct information, you may try to find it.
>
> The Android Kernel says that this is the cy8cmbr3xxx. I
> downloaded the datasheets, but it doesn't have any similarity
> with the device. Which means that on tm2 we don't the
> cy8cmbr3xxx bot something else that I even doubt comes from
> cypress, but I strongly believe it's a dedicated hardware.

Although this device is a dedicated h/w, you should keep the principal.
Did you check the schematic document of TM2? The schematic document
might include the specific device name.

Sometimes, the downloaded datasheet does not include the
all of information of device because of confidential information.
But, I’m not sure. Just it is guess as my experience.

I want to check the manufacturer and name of device with you
on next Monday.

>
> Now we have two choices:
>
> 1. drop support because we are not 100% sure on the device and
> supplier.
>
> 2. call it Samsung and provide support anyway as, at the end, it
> is a samsung hardware.
>
> With Jaechul we chose option 2.
>
>> > assign the device to the wrong manufacturer, we preferred calling
>> > it Samsung as it is in a Samsung device.
>>
>> As you mentioned, Samsung made not this touchkey device. It is
>> certainly wrong manufacturer. I have not seen to use the h/w board
>> name as the peripheral device name.
>>
>> I don't prefer to use the inaccurate manufacturer and device name.
>
> Eventually, Jaechul can assign the device to cypress, but the
> name has to remain tm2-touchkey. Something like this:
>
> compatible = "cypress,tm2-touchkey";
>
> What do you think?

If we never to find the correct device name, we might use your suggestion.
As I already said, I’d like to check it again with you.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [V9fs-developer] 9pfs hangs since 4.7

[Al Viro]

On Sat, Jan 07, 2017 at 06:15:23PM +, Al Viro wrote:
> On Sat, Jan 07, 2017 at 05:19:10PM +, Al Viro wrote:
> 
> > released) simply trigger virtio_queue_notify_vq() again?  It *is* a bug
> > (if we get a burst filling a previously empty queue all at once, there won't
> > be any slots becoming freed
> 
> Umm...  Nope, even in that scenario we'll have all requests except the last
> one processed.  I'm trying to put together a simpler reproducer, but...
> no luck so far.

FWIW, here's another fun bug in qemu 9pfs: client may issue multiple
Tflush on the same pending request.  Server must not reply to them
out of order and it must reply to at least the last one.  If client has
sent more than one Tflush, it must treat an arrival of Rflush to one of
those as if it has received an Rflush to each of the earlier Tflush as
well (IOW, *their* tags are released).  Client may not reuse the tag of
victim request until it has received Rflush for the last Tflush it has
sent.

Linux kernel-side 9p client doesn't issue such multiple Tflush, but the
protocol allows that.

qemu server does not guarantee in-order replies to multiple Tflush; worse,
while it is likely to reply only to one of those, it may very well be
the _first_ one.  Subsequent ones will be lost; moreover, it'll leak
both coroutines and ring slots.

AFAICS, a clean way to deal with that would be to handle Tflush synchronously,
right in pdu_submit():
if pdu->type == Tflush
look the victim request up.
if !victim || victim == pdu // [*]
send reply and free pdu immediately.
if victim->type == Tflush   // [**]
pdu->victim = victim->victim
else
pdu->victim = victim
mark the victim cancelled
add pdu to the tail of pdu->victim->flushes
and let pdu_complete(pdu) send a reply to each request in pdu->flushes
as well (freeing them as we go)

Some locking might be needed to avoid the races between pdu_submit() and
pdu_complete(), but it's not going to be a wide critical area.  I'm not
familiar with qemu locking primitives, sorry; what's providing an exclusion
between QLIST_INSERT_HEAD in pdu_alloc() (from handle_9p_output())
and QLIST_REMOVE in pdu_free() (from pdu_complete())?  Looks like the same
thing ought to suffice here...

[*] a cute way to hurt the current qemu server, BTW - coroutine that waits for
itself to complete...

[**] Tflush to Tflush is another fun corner case - it does *not* do anything
to the earlier Tflush, but reply to it must follow that to original Tflush
to avoid tag reuse problems.  Note that this is not the "multiple Tflush"
case mentioned above - those would all have oldtag pointing to the same
request; they are not chained and unlike this one can happen with legitimate
clients.  Tflush to Tflush, OTOH, is not something a sane client would do.

Re: [V9fs-developer] 9pfs hangs since 4.7

[Al Viro]

On Sat, Jan 07, 2017 at 06:15:23PM +, Al Viro wrote:
> On Sat, Jan 07, 2017 at 05:19:10PM +, Al Viro wrote:
> 
> > released) simply trigger virtio_queue_notify_vq() again?  It *is* a bug
> > (if we get a burst filling a previously empty queue all at once, there won't
> > be any slots becoming freed
> 
> Umm...  Nope, even in that scenario we'll have all requests except the last
> one processed.  I'm trying to put together a simpler reproducer, but...
> no luck so far.

FWIW, here's another fun bug in qemu 9pfs: client may issue multiple
Tflush on the same pending request.  Server must not reply to them
out of order and it must reply to at least the last one.  If client has
sent more than one Tflush, it must treat an arrival of Rflush to one of
those as if it has received an Rflush to each of the earlier Tflush as
well (IOW, *their* tags are released).  Client may not reuse the tag of
victim request until it has received Rflush for the last Tflush it has
sent.

Linux kernel-side 9p client doesn't issue such multiple Tflush, but the
protocol allows that.

qemu server does not guarantee in-order replies to multiple Tflush; worse,
while it is likely to reply only to one of those, it may very well be
the _first_ one.  Subsequent ones will be lost; moreover, it'll leak
both coroutines and ring slots.

AFAICS, a clean way to deal with that would be to handle Tflush synchronously,
right in pdu_submit():
if pdu->type == Tflush
look the victim request up.
if !victim || victim == pdu // [*]
send reply and free pdu immediately.
if victim->type == Tflush   // [**]
pdu->victim = victim->victim
else
pdu->victim = victim
mark the victim cancelled
add pdu to the tail of pdu->victim->flushes
and let pdu_complete(pdu) send a reply to each request in pdu->flushes
as well (freeing them as we go)

Some locking might be needed to avoid the races between pdu_submit() and
pdu_complete(), but it's not going to be a wide critical area.  I'm not
familiar with qemu locking primitives, sorry; what's providing an exclusion
between QLIST_INSERT_HEAD in pdu_alloc() (from handle_9p_output())
and QLIST_REMOVE in pdu_free() (from pdu_complete())?  Looks like the same
thing ought to suffice here...

[*] a cute way to hurt the current qemu server, BTW - coroutine that waits for
itself to complete...

[**] Tflush to Tflush is another fun corner case - it does *not* do anything
to the earlier Tflush, but reply to it must follow that to original Tflush
to avoid tag reuse problems.  Note that this is not the "multiple Tflush"
case mentioned above - those would all have oldtag pointing to the same
request; they are not chained and unlike this one can happen with legitimate
clients.  Tflush to Tflush, OTOH, is not something a sane client would do.

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

[Andi Shyti]

Hi Chanwoo,

> >> >>> +   touchkey@20 {
> >> >>> +   compatible = "samsung,tm2-touchkey";
> >> >>> +   reg = <0x20>;
> >> >>> +   interrupt-parent = <>;
> >> >>> +   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> >> >>> +   vcc-supply = <_reg>;
> >> >>> +   vdd-supply = <_reg>;
> >> >>> +   };
> >> >>> +};
> >> >>> +
> >> >>>  _reg {
> >> >>> regulator-name = "TSP_VDD_1.85V_AP";
> >> >>> regulator-min-microvolt = <185>;
> >>
> >> I repiled the touchkey driver against compatible name.
> >> Usually, when developing the device driver, we use the specific h/w name
> >> but in this patch, the touckey dt node uses the h/w board name instead of
> >> original touckhey name.
> >
> > this should be a device specifically done for the tm2 and we are
> > not sure who is the manufacturer of the device. In order to not
> 
> As I knew, this touchkey was made by Cypress semiconductor.
> But, for more correct information, you may try to find it.

The Android Kernel says that this is the cy8cmbr3xxx. I
downloaded the datasheets, but it doesn't have any similarity
with the device. Which means that on tm2 we don't the
cy8cmbr3xxx bot something else that I even doubt comes from
cypress, but I strongly believe it's a dedicated hardware.

Now we have two choices:

1. drop support because we are not 100% sure on the device and
supplier.

2. call it Samsung and provide support anyway as, at the end, it
is a samsung hardware.

With Jaechul we chose option 2.

> > assign the device to the wrong manufacturer, we preferred calling
> > it Samsung as it is in a Samsung device.
> 
> As you mentioned, Samsung made not this touchkey device. It is
> certainly wrong manufacturer. I have not seen to use the h/w board
> name as the peripheral device name.
> 
> I don't prefer to use the inaccurate manufacturer and device name.

Eventually, Jaechul can assign the device to cypress, but the
name has to remain tm2-touchkey. Something like this:

compatible = "cypress,tm2-touchkey";

What do you think?

Andi

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

[Andi Shyti]

Hi Chanwoo,

> >> >>> +   touchkey@20 {
> >> >>> +   compatible = "samsung,tm2-touchkey";
> >> >>> +   reg = <0x20>;
> >> >>> +   interrupt-parent = <>;
> >> >>> +   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> >> >>> +   vcc-supply = <_reg>;
> >> >>> +   vdd-supply = <_reg>;
> >> >>> +   };
> >> >>> +};
> >> >>> +
> >> >>>  _reg {
> >> >>> regulator-name = "TSP_VDD_1.85V_AP";
> >> >>> regulator-min-microvolt = <185>;
> >>
> >> I repiled the touchkey driver against compatible name.
> >> Usually, when developing the device driver, we use the specific h/w name
> >> but in this patch, the touckey dt node uses the h/w board name instead of
> >> original touckhey name.
> >
> > this should be a device specifically done for the tm2 and we are
> > not sure who is the manufacturer of the device. In order to not
> 
> As I knew, this touchkey was made by Cypress semiconductor.
> But, for more correct information, you may try to find it.

The Android Kernel says that this is the cy8cmbr3xxx. I
downloaded the datasheets, but it doesn't have any similarity
with the device. Which means that on tm2 we don't the
cy8cmbr3xxx bot something else that I even doubt comes from
cypress, but I strongly believe it's a dedicated hardware.

Now we have two choices:

1. drop support because we are not 100% sure on the device and
supplier.

2. call it Samsung and provide support anyway as, at the end, it
is a samsung hardware.

With Jaechul we chose option 2.

> > assign the device to the wrong manufacturer, we preferred calling
> > it Samsung as it is in a Samsung device.
> 
> As you mentioned, Samsung made not this touchkey device. It is
> certainly wrong manufacturer. I have not seen to use the h/w board
> name as the peripheral device name.
> 
> I don't prefer to use the inaccurate manufacturer and device name.

Eventually, Jaechul can assign the device to cypress, but the
name has to remain tm2-touchkey. Something like this:

compatible = "cypress,tm2-touchkey";

What do you think?

Andi

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

[Chanwoo Choi]

Hi Andi,

2017-01-07 21:40 GMT+09:00 Andi Shyti :
> Hi Chanwoo,
>
>> >>> +   touchkey@20 {
>> >>> +   compatible = "samsung,tm2-touchkey";
>> >>> +   reg = <0x20>;
>> >>> +   interrupt-parent = <>;
>> >>> +   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
>> >>> +   vcc-supply = <_reg>;
>> >>> +   vdd-supply = <_reg>;
>> >>> +   };
>> >>> +};
>> >>> +
>> >>>  _reg {
>> >>> regulator-name = "TSP_VDD_1.85V_AP";
>> >>> regulator-min-microvolt = <185>;
>>
>> I repiled the touchkey driver against compatible name.
>> Usually, when developing the device driver, we use the specific h/w name
>> but in this patch, the touckey dt node uses the h/w board name instead of
>> original touckhey name.
>
> this should be a device specifically done for the tm2 and we are
> not sure who is the manufacturer of the device. In order to not

As I knew, this touchkey was made by Cypress semiconductor.
But, for more correct information, you may try to find it.

> assign the device to the wrong manufacturer, we preferred calling
> it Samsung as it is in a Samsung device.

As you mentioned, Samsung made not this touchkey device. It is
certainly wrong manufacturer. I have not seen to use the h/w board
name as the peripheral device name.

I don't prefer to use the inaccurate manufacturer and device name.

-- 
Best Regards,
Chanwoo Choi

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

[Chanwoo Choi]

Hi Andi,

2017-01-07 21:40 GMT+09:00 Andi Shyti :
> Hi Chanwoo,
>
>> >>> +   touchkey@20 {
>> >>> +   compatible = "samsung,tm2-touchkey";
>> >>> +   reg = <0x20>;
>> >>> +   interrupt-parent = <>;
>> >>> +   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
>> >>> +   vcc-supply = <_reg>;
>> >>> +   vdd-supply = <_reg>;
>> >>> +   };
>> >>> +};
>> >>> +
>> >>>  _reg {
>> >>> regulator-name = "TSP_VDD_1.85V_AP";
>> >>> regulator-min-microvolt = <185>;
>>
>> I repiled the touchkey driver against compatible name.
>> Usually, when developing the device driver, we use the specific h/w name
>> but in this patch, the touckey dt node uses the h/w board name instead of
>> original touckhey name.
>
> this should be a device specifically done for the tm2 and we are
> not sure who is the manufacturer of the device. In order to not

As I knew, this touchkey was made by Cypress semiconductor.
But, for more correct information, you may try to find it.

> assign the device to the wrong manufacturer, we preferred calling
> it Samsung as it is in a Samsung device.

As you mentioned, Samsung made not this touchkey device. It is
certainly wrong manufacturer. I have not seen to use the h/w board
name as the peripheral device name.

I don't prefer to use the inaccurate manufacturer and device name.

-- 
Best Regards,
Chanwoo Choi

Re: [f2fs-dev] [PATCH 3/5] f2fs: check in-memory block bitmap

[Jaegeuk Kim]

Hi Chao,

On 01/07, Chao Yu wrote:
> This patch adds a mirror for valid block bitmap, and use it to detect
> in-memory bitmap corruption which may be caused by bit-transition of
> cache or memory overflow.
> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/segment.c | 30 --
>  fs/f2fs/segment.h |  6 ++
>  2 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index fa8c0ae87d47..ec21ee1c61cd 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1026,14 +1026,32 @@ static void update_sit_entry(struct f2fs_sb_info 
> *sbi, block_t blkaddr, int del)
> 
>   /* Update valid block bitmap */
>   if (del > 0) {
> - if (f2fs_test_and_set_bit(offset, se->cur_valid_map))
> + if (f2fs_test_and_set_bit(offset, se->cur_valid_map)) {
> +#ifdef CONFIG_F2FS_CHECK_FS
> + if (f2fs_test_and_set_bit(offset,
> + se->cur_valid_map_mir))
> + f2fs_bug_on(sbi, 1);
> + else
> + WARN_ON(1);
> +#else
>   f2fs_bug_on(sbi, 1);
> +#endif
> + }
>   if (f2fs_discard_en(sbi) &&
>   !f2fs_test_and_set_bit(offset, se->discard_map))
>   sbi->discard_blks--;
>   } else {
> - if (!f2fs_test_and_clear_bit(offset, se->cur_valid_map))
> + if (!f2fs_test_and_clear_bit(offset, se->cur_valid_map)) {
> +#ifdef CONFIG_F2FS_CHECK_FS
> + if (!f2fs_test_and_clear_bit(offset,
> + se->cur_valid_map_mir))
> + f2fs_bug_on(sbi, 1);
> + else
> + WARN_ON(1);
> +#else
>   f2fs_bug_on(sbi, 1);
> +#endif
> + }
>   if (f2fs_discard_en(sbi) &&
>   f2fs_test_and_clear_bit(offset, se->discard_map))
>   sbi->discard_blks++;
> @@ -2357,6 +2375,13 @@ static int build_sit_info(struct f2fs_sb_info *sbi)
>   !sit_i->sentries[start].ckpt_valid_map)
>   return -ENOMEM;
> 
> +#ifdef CONFIG_F2FS_CHECK_FS
> + sit_i->sentries[start].cur_valid_map_mir
> + = kzalloc(SIT_VBLOCK_MAP_SIZE, GFP_KERNEL);
> + if (!sit_i->sentries[start].cur_valid_map_mir)
> + return -ENOMEM;
> +#endif
> +
>   if (f2fs_discard_en(sbi)) {
>   sit_i->sentries[start].discard_map
>   = kzalloc(SIT_VBLOCK_MAP_SIZE, GFP_KERNEL);
> @@ -2786,6 +2811,7 @@ static void destroy_sit_info(struct f2fs_sb_info *sbi)
>   if (sit_i->sentries) {
>   for (start = 0; start < MAIN_SEGS(sbi); start++) {
>   kfree(sit_i->sentries[start].cur_valid_map);

I added:

#ifdef CONFIG_F2FS_CHECK_FS

> + kfree(sit_i->sentries[start].cur_valid_map_mir);

#endif

Thanks,

Re: [f2fs-dev] [PATCH 3/5] f2fs: check in-memory block bitmap

[Jaegeuk Kim]

Hi Chao,

On 01/07, Chao Yu wrote:
> This patch adds a mirror for valid block bitmap, and use it to detect
> in-memory bitmap corruption which may be caused by bit-transition of
> cache or memory overflow.
> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/segment.c | 30 --
>  fs/f2fs/segment.h |  6 ++
>  2 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index fa8c0ae87d47..ec21ee1c61cd 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1026,14 +1026,32 @@ static void update_sit_entry(struct f2fs_sb_info 
> *sbi, block_t blkaddr, int del)
> 
>   /* Update valid block bitmap */
>   if (del > 0) {
> - if (f2fs_test_and_set_bit(offset, se->cur_valid_map))
> + if (f2fs_test_and_set_bit(offset, se->cur_valid_map)) {
> +#ifdef CONFIG_F2FS_CHECK_FS
> + if (f2fs_test_and_set_bit(offset,
> + se->cur_valid_map_mir))
> + f2fs_bug_on(sbi, 1);
> + else
> + WARN_ON(1);
> +#else
>   f2fs_bug_on(sbi, 1);
> +#endif
> + }
>   if (f2fs_discard_en(sbi) &&
>   !f2fs_test_and_set_bit(offset, se->discard_map))
>   sbi->discard_blks--;
>   } else {
> - if (!f2fs_test_and_clear_bit(offset, se->cur_valid_map))
> + if (!f2fs_test_and_clear_bit(offset, se->cur_valid_map)) {
> +#ifdef CONFIG_F2FS_CHECK_FS
> + if (!f2fs_test_and_clear_bit(offset,
> + se->cur_valid_map_mir))
> + f2fs_bug_on(sbi, 1);
> + else
> + WARN_ON(1);
> +#else
>   f2fs_bug_on(sbi, 1);
> +#endif
> + }
>   if (f2fs_discard_en(sbi) &&
>   f2fs_test_and_clear_bit(offset, se->discard_map))
>   sbi->discard_blks++;
> @@ -2357,6 +2375,13 @@ static int build_sit_info(struct f2fs_sb_info *sbi)
>   !sit_i->sentries[start].ckpt_valid_map)
>   return -ENOMEM;
> 
> +#ifdef CONFIG_F2FS_CHECK_FS
> + sit_i->sentries[start].cur_valid_map_mir
> + = kzalloc(SIT_VBLOCK_MAP_SIZE, GFP_KERNEL);
> + if (!sit_i->sentries[start].cur_valid_map_mir)
> + return -ENOMEM;
> +#endif
> +
>   if (f2fs_discard_en(sbi)) {
>   sit_i->sentries[start].discard_map
>   = kzalloc(SIT_VBLOCK_MAP_SIZE, GFP_KERNEL);
> @@ -2786,6 +2811,7 @@ static void destroy_sit_info(struct f2fs_sb_info *sbi)
>   if (sit_i->sentries) {
>   for (start = 0; start < MAIN_SEGS(sbi); start++) {
>   kfree(sit_i->sentries[start].cur_valid_map);

I added:

#ifdef CONFIG_F2FS_CHECK_FS

> + kfree(sit_i->sentries[start].cur_valid_map_mir);

#endif

Thanks,

Re: [PATCH] Staging: speakup: styel fix, octal file permissions

[Derek Robson]

On Sat, Jan 07, 2017 at 08:39:45AM +0100, Greg KH wrote:
> On Sat, Jan 07, 2017 at 05:11:16PM +1300, Derek Robson wrote:
> > Changed file permission to octal style,
> > Found using checkpatch
> 
> Typo in your subject line :(
> 
> > 
> > Signed-off-by: Derek Robson 
> > ---
> >  drivers/staging/speakup/kobjects.c | 54 
> > +++---
> >  1 file changed, 27 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/staging/speakup/kobjects.c 
> > b/drivers/staging/speakup/kobjects.c
> > index e744aa9730ff..4e7ebc306488 100644
> > --- a/drivers/staging/speakup/kobjects.c
> > +++ b/drivers/staging/speakup/kobjects.c
> > @@ -865,66 +865,66 @@ static struct kobj_attribute version_attribute =
> > __ATTR_RO(version);
> >  
> >  static struct kobj_attribute delimiters_attribute =
> > -   __ATTR(delimiters, S_IWUSR | S_IRUGO, punc_show, punc_store);
> > +   __ATTR(delimiters, 0644, punc_show, punc_store);
> >  static struct kobj_attribute ex_num_attribute =
> > -   __ATTR(ex_num, S_IWUSR | S_IRUGO, punc_show, punc_store);
> > +   __ATTR(ex_num, 0644, punc_show, punc_store);
> 
> Why not just use __ATTR_RW() for all of these instead?  Be much easier
> and smaller and is recommended instead of spelling out the mode values
> everywhere.

It looks like that won't work in this case the handler is reused and not in the 
standard format of attrName_show. 

Or have I not understood the use of __ATTR_RW() ?

Thanks

Re: [PATCH] Staging: speakup: styel fix, octal file permissions

[Derek Robson]

On Sat, Jan 07, 2017 at 08:39:45AM +0100, Greg KH wrote:
> On Sat, Jan 07, 2017 at 05:11:16PM +1300, Derek Robson wrote:
> > Changed file permission to octal style,
> > Found using checkpatch
> 
> Typo in your subject line :(
> 
> > 
> > Signed-off-by: Derek Robson 
> > ---
> >  drivers/staging/speakup/kobjects.c | 54 
> > +++---
> >  1 file changed, 27 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/staging/speakup/kobjects.c 
> > b/drivers/staging/speakup/kobjects.c
> > index e744aa9730ff..4e7ebc306488 100644
> > --- a/drivers/staging/speakup/kobjects.c
> > +++ b/drivers/staging/speakup/kobjects.c
> > @@ -865,66 +865,66 @@ static struct kobj_attribute version_attribute =
> > __ATTR_RO(version);
> >  
> >  static struct kobj_attribute delimiters_attribute =
> > -   __ATTR(delimiters, S_IWUSR | S_IRUGO, punc_show, punc_store);
> > +   __ATTR(delimiters, 0644, punc_show, punc_store);
> >  static struct kobj_attribute ex_num_attribute =
> > -   __ATTR(ex_num, S_IWUSR | S_IRUGO, punc_show, punc_store);
> > +   __ATTR(ex_num, 0644, punc_show, punc_store);
> 
> Why not just use __ATTR_RW() for all of these instead?  Be much easier
> and smaller and is recommended instead of spelling out the mode values
> everywhere.

It looks like that won't work in this case the handler is reused and not in the 
standard format of attrName_show. 

Or have I not understood the use of __ATTR_RW() ?

Thanks

Re: [PATCH tip/master v3] kprobes: extable: Identify kprobes' insn-slots as kernel text area

[Masami Hiramatsu]

On Wed, 4 Jan 2017 11:01:02 +0100
Peter Zijlstra  wrote:

> On Wed, Jan 04, 2017 at 02:06:04PM +0900, Masami Hiramatsu wrote:
> > On Tue, 3 Jan 2017 11:54:02 +0100
> > Peter Zijlstra  wrote:
> 
> > > How many entries should one expect on that list? I spend quite a bit of
> > > time reducing the cost of is_module_text_address() a while back and see
> > > that both ftrace (which actually needs this to be fast) and now
> > > kprobes have linear list walks in here.
> > 
> > It depends on how many probes are used and optimized. However, in most
> > cases, there should be one entry (unless user defines optimized probes
> > over 32 on x86, from my experience, it is very rare case. :) )
> 
> OK, that's good :-)

OK, I'll add above comment on the patch.

> 
> > > I'm assuming the ftrace thing to be mostly empty, since I never saw it
> > > on my benchmarks back then, but it is something Steve should look at I
> > > suppose.
> > > 
> > > Similarly, the changelog here should include some talk about worst case
> > > costs.
> > 
> > Would you have any good benchmark to measure it?
> 
> Not trivially so; what I did was cobble together a debugfs file that
> measures the average of the PMI time in perf_sample_event_took(), and a
> module that has a 10 deep callchain around a while(1) loop. Then perf
> record with callchains for a few seconds.
> 
> Generating the callchain does the unwinder thing and ends up calling
> is_kernel_address() lots.
> 
> The case I worked on was 0 modules vs 100+ modules in a distro build,
> which was fairly obviously painful back then, since
> is_module_text_address() used a linear lookup.
> 
> I'm not sure I still have all those bits, but I can dig around a bit if
> you're interested.

Hmm, I tried to do similar thing (make a test module which has a loop with
10 deep recursive call and save stack-trace) on kvm, but got very unstable
results.
Maybe it needs to run on bare-metal machine.

Thanks,

-- 
Masami Hiramatsu 

Re: [PATCH tip/master v3] kprobes: extable: Identify kprobes' insn-slots as kernel text area

[Masami Hiramatsu]

On Wed, 4 Jan 2017 11:01:02 +0100
Peter Zijlstra  wrote:

> On Wed, Jan 04, 2017 at 02:06:04PM +0900, Masami Hiramatsu wrote:
> > On Tue, 3 Jan 2017 11:54:02 +0100
> > Peter Zijlstra  wrote:
> 
> > > How many entries should one expect on that list? I spend quite a bit of
> > > time reducing the cost of is_module_text_address() a while back and see
> > > that both ftrace (which actually needs this to be fast) and now
> > > kprobes have linear list walks in here.
> > 
> > It depends on how many probes are used and optimized. However, in most
> > cases, there should be one entry (unless user defines optimized probes
> > over 32 on x86, from my experience, it is very rare case. :) )
> 
> OK, that's good :-)

OK, I'll add above comment on the patch.

> 
> > > I'm assuming the ftrace thing to be mostly empty, since I never saw it
> > > on my benchmarks back then, but it is something Steve should look at I
> > > suppose.
> > > 
> > > Similarly, the changelog here should include some talk about worst case
> > > costs.
> > 
> > Would you have any good benchmark to measure it?
> 
> Not trivially so; what I did was cobble together a debugfs file that
> measures the average of the PMI time in perf_sample_event_took(), and a
> module that has a 10 deep callchain around a while(1) loop. Then perf
> record with callchains for a few seconds.
> 
> Generating the callchain does the unwinder thing and ends up calling
> is_kernel_address() lots.
> 
> The case I worked on was 0 modules vs 100+ modules in a distro build,
> which was fairly obviously painful back then, since
> is_module_text_address() used a linear lookup.
> 
> I'm not sure I still have all those bits, but I can dig around a bit if
> you're interested.

Hmm, I tried to do similar thing (make a test module which has a loop with
10 deep recursive call and save stack-trace) on kvm, but got very unstable
results.
Maybe it needs to run on bare-metal machine.

Thanks,

-- 
Masami Hiramatsu 

Re: [PATCH net-next] net: dsa: move HWMON support to its own file

[David Miller]

From: Vivien Didelot 
Date: Fri,  6 Jan 2017 16:42:00 -0500

> Isolate the HWMON support in DSA in its own file. Currently only the
> legacy DSA code is concerned.
> 
> Signed-off-by: Vivien Didelot 

Applied.

Re: [PATCH net-next] net: dsa: move HWMON support to its own file

[David Miller]

From: Vivien Didelot 
Date: Fri,  6 Jan 2017 16:42:00 -0500

> Isolate the HWMON support in DSA in its own file. Currently only the
> legacy DSA code is concerned.
> 
> Signed-off-by: Vivien Didelot 

Applied.

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
 wrote:

> Just remuxed GPIO signals to these pads, applied your two patches and
> used rts-gpios in the DT but I still see the same problem :/
>
> When transmit something, I get doubled characters, then zeros and at the
> end garbled data of previous transmissions, same as described in my
> first post (Logic analyzer: https://pqgruber.com/rs485_results.png)
> The data is always 4096 bytes long, this explains why the echo command
> is blocking for about 4 seconds (<- 4096 bytes at a baudrate of 9600).
> The TE line is also high until all 4096 bytes are sent.
>
> I think this comes from the UART_XMIT_SIZE which is defined to the page
> size.
> Maybe there is something wrong in imx_transmit_buffer and leads to the
> whole circular buffer being sent out all the time, not stopping..
>
> Do these debug logs tell you anything?
> https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5
>
> I am analyzing the signals coming directly from the i.MX6Q, so this must
> be a software problem, but I don't understand why it works for you, if
> we use the same software.
>
> Do you use any other patches on top of mainline and do you use the SDMA
> scripts from the ROM?

No, I use the original 4.9 + the two patches I sent. Yes, I do use the
SDMA scripts from ROM.

Here is the procedure I did to try to reproduce the issue you reported:

(The rs485conf is available at:
https://github.com/mniestroj/rs485conf/blob/master/main.c )

First of all I enable rs485 for ttymxc3 using the rs485conf application:

root@imx6qsabresd:/home# ./rs485conf  /dev/ttymxc3 -e 1
[   27.106517] random: crng init done
= Current configuration:
RS485 enabled:false
RTS on send:  high
RTS after send:   low
RTS delay before send:0
RTS delay after send: 0
Receive during sending data:  true

= New configuration:
RS485 enabled:true
RTS on send:  high
RTS after send:   low
RTS delay before send:0
RTS delay after send: 0
Receive during sending data:  true

= Saved configuration:
RS485 enabled:true
RTS on send:  high
RTS after send:   low
RTS delay before send:0
RTS delay after send: 0
Receive during sending data:  true
root@imx6qsabresd:/ho

Then

root@imx6qsabresd:/home# echo A > /dev/ttymxc3

(wait 10 seconds)

root@imx6qsabresd:/home# echo B > /dev/ttymxc3

(wait 10 seconds)

root@imx6qsabresd:/home# echo C > /dev/ttymxc3

On the serial console at 9600bps only the:
A
B
C

are seen, so not duplicated characters, nor noise is seen on the console.

Regards,

Fabio Estevam

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
 wrote:

> Just remuxed GPIO signals to these pads, applied your two patches and
> used rts-gpios in the DT but I still see the same problem :/
>
> When transmit something, I get doubled characters, then zeros and at the
> end garbled data of previous transmissions, same as described in my
> first post (Logic analyzer: https://pqgruber.com/rs485_results.png)
> The data is always 4096 bytes long, this explains why the echo command
> is blocking for about 4 seconds (<- 4096 bytes at a baudrate of 9600).
> The TE line is also high until all 4096 bytes are sent.
>
> I think this comes from the UART_XMIT_SIZE which is defined to the page
> size.
> Maybe there is something wrong in imx_transmit_buffer and leads to the
> whole circular buffer being sent out all the time, not stopping..
>
> Do these debug logs tell you anything?
> https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5
>
> I am analyzing the signals coming directly from the i.MX6Q, so this must
> be a software problem, but I don't understand why it works for you, if
> we use the same software.
>
> Do you use any other patches on top of mainline and do you use the SDMA
> scripts from the ROM?

No, I use the original 4.9 + the two patches I sent. Yes, I do use the
SDMA scripts from ROM.

Here is the procedure I did to try to reproduce the issue you reported:

(The rs485conf is available at:
https://github.com/mniestroj/rs485conf/blob/master/main.c )

First of all I enable rs485 for ttymxc3 using the rs485conf application:

root@imx6qsabresd:/home# ./rs485conf  /dev/ttymxc3 -e 1
[   27.106517] random: crng init done
= Current configuration:
RS485 enabled:false
RTS on send:  high
RTS after send:   low
RTS delay before send:0
RTS delay after send: 0
Receive during sending data:  true

= New configuration:
RS485 enabled:true
RTS on send:  high
RTS after send:   low
RTS delay before send:0
RTS delay after send: 0
Receive during sending data:  true

= Saved configuration:
RS485 enabled:true
RTS on send:  high
RTS after send:   low
RTS delay before send:0
RTS delay after send: 0
Receive during sending data:  true
root@imx6qsabresd:/ho

Then

root@imx6qsabresd:/home# echo A > /dev/ttymxc3

(wait 10 seconds)

root@imx6qsabresd:/home# echo B > /dev/ttymxc3

(wait 10 seconds)

root@imx6qsabresd:/home# echo C > /dev/ttymxc3

On the serial console at 9600bps only the:
A
B
C

are seen, so not duplicated characters, nor noise is seen on the console.

Regards,

Fabio Estevam

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On Sun, Jan 8, 2017 at 2:45 AM, Rafael J. Wysocki  wrote:
> On Sun, Jan 8, 2017 at 2:01 AM, Borislav Petkov  wrote:
>> On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote:
>>> So we get the table, but apparently we crash when we attempt to put it.
>>
>> Right, except on 4.10-rc2 we don't crash but we freeze early. These are
>> the last lines:
>>
>> ...
>> [0.004778] mce: CPU supports 7 MCE banks
>> [0.004861] LVT offset 1 assigned for vector 0xf9
>> [0.004945] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
>> [0.005025] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512, 1GB 0
>> [0.005165] Freeing SMP alternatives memory: 24K
>> [0.211154] ftrace: allocating 25022 entries in 98 pages
>> [0.219614] smpboot: Max logical packages: 2
>> 
>>
>>> Let's try to check the obvious just to rule it out (see attached), but
>>> honestly I'm not sure what's going on in there.
>>
>> No change, same freeze.
>
> I was afraid that that would be the case.
>
> Can you try to comment out the acpi_put_table() in
> early_amd_iommu_init() and see if that makes any difference?

Well, there is a bug in early_amd_iommu_init() that may matter in
theory if the table checksum is incorrect.

Please see if the attached makes any difference.

Thanks,
Rafael
---
 drivers/iommu/amd_iommu_init.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/drivers/iommu/amd_iommu_init.c
===
--- linux-pm.orig/drivers/iommu/amd_iommu_init.c
+++ linux-pm/drivers/iommu/amd_iommu_init.c
@@ -2230,7 +2230,7 @@ static int __init early_amd_iommu_init(v
 	 */
 	ret = check_ivrs_checksum(ivrs_base);
 	if (ret)
-		return ret;
+		goto out;
 
 	amd_iommu_target_ivhd_type = get_highest_supported_ivhd_type(ivrs_base);
 	DUMP_printk("Using IVHD type %#x\n", amd_iommu_target_ivhd_type);

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On Sun, Jan 8, 2017 at 2:45 AM, Rafael J. Wysocki  wrote:
> On Sun, Jan 8, 2017 at 2:01 AM, Borislav Petkov  wrote:
>> On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote:
>>> So we get the table, but apparently we crash when we attempt to put it.
>>
>> Right, except on 4.10-rc2 we don't crash but we freeze early. These are
>> the last lines:
>>
>> ...
>> [0.004778] mce: CPU supports 7 MCE banks
>> [0.004861] LVT offset 1 assigned for vector 0xf9
>> [0.004945] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
>> [0.005025] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512, 1GB 0
>> [0.005165] Freeing SMP alternatives memory: 24K
>> [0.211154] ftrace: allocating 25022 entries in 98 pages
>> [0.219614] smpboot: Max logical packages: 2
>> 
>>
>>> Let's try to check the obvious just to rule it out (see attached), but
>>> honestly I'm not sure what's going on in there.
>>
>> No change, same freeze.
>
> I was afraid that that would be the case.
>
> Can you try to comment out the acpi_put_table() in
> early_amd_iommu_init() and see if that makes any difference?

Well, there is a bug in early_amd_iommu_init() that may matter in
theory if the table checksum is incorrect.

Please see if the attached makes any difference.

Thanks,
Rafael
---
 drivers/iommu/amd_iommu_init.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/drivers/iommu/amd_iommu_init.c
===
--- linux-pm.orig/drivers/iommu/amd_iommu_init.c
+++ linux-pm/drivers/iommu/amd_iommu_init.c
@@ -2230,7 +2230,7 @@ static int __init early_amd_iommu_init(v
 	 */
 	ret = check_ivrs_checksum(ivrs_base);
 	if (ret)
-		return ret;
+		goto out;
 
 	amd_iommu_target_ivhd_type = get_highest_supported_ivhd_type(ivrs_base);
 	DUMP_printk("Using IVHD type %#x\n", amd_iommu_target_ivhd_type);

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Linus Torvalds]

On Sat, Jan 7, 2017 at 6:02 PM, Johannes Weiner  wrote:
>
> Linus? Andrew?

Looks fine to me. Will apply.

   Linus

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Linus Torvalds]

On Sat, Jan 7, 2017 at 6:02 PM, Johannes Weiner  wrote:
>
> Linus? Andrew?

Looks fine to me. Will apply.

   Linus

Re: [net-next v1 0/8] netcp: enhancements and minor fixes

[David Miller]

From: Murali Karicheri 
Date: Fri, 6 Jan 2017 15:37:38 -0500

> This series is for net-next. This propagates enhancements and minor
> bug fixes from internal version of the driver to keep the upstream
> in sync. Please review and apply if this looks good.
> 
> Tested on all of K2HK/E/L boards with nfs rootfs.
> Test logs below
> K2HK-EVM: http://pastebin.ubuntu.com/23754106/
> k2L-EVM: http://pastebin.ubuntu.com/23754143/
> K2E-EVM: http://pastebin.ubuntu.com/23754159/
> 
> History:
>   v1 - dropped 1/10 amd 2/10 of v0 based on comments from Rob as
>it needs more work before submission
>   v0 - Initial version

Series applied, thanks.

Re: [net-next v1 0/8] netcp: enhancements and minor fixes

[David Miller]

From: Murali Karicheri 
Date: Fri, 6 Jan 2017 15:37:38 -0500

> This series is for net-next. This propagates enhancements and minor
> bug fixes from internal version of the driver to keep the upstream
> in sync. Please review and apply if this looks good.
> 
> Tested on all of K2HK/E/L boards with nfs rootfs.
> Test logs below
> K2HK-EVM: http://pastebin.ubuntu.com/23754106/
> k2L-EVM: http://pastebin.ubuntu.com/23754143/
> K2E-EVM: http://pastebin.ubuntu.com/23754159/
> 
> History:
>   v1 - dropped 1/10 amd 2/10 of v0 based on comments from Rob as
>it needs more work before submission
>   v0 - Initial version

Series applied, thanks.

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Johannes Weiner]

On Tue, Jan 03, 2017 at 01:28:25PM +0100, Jan Kara wrote:
> On Mon 02-01-17 16:11:36, Johannes Weiner wrote:
> > On Fri, Dec 23, 2016 at 03:33:29AM -0500, Johannes Weiner wrote:
> > > On Fri, Dec 23, 2016 at 02:32:41AM -0500, Johannes Weiner wrote:
> > > > On Thu, Dec 22, 2016 at 12:22:27PM -0800, Hugh Dickins wrote:
> > > > > On Wed, 21 Dec 2016, Linus Torvalds wrote:
> > > > > > On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner  
> > > > > > wrote:
> > > > > > > I unmounted the fs, mkfs'd it again, ran the
> > > > > > > workload again and about a minute in this fired:
> > > > > > >
> > > > > > > [628867.607417] [ cut here ]
> > > > > > > [628867.608603] WARNING: CPU: 2 PID: 16925 at mm/workingset.c:461 
> > > > > > > shadow_lru_isolate+0x171/0x220
> > > > > > 
> > > > > > Well, part of the changes during the merge window were the shadow
> > > > > > entry tracking changes that came in through Andrew's tree. Adding
> > > > > > Johannes Weiner to the participants.

Okay, the below patch should address this problem. Dave Jones managed
to reproduce it with the added WARN_ONs, and they made it obvious. He
cannot trigger it anymore with this fix applied. Thanks Dave!

Linus? Andrew?

---

>From 503eeb20e68bdf3529bdc14aca1ce564880129f2 Mon Sep 17 00:00:00 2001
From: Johannes Weiner 
Date: Fri, 6 Jan 2017 19:21:43 -0500
Subject: [PATCH] mm: workingset: fix use-after-free in shadow node shrinker

Several people report seeing warnings about inconsistent radix tree
nodes followed by crashes in the workingset code, which all looked
like use-after-free access from the shadow node shrinker. Dave Jones
managed to reproduce the issue with a debug patch applied, which
confirmed that the radix tree shrinking indeed frees shadow nodes
while they are still linked to the shadow LRU:

  WARNING: CPU: 2 PID: 53 at lib/radix-tree.c:643 delete_node+0x1e4/0x200
  CPU: 2 PID: 53 Comm: kswapd0 Not tainted 4.10.0-rc2-think+ #3
  Call Trace:
   dump_stack+0x4f/0x73
   __warn+0xcb/0xf0
   warn_slowpath_null+0x1d/0x20
   delete_node+0x1e4/0x200
   __radix_tree_delete_node+0xd/0x10
   shadow_lru_isolate+0xe6/0x220
   __list_lru_walk_one.isra.4+0x9b/0x190
   ? memcg_drain_all_list_lrus+0x1d0/0x1d0
   list_lru_walk_one+0x23/0x30
   scan_shadow_nodes+0x2e/0x40
   shrink_slab.part.44+0x23d/0x5d0
   ? 0xa023a077
   shrink_node+0x22c/0x330
   kswapd+0x392/0x8f0

This is the WARN_ON_ONCE(!list_empty(>private_list)) placed in
the inlined radix_tree_shrink().

The problem is with 14b468791fa9 ("mm: workingset: move shadow entry
tracking to radix tree exceptional tracking"), which passes an update
callback into the radix tree to link and unlink shadow leaf nodes when
tree entries change, but forgot to pass the callback when reclaiming a
shadow node. While the reclaimed shadow node itself is unlinked by the
shrinker, its deletion from the tree can cause the left-most leaf node
in the tree to be shrunk. If that happens to be a shadow node as well,
we don't unlink it from the LRU as we should.

Consider this tree, where the s are shadow entries:

 root->rnode
  |
 [0   n]
  |   |
   [s] [s]

Now the shadow node shrinker reclaims the rightmost leaf node through
the shadow node LRU:

 root->rnode
  |
 [0]
  |
  [s ]

Because the parent of the deleted node is the first level below the
root and has only one child in the left-most slot, the intermediate
level is shrunk and the node containing the single shadow is put in
its place:

 root->rnode
  |
 [s]

The shrinker again sees a single left-most slot in a first level node
and thus decides to store the shadow in root->rnode directly and free
the node - which is a leaf node on the shadow node LRU.

root->rnode
 |
 s

Without the update callback, the freed node remains on the shadow LRU,
where it causes later shrinker runs to crash.

Pass the node updater callback into __radix_tree_delete_node() in case
the deletion causes the left-most branch in the tree to collapse too.

Also add warnings when linked nodes are freed right away, rather than
wait for the use-after-free when the list is scanned much later.

Fixes: 14b468791fa9 ("mm: workingset: move shadow entry tracking to radix tree 
exceptional tracking")
Reported-by: Dave Chinner 
Reported-by: Hugh Dickins 
Reported-by: Andrea Arcangeli 
Reported-by: Dave Jones 
Tested-by: Dave Jones 
Signed-off-by: Johannes Weiner 
---
 include/linux/radix-tree.h |  4 +++-
 lib/radix-tree.c   | 11 +--
 mm/workingset.c|  3 ++-
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
index 5dea8f6440e4..52bda854593b 100644
--- a/include/linux/radix-tree.h
+++ b/include/linux/radix-tree.h

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Johannes Weiner]

On Tue, Jan 03, 2017 at 01:28:25PM +0100, Jan Kara wrote:
> On Mon 02-01-17 16:11:36, Johannes Weiner wrote:
> > On Fri, Dec 23, 2016 at 03:33:29AM -0500, Johannes Weiner wrote:
> > > On Fri, Dec 23, 2016 at 02:32:41AM -0500, Johannes Weiner wrote:
> > > > On Thu, Dec 22, 2016 at 12:22:27PM -0800, Hugh Dickins wrote:
> > > > > On Wed, 21 Dec 2016, Linus Torvalds wrote:
> > > > > > On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner  
> > > > > > wrote:
> > > > > > > I unmounted the fs, mkfs'd it again, ran the
> > > > > > > workload again and about a minute in this fired:
> > > > > > >
> > > > > > > [628867.607417] [ cut here ]
> > > > > > > [628867.608603] WARNING: CPU: 2 PID: 16925 at mm/workingset.c:461 
> > > > > > > shadow_lru_isolate+0x171/0x220
> > > > > > 
> > > > > > Well, part of the changes during the merge window were the shadow
> > > > > > entry tracking changes that came in through Andrew's tree. Adding
> > > > > > Johannes Weiner to the participants.

Okay, the below patch should address this problem. Dave Jones managed
to reproduce it with the added WARN_ONs, and they made it obvious. He
cannot trigger it anymore with this fix applied. Thanks Dave!

Linus? Andrew?

---

>From 503eeb20e68bdf3529bdc14aca1ce564880129f2 Mon Sep 17 00:00:00 2001
From: Johannes Weiner 
Date: Fri, 6 Jan 2017 19:21:43 -0500
Subject: [PATCH] mm: workingset: fix use-after-free in shadow node shrinker

Several people report seeing warnings about inconsistent radix tree
nodes followed by crashes in the workingset code, which all looked
like use-after-free access from the shadow node shrinker. Dave Jones
managed to reproduce the issue with a debug patch applied, which
confirmed that the radix tree shrinking indeed frees shadow nodes
while they are still linked to the shadow LRU:

  WARNING: CPU: 2 PID: 53 at lib/radix-tree.c:643 delete_node+0x1e4/0x200
  CPU: 2 PID: 53 Comm: kswapd0 Not tainted 4.10.0-rc2-think+ #3
  Call Trace:
   dump_stack+0x4f/0x73
   __warn+0xcb/0xf0
   warn_slowpath_null+0x1d/0x20
   delete_node+0x1e4/0x200
   __radix_tree_delete_node+0xd/0x10
   shadow_lru_isolate+0xe6/0x220
   __list_lru_walk_one.isra.4+0x9b/0x190
   ? memcg_drain_all_list_lrus+0x1d0/0x1d0
   list_lru_walk_one+0x23/0x30
   scan_shadow_nodes+0x2e/0x40
   shrink_slab.part.44+0x23d/0x5d0
   ? 0xa023a077
   shrink_node+0x22c/0x330
   kswapd+0x392/0x8f0

This is the WARN_ON_ONCE(!list_empty(>private_list)) placed in
the inlined radix_tree_shrink().

The problem is with 14b468791fa9 ("mm: workingset: move shadow entry
tracking to radix tree exceptional tracking"), which passes an update
callback into the radix tree to link and unlink shadow leaf nodes when
tree entries change, but forgot to pass the callback when reclaiming a
shadow node. While the reclaimed shadow node itself is unlinked by the
shrinker, its deletion from the tree can cause the left-most leaf node
in the tree to be shrunk. If that happens to be a shadow node as well,
we don't unlink it from the LRU as we should.

Consider this tree, where the s are shadow entries:

 root->rnode
  |
 [0   n]
  |   |
   [s] [s]

Now the shadow node shrinker reclaims the rightmost leaf node through
the shadow node LRU:

 root->rnode
  |
 [0]
  |
  [s ]

Because the parent of the deleted node is the first level below the
root and has only one child in the left-most slot, the intermediate
level is shrunk and the node containing the single shadow is put in
its place:

 root->rnode
  |
 [s]

The shrinker again sees a single left-most slot in a first level node
and thus decides to store the shadow in root->rnode directly and free
the node - which is a leaf node on the shadow node LRU.

root->rnode
 |
 s

Without the update callback, the freed node remains on the shadow LRU,
where it causes later shrinker runs to crash.

Pass the node updater callback into __radix_tree_delete_node() in case
the deletion causes the left-most branch in the tree to collapse too.

Also add warnings when linked nodes are freed right away, rather than
wait for the use-after-free when the list is scanned much later.

Fixes: 14b468791fa9 ("mm: workingset: move shadow entry tracking to radix tree 
exceptional tracking")
Reported-by: Dave Chinner 
Reported-by: Hugh Dickins 
Reported-by: Andrea Arcangeli 
Reported-by: Dave Jones 
Tested-by: Dave Jones 
Signed-off-by: Johannes Weiner 
---
 include/linux/radix-tree.h |  4 +++-
 lib/radix-tree.c   | 11 +--
 mm/workingset.c|  3 ++-
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
index 5dea8f6440e4..52bda854593b 100644
--- a/include/linux/radix-tree.h
+++ b/include/linux/radix-tree.h
@@ -306,7 +306,9 @@ void radix_tree_iter_replace(struct radix_tree_root *,
 void radix_tree_replace_slot(struct radix_tree_root *root,
 void 

Re: [PATCH v2 0/7] net: ethernet: ti: cpsw: support placing CPDMA descriptors into DDR

[David Miller]

From: Grygorii Strashko 
Date: Fri, 6 Jan 2017 14:07:28 -0600

> This series intended to add support for placing CPDMA descriptors into DDR by
> introducing new module parameter "descs_pool_size" to specify size of 
> descriptor's
> pool. The "descs_pool_size" defines total number of CPDMA
> CPPI descriptors to be used for both ingress/egress packets
> processing. If not specified - the default value 256 will be used
> which will allow to place descriptor's pool into the internal CPPI
> RAM.
> 
> In addition, added ability to re-split CPDMA pool of descriptors between RX 
> and TX
> path via ethtool '-G' command wich will allow to configure and fix number
> of descriptors used by RX and TX path, which, then, will be split between
> RX/TX channels proportionally depending on number of RX/TX channels and
> its weight. 
> 
> This allows significantly to reduce UDP packets drop rate
> for bandwidth >301 Mbits/sec (am57x).  
> 
> Before enabling this feature, the am437x SoC has to be fixed as it's proved
> that it's not working when CPDMA descriptors placed in DDR.
> So, the patch 1 fixes this issue.

Series applied to net-next, thanks.

Re: [PATCH v2 0/7] net: ethernet: ti: cpsw: support placing CPDMA descriptors into DDR

[David Miller]

From: Grygorii Strashko 
Date: Fri, 6 Jan 2017 14:07:28 -0600

> This series intended to add support for placing CPDMA descriptors into DDR by
> introducing new module parameter "descs_pool_size" to specify size of 
> descriptor's
> pool. The "descs_pool_size" defines total number of CPDMA
> CPPI descriptors to be used for both ingress/egress packets
> processing. If not specified - the default value 256 will be used
> which will allow to place descriptor's pool into the internal CPPI
> RAM.
> 
> In addition, added ability to re-split CPDMA pool of descriptors between RX 
> and TX
> path via ethtool '-G' command wich will allow to configure and fix number
> of descriptors used by RX and TX path, which, then, will be split between
> RX/TX channels proportionally depending on number of RX/TX channels and
> its weight. 
> 
> This allows significantly to reduce UDP packets drop rate
> for bandwidth >301 Mbits/sec (am57x).  
> 
> Before enabling this feature, the am437x SoC has to be fixed as it's proved
> that it's not working when CPDMA descriptors placed in DDR.
> So, the patch 1 fixes this issue.

Series applied to net-next, thanks.

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On Sun, Jan 8, 2017 at 2:01 AM, Borislav Petkov  wrote:
> On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote:
>> So we get the table, but apparently we crash when we attempt to put it.
>
> Right, except on 4.10-rc2 we don't crash but we freeze early. These are
> the last lines:
>
> ...
> [0.004778] mce: CPU supports 7 MCE banks
> [0.004861] LVT offset 1 assigned for vector 0xf9
> [0.004945] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
> [0.005025] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512, 1GB 0
> [0.005165] Freeing SMP alternatives memory: 24K
> [0.211154] ftrace: allocating 25022 entries in 98 pages
> [0.219614] smpboot: Max logical packages: 2
> 
>
>> Let's try to check the obvious just to rule it out (see attached), but
>> honestly I'm not sure what's going on in there.
>
> No change, same freeze.

I was afraid that that would be the case.

Can you try to comment out the acpi_put_table() in
early_amd_iommu_init() and see if that makes any difference?

Thanks,
Rafael

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On Sun, Jan 8, 2017 at 2:01 AM, Borislav Petkov  wrote:
> On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote:
>> So we get the table, but apparently we crash when we attempt to put it.
>
> Right, except on 4.10-rc2 we don't crash but we freeze early. These are
> the last lines:
>
> ...
> [0.004778] mce: CPU supports 7 MCE banks
> [0.004861] LVT offset 1 assigned for vector 0xf9
> [0.004945] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
> [0.005025] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512, 1GB 0
> [0.005165] Freeing SMP alternatives memory: 24K
> [0.211154] ftrace: allocating 25022 entries in 98 pages
> [0.219614] smpboot: Max logical packages: 2
> 
>
>> Let's try to check the obvious just to rule it out (see attached), but
>> honestly I'm not sure what's going on in there.
>
> No change, same freeze.

I was afraid that that would be the case.

Can you try to comment out the acpi_put_table() in
early_amd_iommu_init() and see if that makes any difference?

Thanks,
Rafael

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

[David Miller]

From: Eric Biggers 
Date: Sat, 7 Jan 2017 14:09:11 -0800

> Well, except those instructions aren't actually used in these
> places.  Although x86_64 SHA1-NI accelerated SHA-1 is available in
> the Linux crypto API, it seems that in kernel code it remains
> impractical to use these instructions on small amounts of data
> because they use XMM registers, which means the overhead of
> kernel_fpu_begin()/kernel_fpu_end() must be incurred.  Furthermore,
> kernel_fpu_begin() is not allowed in all contexts so there has to be
> a fallback.
> 
> Out of curiosity, is this actually a solvable problem, e.g. by
> making the code using the XMM registers responsible for saving and
> restoring the ones clobbered, or by optimizing
> kernel_fpu_begin()/kernel_fpu_end()?  Or does it in fact remain
> impractical for such instructions to be used for applications like
> this one?

On x86 making the FPU save more tractible in situations like this is
really hard and will make the code significantly more complex.

It's simpler and cheaper on sparc64, and unlike on x86 there aren't
any fundament restrictions on where FPU stuff can be used.  This is
because we don't have "save all the FPU state" instructions and have
to do it all by hand anyways.

However I will note that just like x86, sparc64 doesn't override the
md5_transform() in lib/md5.c like it should.

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

[David Miller]

From: Eric Biggers 
Date: Sat, 7 Jan 2017 14:09:11 -0800

> Well, except those instructions aren't actually used in these
> places.  Although x86_64 SHA1-NI accelerated SHA-1 is available in
> the Linux crypto API, it seems that in kernel code it remains
> impractical to use these instructions on small amounts of data
> because they use XMM registers, which means the overhead of
> kernel_fpu_begin()/kernel_fpu_end() must be incurred.  Furthermore,
> kernel_fpu_begin() is not allowed in all contexts so there has to be
> a fallback.
> 
> Out of curiosity, is this actually a solvable problem, e.g. by
> making the code using the XMM registers responsible for saving and
> restoring the ones clobbered, or by optimizing
> kernel_fpu_begin()/kernel_fpu_end()?  Or does it in fact remain
> impractical for such instructions to be used for applications like
> this one?

On x86 making the FPU save more tractible in situations like this is
really hard and will make the code significantly more complex.

It's simpler and cheaper on sparc64, and unlike on x86 there aren't
any fundament restrictions on where FPU stuff can be used.  This is
because we don't have "save all the FPU state" instructions and have
to do it all by hand anyways.

However I will note that just like x86, sparc64 doesn't override the
md5_transform() in lib/md5.c like it should.

[PATCH] media: fix dm1105.c build error

[Randy Dunlap]

From: Randy Dunlap 

Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and
CONFIG_DVB_DM1105=y.

drivers/built-in.o: In function `dm1105_probe':
dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus'

Signed-off-by: Randy Dunlap 
Reported-by: kbuild test robot 
Cc: Javier Martinez Canillas 
Cc: sta...@vger.kernel.org # applies to 4.0 (maybe even 3.x)
---
 drivers/media/pci/dm1105/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-410-rc2.orig/drivers/media/pci/dm1105/Kconfig
+++ lnx-410-rc2/drivers/media/pci/dm1105/Kconfig
@@ -1,6 +1,6 @@
 config DVB_DM1105
tristate "SDMC DM1105 based PCI cards"
-   depends on DVB_CORE && PCI && I2C
+   depends on DVB_CORE && PCI && I2C && I2C_ALGOBIT
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0299 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0288 if MEDIA_SUBDRV_AUTOSELECT

[PATCH] media: fix dm1105.c build error

[Randy Dunlap]

From: Randy Dunlap 

Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and
CONFIG_DVB_DM1105=y.

drivers/built-in.o: In function `dm1105_probe':
dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus'

Signed-off-by: Randy Dunlap 
Reported-by: kbuild test robot 
Cc: Javier Martinez Canillas 
Cc: sta...@vger.kernel.org # applies to 4.0 (maybe even 3.x)
---
 drivers/media/pci/dm1105/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-410-rc2.orig/drivers/media/pci/dm1105/Kconfig
+++ lnx-410-rc2/drivers/media/pci/dm1105/Kconfig
@@ -1,6 +1,6 @@
 config DVB_DM1105
tristate "SDMC DM1105 based PCI cards"
-   depends on DVB_CORE && PCI && I2C
+   depends on DVB_CORE && PCI && I2C && I2C_ALGOBIT
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0299 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0288 if MEDIA_SUBDRV_AUTOSELECT

Re: [PATCH v5] net: stmmac: fix maxmtu assignment to be within valid range

[Andy Shevchenko]

On Sat, Jan 7, 2017 at 11:32 AM, Kweh, Hock Leong
 wrote:
> From: "Kweh, Hock Leong" 
>
> There is no checking valid value of maxmtu when getting it from
> device tree. This resolution added the checking condition to
> ensure the assignment is made within a valid range.

FWIW:
Reviewed-by: Andy Shevchenko 

>
> Signed-off-by: Kweh, Hock Leong 
> ---
> changelog v5:
> * revert back that plat->maxmtu > ndev->max_mtu is a valid case
>   when ndev->max_mtu assignment is entering to the else statement
> * add comment to enchance clarification
>
> changelog v4:
> * add print warning message when maxmtu > max_mtu as well
> * add maxmtu = JUMBO_LEN into each *_default_data() at stmmac_pci.c
>
> changelog v3:
> * print the warning message only if maxmtu < min_mtu
> * add maxmtu = JUMBO_LEN at stmmac_pci.c to follow stmmac_platform.c
>
> changelog v2:
> * correction of "devicetree" to "device tree" reported by Andy
> * print warning message while maxmtu is not in valid range
>
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |   10 +-
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c  |6 ++
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 92ac006..8e56dc4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3345,8 +3345,16 @@ int stmmac_dvr_probe(struct device *device,
> ndev->max_mtu = JUMBO_LEN;
> else
> ndev->max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
> -   if (priv->plat->maxmtu < ndev->max_mtu)
> +   /* Will not overwrite ndev->max_mtu if plat->maxmtu > ndev->max_mtu
> +* as well as plat->maxmtu < ndev->min_mtu which is a invalid range.
> +*/
> +   if ((priv->plat->maxmtu < ndev->max_mtu) &&
> +   (priv->plat->maxmtu >= ndev->min_mtu))
> ndev->max_mtu = priv->plat->maxmtu;
> +   else if (priv->plat->maxmtu < ndev->min_mtu)
> +   netdev_warn(priv->dev,
> +   "%s: warning: maxmtu having invalid value (%d)\n",
> +   __func__, priv->plat->maxmtu);
>
> if (flow_ctrl)
> priv->flow_ctrl = FLOW_AUTO;/* RX/TX pause on */
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> index a283177..3da4737 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> @@ -89,6 +89,9 @@ static void stmmac_default_data(struct plat_stmmacenet_data 
> *plat)
>
> /* Set default value for unicast filter entries */
> plat->unicast_filter_entries = 1;
> +
> +   /* Set the maxmtu to a default of JUMBO_LEN */
> +   plat->maxmtu = JUMBO_LEN;
>  }
>
>  static int quark_default_data(struct plat_stmmacenet_data *plat,
> @@ -126,6 +129,9 @@ static int quark_default_data(struct plat_stmmacenet_data 
> *plat,
> /* Set default value for unicast filter entries */
> plat->unicast_filter_entries = 1;
>
> +   /* Set the maxmtu to a default of JUMBO_LEN */
> +   plat->maxmtu = JUMBO_LEN;
> +
> return 0;
>  }
>
> --
> 1.7.9.5
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5] net: stmmac: fix maxmtu assignment to be within valid range

[Andy Shevchenko]

On Sat, Jan 7, 2017 at 11:32 AM, Kweh, Hock Leong
 wrote:
> From: "Kweh, Hock Leong" 
>
> There is no checking valid value of maxmtu when getting it from
> device tree. This resolution added the checking condition to
> ensure the assignment is made within a valid range.

FWIW:
Reviewed-by: Andy Shevchenko 

>
> Signed-off-by: Kweh, Hock Leong 
> ---
> changelog v5:
> * revert back that plat->maxmtu > ndev->max_mtu is a valid case
>   when ndev->max_mtu assignment is entering to the else statement
> * add comment to enchance clarification
>
> changelog v4:
> * add print warning message when maxmtu > max_mtu as well
> * add maxmtu = JUMBO_LEN into each *_default_data() at stmmac_pci.c
>
> changelog v3:
> * print the warning message only if maxmtu < min_mtu
> * add maxmtu = JUMBO_LEN at stmmac_pci.c to follow stmmac_platform.c
>
> changelog v2:
> * correction of "devicetree" to "device tree" reported by Andy
> * print warning message while maxmtu is not in valid range
>
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |   10 +-
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c  |6 ++
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 92ac006..8e56dc4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3345,8 +3345,16 @@ int stmmac_dvr_probe(struct device *device,
> ndev->max_mtu = JUMBO_LEN;
> else
> ndev->max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
> -   if (priv->plat->maxmtu < ndev->max_mtu)
> +   /* Will not overwrite ndev->max_mtu if plat->maxmtu > ndev->max_mtu
> +* as well as plat->maxmtu < ndev->min_mtu which is a invalid range.
> +*/
> +   if ((priv->plat->maxmtu < ndev->max_mtu) &&
> +   (priv->plat->maxmtu >= ndev->min_mtu))
> ndev->max_mtu = priv->plat->maxmtu;
> +   else if (priv->plat->maxmtu < ndev->min_mtu)
> +   netdev_warn(priv->dev,
> +   "%s: warning: maxmtu having invalid value (%d)\n",
> +   __func__, priv->plat->maxmtu);
>
> if (flow_ctrl)
> priv->flow_ctrl = FLOW_AUTO;/* RX/TX pause on */
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> index a283177..3da4737 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> @@ -89,6 +89,9 @@ static void stmmac_default_data(struct plat_stmmacenet_data 
> *plat)
>
> /* Set default value for unicast filter entries */
> plat->unicast_filter_entries = 1;
> +
> +   /* Set the maxmtu to a default of JUMBO_LEN */
> +   plat->maxmtu = JUMBO_LEN;
>  }
>
>  static int quark_default_data(struct plat_stmmacenet_data *plat,
> @@ -126,6 +129,9 @@ static int quark_default_data(struct plat_stmmacenet_data 
> *plat,
> /* Set default value for unicast filter entries */
> plat->unicast_filter_entries = 1;
>
> +   /* Set the maxmtu to a default of JUMBO_LEN */
> +   plat->maxmtu = JUMBO_LEN;
> +
> return 0;
>  }
>
> --
> 1.7.9.5
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v7 2/3] serial: exar: split out the exar code from 8250_pci

[Andy Shevchenko]

On Sun, Jan 8, 2017 at 1:57 AM, Sudip Mukherjee
 wrote:
> Add the serial driver for the exar chips. And also register the
> platform device for the exar gpio.

Did you ignore some comments?

IIRC I recommended to use proper vendor name like Exar (or how is it spelled?).

> Headers, if arranged in alphabetical order, will give a build warning.

I think I know how to make it better.

> And thanks for revewing that v6. I think those were the worst patch I
> have ever posted.

You may do even more better. See below.

> +#undef DEBUG

> +#include 

(1)

> +#include 

Squeez this to the rest

> +#include 

(2)

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

You perhaps need something like this here:

+ empty line
(1) +#include 

> +

(2) +#include 

> +#include "8250.h"

> +
> +#define PCI_NUM_BAR_RESOURCES  6
> +
> +struct exar8250;


> +
> +struct exar8250_board {
> +   unsigned int num_ports;
> +   unsigned int base_baud;
> +   unsigned int uart_offset; /* the space between channels */
> +   /*
> +* reg_shift:  describes how the UART registers are mapped
> +* to PCI memory by the card.
> +*/
> +   unsigned int reg_shift;
> +   unsigned int first_offset;
> +   int (*setup)(struct exar8250 *,
> +const struct exar8250_board *,
> +struct uart_8250_port *, int);
> +   void(*exit)(struct pci_dev *dev);
> +};
> +
> +struct exar8250 {

> +   struct pci_dev  *dev;

You perhaps don't need to save parent device, thus

struct device *dev;

here and users will do

struct pci_dev *pci_dev = to_pci_dev(dev);

when needed.

> +   unsigned intnr;
> +   struct exar8250_board   *board;
> +   int line[0];
> +};
> +
> +static int default_setup(struct exar8250 *priv,
> +const struct exar8250_board *board,
> +struct uart_8250_port *port, int idx)
> +{
> +   unsigned int bar = 0, offset = board->first_offset, maxnr;
> +   struct pci_dev *dev = priv->dev;
> +
> +   offset += idx * board->uart_offset;
> +

> +   maxnr = (pci_resource_len(dev, bar) - board->first_offset) >>
> +   (board->reg_shift + 3);

Can be calculated once?

> +
> +   if (idx >= maxnr)
> +   return 1;
> +

> +   if (!pcim_iomap(dev, bar, 0) && !pcim_iomap_table(dev))
> +   return -ENOMEM;

Do you need to check this per port? In probe you would know this.

> +
> +   port->port.iotype = UPIO_MEM;
> +   port->port.iobase = 0;
> +   port->port.mapbase = pci_resource_start(dev, bar) + offset;
> +   port->port.membase = pcim_iomap_table(dev)[bar] + offset;
> +   port->port.regshift = board->reg_shift;
> +
> +   return 0;
> +}
> +
> +static int
> +pci_xr17c154_setup(struct exar8250 *priv,
> +  const struct exar8250_board *board,
> + struct uart_8250_port *port, int idx)
> +{
> +   port->port.flags |= UPF_EXAR_EFR;
> +   return default_setup(priv, board, port, idx);
> +}
> +

> +static inline int
> +xr17v35x_has_slave(struct exar8250 *priv)
> +{
> +   const int dev_id = priv->dev->device;
> +
> +   return ((dev_id == PCI_DEVICE_ID_EXAR_XR17V4358) ||
> +   (dev_id == PCI_DEVICE_ID_EXAR_XR17V8358));
> +}

Can be easily converted to
unsigned int flags;
in your custom struct, and be assigned constantly based on ID.

> +
> +static int
> +pci_xr17v35x_setup(struct exar8250 *priv,
> +  const struct exar8250_board *board,
> + struct uart_8250_port *port, int idx)
> +{
> +   u8 __iomem *p;
> +   int ret;
> +
> +   p = pci_ioremap_bar(priv->dev, 0);
> +   if (!p)
> +   return -ENOMEM;
> +
> +   port->port.flags |= UPF_EXAR_EFR;
> +
> +   /*
> +* Setup the uart clock for the devices on expansion slot to
> +* half the clock speed of the main chip (which is 125MHz)
> +*/
> +   if (xr17v35x_has_slave(priv) && idx >= 8)
> +   port->port.uartclk = (7812500 * 16 / 2);
> +
> +   /*
> +* Setup Multipurpose Input/Output pins.
> +*/

> +   if (idx == 0) {
> +   writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
> +   writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
> +   writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
> +   writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
> +   writeb(0x00, p + 

Re: [PATCH v7 2/3] serial: exar: split out the exar code from 8250_pci

[Andy Shevchenko]

On Sun, Jan 8, 2017 at 1:57 AM, Sudip Mukherjee
 wrote:
> Add the serial driver for the exar chips. And also register the
> platform device for the exar gpio.

Did you ignore some comments?

IIRC I recommended to use proper vendor name like Exar (or how is it spelled?).

> Headers, if arranged in alphabetical order, will give a build warning.

I think I know how to make it better.

> And thanks for revewing that v6. I think those were the worst patch I
> have ever posted.

You may do even more better. See below.

> +#undef DEBUG

> +#include 

(1)

> +#include 

Squeez this to the rest

> +#include 

(2)

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

You perhaps need something like this here:

+ empty line
(1) +#include 

> +

(2) +#include 

> +#include "8250.h"

> +
> +#define PCI_NUM_BAR_RESOURCES  6
> +
> +struct exar8250;


> +
> +struct exar8250_board {
> +   unsigned int num_ports;
> +   unsigned int base_baud;
> +   unsigned int uart_offset; /* the space between channels */
> +   /*
> +* reg_shift:  describes how the UART registers are mapped
> +* to PCI memory by the card.
> +*/
> +   unsigned int reg_shift;
> +   unsigned int first_offset;
> +   int (*setup)(struct exar8250 *,
> +const struct exar8250_board *,
> +struct uart_8250_port *, int);
> +   void(*exit)(struct pci_dev *dev);
> +};
> +
> +struct exar8250 {

> +   struct pci_dev  *dev;

You perhaps don't need to save parent device, thus

struct device *dev;

here and users will do

struct pci_dev *pci_dev = to_pci_dev(dev);

when needed.

> +   unsigned intnr;
> +   struct exar8250_board   *board;
> +   int line[0];
> +};
> +
> +static int default_setup(struct exar8250 *priv,
> +const struct exar8250_board *board,
> +struct uart_8250_port *port, int idx)
> +{
> +   unsigned int bar = 0, offset = board->first_offset, maxnr;
> +   struct pci_dev *dev = priv->dev;
> +
> +   offset += idx * board->uart_offset;
> +

> +   maxnr = (pci_resource_len(dev, bar) - board->first_offset) >>
> +   (board->reg_shift + 3);

Can be calculated once?

> +
> +   if (idx >= maxnr)
> +   return 1;
> +

> +   if (!pcim_iomap(dev, bar, 0) && !pcim_iomap_table(dev))
> +   return -ENOMEM;

Do you need to check this per port? In probe you would know this.

> +
> +   port->port.iotype = UPIO_MEM;
> +   port->port.iobase = 0;
> +   port->port.mapbase = pci_resource_start(dev, bar) + offset;
> +   port->port.membase = pcim_iomap_table(dev)[bar] + offset;
> +   port->port.regshift = board->reg_shift;
> +
> +   return 0;
> +}
> +
> +static int
> +pci_xr17c154_setup(struct exar8250 *priv,
> +  const struct exar8250_board *board,
> + struct uart_8250_port *port, int idx)
> +{
> +   port->port.flags |= UPF_EXAR_EFR;
> +   return default_setup(priv, board, port, idx);
> +}
> +

> +static inline int
> +xr17v35x_has_slave(struct exar8250 *priv)
> +{
> +   const int dev_id = priv->dev->device;
> +
> +   return ((dev_id == PCI_DEVICE_ID_EXAR_XR17V4358) ||
> +   (dev_id == PCI_DEVICE_ID_EXAR_XR17V8358));
> +}

Can be easily converted to
unsigned int flags;
in your custom struct, and be assigned constantly based on ID.

> +
> +static int
> +pci_xr17v35x_setup(struct exar8250 *priv,
> +  const struct exar8250_board *board,
> + struct uart_8250_port *port, int idx)
> +{
> +   u8 __iomem *p;
> +   int ret;
> +
> +   p = pci_ioremap_bar(priv->dev, 0);
> +   if (!p)
> +   return -ENOMEM;
> +
> +   port->port.flags |= UPF_EXAR_EFR;
> +
> +   /*
> +* Setup the uart clock for the devices on expansion slot to
> +* half the clock speed of the main chip (which is 125MHz)
> +*/
> +   if (xr17v35x_has_slave(priv) && idx >= 8)
> +   port->port.uartclk = (7812500 * 16 / 2);
> +
> +   /*
> +* Setup Multipurpose Input/Output pins.
> +*/

> +   if (idx == 0) {
> +   writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
> +   writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
> +   writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
> +   writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
> +   writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
> +   writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
> +   

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Borislav Petkov]

On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote:
> So we get the table, but apparently we crash when we attempt to put it.

Right, except on 4.10-rc2 we don't crash but we freeze early. These are
the last lines:

...
[0.004778] mce: CPU supports 7 MCE banks
[0.004861] LVT offset 1 assigned for vector 0xf9
[0.004945] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[0.005025] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512, 1GB 0
[0.005165] Freeing SMP alternatives memory: 24K
[0.211154] ftrace: allocating 25022 entries in 98 pages
[0.219614] smpboot: Max logical packages: 2


> Let's try to check the obvious just to rule it out (see attached), but
> honestly I'm not sure what's going on in there.

No change, same freeze.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Borislav Petkov]

On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote:
> So we get the table, but apparently we crash when we attempt to put it.

Right, except on 4.10-rc2 we don't crash but we freeze early. These are
the last lines:

...
[0.004778] mce: CPU supports 7 MCE banks
[0.004861] LVT offset 1 assigned for vector 0xf9
[0.004945] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[0.005025] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512, 1GB 0
[0.005165] Freeing SMP alternatives memory: 24K
[0.211154] ftrace: allocating 25022 entries in 98 pages
[0.219614] smpboot: Max logical packages: 2


> Let's try to check the obvious just to rule it out (see attached), but
> honestly I'm not sure what's going on in there.

No change, same freeze.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On Sun, Jan 8, 2017 at 1:37 AM, Borislav Petkov  wrote:
> On Sun, Jan 08, 2017 at 01:22:55AM +0100, Rafael J. Wysocki wrote:
>> Is an IVRS table actually present on this machine?
>
> Like this?
>
> [0.00] ACPI: IVRS 0x9CFD6000 D0 (v02 AMDAGESA
> 0001 AMD  )

Yup.

So we get the table, but apparently we crash when we attempt to put it.

Let's try to check the obvious just to rule it out (see attached), but
honestly I'm not sure what's going on in there.

Thanks,
Rafael

---
 drivers/iommu/amd_iommu_init.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/iommu/amd_iommu_init.c
===
--- linux-pm.orig/drivers/iommu/amd_iommu_init.c
+++ linux-pm/drivers/iommu/amd_iommu_init.c
@@ -2337,8 +2337,10 @@ static int __init early_amd_iommu_init(v
 
 out:
 	/* Don't leak any ACPI memory */
-	acpi_put_table(ivrs_base);
-	ivrs_base = NULL;
+	if (ivrs_base) {
+		acpi_put_table(ivrs_base);
+		ivrs_base = NULL;
+	}
 
 	return ret;
 }
@@ -2372,7 +2374,8 @@ static bool detect_ivrs(void)
 		return false;
 	}
 
-	acpi_put_table(ivrs_base);
+	if (ivrs_base)
+		acpi_put_table(ivrs_base);
 
 	/* Make sure ACS will be enabled during PCI probe */
 	pci_request_acs();

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On Sun, Jan 8, 2017 at 1:37 AM, Borislav Petkov  wrote:
> On Sun, Jan 08, 2017 at 01:22:55AM +0100, Rafael J. Wysocki wrote:
>> Is an IVRS table actually present on this machine?
>
> Like this?
>
> [0.00] ACPI: IVRS 0x9CFD6000 D0 (v02 AMDAGESA
> 0001 AMD  )

Yup.

So we get the table, but apparently we crash when we attempt to put it.

Let's try to check the obvious just to rule it out (see attached), but
honestly I'm not sure what's going on in there.

Thanks,
Rafael

---
 drivers/iommu/amd_iommu_init.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/iommu/amd_iommu_init.c
===
--- linux-pm.orig/drivers/iommu/amd_iommu_init.c
+++ linux-pm/drivers/iommu/amd_iommu_init.c
@@ -2337,8 +2337,10 @@ static int __init early_amd_iommu_init(v
 
 out:
 	/* Don't leak any ACPI memory */
-	acpi_put_table(ivrs_base);
-	ivrs_base = NULL;
+	if (ivrs_base) {
+		acpi_put_table(ivrs_base);
+		ivrs_base = NULL;
+	}
 
 	return ret;
 }
@@ -2372,7 +2374,8 @@ static bool detect_ivrs(void)
 		return false;
 	}
 
-	acpi_put_table(ivrs_base);
+	if (ivrs_base)
+		acpi_put_table(ivrs_base);
 
 	/* Make sure ACS will be enabled during PCI probe */
 	pci_request_acs();

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Borislav Petkov]

On Sun, Jan 08, 2017 at 01:22:55AM +0100, Rafael J. Wysocki wrote:
> Is an IVRS table actually present on this machine?

Like this?

[0.00] ACPI: IVRS 0x9CFD6000 D0 (v02 AMDAGESA
0001 AMD  )

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Borislav Petkov]

On Sun, Jan 08, 2017 at 01:22:55AM +0100, Rafael J. Wysocki wrote:
> Is an IVRS table actually present on this machine?

Like this?

[0.00] ACPI: IVRS 0x9CFD6000 D0 (v02 AMDAGESA
0001 AMD  )

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

[Nicolai Stange]

Ard Biesheuvel  writes:

> On 6 January 2017 at 17:46, Nicolai Stange  wrote:
>> Ard Biesheuvel  writes:
>>
>>> On 6 January 2017 at 13:02, Nicolai Stange  wrote:
 Ard Biesheuvel  writes:

> On 5 January 2017 at 12:51, Nicolai Stange  wrote:
>> Before invoking the arch specific handler, efi_mem_reserve() reserves
>> the given memory region through memblock.
>>
>> efi_mem_reserve() can get called after mm_init() though -- through
>> efi_bgrt_init(), for example. After mm_init(), memblock is dead and 
>> should
>> not be used anymore.
>>
>> Let efi_mem_reserve() check whether memblock is dead and not do the
>> reservation if so. Emit a warning from the generic efi_arch mem_reserve()
>> in this case: if the architecture doesn't provide any other means of
>> registering the region as reserved, the operation would be a nop.
>>
>> Fixes: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid 
>> copying image data")
>> Signed-off-by: Nicolai Stange 
>> ---
>> Applicable to next-20170105.
>> No changes to v2.
>> Boot-tested on x86_64.
>>
>>  drivers/firmware/efi/efi.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
>> index 92914801e388..158a8df2f4af 100644
>> --- a/drivers/firmware/efi/efi.c
>> +++ b/drivers/firmware/efi/efi.c
>> @@ -403,7 +403,10 @@ u64 __init efi_mem_desc_end(efi_memory_desc_t *md)
>> return end;
>>  }
>>
>> -void __init __weak efi_arch_mem_reserve(phys_addr_t addr, u64 size) {}
>> +void __init __weak efi_arch_mem_reserve(phys_addr_t addr, u64 size)
>> +{
>> +   WARN(slab_is_available(), "efi_mem_reserve() has no effect");
>> +}
>>
>>  /**
>>   * efi_mem_reserve - Reserve an EFI memory region
>> @@ -419,7 +422,7 @@ void __init __weak efi_arch_mem_reserve(phys_addr_t 
>> addr, u64 size) {}
>>   */
>>  void __init efi_mem_reserve(phys_addr_t addr, u64 size)
>>  {
>> -   if (!memblock_is_region_reserved(addr, size))
>> +   if (!slab_is_available() && !memblock_is_region_reserved(addr, 
>> size))
>> memblock_reserve(addr, size);
>>

 More context:

 /*
  * Some architectures (x86) reserve all boot services ranges
  * until efi_free_boot_services() because of buggy firmware
  * implementations. This means the above memblock_reserve() is
  * superfluous on x86 and instead what it needs to do is
  * ensure the @start, @size is not freed.
  */
 efi_arch_mem_reserve(addr, size);
 }


> I share Dave's concern: on x86, this will silently ignore the
> reservation if slab_is_available() returns true,

 AFAICS, x86 has got an efi_arch_mem_reserve() which doesn't ignore the
 reservation at any stage.

>>>
>>> Thanks for the clarification. But my concern is whether changing the
>>> EFI memory map is going to have any effect at this stage, i.e., after
>>> slab_is_available() returns true: haven't we already communicated to
>>> the kernel which RAM regions it may allocate from? How does it know
>>> the memory map has changed, and how do we ensure that it has not
>>> already allocated from the region we are reserving here?
>>
>> Ah, I see what you mean. I think it works like this on x86:
>>
>> All EFI_BOOT_SERVICES_* regions as reported by the firmware are marked
>> as reserved at memblock unconditionally through the early setup_arch()
>> => efi_reserve_boot_services(). This prevents these from getting handed
>> over to the "normal" kernel MM until efi_free_boot_services()
>> gets called later on. The latter frees these EFI_BOOT_SERVICES_* regions,
>> but only if their EFI_MEMORY_RUNTIME flag is not set.
>>
>> Now, efi_arch_mem_reserve() basically just sets the EFI_MEMORY_RUNTIME
>> flag, allowing the given region to survive beyond efi_free_boot_services().
>>
>> Corrolary 1: any efi_mem_reserve() after efi_free_boot_services wouldn't
>> have any effect.
>>
>
> This is my point exactly. But it appears efi_free_boot_services()
> occurs much later than I thought, and so there is a sizabe time window
> where SLAB is up but reservations can still be made. But we don't
> check whether efi_free_boot_services() has been called.

Ok, but this patch is about slab_is_available()/resp. the
non-availability of memblock and I'd rather consider the implementation
of these kinds of safety checks as being a different story?



Out of curiosity, I had a deeper look at the BootServices*-md
requirement though:

> Another problem is that we never check 

Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

[Nicolai Stange]

Ard Biesheuvel  writes:

> On 6 January 2017 at 17:46, Nicolai Stange  wrote:
>> Ard Biesheuvel  writes:
>>
>>> On 6 January 2017 at 13:02, Nicolai Stange  wrote:
 Ard Biesheuvel  writes:

> On 5 January 2017 at 12:51, Nicolai Stange  wrote:
>> Before invoking the arch specific handler, efi_mem_reserve() reserves
>> the given memory region through memblock.
>>
>> efi_mem_reserve() can get called after mm_init() though -- through
>> efi_bgrt_init(), for example. After mm_init(), memblock is dead and 
>> should
>> not be used anymore.
>>
>> Let efi_mem_reserve() check whether memblock is dead and not do the
>> reservation if so. Emit a warning from the generic efi_arch mem_reserve()
>> in this case: if the architecture doesn't provide any other means of
>> registering the region as reserved, the operation would be a nop.
>>
>> Fixes: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid 
>> copying image data")
>> Signed-off-by: Nicolai Stange 
>> ---
>> Applicable to next-20170105.
>> No changes to v2.
>> Boot-tested on x86_64.
>>
>>  drivers/firmware/efi/efi.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
>> index 92914801e388..158a8df2f4af 100644
>> --- a/drivers/firmware/efi/efi.c
>> +++ b/drivers/firmware/efi/efi.c
>> @@ -403,7 +403,10 @@ u64 __init efi_mem_desc_end(efi_memory_desc_t *md)
>> return end;
>>  }
>>
>> -void __init __weak efi_arch_mem_reserve(phys_addr_t addr, u64 size) {}
>> +void __init __weak efi_arch_mem_reserve(phys_addr_t addr, u64 size)
>> +{
>> +   WARN(slab_is_available(), "efi_mem_reserve() has no effect");
>> +}
>>
>>  /**
>>   * efi_mem_reserve - Reserve an EFI memory region
>> @@ -419,7 +422,7 @@ void __init __weak efi_arch_mem_reserve(phys_addr_t 
>> addr, u64 size) {}
>>   */
>>  void __init efi_mem_reserve(phys_addr_t addr, u64 size)
>>  {
>> -   if (!memblock_is_region_reserved(addr, size))
>> +   if (!slab_is_available() && !memblock_is_region_reserved(addr, 
>> size))
>> memblock_reserve(addr, size);
>>

 More context:

 /*
  * Some architectures (x86) reserve all boot services ranges
  * until efi_free_boot_services() because of buggy firmware
  * implementations. This means the above memblock_reserve() is
  * superfluous on x86 and instead what it needs to do is
  * ensure the @start, @size is not freed.
  */
 efi_arch_mem_reserve(addr, size);
 }


> I share Dave's concern: on x86, this will silently ignore the
> reservation if slab_is_available() returns true,

 AFAICS, x86 has got an efi_arch_mem_reserve() which doesn't ignore the
 reservation at any stage.

>>>
>>> Thanks for the clarification. But my concern is whether changing the
>>> EFI memory map is going to have any effect at this stage, i.e., after
>>> slab_is_available() returns true: haven't we already communicated to
>>> the kernel which RAM regions it may allocate from? How does it know
>>> the memory map has changed, and how do we ensure that it has not
>>> already allocated from the region we are reserving here?
>>
>> Ah, I see what you mean. I think it works like this on x86:
>>
>> All EFI_BOOT_SERVICES_* regions as reported by the firmware are marked
>> as reserved at memblock unconditionally through the early setup_arch()
>> => efi_reserve_boot_services(). This prevents these from getting handed
>> over to the "normal" kernel MM until efi_free_boot_services()
>> gets called later on. The latter frees these EFI_BOOT_SERVICES_* regions,
>> but only if their EFI_MEMORY_RUNTIME flag is not set.
>>
>> Now, efi_arch_mem_reserve() basically just sets the EFI_MEMORY_RUNTIME
>> flag, allowing the given region to survive beyond efi_free_boot_services().
>>
>> Corrolary 1: any efi_mem_reserve() after efi_free_boot_services wouldn't
>> have any effect.
>>
>
> This is my point exactly. But it appears efi_free_boot_services()
> occurs much later than I thought, and so there is a sizabe time window
> where SLAB is up but reservations can still be made. But we don't
> check whether efi_free_boot_services() has been called.

Ok, but this patch is about slab_is_available()/resp. the
non-availability of memblock and I'd rather consider the implementation
of these kinds of safety checks as being a different story?



Out of curiosity, I had a deeper look at the BootServices*-md
requirement though:

> Another problem is that we never check that the reservation is covered
> by a BootServicesData region, which are the only ones that are
> guaranteed to be retained up to this point.

I think the "only ones 

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On Sun, Jan 8, 2017 at 1:07 AM, Borislav Petkov  wrote:
> On Sun, Jan 08, 2017 at 12:30:27AM +0100, Rafael J. Wysocki wrote:
>> Please check if this helps:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d
>
> Unfortunately no, still same early freeze. :-\
>
> The splat happens when booting 6b11d1d67713 directly, 4.10-rc2 doesn't
> splat but freezes simply very early during boot.

Is an IVRS table actually present on this machine?

Thanks,
Rafael

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On Sun, Jan 8, 2017 at 1:07 AM, Borislav Petkov  wrote:
> On Sun, Jan 08, 2017 at 12:30:27AM +0100, Rafael J. Wysocki wrote:
>> Please check if this helps:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d
>
> Unfortunately no, still same early freeze. :-\
>
> The splat happens when booting 6b11d1d67713 directly, 4.10-rc2 doesn't
> splat but freezes simply very early during boot.

Is an IVRS table actually present on this machine?

Thanks,
Rafael

Re: stack unwinder warning.

[Dave Jones]

On Fri, Jan 06, 2017 at 10:50:32AM -0600, Josh Poimboeuf wrote:

 > > WARNING: kernel stack frame pointer at c90001443f30 in 
 > > kworker/u8:8:30468 has bad value   (null)
 > > unwind stack type:0 next_sp:  (null) mask:6 graph_idx:0
 > 
 > This is actually a separate issue.  The below patch should fix it.
 > 
 > Would you mind running it for a bit along with the other patch?

haven't seen any reoccurance of that trace in the last day.

Dave

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Borislav Petkov]

On Sun, Jan 08, 2017 at 12:30:27AM +0100, Rafael J. Wysocki wrote:
> Please check if this helps:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d

Unfortunately no, still same early freeze. :-\

The splat happens when booting 6b11d1d67713 directly, 4.10-rc2 doesn't
splat but freezes simply very early during boot.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: stack unwinder warning.

[Dave Jones]

On Fri, Jan 06, 2017 at 10:50:32AM -0600, Josh Poimboeuf wrote:

 > > WARNING: kernel stack frame pointer at c90001443f30 in 
 > > kworker/u8:8:30468 has bad value   (null)
 > > unwind stack type:0 next_sp:  (null) mask:6 graph_idx:0
 > 
 > This is actually a separate issue.  The below patch should fix it.
 > 
 > Would you mind running it for a bit along with the other patch?

haven't seen any reoccurance of that trace in the last day.

Dave

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Borislav Petkov]

On Sun, Jan 08, 2017 at 12:30:27AM +0100, Rafael J. Wysocki wrote:
> Please check if this helps:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d

Unfortunately no, still same early freeze. :-\

The splat happens when booting 6b11d1d67713 directly, 4.10-rc2 doesn't
splat but freezes simply very early during boot.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH v7 3/3] serial: 8250_pci: remove exar code

[Sudip Mukherjee]

Remove the exar specific codes from 8250_pci and blacklist those chips
so that the exar serial binds to the devices.

Signed-off-by: Sudip Mukherjee 
---
 drivers/tty/serial/8250/8250_pci.c | 336 +
 1 file changed, 3 insertions(+), 333 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index b98c157..8a5b740 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1580,9 +1580,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #endif
 }
 
-#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
-#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
-
 #define UART_EXAR_MPIOINT_7_0  0x8f/* MPIOINT[7:0] */
 #define UART_EXAR_MPIOLVL_7_0  0x90/* MPIOLVL[7:0] */
 #define UART_EXAR_MPIO3T_7_0   0x91/* MPIO3T[7:0] */
@@ -1595,71 +1592,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #define UART_EXAR_MPIOINV_15_8 0x98/* MPIOINV[15:8] */
 #define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
 #define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
-
-static int
-pci_xr17c154_setup(struct serial_private *priv,
- const struct pciserial_board *board,
- struct uart_8250_port *port, int idx)
-{
-   port->port.flags |= UPF_EXAR_EFR;
-   return pci_default_setup(priv, board, port, idx);
-}
-
-static inline int
-xr17v35x_has_slave(struct serial_private *priv)
-{
-   const int dev_id = priv->dev->device;
-
-   return ((dev_id == PCI_DEVICE_ID_EXAR_XR17V4358) ||
-   (dev_id == PCI_DEVICE_ID_EXAR_XR17V8358));
-}
-
-static int
-pci_xr17v35x_setup(struct serial_private *priv,
- const struct pciserial_board *board,
- struct uart_8250_port *port, int idx)
-{
-   u8 __iomem *p;
-
-   p = pci_ioremap_bar(priv->dev, 0);
-   if (p == NULL)
-   return -ENOMEM;
-
-   port->port.flags |= UPF_EXAR_EFR;
-
-   /*
-* Setup the uart clock for the devices on expansion slot to
-* half the clock speed of the main chip (which is 125MHz)
-*/
-   if (xr17v35x_has_slave(priv) && idx >= 8)
-   port->port.uartclk = (7812500 * 16 / 2);
-
-   /*
-* Setup Multipurpose Input/Output pins.
-*/
-   if (idx == 0) {
-   writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
-   writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
-   writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
-   }
-   writeb(0x00, p + UART_EXAR_8XMODE);
-   writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
-   writeb(128, p + UART_EXAR_TXTRG);
-   writeb(128, p + UART_EXAR_RXTRG);
-   iounmap(p);
-
-   return pci_default_setup(priv, board, port, idx);
-}
-
 #define PCI_DEVICE_ID_COMMTECH_4222PCI335 0x0004
 #define PCI_DEVICE_ID_COMMTECH_4224PCI335 0x0002
 #define PCI_DEVICE_ID_COMMTECH_2324PCI335 0x000a
@@ -1784,9 +1716,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #define PCI_VENDOR_ID_AGESTAR  0x5372
 #define PCI_DEVICE_ID_AGESTAR_9375 0x6872
 #define PCI_VENDOR_ID_ASIX 0x9710
-#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
-#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
-#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
 #define PCI_DEVICE_ID_BROADCOM_TRUMANAGE 0x160a
 #define PCI_DEVICE_ID_AMCC_ADDIDATA_APCI7800 0x818e
 
@@ -2238,65 +2167,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
.setup  = pci_timedia_setup,
},
/*
-* Exar cards
-*/
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C152,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C154,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C158,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   

[PATCH v7 3/3] serial: 8250_pci: remove exar code

[Sudip Mukherjee]

Remove the exar specific codes from 8250_pci and blacklist those chips
so that the exar serial binds to the devices.

Signed-off-by: Sudip Mukherjee 
---
 drivers/tty/serial/8250/8250_pci.c | 336 +
 1 file changed, 3 insertions(+), 333 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index b98c157..8a5b740 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1580,9 +1580,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #endif
 }
 
-#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
-#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
-
 #define UART_EXAR_MPIOINT_7_0  0x8f/* MPIOINT[7:0] */
 #define UART_EXAR_MPIOLVL_7_0  0x90/* MPIOLVL[7:0] */
 #define UART_EXAR_MPIO3T_7_0   0x91/* MPIO3T[7:0] */
@@ -1595,71 +1592,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #define UART_EXAR_MPIOINV_15_8 0x98/* MPIOINV[15:8] */
 #define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
 #define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
-
-static int
-pci_xr17c154_setup(struct serial_private *priv,
- const struct pciserial_board *board,
- struct uart_8250_port *port, int idx)
-{
-   port->port.flags |= UPF_EXAR_EFR;
-   return pci_default_setup(priv, board, port, idx);
-}
-
-static inline int
-xr17v35x_has_slave(struct serial_private *priv)
-{
-   const int dev_id = priv->dev->device;
-
-   return ((dev_id == PCI_DEVICE_ID_EXAR_XR17V4358) ||
-   (dev_id == PCI_DEVICE_ID_EXAR_XR17V8358));
-}
-
-static int
-pci_xr17v35x_setup(struct serial_private *priv,
- const struct pciserial_board *board,
- struct uart_8250_port *port, int idx)
-{
-   u8 __iomem *p;
-
-   p = pci_ioremap_bar(priv->dev, 0);
-   if (p == NULL)
-   return -ENOMEM;
-
-   port->port.flags |= UPF_EXAR_EFR;
-
-   /*
-* Setup the uart clock for the devices on expansion slot to
-* half the clock speed of the main chip (which is 125MHz)
-*/
-   if (xr17v35x_has_slave(priv) && idx >= 8)
-   port->port.uartclk = (7812500 * 16 / 2);
-
-   /*
-* Setup Multipurpose Input/Output pins.
-*/
-   if (idx == 0) {
-   writeb(0x00, p + UART_EXAR_MPIOINT_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
-   writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
-   writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
-   }
-   writeb(0x00, p + UART_EXAR_8XMODE);
-   writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
-   writeb(128, p + UART_EXAR_TXTRG);
-   writeb(128, p + UART_EXAR_RXTRG);
-   iounmap(p);
-
-   return pci_default_setup(priv, board, port, idx);
-}
-
 #define PCI_DEVICE_ID_COMMTECH_4222PCI335 0x0004
 #define PCI_DEVICE_ID_COMMTECH_4224PCI335 0x0002
 #define PCI_DEVICE_ID_COMMTECH_2324PCI335 0x000a
@@ -1784,9 +1716,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
 #define PCI_VENDOR_ID_AGESTAR  0x5372
 #define PCI_DEVICE_ID_AGESTAR_9375 0x6872
 #define PCI_VENDOR_ID_ASIX 0x9710
-#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
-#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
-#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
 #define PCI_DEVICE_ID_BROADCOM_TRUMANAGE 0x160a
 #define PCI_DEVICE_ID_AMCC_ADDIDATA_APCI7800 0x818e
 
@@ -2238,65 +2167,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
.setup  = pci_timedia_setup,
},
/*
-* Exar cards
-*/
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C152,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C154,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = PCI_DEVICE_ID_EXAR_XR17C158,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = PCI_ANY_ID,
-   .setup  = pci_xr17c154_setup,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_EXAR,
-   .device = 

[PATCH v7 0/3] add gpio support to exar

[Sudip Mukherjee]

Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
can be controlled using gpio interface.

v5 was sent in January, 2016 and after reviews it was suggested to
split the exar code out of 8250_pci and make its own driver.

For reference it is at https://patchwork.kernel.org/patch/8058311/

First split attempt was patch series v6.

regards
sudip

Sudip Mukherjee (3):
  gpio: exar: add gpio for exar cards
  serial: exar: split out the exar code from 8250_pci
  serial: 8250_pci: remove exar code

 drivers/gpio/Kconfig|   7 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-exar.c| 238 +
 drivers/tty/serial/8250/8250_exar.c | 515 
 drivers/tty/serial/8250/8250_pci.c  | 336 +--
 drivers/tty/serial/8250/Kconfig |   5 +
 drivers/tty/serial/8250/Makefile|   1 +
 7 files changed, 770 insertions(+), 333 deletions(-)
 create mode 100644 drivers/gpio/gpio-exar.c
 create mode 100644 drivers/tty/serial/8250/8250_exar.c

-- 
1.9.1

[PATCH v7 0/3] add gpio support to exar

[Sudip Mukherjee]

Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
can be controlled using gpio interface.

v5 was sent in January, 2016 and after reviews it was suggested to
split the exar code out of 8250_pci and make its own driver.

For reference it is at https://patchwork.kernel.org/patch/8058311/

First split attempt was patch series v6.

regards
sudip

Sudip Mukherjee (3):
  gpio: exar: add gpio for exar cards
  serial: exar: split out the exar code from 8250_pci
  serial: 8250_pci: remove exar code

 drivers/gpio/Kconfig|   7 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-exar.c| 238 +
 drivers/tty/serial/8250/8250_exar.c | 515 
 drivers/tty/serial/8250/8250_pci.c  | 336 +--
 drivers/tty/serial/8250/Kconfig |   5 +
 drivers/tty/serial/8250/Makefile|   1 +
 7 files changed, 770 insertions(+), 333 deletions(-)
 create mode 100644 drivers/gpio/gpio-exar.c
 create mode 100644 drivers/tty/serial/8250/8250_exar.c

-- 
1.9.1

[PATCH v7 1/3] gpio: exar: add gpio for exar cards

[Sudip Mukherjee]

Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
can be controlled using gpio interface.

Add the gpio specific code.

Signed-off-by: Sudip Mukherjee 
---
 drivers/gpio/Kconfig |   7 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-exar.c | 238 +++
 3 files changed, 246 insertions(+)
 create mode 100644 drivers/gpio/gpio-exar.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ed37e59..89033d6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -185,6 +185,13 @@ config GPIO_ETRAXFS
help
  Say yes here to support the GPIO controller on Axis ETRAX FS SoCs.
 
+config GPIO_EXAR
+   tristate "Support for GPIO pins on XR17V352/354/358"
+   depends on SERIAL_8250_EXAR
+   help
+ Selecting this option will enable handling of GPIO pins present
+ on Exar XR17V352/354/358 chips.
+
 config GPIO_GE_FPGA
bool "GE FPGA based GPIO"
depends on GE_FPGA
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index d074c22..d4d44f8 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_GPIO_DWAPB)  += gpio-dwapb.o
 obj-$(CONFIG_GPIO_EM)  += gpio-em.o
 obj-$(CONFIG_GPIO_EP93XX)  += gpio-ep93xx.o
 obj-$(CONFIG_GPIO_ETRAXFS) += gpio-etraxfs.o
+obj-$(CONFIG_GPIO_EXAR)+= gpio-exar.o
 obj-$(CONFIG_GPIO_F7188X)  += gpio-f7188x.o
 obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
 obj-$(CONFIG_GPIO_GPIO_MM) += gpio-gpio-mm.o
diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
new file mode 100644
index 000..b7d1363
--- /dev/null
+++ b/drivers/gpio/gpio-exar.c
@@ -0,0 +1,238 @@
+/*
+ * GPIO driver for Exar XR17V35X chip
+ *
+ * Copyright (C) 2015 Sudip Mukherjee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define EXAR_OFFSET_MPIOLVL_LO 0x90
+#define EXAR_OFFSET_MPIOSEL_LO 0x93
+#define EXAR_OFFSET_MPIOLVL_HI 0x96
+#define EXAR_OFFSET_MPIOSEL_HI 0x99
+
+#define DRIVER_NAME "gpio_exar"
+
+static LIST_HEAD(exar_list);
+static DEFINE_MUTEX(exar_list_mtx);
+DEFINE_IDA(ida_index);
+
+struct exar_gpio_chip {
+   struct gpio_chip gpio_chip;
+   struct pci_dev *pcidev;
+   struct mutex lock;
+   struct list_head list;
+   int index;
+   void __iomem *regs;
+   char name[16];
+};
+
+#define to_exar_chip(n) container_of(n, struct exar_gpio_chip, gpio_chip)
+
+static inline unsigned int read_exar_reg(struct exar_gpio_chip *chip,
+int offset)
+{
+   dev_dbg(chip->gpio_chip.parent, "regs=%p offset=%x\n",
+   chip->regs, offset);
+
+   return readb(chip->regs + offset);
+}
+
+static inline void write_exar_reg(struct exar_gpio_chip *chip, int offset,
+ int value)
+{
+   dev_dbg(chip->gpio_chip.parent,
+   "regs=%p value=%x offset=%x\n", chip->regs, value,
+   offset);
+   writeb(value, chip->regs + offset);
+}
+
+static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
+   unsigned int offset)
+{
+   struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);
+   int temp;
+
+   mutex_lock(_gpio->lock);
+   temp = read_exar_reg(exar_gpio, reg);
+   temp &= ~(1 << offset);
+   temp |= val << offset;
+   write_exar_reg(exar_gpio, reg, temp);
+   mutex_unlock(_gpio->lock);
+}
+
+static int exar_set_direction(struct gpio_chip *chip, int direction,
+ unsigned int offset)
+{
+   if (offset < 8)
+   exar_update(chip, EXAR_OFFSET_MPIOSEL_LO, direction,
+   offset);
+   else
+   exar_update(chip, EXAR_OFFSET_MPIOSEL_HI, direction,
+   offset - 8);
+   return 0;
+}
+
+static int exar_direction_output(struct gpio_chip *chip, unsigned int offset,
+int value)
+{
+   return exar_set_direction(chip, 0, offset);
+}
+
+static int exar_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+   return exar_set_direction(chip, 1, offset);
+}
+
+static int exar_get(struct gpio_chip *chip, unsigned int reg)
+{
+   struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);
+   int value;
+
+   mutex_lock(_gpio->lock);
+   value = read_exar_reg(exar_gpio, reg);
+   mutex_unlock(_gpio->lock);
+
+   return value;
+}
+
+static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+   int val;
+
+   if (offset < 8)
+   val = exar_get(chip, 

[PATCH v7 2/3] serial: exar: split out the exar code from 8250_pci

[Sudip Mukherjee]

Add the serial driver for the exar chips. And also register the
platform device for the exar gpio.

Signed-off-by: Sudip Mukherjee 
---

Hi Andy,
Headers, if arranged in alphabetical order, will give a build warning.
And thanks for revewing that v6. I think those were the worst patch I
have ever posted.

 drivers/tty/serial/8250/8250_exar.c | 515 
 drivers/tty/serial/8250/Kconfig |   5 +
 drivers/tty/serial/8250/Makefile|   1 +
 3 files changed, 521 insertions(+)
 create mode 100644 drivers/tty/serial/8250/8250_exar.c

diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
new file mode 100644
index 000..abfd803
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -0,0 +1,515 @@
+/*
+ *  Probe module for 8250/16550-type Exar chips PCI serial ports.
+ *
+ *  Based on drivers/tty/serial/8250/8250_pci.c,
+ *
+ *  Copyright (C) 2017 Sudip Mukherjee, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#undef DEBUG
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "8250.h"
+
+#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
+#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
+#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
+#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
+#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
+
+#define UART_EXAR_MPIOINT_7_0  0x8f/* MPIOINT[7:0] */
+#define UART_EXAR_MPIOLVL_7_0  0x90/* MPIOLVL[7:0] */
+#define UART_EXAR_MPIO3T_7_0   0x91/* MPIO3T[7:0] */
+#define UART_EXAR_MPIOINV_7_0  0x92/* MPIOINV[7:0] */
+#define UART_EXAR_MPIOSEL_7_0  0x93/* MPIOSEL[7:0] */
+#define UART_EXAR_MPIOOD_7_0   0x94/* MPIOOD[7:0] */
+#define UART_EXAR_MPIOINT_15_8 0x95/* MPIOINT[15:8] */
+#define UART_EXAR_MPIOLVL_15_8 0x96/* MPIOLVL[15:8] */
+#define UART_EXAR_MPIO3T_15_8  0x97/* MPIO3T[15:8] */
+#define UART_EXAR_MPIOINV_15_8 0x98/* MPIOINV[15:8] */
+#define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
+#define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
+
+#define PCI_NUM_BAR_RESOURCES  6
+
+struct exar8250;
+
+struct exar8250_board {
+   unsigned int num_ports;
+   unsigned int base_baud;
+   unsigned int uart_offset; /* the space between channels */
+   /*
+* reg_shift:  describes how the UART registers are mapped
+* to PCI memory by the card.
+*/
+   unsigned int reg_shift;
+   unsigned int first_offset;
+   int (*setup)(struct exar8250 *,
+const struct exar8250_board *,
+struct uart_8250_port *, int);
+   void(*exit)(struct pci_dev *dev);
+};
+
+struct exar8250 {
+   struct pci_dev  *dev;
+   unsigned intnr;
+   struct exar8250_board   *board;
+   int line[0];
+};
+
+static int default_setup(struct exar8250 *priv,
+const struct exar8250_board *board,
+struct uart_8250_port *port, int idx)
+{
+   unsigned int bar = 0, offset = board->first_offset, maxnr;
+   struct pci_dev *dev = priv->dev;
+
+   offset += idx * board->uart_offset;
+
+   maxnr = (pci_resource_len(dev, bar) - board->first_offset) >>
+   (board->reg_shift + 3);
+
+   if (idx >= maxnr)
+   return 1;
+
+   if (!pcim_iomap(dev, bar, 0) && !pcim_iomap_table(dev))
+   return -ENOMEM;
+
+   port->port.iotype = UPIO_MEM;
+   port->port.iobase = 0;
+   port->port.mapbase = pci_resource_start(dev, bar) + offset;
+   port->port.membase = pcim_iomap_table(dev)[bar] + offset;
+   port->port.regshift = board->reg_shift;
+
+   return 0;
+}
+
+static int
+pci_xr17c154_setup(struct exar8250 *priv,
+  const struct exar8250_board *board,
+ struct uart_8250_port *port, int idx)
+{
+   port->port.flags |= UPF_EXAR_EFR;
+   return default_setup(priv, board, port, idx);
+}
+
+static inline int
+xr17v35x_has_slave(struct exar8250 *priv)
+{
+   const int dev_id = priv->dev->device;
+
+   return ((dev_id == PCI_DEVICE_ID_EXAR_XR17V4358) ||
+   (dev_id == PCI_DEVICE_ID_EXAR_XR17V8358));
+}
+
+static int
+pci_xr17v35x_setup(struct exar8250 *priv,
+  const struct exar8250_board *board,
+ struct uart_8250_port *port, int idx)
+{
+   u8 __iomem *p;
+   int ret;
+
+   p = pci_ioremap_bar(priv->dev, 0);
+   if (!p)
+   return -ENOMEM;
+
+   port->port.flags |= UPF_EXAR_EFR;
+
+   /*
+* Setup the uart clock for the devices on expansion slot to
+* 

[PATCH v7 1/3] gpio: exar: add gpio for exar cards

[Sudip Mukherjee]

Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
can be controlled using gpio interface.

Add the gpio specific code.

Signed-off-by: Sudip Mukherjee 
---
 drivers/gpio/Kconfig |   7 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-exar.c | 238 +++
 3 files changed, 246 insertions(+)
 create mode 100644 drivers/gpio/gpio-exar.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ed37e59..89033d6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -185,6 +185,13 @@ config GPIO_ETRAXFS
help
  Say yes here to support the GPIO controller on Axis ETRAX FS SoCs.
 
+config GPIO_EXAR
+   tristate "Support for GPIO pins on XR17V352/354/358"
+   depends on SERIAL_8250_EXAR
+   help
+ Selecting this option will enable handling of GPIO pins present
+ on Exar XR17V352/354/358 chips.
+
 config GPIO_GE_FPGA
bool "GE FPGA based GPIO"
depends on GE_FPGA
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index d074c22..d4d44f8 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_GPIO_DWAPB)  += gpio-dwapb.o
 obj-$(CONFIG_GPIO_EM)  += gpio-em.o
 obj-$(CONFIG_GPIO_EP93XX)  += gpio-ep93xx.o
 obj-$(CONFIG_GPIO_ETRAXFS) += gpio-etraxfs.o
+obj-$(CONFIG_GPIO_EXAR)+= gpio-exar.o
 obj-$(CONFIG_GPIO_F7188X)  += gpio-f7188x.o
 obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
 obj-$(CONFIG_GPIO_GPIO_MM) += gpio-gpio-mm.o
diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
new file mode 100644
index 000..b7d1363
--- /dev/null
+++ b/drivers/gpio/gpio-exar.c
@@ -0,0 +1,238 @@
+/*
+ * GPIO driver for Exar XR17V35X chip
+ *
+ * Copyright (C) 2015 Sudip Mukherjee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define EXAR_OFFSET_MPIOLVL_LO 0x90
+#define EXAR_OFFSET_MPIOSEL_LO 0x93
+#define EXAR_OFFSET_MPIOLVL_HI 0x96
+#define EXAR_OFFSET_MPIOSEL_HI 0x99
+
+#define DRIVER_NAME "gpio_exar"
+
+static LIST_HEAD(exar_list);
+static DEFINE_MUTEX(exar_list_mtx);
+DEFINE_IDA(ida_index);
+
+struct exar_gpio_chip {
+   struct gpio_chip gpio_chip;
+   struct pci_dev *pcidev;
+   struct mutex lock;
+   struct list_head list;
+   int index;
+   void __iomem *regs;
+   char name[16];
+};
+
+#define to_exar_chip(n) container_of(n, struct exar_gpio_chip, gpio_chip)
+
+static inline unsigned int read_exar_reg(struct exar_gpio_chip *chip,
+int offset)
+{
+   dev_dbg(chip->gpio_chip.parent, "regs=%p offset=%x\n",
+   chip->regs, offset);
+
+   return readb(chip->regs + offset);
+}
+
+static inline void write_exar_reg(struct exar_gpio_chip *chip, int offset,
+ int value)
+{
+   dev_dbg(chip->gpio_chip.parent,
+   "regs=%p value=%x offset=%x\n", chip->regs, value,
+   offset);
+   writeb(value, chip->regs + offset);
+}
+
+static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
+   unsigned int offset)
+{
+   struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);
+   int temp;
+
+   mutex_lock(_gpio->lock);
+   temp = read_exar_reg(exar_gpio, reg);
+   temp &= ~(1 << offset);
+   temp |= val << offset;
+   write_exar_reg(exar_gpio, reg, temp);
+   mutex_unlock(_gpio->lock);
+}
+
+static int exar_set_direction(struct gpio_chip *chip, int direction,
+ unsigned int offset)
+{
+   if (offset < 8)
+   exar_update(chip, EXAR_OFFSET_MPIOSEL_LO, direction,
+   offset);
+   else
+   exar_update(chip, EXAR_OFFSET_MPIOSEL_HI, direction,
+   offset - 8);
+   return 0;
+}
+
+static int exar_direction_output(struct gpio_chip *chip, unsigned int offset,
+int value)
+{
+   return exar_set_direction(chip, 0, offset);
+}
+
+static int exar_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+   return exar_set_direction(chip, 1, offset);
+}
+
+static int exar_get(struct gpio_chip *chip, unsigned int reg)
+{
+   struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);
+   int value;
+
+   mutex_lock(_gpio->lock);
+   value = read_exar_reg(exar_gpio, reg);
+   mutex_unlock(_gpio->lock);
+
+   return value;
+}
+
+static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+   int val;
+
+   if (offset < 8)
+   val = exar_get(chip, EXAR_OFFSET_MPIOSEL_LO) >> offset;
+   else
+   val = 

[PATCH v7 2/3] serial: exar: split out the exar code from 8250_pci

[Sudip Mukherjee]

Add the serial driver for the exar chips. And also register the
platform device for the exar gpio.

Signed-off-by: Sudip Mukherjee 
---

Hi Andy,
Headers, if arranged in alphabetical order, will give a build warning.
And thanks for revewing that v6. I think those were the worst patch I
have ever posted.

 drivers/tty/serial/8250/8250_exar.c | 515 
 drivers/tty/serial/8250/Kconfig |   5 +
 drivers/tty/serial/8250/Makefile|   1 +
 3 files changed, 521 insertions(+)
 create mode 100644 drivers/tty/serial/8250/8250_exar.c

diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
new file mode 100644
index 000..abfd803
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -0,0 +1,515 @@
+/*
+ *  Probe module for 8250/16550-type Exar chips PCI serial ports.
+ *
+ *  Based on drivers/tty/serial/8250/8250_pci.c,
+ *
+ *  Copyright (C) 2017 Sudip Mukherjee, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#undef DEBUG
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "8250.h"
+
+#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
+#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
+#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
+#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
+#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
+
+#define UART_EXAR_MPIOINT_7_0  0x8f/* MPIOINT[7:0] */
+#define UART_EXAR_MPIOLVL_7_0  0x90/* MPIOLVL[7:0] */
+#define UART_EXAR_MPIO3T_7_0   0x91/* MPIO3T[7:0] */
+#define UART_EXAR_MPIOINV_7_0  0x92/* MPIOINV[7:0] */
+#define UART_EXAR_MPIOSEL_7_0  0x93/* MPIOSEL[7:0] */
+#define UART_EXAR_MPIOOD_7_0   0x94/* MPIOOD[7:0] */
+#define UART_EXAR_MPIOINT_15_8 0x95/* MPIOINT[15:8] */
+#define UART_EXAR_MPIOLVL_15_8 0x96/* MPIOLVL[15:8] */
+#define UART_EXAR_MPIO3T_15_8  0x97/* MPIO3T[15:8] */
+#define UART_EXAR_MPIOINV_15_8 0x98/* MPIOINV[15:8] */
+#define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
+#define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
+
+#define PCI_NUM_BAR_RESOURCES  6
+
+struct exar8250;
+
+struct exar8250_board {
+   unsigned int num_ports;
+   unsigned int base_baud;
+   unsigned int uart_offset; /* the space between channels */
+   /*
+* reg_shift:  describes how the UART registers are mapped
+* to PCI memory by the card.
+*/
+   unsigned int reg_shift;
+   unsigned int first_offset;
+   int (*setup)(struct exar8250 *,
+const struct exar8250_board *,
+struct uart_8250_port *, int);
+   void(*exit)(struct pci_dev *dev);
+};
+
+struct exar8250 {
+   struct pci_dev  *dev;
+   unsigned intnr;
+   struct exar8250_board   *board;
+   int line[0];
+};
+
+static int default_setup(struct exar8250 *priv,
+const struct exar8250_board *board,
+struct uart_8250_port *port, int idx)
+{
+   unsigned int bar = 0, offset = board->first_offset, maxnr;
+   struct pci_dev *dev = priv->dev;
+
+   offset += idx * board->uart_offset;
+
+   maxnr = (pci_resource_len(dev, bar) - board->first_offset) >>
+   (board->reg_shift + 3);
+
+   if (idx >= maxnr)
+   return 1;
+
+   if (!pcim_iomap(dev, bar, 0) && !pcim_iomap_table(dev))
+   return -ENOMEM;
+
+   port->port.iotype = UPIO_MEM;
+   port->port.iobase = 0;
+   port->port.mapbase = pci_resource_start(dev, bar) + offset;
+   port->port.membase = pcim_iomap_table(dev)[bar] + offset;
+   port->port.regshift = board->reg_shift;
+
+   return 0;
+}
+
+static int
+pci_xr17c154_setup(struct exar8250 *priv,
+  const struct exar8250_board *board,
+ struct uart_8250_port *port, int idx)
+{
+   port->port.flags |= UPF_EXAR_EFR;
+   return default_setup(priv, board, port, idx);
+}
+
+static inline int
+xr17v35x_has_slave(struct exar8250 *priv)
+{
+   const int dev_id = priv->dev->device;
+
+   return ((dev_id == PCI_DEVICE_ID_EXAR_XR17V4358) ||
+   (dev_id == PCI_DEVICE_ID_EXAR_XR17V8358));
+}
+
+static int
+pci_xr17v35x_setup(struct exar8250 *priv,
+  const struct exar8250_board *board,
+ struct uart_8250_port *port, int idx)
+{
+   u8 __iomem *p;
+   int ret;
+
+   p = pci_ioremap_bar(priv->dev, 0);
+   if (!p)
+   return -ENOMEM;
+
+   port->port.flags |= UPF_EXAR_EFR;
+
+   /*
+* Setup the uart clock for the devices on expansion slot to
+* half the clock speed of the main 

[PATCH] mm: stop leaking PageTables

[Hugh Dickins]

4.10-rc loadtest (even on x86, even without THPCache) fails with
"fork: Cannot allocate memory" or some such; and /proc/meminfo
shows PageTables growing.

rc1 removed the freeing of an unused preallocated pagetable after
do_fault_around() has called map_pages(): which is usually a good
optimization, so that the followup doesn't have to reallocate one;
but it's not sufficient to shift the freeing into alloc_set_pte(),
since there are failure cases (most commonly VM_FAULT_RETRY) which
never reach finish_fault().

Check and free it at the outer level in do_fault(), then we don't
need to worry in alloc_set_pte(), and can restore that to how it was
(I cannot find any reason to pte_free() under lock as it was doing).

And fix a separate pagetable leak, or crash, introduced by the same
change, that could only show up on some ppc64: why does do_set_pmd()'s
failure case attempt to withdraw a pagetable when it never deposited
one, at the same time overwriting (so leaking) the vmf->prealloc_pte?
Residue of an earlier implementation, perhaps?  Delete it.

Fixes: 953c66c2b22a ("mm: THP page cache support for ppc64")
Signed-off-by: Hugh Dickins 
---

 mm/memory.c |   47 ---
 1 file changed, 20 insertions(+), 27 deletions(-)

--- 4.10-rc2/mm/memory.c2016-12-25 18:40:50.830453384 -0800
+++ linux/mm/memory.c   2017-01-07 13:34:29.373381551 -0800
@@ -3008,13 +3008,6 @@ static int do_set_pmd(struct vm_fault *v
ret = 0;
count_vm_event(THP_FILE_MAPPED);
 out:
-   /*
-* If we are going to fallback to pte mapping, do a
-* withdraw with pmd lock held.
-*/
-   if (arch_needs_pgtable_deposit() && ret == VM_FAULT_FALLBACK)
-   vmf->prealloc_pte = pgtable_trans_huge_withdraw(vma->vm_mm,
-   vmf->pmd);
spin_unlock(vmf->ptl);
return ret;
 }
@@ -3055,20 +3048,18 @@ int alloc_set_pte(struct vm_fault *vmf,
 
ret = do_set_pmd(vmf, page);
if (ret != VM_FAULT_FALLBACK)
-   goto fault_handled;
+   return ret;
}
 
if (!vmf->pte) {
ret = pte_alloc_one_map(vmf);
if (ret)
-   goto fault_handled;
+   return ret;
}
 
/* Re-check under ptl */
-   if (unlikely(!pte_none(*vmf->pte))) {
-   ret = VM_FAULT_NOPAGE;
-   goto fault_handled;
-   }
+   if (unlikely(!pte_none(*vmf->pte)))
+   return VM_FAULT_NOPAGE;
 
flush_icache_page(vma, page);
entry = mk_pte(page, vma->vm_page_prot);
@@ -3088,15 +3079,8 @@ int alloc_set_pte(struct vm_fault *vmf,
 
/* no need to invalidate: a not-present page won't be cached */
update_mmu_cache(vma, vmf->address, vmf->pte);
-   ret = 0;
 
-fault_handled:
-   /* preallocated pagetable is unused: free it */
-   if (vmf->prealloc_pte) {
-   pte_free(vmf->vma->vm_mm, vmf->prealloc_pte);
-   vmf->prealloc_pte = 0;
-   }
-   return ret;
+   return 0;
 }
 
 
@@ -3360,15 +3344,24 @@ static int do_shared_fault(struct vm_fau
 static int do_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
+   int ret;
 
/* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND */
if (!vma->vm_ops->fault)
-   return VM_FAULT_SIGBUS;
-   if (!(vmf->flags & FAULT_FLAG_WRITE))
-   return do_read_fault(vmf);
-   if (!(vma->vm_flags & VM_SHARED))
-   return do_cow_fault(vmf);
-   return do_shared_fault(vmf);
+   ret = VM_FAULT_SIGBUS;
+   else if (!(vmf->flags & FAULT_FLAG_WRITE))
+   ret = do_read_fault(vmf);
+   else if (!(vma->vm_flags & VM_SHARED))
+   ret = do_cow_fault(vmf);
+   else
+   ret = do_shared_fault(vmf);
+
+   /* preallocated pagetable is unused: free it */
+   if (vmf->prealloc_pte) {
+   pte_free(vma->vm_mm, vmf->prealloc_pte);
+   vmf->prealloc_pte = 0;
+   }
+   return ret;
 }
 
 static int numa_migrate_prep(struct page *page, struct vm_area_struct *vma,

[PATCH] mm: stop leaking PageTables

[Hugh Dickins]

4.10-rc loadtest (even on x86, even without THPCache) fails with
"fork: Cannot allocate memory" or some such; and /proc/meminfo
shows PageTables growing.

rc1 removed the freeing of an unused preallocated pagetable after
do_fault_around() has called map_pages(): which is usually a good
optimization, so that the followup doesn't have to reallocate one;
but it's not sufficient to shift the freeing into alloc_set_pte(),
since there are failure cases (most commonly VM_FAULT_RETRY) which
never reach finish_fault().

Check and free it at the outer level in do_fault(), then we don't
need to worry in alloc_set_pte(), and can restore that to how it was
(I cannot find any reason to pte_free() under lock as it was doing).

And fix a separate pagetable leak, or crash, introduced by the same
change, that could only show up on some ppc64: why does do_set_pmd()'s
failure case attempt to withdraw a pagetable when it never deposited
one, at the same time overwriting (so leaking) the vmf->prealloc_pte?
Residue of an earlier implementation, perhaps?  Delete it.

Fixes: 953c66c2b22a ("mm: THP page cache support for ppc64")
Signed-off-by: Hugh Dickins 
---

 mm/memory.c |   47 ---
 1 file changed, 20 insertions(+), 27 deletions(-)

--- 4.10-rc2/mm/memory.c2016-12-25 18:40:50.830453384 -0800
+++ linux/mm/memory.c   2017-01-07 13:34:29.373381551 -0800
@@ -3008,13 +3008,6 @@ static int do_set_pmd(struct vm_fault *v
ret = 0;
count_vm_event(THP_FILE_MAPPED);
 out:
-   /*
-* If we are going to fallback to pte mapping, do a
-* withdraw with pmd lock held.
-*/
-   if (arch_needs_pgtable_deposit() && ret == VM_FAULT_FALLBACK)
-   vmf->prealloc_pte = pgtable_trans_huge_withdraw(vma->vm_mm,
-   vmf->pmd);
spin_unlock(vmf->ptl);
return ret;
 }
@@ -3055,20 +3048,18 @@ int alloc_set_pte(struct vm_fault *vmf,
 
ret = do_set_pmd(vmf, page);
if (ret != VM_FAULT_FALLBACK)
-   goto fault_handled;
+   return ret;
}
 
if (!vmf->pte) {
ret = pte_alloc_one_map(vmf);
if (ret)
-   goto fault_handled;
+   return ret;
}
 
/* Re-check under ptl */
-   if (unlikely(!pte_none(*vmf->pte))) {
-   ret = VM_FAULT_NOPAGE;
-   goto fault_handled;
-   }
+   if (unlikely(!pte_none(*vmf->pte)))
+   return VM_FAULT_NOPAGE;
 
flush_icache_page(vma, page);
entry = mk_pte(page, vma->vm_page_prot);
@@ -3088,15 +3079,8 @@ int alloc_set_pte(struct vm_fault *vmf,
 
/* no need to invalidate: a not-present page won't be cached */
update_mmu_cache(vma, vmf->address, vmf->pte);
-   ret = 0;
 
-fault_handled:
-   /* preallocated pagetable is unused: free it */
-   if (vmf->prealloc_pte) {
-   pte_free(vmf->vma->vm_mm, vmf->prealloc_pte);
-   vmf->prealloc_pte = 0;
-   }
-   return ret;
+   return 0;
 }
 
 
@@ -3360,15 +3344,24 @@ static int do_shared_fault(struct vm_fau
 static int do_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
+   int ret;
 
/* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND */
if (!vma->vm_ops->fault)
-   return VM_FAULT_SIGBUS;
-   if (!(vmf->flags & FAULT_FLAG_WRITE))
-   return do_read_fault(vmf);
-   if (!(vma->vm_flags & VM_SHARED))
-   return do_cow_fault(vmf);
-   return do_shared_fault(vmf);
+   ret = VM_FAULT_SIGBUS;
+   else if (!(vmf->flags & FAULT_FLAG_WRITE))
+   ret = do_read_fault(vmf);
+   else if (!(vma->vm_flags & VM_SHARED))
+   ret = do_cow_fault(vmf);
+   else
+   ret = do_shared_fault(vmf);
+
+   /* preallocated pagetable is unused: free it */
+   if (vmf->prealloc_pte) {
+   pte_free(vma->vm_mm, vmf->prealloc_pte);
+   vmf->prealloc_pte = 0;
+   }
+   return ret;
 }
 
 static int numa_migrate_prep(struct page *page, struct vm_area_struct *vma,

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On 1/7/2017 9:42 PM, Borislav Petkov wrote:

Hi,

I'm bisecting a boot freeze with 4.10-rc2 on a laptop and the commit in
$Subject is introducing a breakage, see attached splat. Unfortunately,
it is not complete as I don't have any other means of logging dmesg on a
laptop.

A temporary workaround is to boot with "intremap=off".

Unfortunately, I cannot revert

   174cc7187e6f ("ACPICA: Tables: Back port acpi_get_table_with_size() and 
early_acpi_os_unmap_memory() from Linux kernel")

as it doesn't revert cleanly anymore. From looking at the callstack,
though, it looks like AMD IOMMU is calling acpi_put_table() and patch in
$Subject touches it so I'm guessing the AMD IOMMU needs to be updated to
the new way of parsing the IRQ remapping tables or whatever is going on
there - I'm just guessing.


Hi,

Please check if this helps:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d

Thanks,
Rafael



Thanks.

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Rafael J. Wysocki]

On 1/7/2017 9:42 PM, Borislav Petkov wrote:

Hi,

I'm bisecting a boot freeze with 4.10-rc2 on a laptop and the commit in
$Subject is introducing a breakage, see attached splat. Unfortunately,
it is not complete as I don't have any other means of logging dmesg on a
laptop.

A temporary workaround is to boot with "intremap=off".

Unfortunately, I cannot revert

   174cc7187e6f ("ACPICA: Tables: Back port acpi_get_table_with_size() and 
early_acpi_os_unmap_memory() from Linux kernel")

as it doesn't revert cleanly anymore. From looking at the callstack,
though, it looks like AMD IOMMU is calling acpi_put_table() and patch in
$Subject touches it so I'm guessing the AMD IOMMU needs to be updated to
the new way of parsing the IRQ remapping tables or whatever is going on
there - I'm just guessing.


Hi,

Please check if this helps:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d

Thanks,
Rafael



Thanks.

Re: [PATCH] usb: storage: ene_ub6250: remove unused variable

[Sudip Mukherjee]

On Thursday 05 January 2017 06:36 PM, Greg Kroah-Hartman wrote:

On Sun, Dec 18, 2016 at 10:34:31PM +, Sudip Mukherjee wrote:

The variable Newblk was only being assigned some value but was never
used after that.

Signed-off-by: Sudip Mukherjee 
---
  drivers/usb/storage/ene_ub6250.c | 2 --
  1 file changed, 2 deletions(-)


from and signed-off-by does not match :(

Same with your other usb patch...



I can add the From: tag in the patch. But this is from the last time we 
had this same conversation.


http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-February/065121.html


Regards
Sudip

Re: [PATCH] usb: storage: ene_ub6250: remove unused variable

[Sudip Mukherjee]

On Thursday 05 January 2017 06:36 PM, Greg Kroah-Hartman wrote:

On Sun, Dec 18, 2016 at 10:34:31PM +, Sudip Mukherjee wrote:

The variable Newblk was only being assigned some value but was never
used after that.

Signed-off-by: Sudip Mukherjee 
---
  drivers/usb/storage/ene_ub6250.c | 2 --
  1 file changed, 2 deletions(-)


from and signed-off-by does not match :(

Same with your other usb patch...



I can add the From: tag in the patch. But this is from the last time we 
had this same conversation.


http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-February/065121.html


Regards
Sudip

Re: imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

Hi Fabio,

On Sat, Jan 07, 2017 at 07:43:48PM -0200, Fabio Estevam wrote:
> Hi Clemens,
> 
> On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
>  wrote:
> 
> > Great!
> >
> > Did you observe the same effect I described, with the doubling of
> > characters in the front and the leftovers from previous transmissions at
> > the end?
> 
> No, I don't observe these errors when I use 'rts-gpios' in the device tree.
> 
> Maybe you could try to use 'rts-gpios' for a quick test by applying
> the patches I have just sent.
> 
> If you run this test, please remove 'uart-has-rtscts' from your dts.
> According to Documentation/devicetree/bindings/serial/serial.txt they
> are mutually-exclusive.

Just remuxed GPIO signals to these pads, applied your two patches and
used rts-gpios in the DT but I still see the same problem :/

When transmit something, I get doubled characters, then zeros and at the
end garbled data of previous transmissions, same as described in my
first post (Logic analyzer: https://pqgruber.com/rs485_results.png)
The data is always 4096 bytes long, this explains why the echo command
is blocking for about 4 seconds (<- 4096 bytes at a baudrate of 9600).
The TE line is also high until all 4096 bytes are sent.

I think this comes from the UART_XMIT_SIZE which is defined to the page
size.
Maybe there is something wrong in imx_transmit_buffer and leads to the
whole circular buffer being sent out all the time, not stopping..

Do these debug logs tell you anything?
https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5

I am analyzing the signals coming directly from the i.MX6Q, so this must
be a software problem, but I don't understand why it works for you, if
we use the same software.

Do you use any other patches on top of mainline and do you use the SDMA
scripts from the ROM?

Thanks,
Clemens

Re: imx: RS-485 problems during TX, maybe DMA related

[Clemens Gruber]

Hi Fabio,

On Sat, Jan 07, 2017 at 07:43:48PM -0200, Fabio Estevam wrote:
> Hi Clemens,
> 
> On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
>  wrote:
> 
> > Great!
> >
> > Did you observe the same effect I described, with the doubling of
> > characters in the front and the leftovers from previous transmissions at
> > the end?
> 
> No, I don't observe these errors when I use 'rts-gpios' in the device tree.
> 
> Maybe you could try to use 'rts-gpios' for a quick test by applying
> the patches I have just sent.
> 
> If you run this test, please remove 'uart-has-rtscts' from your dts.
> According to Documentation/devicetree/bindings/serial/serial.txt they
> are mutually-exclusive.

Just remuxed GPIO signals to these pads, applied your two patches and
used rts-gpios in the DT but I still see the same problem :/

When transmit something, I get doubled characters, then zeros and at the
end garbled data of previous transmissions, same as described in my
first post (Logic analyzer: https://pqgruber.com/rs485_results.png)
The data is always 4096 bytes long, this explains why the echo command
is blocking for about 4 seconds (<- 4096 bytes at a baudrate of 9600).
The TE line is also high until all 4096 bytes are sent.

I think this comes from the UART_XMIT_SIZE which is defined to the page
size.
Maybe there is something wrong in imx_transmit_buffer and leads to the
whole circular buffer being sent out all the time, not stopping..

Do these debug logs tell you anything?
https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5

I am analyzing the signals coming directly from the i.MX6Q, so this must
be a software problem, but I don't understand why it works for you, if
we use the same software.

Do you use any other patches on top of mainline and do you use the SDMA
scripts from the ROM?

Thanks,
Clemens

Re: [PATCH v2] fscrypt: Factor out bio specific functions

[Richard Weinberger]

Ted,

Am 07.01.2017 um 20:24 schrieb Theodore Ts'o:
> On Wed, Jan 04, 2017 at 12:10:43PM -0800, Eric Biggers wrote:
>>
>> I thought you're supposed to be able to build the kernel no matter how it's
>> configured.  If this patch is really too large for 4.10 then perhaps we 
>> should
>> make FS_ENCRYPTION select CONFIG_BLOCK instead?
> 
> We already have FS_ENCRYPTIOn depending on BLOCK, so this is *not*
> fixing a build break.

Kconfig is tricky. We face a build error with CONFIG_BLOCK=n with 
UBIFS_FS_ENCRYPTION enabled.
UBIFS file encryption does "select FS_ENCRYPTION" just like ext4 and f2fs.
This will enable ENCRYPTION even when no block support is available.

I can make UBIFS depend on BLOCK as intermediate fix.
But the real fix is this patch.

Thanks,
//richard

Re: [PATCH v2] fscrypt: Factor out bio specific functions

[Richard Weinberger]

Ted,

Am 07.01.2017 um 20:24 schrieb Theodore Ts'o:
> On Wed, Jan 04, 2017 at 12:10:43PM -0800, Eric Biggers wrote:
>>
>> I thought you're supposed to be able to build the kernel no matter how it's
>> configured.  If this patch is really too large for 4.10 then perhaps we 
>> should
>> make FS_ENCRYPTION select CONFIG_BLOCK instead?
> 
> We already have FS_ENCRYPTIOn depending on BLOCK, so this is *not*
> fixing a build break.

Kconfig is tricky. We face a build error with CONFIG_BLOCK=n with 
UBIFS_FS_ENCRYPTION enabled.
UBIFS file encryption does "select FS_ENCRYPTION" just like ext4 and f2fs.
This will enable ENCRYPTION even when no block support is available.

I can make UBIFS depend on BLOCK as intermediate fix.
But the real fix is this patch.

Thanks,
//richard

Re: [RFC PATCH] intel: Use upper_32_bits and lower_32_bits

[Julia Lawall]

On Sat, 7 Jan 2017, Joe Perches wrote:

> Shifting and masking various types can be made a bit
> simpler to read by using the available kernel macros.

It looks much nicer to me, especially in the lower case, where there are
multiple ways to express the same thing.

julia


>
> Signed-off-by: Joe Perches 
> ---
>
> This RFC patch is meant as an example, not necessarily
> to apply, though it does compile to equivalent code.
>
> It does seem a bit simpler for a human to read.
>
> Perhaps this could be automated via a coccinelle script,
> but this was done with grep & sed and some typing.
>
> Treewide, there are many hundred instances of this style code
> that could be converted.
>
> Dunno if it's really worth it though.
>
> Another usage that could be converted is DMA_BIT_MASK(32)
> where it is equivalent to upper_32_bits and lower_32_bits.
>
>  drivers/net/ethernet/intel/e1000/e1000_ethtool.c   |  8 
>  drivers/net/ethernet/intel/e1000/e1000_main.c  |  8 
>  drivers/net/ethernet/intel/e1000e/ethtool.c|  8 
>  drivers/net/ethernet/intel/fm10k/fm10k_common.c|  4 ++--
>  drivers/net/ethernet/intel/fm10k/fm10k_pf.c|  2 +-
>  drivers/net/ethernet/intel/i40e/i40e_common.c  |  4 ++--
>  drivers/net/ethernet/intel/i40e/i40e_ethtool.c |  8 
>  drivers/net/ethernet/intel/i40e/i40e_main.c|  4 ++--
>  drivers/net/ethernet/intel/i40e/i40e_ptp.c | 12 ++--
>  drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |  9 +
>  drivers/net/ethernet/intel/i40evf/i40evf_main.c|  4 ++--
>  drivers/net/ethernet/intel/igb/igb_main.c  | 10 --
>  drivers/net/ethernet/intel/igb/igb_ptp.c   |  4 ++--
>  drivers/net/ethernet/intel/ixgb/ixgb_main.c| 12 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_common.h|  4 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c   | 12 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 16 
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c   | 12 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c  |  4 ++--
>  19 files changed, 72 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c 
> b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> index 975eeb885ca2..11ad95f34f4f 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> @@ -1021,8 +1021,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter 
> *adapter)
>   }
>   txdr->next_to_use = txdr->next_to_clean = 0;
>
> - ew32(TDBAL, ((u64)txdr->dma & 0x));
> - ew32(TDBAH, ((u64)txdr->dma >> 32));
> + ew32(TDBAL, lower_32_bits(txdr->dma));
> + ew32(TDBAH, upper_32_bits(txdr->dma));
>   ew32(TDLEN, txdr->count * sizeof(struct e1000_tx_desc));
>   ew32(TDH, 0);
>   ew32(TDT, 0);
> @@ -1081,8 +1081,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter 
> *adapter)
>
>   rctl = er32(RCTL);
>   ew32(RCTL, rctl & ~E1000_RCTL_EN);
> - ew32(RDBAL, ((u64)rxdr->dma & 0x));
> - ew32(RDBAH, ((u64)rxdr->dma >> 32));
> + ew32(RDBAL, lower_32_bits(rxdr->dma));
> + ew32(RDBAH, upper_32_bits(rxdr->dma));
>   ew32(RDLEN, rxdr->size);
>   ew32(RDH, 0);
>   ew32(RDT, 0);
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c 
> b/drivers/net/ethernet/intel/e1000/e1000_main.c
> index 93fc6c67306b..d222f731f280 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> @@ -1614,8 +1614,8 @@ static void e1000_configure_tx(struct e1000_adapter 
> *adapter)
>   tdlen = adapter->tx_ring[0].count *
>   sizeof(struct e1000_tx_desc);
>   ew32(TDLEN, tdlen);
> - ew32(TDBAH, (tdba >> 32));
> - ew32(TDBAL, (tdba & 0xULL));
> + ew32(TDBAH, upper_32_bits(tdba));
> + ew32(TDBAL, lower_32_bits(tdba));
>   ew32(TDT, 0);
>   ew32(TDH, 0);
>   adapter->tx_ring[0].tdh = ((hw->mac_type >= e1000_82543) ?
> @@ -1896,8 +1896,8 @@ static void e1000_configure_rx(struct e1000_adapter 
> *adapter)
>   default:
>   rdba = adapter->rx_ring[0].dma;
>   ew32(RDLEN, rdlen);
> - ew32(RDBAH, (rdba >> 32));
> - ew32(RDBAL, (rdba & 0xULL));
> + ew32(RDBAH, upper_32_bits(rdba));
> + ew32(RDBAL, lower_32_bits(rdba));
>   ew32(RDT, 0);
>   ew32(RDH, 0);
>   adapter->rx_ring[0].rdh = ((hw->mac_type >= e1000_82543) ?
> diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c 
> b/drivers/net/ethernet/intel/e1000e/ethtool.c
> index 7aff68a4a4df..35304b380eaa 100644
> --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c

Re: [RFC PATCH] intel: Use upper_32_bits and lower_32_bits

[Julia Lawall]

On Sat, 7 Jan 2017, Joe Perches wrote:

> Shifting and masking various types can be made a bit
> simpler to read by using the available kernel macros.

It looks much nicer to me, especially in the lower case, where there are
multiple ways to express the same thing.

julia


>
> Signed-off-by: Joe Perches 
> ---
>
> This RFC patch is meant as an example, not necessarily
> to apply, though it does compile to equivalent code.
>
> It does seem a bit simpler for a human to read.
>
> Perhaps this could be automated via a coccinelle script,
> but this was done with grep & sed and some typing.
>
> Treewide, there are many hundred instances of this style code
> that could be converted.
>
> Dunno if it's really worth it though.
>
> Another usage that could be converted is DMA_BIT_MASK(32)
> where it is equivalent to upper_32_bits and lower_32_bits.
>
>  drivers/net/ethernet/intel/e1000/e1000_ethtool.c   |  8 
>  drivers/net/ethernet/intel/e1000/e1000_main.c  |  8 
>  drivers/net/ethernet/intel/e1000e/ethtool.c|  8 
>  drivers/net/ethernet/intel/fm10k/fm10k_common.c|  4 ++--
>  drivers/net/ethernet/intel/fm10k/fm10k_pf.c|  2 +-
>  drivers/net/ethernet/intel/i40e/i40e_common.c  |  4 ++--
>  drivers/net/ethernet/intel/i40e/i40e_ethtool.c |  8 
>  drivers/net/ethernet/intel/i40e/i40e_main.c|  4 ++--
>  drivers/net/ethernet/intel/i40e/i40e_ptp.c | 12 ++--
>  drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |  9 +
>  drivers/net/ethernet/intel/i40evf/i40evf_main.c|  4 ++--
>  drivers/net/ethernet/intel/igb/igb_main.c  | 10 --
>  drivers/net/ethernet/intel/igb/igb_ptp.c   |  4 ++--
>  drivers/net/ethernet/intel/ixgb/ixgb_main.c| 12 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_common.h|  4 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c   | 12 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 16 
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c   | 12 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c  |  4 ++--
>  19 files changed, 72 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c 
> b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> index 975eeb885ca2..11ad95f34f4f 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> @@ -1021,8 +1021,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter 
> *adapter)
>   }
>   txdr->next_to_use = txdr->next_to_clean = 0;
>
> - ew32(TDBAL, ((u64)txdr->dma & 0x));
> - ew32(TDBAH, ((u64)txdr->dma >> 32));
> + ew32(TDBAL, lower_32_bits(txdr->dma));
> + ew32(TDBAH, upper_32_bits(txdr->dma));
>   ew32(TDLEN, txdr->count * sizeof(struct e1000_tx_desc));
>   ew32(TDH, 0);
>   ew32(TDT, 0);
> @@ -1081,8 +1081,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter 
> *adapter)
>
>   rctl = er32(RCTL);
>   ew32(RCTL, rctl & ~E1000_RCTL_EN);
> - ew32(RDBAL, ((u64)rxdr->dma & 0x));
> - ew32(RDBAH, ((u64)rxdr->dma >> 32));
> + ew32(RDBAL, lower_32_bits(rxdr->dma));
> + ew32(RDBAH, upper_32_bits(rxdr->dma));
>   ew32(RDLEN, rxdr->size);
>   ew32(RDH, 0);
>   ew32(RDT, 0);
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c 
> b/drivers/net/ethernet/intel/e1000/e1000_main.c
> index 93fc6c67306b..d222f731f280 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> @@ -1614,8 +1614,8 @@ static void e1000_configure_tx(struct e1000_adapter 
> *adapter)
>   tdlen = adapter->tx_ring[0].count *
>   sizeof(struct e1000_tx_desc);
>   ew32(TDLEN, tdlen);
> - ew32(TDBAH, (tdba >> 32));
> - ew32(TDBAL, (tdba & 0xULL));
> + ew32(TDBAH, upper_32_bits(tdba));
> + ew32(TDBAL, lower_32_bits(tdba));
>   ew32(TDT, 0);
>   ew32(TDH, 0);
>   adapter->tx_ring[0].tdh = ((hw->mac_type >= e1000_82543) ?
> @@ -1896,8 +1896,8 @@ static void e1000_configure_rx(struct e1000_adapter 
> *adapter)
>   default:
>   rdba = adapter->rx_ring[0].dma;
>   ew32(RDLEN, rdlen);
> - ew32(RDBAH, (rdba >> 32));
> - ew32(RDBAL, (rdba & 0xULL));
> + ew32(RDBAH, upper_32_bits(rdba));
> + ew32(RDBAL, lower_32_bits(rdba));
>   ew32(RDT, 0);
>   ew32(RDH, 0);
>   adapter->rx_ring[0].rdh = ((hw->mac_type >= e1000_82543) ?
> diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c 
> b/drivers/net/ethernet/intel/e1000e/ethtool.c
> index 7aff68a4a4df..35304b380eaa 100644
> --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
> @@ -1203,8 

[PATCH] net: intel: e100: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/intel/e100.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/e100.c 
b/drivers/net/ethernet/intel/e100.c
index 25c6dfd..04e9392 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -2426,19 +2426,21 @@ static int e100_loopback_test(struct nic *nic, enum 
loopback loopback_mode)
 #define E100_82552_LED_ON   0x000F /* LEDTX and LED_RX both on */
 #define E100_82552_LED_OFF  0x000A /* LEDTX and LED_RX both off */
 
-static int e100_get_settings(struct net_device *netdev, struct ethtool_cmd 
*cmd)
+static int e100_get_link_ksettings(struct net_device *netdev,
+  struct ethtool_link_ksettings *cmd)
 {
struct nic *nic = netdev_priv(netdev);
-   return mii_ethtool_gset(>mii, cmd);
+   return mii_ethtool_get_link_ksettings(>mii, cmd);
 }
 
-static int e100_set_settings(struct net_device *netdev, struct ethtool_cmd 
*cmd)
+static int e100_set_link_ksettings(struct net_device *netdev,
+  const struct ethtool_link_ksettings *cmd)
 {
struct nic *nic = netdev_priv(netdev);
int err;
 
mdio_write(netdev, nic->mii.phy_id, MII_BMCR, BMCR_RESET);
-   err = mii_ethtool_sset(>mii, cmd);
+   err = mii_ethtool_set_link_ksettings(>mii, cmd);
e100_exec_cb(nic, NULL, e100_configure);
 
return err;
@@ -2741,8 +2743,6 @@ static void e100_get_strings(struct net_device *netdev, 
u32 stringset, u8 *data)
 }
 
 static const struct ethtool_ops e100_ethtool_ops = {
-   .get_settings   = e100_get_settings,
-   .set_settings   = e100_set_settings,
.get_drvinfo= e100_get_drvinfo,
.get_regs_len   = e100_get_regs_len,
.get_regs   = e100_get_regs,
@@ -2763,6 +2763,8 @@ static void e100_get_strings(struct net_device *netdev, 
u32 stringset, u8 *data)
.get_ethtool_stats  = e100_get_ethtool_stats,
.get_sset_count = e100_get_sset_count,
.get_ts_info= ethtool_op_get_ts_info,
+   .get_link_ksettings = e100_get_link_ksettings,
+   .set_link_ksettings = e100_set_link_ksettings,
 };
 
 static int e100_do_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
-- 
1.7.4.4

[PATCH] net: intel: e100: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/intel/e100.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/e100.c 
b/drivers/net/ethernet/intel/e100.c
index 25c6dfd..04e9392 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -2426,19 +2426,21 @@ static int e100_loopback_test(struct nic *nic, enum 
loopback loopback_mode)
 #define E100_82552_LED_ON   0x000F /* LEDTX and LED_RX both on */
 #define E100_82552_LED_OFF  0x000A /* LEDTX and LED_RX both off */
 
-static int e100_get_settings(struct net_device *netdev, struct ethtool_cmd 
*cmd)
+static int e100_get_link_ksettings(struct net_device *netdev,
+  struct ethtool_link_ksettings *cmd)
 {
struct nic *nic = netdev_priv(netdev);
-   return mii_ethtool_gset(>mii, cmd);
+   return mii_ethtool_get_link_ksettings(>mii, cmd);
 }
 
-static int e100_set_settings(struct net_device *netdev, struct ethtool_cmd 
*cmd)
+static int e100_set_link_ksettings(struct net_device *netdev,
+  const struct ethtool_link_ksettings *cmd)
 {
struct nic *nic = netdev_priv(netdev);
int err;
 
mdio_write(netdev, nic->mii.phy_id, MII_BMCR, BMCR_RESET);
-   err = mii_ethtool_sset(>mii, cmd);
+   err = mii_ethtool_set_link_ksettings(>mii, cmd);
e100_exec_cb(nic, NULL, e100_configure);
 
return err;
@@ -2741,8 +2743,6 @@ static void e100_get_strings(struct net_device *netdev, 
u32 stringset, u8 *data)
 }
 
 static const struct ethtool_ops e100_ethtool_ops = {
-   .get_settings   = e100_get_settings,
-   .set_settings   = e100_set_settings,
.get_drvinfo= e100_get_drvinfo,
.get_regs_len   = e100_get_regs_len,
.get_regs   = e100_get_regs,
@@ -2763,6 +2763,8 @@ static void e100_get_strings(struct net_device *netdev, 
u32 stringset, u8 *data)
.get_ethtool_stats  = e100_get_ethtool_stats,
.get_sset_count = e100_get_sset_count,
.get_ts_info= ethtool_op_get_ts_info,
+   .get_link_ksettings = e100_get_link_ksettings,
+   .set_link_ksettings = e100_set_link_ksettings,
 };
 
 static int e100_do_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
-- 
1.7.4.4

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

[Eric Biggers]

Hi David,

On Sat, Jan 07, 2017 at 04:37:36PM -0500, David Miller wrote:
> From: "Jason A. Donenfeld" 
> Date: Sat,  7 Jan 2017 15:40:56 +0100
> 
> > This gives a clear speed and security improvement. Siphash is both
> > faster and is more solid crypto than the aging MD5.
[snip]
> 
> This and the next patch are a real shame, performance wise, on cpus
> that have single-instruction SHA1 and MD5 implementations.  Sparc64
> has both, and I believe x86_64 can do SHA1 these days.
> 
> It took so long to get those instructions into real silicon, and then
> have software implemented to make use of them as well.
> 
> Who knows when we'll see SipHash widely deployed in any instruction
> set, if at all, right?  And by that time we'll possibly find out that
> "Oh shit, this SipHash thing has flaws!" and we'll need
> DIPPY_DO_DA_HASH and thus be forced back to a software implementation
> again.
> 
> I understand the reasons why these patches are being proposed, I just
> thought I'd mention the issue of cpus that implement secure hash
> algorithm instructions.

Well, except those instructions aren't actually used in these places.  Although
x86_64 SHA1-NI accelerated SHA-1 is available in the Linux crypto API, it seems
that in kernel code it remains impractical to use these instructions on small
amounts of data because they use XMM registers, which means the overhead of
kernel_fpu_begin()/kernel_fpu_end() must be incurred.  Furthermore,
kernel_fpu_begin() is not allowed in all contexts so there has to be a fallback.

Out of curiosity, is this actually a solvable problem, e.g. by making the code
using the XMM registers responsible for saving and restoring the ones clobbered,
or by optimizing kernel_fpu_begin()/kernel_fpu_end()?  Or does it in fact remain
impractical for such instructions to be used for applications like this one?

Eric

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

[Eric Biggers]

Hi David,

On Sat, Jan 07, 2017 at 04:37:36PM -0500, David Miller wrote:
> From: "Jason A. Donenfeld" 
> Date: Sat,  7 Jan 2017 15:40:56 +0100
> 
> > This gives a clear speed and security improvement. Siphash is both
> > faster and is more solid crypto than the aging MD5.
[snip]
> 
> This and the next patch are a real shame, performance wise, on cpus
> that have single-instruction SHA1 and MD5 implementations.  Sparc64
> has both, and I believe x86_64 can do SHA1 these days.
> 
> It took so long to get those instructions into real silicon, and then
> have software implemented to make use of them as well.
> 
> Who knows when we'll see SipHash widely deployed in any instruction
> set, if at all, right?  And by that time we'll possibly find out that
> "Oh shit, this SipHash thing has flaws!" and we'll need
> DIPPY_DO_DA_HASH and thus be forced back to a software implementation
> again.
> 
> I understand the reasons why these patches are being proposed, I just
> thought I'd mention the issue of cpus that implement secure hash
> algorithm instructions.

Well, except those instructions aren't actually used in these places.  Although
x86_64 SHA1-NI accelerated SHA-1 is available in the Linux crypto API, it seems
that in kernel code it remains impractical to use these instructions on small
amounts of data because they use XMM registers, which means the overhead of
kernel_fpu_begin()/kernel_fpu_end() must be incurred.  Furthermore,
kernel_fpu_begin() is not allowed in all contexts so there has to be a fallback.

Out of curiosity, is this actually a solvable problem, e.g. by making the code
using the XMM registers responsible for saving and restoring the ones clobbered,
or by optimizing kernel_fpu_begin()/kernel_fpu_end()?  Or does it in fact remain
impractical for such instructions to be used for applications like this one?

Eric

[PATCH v2 1/2] Staging: unisys: visorbus: visorbus_main.c: fixed style

[Derek Robson]

Changed file permissions to octal sytle.
Found using checkpatch.

Acked-by: David Kershner 
Signed-off-by: Derek Robson 
---
Version 1 had duplicated subject/commit message, fixed in v2

 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 3457ef338e1e..28ca291a4053 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -984,7 +984,7 @@ create_bus_instance(struct visor_device *dev)
goto err_hdr_info;
}
dev->debugfs_client_bus_info =
-   debugfs_create_file("client_bus_info", S_IRUSR | S_IRGRP,
+   debugfs_create_file("client_bus_info", 0440,
dev->debugfs_dir, dev,
_bus_info_debugfs_fops);
if (!dev->debugfs_client_bus_info) {
@@ -1337,10 +1337,10 @@ visorbus_exit(void)
debugfs_remove_recursive(visorbus_debugfs_dir);
 }
 
-module_param_named(forcematch, visorbus_forcematch, int, S_IRUGO);
+module_param_named(forcematch, visorbus_forcematch, int, 0444);
 MODULE_PARM_DESC(visorbus_forcematch,
 "1 to force a successful dev <--> drv match");
 
-module_param_named(forcenomatch, visorbus_forcenomatch, int, S_IRUGO);
+module_param_named(forcenomatch, visorbus_forcenomatch, int, 0444);
 MODULE_PARM_DESC(visorbus_forcenomatch,
 "1 to force an UNsuccessful dev <--> drv match");
-- 
2.11.0

[PATCH v2 1/2] Staging: unisys: visorbus: visorbus_main.c: fixed style

[Derek Robson]

Changed file permissions to octal sytle.
Found using checkpatch.

Acked-by: David Kershner 
Signed-off-by: Derek Robson 
---
Version 1 had duplicated subject/commit message, fixed in v2

 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 3457ef338e1e..28ca291a4053 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -984,7 +984,7 @@ create_bus_instance(struct visor_device *dev)
goto err_hdr_info;
}
dev->debugfs_client_bus_info =
-   debugfs_create_file("client_bus_info", S_IRUSR | S_IRGRP,
+   debugfs_create_file("client_bus_info", 0440,
dev->debugfs_dir, dev,
_bus_info_debugfs_fops);
if (!dev->debugfs_client_bus_info) {
@@ -1337,10 +1337,10 @@ visorbus_exit(void)
debugfs_remove_recursive(visorbus_debugfs_dir);
 }
 
-module_param_named(forcematch, visorbus_forcematch, int, S_IRUGO);
+module_param_named(forcematch, visorbus_forcematch, int, 0444);
 MODULE_PARM_DESC(visorbus_forcematch,
 "1 to force a successful dev <--> drv match");
 
-module_param_named(forcenomatch, visorbus_forcenomatch, int, S_IRUGO);
+module_param_named(forcenomatch, visorbus_forcenomatch, int, 0444);
 MODULE_PARM_DESC(visorbus_forcenomatch,
 "1 to force an UNsuccessful dev <--> drv match");
-- 
2.11.0

[PATCH v2 2/2] Staging: unisys: visorbus: visorchipset.c: style fix

[Derek Robson]

Changed file permissions to octal sytle.
Found using checkpatch.

Acked-by: David Kershner 
Signed-off-by: Derek Robson 
---
Version 1 had duplicated subject/commit message, fixed in v2

 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index d7148c351d3f..66944e7534e9 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -2277,7 +2277,7 @@ static void exit_unisys(void)
acpi_bus_unregister_driver(_acpi_driver);
 }
 
-module_param_named(major, visorchipset_major, int, S_IRUGO);
+module_param_named(major, visorchipset_major, int, 0444);
 MODULE_PARM_DESC(visorchipset_major,
 "major device number to use for the device node");
 
-- 
2.11.0

[PATCH v2 2/2] Staging: unisys: visorbus: visorchipset.c: style fix

[Derek Robson]

Changed file permissions to octal sytle.
Found using checkpatch.

Acked-by: David Kershner 
Signed-off-by: Derek Robson 
---
Version 1 had duplicated subject/commit message, fixed in v2

 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index d7148c351d3f..66944e7534e9 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -2277,7 +2277,7 @@ static void exit_unisys(void)
acpi_bus_unregister_driver(_acpi_driver);
 }
 
-module_param_named(major, visorchipset_major, int, S_IRUGO);
+module_param_named(major, visorchipset_major, int, 0444);
 MODULE_PARM_DESC(visorchipset_major,
 "major device number to use for the device node");
 
-- 
2.11.0

[PATCH v2 0/2] Staging: unisys: visorbus: style fix

[Derek Robson]

Two files change in style fix, changes are octal file permiss
ions.

version 2: first verion has duplicated subject/commit messages


Derek Robson (2):
  Staging: unisys: visorbus: visorbus_main.c: fixed style
  Staging: unisys: visorbus: visorchipset.c: style fix

 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
 drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.11.0

[PATCH v2 0/2] Staging: unisys: visorbus: style fix

[Derek Robson]

Two files change in style fix, changes are octal file permiss
ions.

version 2: first verion has duplicated subject/commit messages


Derek Robson (2):
  Staging: unisys: visorbus: visorbus_main.c: fixed style
  Staging: unisys: visorbus: visorchipset.c: style fix

 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
 drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.11.0

Re: [PATCH v6 2/3] serial: exar: split out the exar code from 8250_pci

[kbuild test robot]

Hi Sudip,

[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sudip-Mukherjee/add-gpio-support-to-exar/20170107-005654
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: x86_64-randconfig-s2-01080418 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpio/gpio-exar.c: In function 'gpio_exar_probe':
>> drivers/gpio/gpio-exar.c:146: warning: unused variable 'exar_temp'

vim +/exar_temp +146 drivers/gpio/gpio-exar.c

b9ca4a99 Sudip Mukherjee 2017-01-05  130  }
b9ca4a99 Sudip Mukherjee 2017-01-05  131  
b9ca4a99 Sudip Mukherjee 2017-01-05  132  static void exar_set_value(struct 
gpio_chip *chip, unsigned int offset,
b9ca4a99 Sudip Mukherjee 2017-01-05  133   int value)
b9ca4a99 Sudip Mukherjee 2017-01-05  134  {
b9ca4a99 Sudip Mukherjee 2017-01-05  135if (offset < 8)
b9ca4a99 Sudip Mukherjee 2017-01-05  136exar_update(chip, 
EXAR_OFFSET_MPIOLVL_LO, value,
b9ca4a99 Sudip Mukherjee 2017-01-05  137offset);
b9ca4a99 Sudip Mukherjee 2017-01-05  138else
b9ca4a99 Sudip Mukherjee 2017-01-05  139exar_update(chip, 
EXAR_OFFSET_MPIOLVL_HI, value,
b9ca4a99 Sudip Mukherjee 2017-01-05  140offset - 8);
b9ca4a99 Sudip Mukherjee 2017-01-05  141  }
b9ca4a99 Sudip Mukherjee 2017-01-05  142  
b9ca4a99 Sudip Mukherjee 2017-01-05  143  static int gpio_exar_probe(struct 
platform_device *pdev)
b9ca4a99 Sudip Mukherjee 2017-01-05  144  {
b9ca4a99 Sudip Mukherjee 2017-01-05  145struct pci_dev *dev = 
platform_get_drvdata(pdev);
b9ca4a99 Sudip Mukherjee 2017-01-05 @146struct exar_gpio_chip 
*exar_gpio, *exar_temp;
b9ca4a99 Sudip Mukherjee 2017-01-05  147void __iomem *p;
b9ca4a99 Sudip Mukherjee 2017-01-05  148int index = 1;
b9ca4a99 Sudip Mukherjee 2017-01-05  149int ret;
b9ca4a99 Sudip Mukherjee 2017-01-05  150  
b9ca4a99 Sudip Mukherjee 2017-01-05  151if (dev->vendor != 
PCI_VENDOR_ID_EXAR)
b9ca4a99 Sudip Mukherjee 2017-01-05  152return -ENODEV;
b9ca4a99 Sudip Mukherjee 2017-01-05  153  
b9ca4a99 Sudip Mukherjee 2017-01-05  154p = pci_ioremap_bar(dev, 0);

:: The code at line 146 was first introduced by commit
:: b9ca4a9920e0d8e8fca8a56c4132bfc8c6435506 gpio: exar: add gpio for exar 
cards

:: TO: Sudip Mukherjee <sudipm.mukher...@gmail.com>
:: CC: 0day robot <fengguang...@intel.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v6 2/3] serial: exar: split out the exar code from 8250_pci

[kbuild test robot]

Hi Sudip,

[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sudip-Mukherjee/add-gpio-support-to-exar/20170107-005654
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: x86_64-randconfig-s2-01080418 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpio/gpio-exar.c: In function 'gpio_exar_probe':
>> drivers/gpio/gpio-exar.c:146: warning: unused variable 'exar_temp'

vim +/exar_temp +146 drivers/gpio/gpio-exar.c

b9ca4a99 Sudip Mukherjee 2017-01-05  130  }
b9ca4a99 Sudip Mukherjee 2017-01-05  131  
b9ca4a99 Sudip Mukherjee 2017-01-05  132  static void exar_set_value(struct 
gpio_chip *chip, unsigned int offset,
b9ca4a99 Sudip Mukherjee 2017-01-05  133   int value)
b9ca4a99 Sudip Mukherjee 2017-01-05  134  {
b9ca4a99 Sudip Mukherjee 2017-01-05  135if (offset < 8)
b9ca4a99 Sudip Mukherjee 2017-01-05  136exar_update(chip, 
EXAR_OFFSET_MPIOLVL_LO, value,
b9ca4a99 Sudip Mukherjee 2017-01-05  137offset);
b9ca4a99 Sudip Mukherjee 2017-01-05  138else
b9ca4a99 Sudip Mukherjee 2017-01-05  139exar_update(chip, 
EXAR_OFFSET_MPIOLVL_HI, value,
b9ca4a99 Sudip Mukherjee 2017-01-05  140offset - 8);
b9ca4a99 Sudip Mukherjee 2017-01-05  141  }
b9ca4a99 Sudip Mukherjee 2017-01-05  142  
b9ca4a99 Sudip Mukherjee 2017-01-05  143  static int gpio_exar_probe(struct 
platform_device *pdev)
b9ca4a99 Sudip Mukherjee 2017-01-05  144  {
b9ca4a99 Sudip Mukherjee 2017-01-05  145struct pci_dev *dev = 
platform_get_drvdata(pdev);
b9ca4a99 Sudip Mukherjee 2017-01-05 @146struct exar_gpio_chip 
*exar_gpio, *exar_temp;
b9ca4a99 Sudip Mukherjee 2017-01-05  147void __iomem *p;
b9ca4a99 Sudip Mukherjee 2017-01-05  148int index = 1;
b9ca4a99 Sudip Mukherjee 2017-01-05  149int ret;
b9ca4a99 Sudip Mukherjee 2017-01-05  150  
b9ca4a99 Sudip Mukherjee 2017-01-05  151if (dev->vendor != 
PCI_VENDOR_ID_EXAR)
b9ca4a99 Sudip Mukherjee 2017-01-05  152return -ENODEV;
b9ca4a99 Sudip Mukherjee 2017-01-05  153  
b9ca4a99 Sudip Mukherjee 2017-01-05  154p = pci_ioremap_bar(dev, 0);

:: The code at line 146 was first introduced by commit
:: b9ca4a9920e0d8e8fca8a56c4132bfc8c6435506 gpio: exar: add gpio for exar 
cards

:: TO: Sudip Mukherjee 
:: CC: 0day robot 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
 wrote:

> Great!
>
> Did you observe the same effect I described, with the doubling of
> characters in the front and the leftovers from previous transmissions at
> the end?

No, I don't observe these errors when I use 'rts-gpios' in the device tree.

Maybe you could try to use 'rts-gpios' for a quick test by applying
the patches I have just sent.

If you run this test, please remove 'uart-has-rtscts' from your dts.
According to Documentation/devicetree/bindings/serial/serial.txt they
are mutually-exclusive.

Regards,

Fabio Estevam

Re: imx: RS-485 problems during TX, maybe DMA related

[Fabio Estevam]

Hi Clemens,

On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
 wrote:

> Great!
>
> Did you observe the same effect I described, with the doubling of
> characters in the front and the leftovers from previous transmissions at
> the end?

No, I don't observe these errors when I use 'rts-gpios' in the device tree.

Maybe you could try to use 'rts-gpios' for a quick test by applying
the patches I have just sent.

If you run this test, please remove 'uart-has-rtscts' from your dts.
According to Documentation/devicetree/bindings/serial/serial.txt they
are mutually-exclusive.

Regards,

Fabio Estevam

Re: [PATCH] i2c: print correct device invalid address

[Vladimir Zapolskiy]

On 01/06/2017 01:02 PM, John Garry wrote:
> In of_i2c_register_device(), when the check for
> device address validity fails we print the info.addr,
> which has not been assigned properly.
> 
> Fix this by printing the actual invalid address.
> 
> Signed-off-by: John Garry 
> 
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index cf9e396..03cfcdd 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -1708,7 +1708,7 @@ static struct i2c_client *of_i2c_register_device(struct 
> i2c_adapter *adap,
>  
>   if (i2c_check_addr_validity(addr, info.flags)) {
>   dev_err(>dev, "of_i2c: invalid addr=%x on %s\n",
> - info.addr, node->full_name);
> + addr, node->full_name);
>   return ERR_PTR(-EINVAL);
>   }
>  
> 

Reviewed-by: Vladimir Zapolskiy 
Fixes: b4e2f6ac1281 ("i2c: apply DT flags when probing")

Thank you for the fix.

--
With best wishes,
Vladimir

Re: [PATCH] i2c: print correct device invalid address

[Vladimir Zapolskiy]

On 01/06/2017 01:02 PM, John Garry wrote:
> In of_i2c_register_device(), when the check for
> device address validity fails we print the info.addr,
> which has not been assigned properly.
> 
> Fix this by printing the actual invalid address.
> 
> Signed-off-by: John Garry 
> 
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index cf9e396..03cfcdd 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -1708,7 +1708,7 @@ static struct i2c_client *of_i2c_register_device(struct 
> i2c_adapter *adap,
>  
>   if (i2c_check_addr_validity(addr, info.flags)) {
>   dev_err(>dev, "of_i2c: invalid addr=%x on %s\n",
> - info.addr, node->full_name);
> + addr, node->full_name);
>   return ERR_PTR(-EINVAL);
>   }
>  
> 

Reviewed-by: Vladimir Zapolskiy 
Fixes: b4e2f6ac1281 ("i2c: apply DT flags when probing")

Thank you for the fix.

--
With best wishes,
Vladimir

[PATCH] net: ibm: ibmvnic: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/ibm/ibmvnic.c |   31 ++-
 1 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index c125966..3c2526b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1025,21 +1025,26 @@ static void ibmvnic_netpoll_controller(struct 
net_device *dev)
 
 /* ethtool functions */
 
-static int ibmvnic_get_settings(struct net_device *netdev,
-   struct ethtool_cmd *cmd)
+static int ibmvnic_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
 {
-   cmd->supported = (SUPPORTED_1000baseT_Full | SUPPORTED_Autoneg |
+   u32 supported, advertising;
+
+   supported = (SUPPORTED_1000baseT_Full | SUPPORTED_Autoneg |
  SUPPORTED_FIBRE);
-   cmd->advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg |
+   advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg |
ADVERTISED_FIBRE);
-   ethtool_cmd_speed_set(cmd, SPEED_1000);
-   cmd->duplex = DUPLEX_FULL;
-   cmd->port = PORT_FIBRE;
-   cmd->phy_address = 0;
-   cmd->transceiver = XCVR_INTERNAL;
-   cmd->autoneg = AUTONEG_ENABLE;
-   cmd->maxtxpkt = 0;
-   cmd->maxrxpkt = 1;
+   cmd->base.speed = SPEED_1000;
+   cmd->base.duplex = DUPLEX_FULL;
+   cmd->base.port = PORT_FIBRE;
+   cmd->base.phy_address = 0;
+   cmd->base.autoneg = AUTONEG_ENABLE;
+
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   advertising);
+
return 0;
 }
 
@@ -1132,7 +1137,6 @@ static void ibmvnic_get_ethtool_stats(struct net_device 
*dev,
 }
 
 static const struct ethtool_ops ibmvnic_ethtool_ops = {
-   .get_settings   = ibmvnic_get_settings,
.get_drvinfo= ibmvnic_get_drvinfo,
.get_msglevel   = ibmvnic_get_msglevel,
.set_msglevel   = ibmvnic_set_msglevel,
@@ -1141,6 +1145,7 @@ static void ibmvnic_get_ethtool_stats(struct net_device 
*dev,
.get_strings= ibmvnic_get_strings,
.get_sset_count = ibmvnic_get_sset_count,
.get_ethtool_stats  = ibmvnic_get_ethtool_stats,
+   .get_link_ksettings = ibmvnic_get_link_ksettings,
 };
 
 /* Routines for managing CRQs/sCRQs  */
-- 
1.7.4.4

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

[David Miller]

From: "Jason A. Donenfeld" 
Date: Sat,  7 Jan 2017 15:40:56 +0100

> This gives a clear speed and security improvement. Siphash is both
> faster and is more solid crypto than the aging MD5.
> 
> Rather than manually filling MD5 buffers, for IPv6, we simply create
> a layout by a simple anonymous struct, for which gcc generates
> rather efficient code. For IPv4, we pass the values directly to the
> short input convenience functions.
> 
> 64-bit x86_64:
> [1.683628] secure_tcpv6_sequence_number_md5# cycles: 99563527
> [1.717350] secure_tcp_sequence_number_md5# cycles: 92890502
> [1.741968] secure_tcpv6_sequence_number_siphash# cycles: 67825362
> [1.762048] secure_tcp_sequence_number_siphash# cycles: 67485526
> 
> 32-bit x86:
> [1.600012] secure_tcpv6_sequence_number_md5# cycles: 103227892
> [1.634219] secure_tcp_sequence_number_md5# cycles: 94732544
> [1.669102] secure_tcpv6_sequence_number_siphash# cycles: 96299384
> [1.700165] secure_tcp_sequence_number_siphash# cycles: 86015473
> 
> Signed-off-by: Jason A. Donenfeld 

This and the next patch are a real shame, performance wise, on cpus
that have single-instruction SHA1 and MD5 implementations.  Sparc64
has both, and I believe x86_64 can do SHA1 these days.

It took so long to get those instructions into real silicon, and then
have software implemented to make use of them as well.

Who knows when we'll see SipHash widely deployed in any instruction
set, if at all, right?  And by that time we'll possibly find out that
"Oh shit, this SipHash thing has flaws!" and we'll need
DIPPY_DO_DA_HASH and thus be forced back to a software implementation
again.

I understand the reasons why these patches are being proposed, I just
thought I'd mention the issue of cpus that implement secure hash
algorithm instructions.

[PATCH] net: ibm: ibmvnic: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/ibm/ibmvnic.c |   31 ++-
 1 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index c125966..3c2526b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1025,21 +1025,26 @@ static void ibmvnic_netpoll_controller(struct 
net_device *dev)
 
 /* ethtool functions */
 
-static int ibmvnic_get_settings(struct net_device *netdev,
-   struct ethtool_cmd *cmd)
+static int ibmvnic_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
 {
-   cmd->supported = (SUPPORTED_1000baseT_Full | SUPPORTED_Autoneg |
+   u32 supported, advertising;
+
+   supported = (SUPPORTED_1000baseT_Full | SUPPORTED_Autoneg |
  SUPPORTED_FIBRE);
-   cmd->advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg |
+   advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg |
ADVERTISED_FIBRE);
-   ethtool_cmd_speed_set(cmd, SPEED_1000);
-   cmd->duplex = DUPLEX_FULL;
-   cmd->port = PORT_FIBRE;
-   cmd->phy_address = 0;
-   cmd->transceiver = XCVR_INTERNAL;
-   cmd->autoneg = AUTONEG_ENABLE;
-   cmd->maxtxpkt = 0;
-   cmd->maxrxpkt = 1;
+   cmd->base.speed = SPEED_1000;
+   cmd->base.duplex = DUPLEX_FULL;
+   cmd->base.port = PORT_FIBRE;
+   cmd->base.phy_address = 0;
+   cmd->base.autoneg = AUTONEG_ENABLE;
+
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   advertising);
+
return 0;
 }
 
@@ -1132,7 +1137,6 @@ static void ibmvnic_get_ethtool_stats(struct net_device 
*dev,
 }
 
 static const struct ethtool_ops ibmvnic_ethtool_ops = {
-   .get_settings   = ibmvnic_get_settings,
.get_drvinfo= ibmvnic_get_drvinfo,
.get_msglevel   = ibmvnic_get_msglevel,
.set_msglevel   = ibmvnic_set_msglevel,
@@ -1141,6 +1145,7 @@ static void ibmvnic_get_ethtool_stats(struct net_device 
*dev,
.get_strings= ibmvnic_get_strings,
.get_sset_count = ibmvnic_get_sset_count,
.get_ethtool_stats  = ibmvnic_get_ethtool_stats,
+   .get_link_ksettings = ibmvnic_get_link_ksettings,
 };
 
 /* Routines for managing CRQs/sCRQs  */
-- 
1.7.4.4

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

[David Miller]

From: "Jason A. Donenfeld" 
Date: Sat,  7 Jan 2017 15:40:56 +0100

> This gives a clear speed and security improvement. Siphash is both
> faster and is more solid crypto than the aging MD5.
> 
> Rather than manually filling MD5 buffers, for IPv6, we simply create
> a layout by a simple anonymous struct, for which gcc generates
> rather efficient code. For IPv4, we pass the values directly to the
> short input convenience functions.
> 
> 64-bit x86_64:
> [1.683628] secure_tcpv6_sequence_number_md5# cycles: 99563527
> [1.717350] secure_tcp_sequence_number_md5# cycles: 92890502
> [1.741968] secure_tcpv6_sequence_number_siphash# cycles: 67825362
> [1.762048] secure_tcp_sequence_number_siphash# cycles: 67485526
> 
> 32-bit x86:
> [1.600012] secure_tcpv6_sequence_number_md5# cycles: 103227892
> [1.634219] secure_tcp_sequence_number_md5# cycles: 94732544
> [1.669102] secure_tcpv6_sequence_number_siphash# cycles: 96299384
> [1.700165] secure_tcp_sequence_number_siphash# cycles: 86015473
> 
> Signed-off-by: Jason A. Donenfeld 

This and the next patch are a real shame, performance wise, on cpus
that have single-instruction SHA1 and MD5 implementations.  Sparc64
has both, and I believe x86_64 can do SHA1 these days.

It took so long to get those instructions into real silicon, and then
have software implemented to make use of them as well.

Who knows when we'll see SipHash widely deployed in any instruction
set, if at all, right?  And by that time we'll possibly find out that
"Oh shit, this SipHash thing has flaws!" and we'll need
DIPPY_DO_DA_HASH and thus be forced back to a software implementation
again.

I understand the reasons why these patches are being proposed, I just
thought I'd mention the issue of cpus that implement secure hash
algorithm instructions.