Re: [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP

[Kirti Wankhede]

On 11/9/2016 2:58 AM, Alex Williamson wrote:
> On Wed, 9 Nov 2016 01:29:19 +0530
> Kirti Wankhede  wrote:
> 
>> On 11/8/2016 11:16 PM, Alex Williamson wrote:
>>> On Tue, 8 Nov 2016 21:56:29 +0530
>>> Kirti Wankhede  wrote:
>>>   
 On 11/8/2016 5:15 AM, Alex Williamson wrote:  
> On Sat, 5 Nov 2016 02:40:45 +0530
> Kirti Wankhede  wrote:
> 
 ...  
>>  
>> +int vfio_register_notifier(struct device *dev, struct notifier_block 
>> *nb)
>
> Is the expectation here that this is a generic notifier for all
> vfio->mdev signaling?  That should probably be made clear in the mdev
> API to avoid vendor drivers assuming their notifier callback only
> occurs for unmaps, even if that's currently the case.
> 

 Ok. Adding comment about notifier callback in mdev_device which is part
 of next patch.

 ...
  
>>  mutex_lock(>lock);
>>  
>> -if (!iommu->external_domain) {
>> +/* Fail if notifier list is empty */
>> +if ((!iommu->external_domain) || (!iommu->notifier.head)) {
>>  ret = -EINVAL;
>>  goto pin_done;
>>  }
>> @@ -867,6 +870,11 @@ unlock:
>>  /* Report how much was unmapped */
>>  unmap->size = unmapped;
>>  
>> +if (unmapped && iommu->external_domain)
>> +blocking_notifier_call_chain(>notifier,
>> + 
>> VFIO_IOMMU_NOTIFY_DMA_UNMAP,
>> + unmap);
>
> This is after the fact, there's already a gap here where pages are
> unpinned and the mdev device is still running.

 Oh, there is a bug here, now unpin_pages() take user_pfn as argument and
 find vfio_dma. If its not found, it doesn't unpin pages. We have to call
 this notifier before vfio_remove_dma(). But if we call this before
 vfio_remove_dma() there will be deadlock since iommu->lock is already
 held here and vfio_iommu_type1_unpin_pages() will also try to hold
 iommu->lock.
 If we want to call blocking_notifier_call_chain() before
 vfio_remove_dma(), sequence should be:

 unmapped += dma->size;
 mutex_unlock(>lock);
 if (iommu->external_domain)) {
struct vfio_iommu_type1_dma_unmap nb_unmap;

nb_unmap.iova = dma->iova;
nb_unmap.size = dma->size;
blocking_notifier_call_chain(>notifier,
 VFIO_IOMMU_NOTIFY_DMA_UNMAP,
 _unmap);
 }
 mutex_lock(>lock);
 vfio_remove_dma(iommu, dma);  
>>>
>>> It seems like it would be worthwhile to have the rb-tree rooted in the
>>> vfio-dma, then we only need to call the notifier if there are pages
>>> pinned within that vfio-dma (ie. the rb-tree is not empty).  We can
>>> then release the lock call the notifier, re-acquire the lock, and
>>> BUG_ON if the rb-tree still is not empty.  We might get duplicate pfns
>>> between separate vfio_dma structs, but as I mentioned in other replies,
>>> that seems like an exception that we don't need to optimize for.
>>>   
>>
>> If we don't optimize for the case where iova from different vfio_dma are
>> mapped to same pfn and we would not consider this case for page
>> accounting then:
> 
> Just to clarify, the current code (not handling mdevs) will pin and do
> page accounting per iova, regardless of whether the iova translates to a
> unique pfn.  As long as we do no worse than that, I'm ok.
> 
>> - have rb tree of pinned iova, where key would be iova, in each vfio_dma
>> structure.
>> - iova tracking structure would have iova and ref_count only.
>> - page accounting would only count number of iova's in rb_tree, case
>> where different iova could map to same pfn would not be considered in
>> this implementation for now.
>> - vfio_unpin_pages() would have user_pfn and pfn as input, we would
>> validate that iova exist in rb tree and trust vendor driver that
>> corresponding pfn is correct, there is no validation of pfn. If want
>> validate pfn, call GUP, verify pfn and call put_pfn().
>> - In .release() or .detach_group() path, if there are entries in this rb
>> tree, call GUP again using that iova, get pfn and then call
>> put_pfn(pfn) for ref_count+1 times. This is because we are not keeping
>> pfn in our tracking logic.
> 
> Wait a sec, if we detach a group from the container and it's not the
> last group in the container (which would trigger a release), we can't
> assume anything about which vfio_dma entries were associated with that
> device.  The vendor driver, through the release of the device(s) within
> that group, needs to unpin.  In a container release, we need to send a
> notifier to the vendor driver(s) to cause an unpin.  This is the only
> mechanism we have to ensure that 

Re: [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP

[Kirti Wankhede]

On 11/9/2016 2:58 AM, Alex Williamson wrote:
> On Wed, 9 Nov 2016 01:29:19 +0530
> Kirti Wankhede  wrote:
> 
>> On 11/8/2016 11:16 PM, Alex Williamson wrote:
>>> On Tue, 8 Nov 2016 21:56:29 +0530
>>> Kirti Wankhede  wrote:
>>>   
 On 11/8/2016 5:15 AM, Alex Williamson wrote:  
> On Sat, 5 Nov 2016 02:40:45 +0530
> Kirti Wankhede  wrote:
> 
 ...  
>>  
>> +int vfio_register_notifier(struct device *dev, struct notifier_block 
>> *nb)
>
> Is the expectation here that this is a generic notifier for all
> vfio->mdev signaling?  That should probably be made clear in the mdev
> API to avoid vendor drivers assuming their notifier callback only
> occurs for unmaps, even if that's currently the case.
> 

 Ok. Adding comment about notifier callback in mdev_device which is part
 of next patch.

 ...
  
>>  mutex_lock(>lock);
>>  
>> -if (!iommu->external_domain) {
>> +/* Fail if notifier list is empty */
>> +if ((!iommu->external_domain) || (!iommu->notifier.head)) {
>>  ret = -EINVAL;
>>  goto pin_done;
>>  }
>> @@ -867,6 +870,11 @@ unlock:
>>  /* Report how much was unmapped */
>>  unmap->size = unmapped;
>>  
>> +if (unmapped && iommu->external_domain)
>> +blocking_notifier_call_chain(>notifier,
>> + 
>> VFIO_IOMMU_NOTIFY_DMA_UNMAP,
>> + unmap);
>
> This is after the fact, there's already a gap here where pages are
> unpinned and the mdev device is still running.

 Oh, there is a bug here, now unpin_pages() take user_pfn as argument and
 find vfio_dma. If its not found, it doesn't unpin pages. We have to call
 this notifier before vfio_remove_dma(). But if we call this before
 vfio_remove_dma() there will be deadlock since iommu->lock is already
 held here and vfio_iommu_type1_unpin_pages() will also try to hold
 iommu->lock.
 If we want to call blocking_notifier_call_chain() before
 vfio_remove_dma(), sequence should be:

 unmapped += dma->size;
 mutex_unlock(>lock);
 if (iommu->external_domain)) {
struct vfio_iommu_type1_dma_unmap nb_unmap;

nb_unmap.iova = dma->iova;
nb_unmap.size = dma->size;
blocking_notifier_call_chain(>notifier,
 VFIO_IOMMU_NOTIFY_DMA_UNMAP,
 _unmap);
 }
 mutex_lock(>lock);
 vfio_remove_dma(iommu, dma);  
>>>
>>> It seems like it would be worthwhile to have the rb-tree rooted in the
>>> vfio-dma, then we only need to call the notifier if there are pages
>>> pinned within that vfio-dma (ie. the rb-tree is not empty).  We can
>>> then release the lock call the notifier, re-acquire the lock, and
>>> BUG_ON if the rb-tree still is not empty.  We might get duplicate pfns
>>> between separate vfio_dma structs, but as I mentioned in other replies,
>>> that seems like an exception that we don't need to optimize for.
>>>   
>>
>> If we don't optimize for the case where iova from different vfio_dma are
>> mapped to same pfn and we would not consider this case for page
>> accounting then:
> 
> Just to clarify, the current code (not handling mdevs) will pin and do
> page accounting per iova, regardless of whether the iova translates to a
> unique pfn.  As long as we do no worse than that, I'm ok.
> 
>> - have rb tree of pinned iova, where key would be iova, in each vfio_dma
>> structure.
>> - iova tracking structure would have iova and ref_count only.
>> - page accounting would only count number of iova's in rb_tree, case
>> where different iova could map to same pfn would not be considered in
>> this implementation for now.
>> - vfio_unpin_pages() would have user_pfn and pfn as input, we would
>> validate that iova exist in rb tree and trust vendor driver that
>> corresponding pfn is correct, there is no validation of pfn. If want
>> validate pfn, call GUP, verify pfn and call put_pfn().
>> - In .release() or .detach_group() path, if there are entries in this rb
>> tree, call GUP again using that iova, get pfn and then call
>> put_pfn(pfn) for ref_count+1 times. This is because we are not keeping
>> pfn in our tracking logic.
> 
> Wait a sec, if we detach a group from the container and it's not the
> last group in the container (which would trigger a release), we can't
> assume anything about which vfio_dma entries were associated with that
> device.  The vendor driver, through the release of the device(s) within
> that group, needs to unpin.  In a container release, we need to send a
> notifier to the vendor driver(s) to cause an unpin.  This is the only
> mechanism we have to ensure that vendor drivers are not leaking
> references.  If during the release, 

[GIT PULL] perf fixes

[Ingo Molnar]

Linus,

Please pull the latest perf-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
perf-urgent-for-linus

   # HEAD: ce75632cc4012f1832bd56efd97c2ba75ca964bb Merge tag 
'perf-hists-hierarchy-fixes-for-mingo-2016' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

An uncore PMU driver hardware enablement change for Intel SkyLake uncore PMUs 
(Skylake Y, U, H and S platforms), plus a number of tooling fixes for the 
histogram handling/displaying code.

 Thanks,

Ingo

-->
Kan Liang (1):
  perf/x86/intel/uncore: Add more Intel uncore IMC PCI IDs for SkyLake

Namhyung Kim (5):
  perf hist browser: Fix hierarchy column counts
  perf hists browser: Fix indentation of folded sign on --hierarchy
  perf hists browser: Show folded sign properly on --hierarchy
  perf hists browser: Fix column indentation on --hierarchy
  perf hists: Fix column length on --hierarchy


 arch/x86/events/intel/uncore_snb.c | 32 +
 tools/perf/ui/browsers/hists.c | 48 +-
 tools/perf/util/hist.c | 12 +-
 3 files changed, 71 insertions(+), 21 deletions(-)

diff --git a/arch/x86/events/intel/uncore_snb.c 
b/arch/x86/events/intel/uncore_snb.c
index 5f845eef9a4d..81195cca7eae 100644
--- a/arch/x86/events/intel/uncore_snb.c
+++ b/arch/x86/events/intel/uncore_snb.c
@@ -8,8 +8,12 @@
 #define PCI_DEVICE_ID_INTEL_HSW_IMC0x0c00
 #define PCI_DEVICE_ID_INTEL_HSW_U_IMC  0x0a04
 #define PCI_DEVICE_ID_INTEL_BDW_IMC0x1604
-#define PCI_DEVICE_ID_INTEL_SKL_IMC0x191f
-#define PCI_DEVICE_ID_INTEL_SKL_U_IMC  0x190c
+#define PCI_DEVICE_ID_INTEL_SKL_U_IMC  0x1904
+#define PCI_DEVICE_ID_INTEL_SKL_Y_IMC  0x190c
+#define PCI_DEVICE_ID_INTEL_SKL_HD_IMC 0x1900
+#define PCI_DEVICE_ID_INTEL_SKL_HQ_IMC 0x1910
+#define PCI_DEVICE_ID_INTEL_SKL_SD_IMC 0x190f
+#define PCI_DEVICE_ID_INTEL_SKL_SQ_IMC 0x191f
 
 /* SNB event control */
 #define SNB_UNC_CTL_EV_SEL_MASK0x00ff
@@ -616,13 +620,29 @@ static const struct pci_device_id bdw_uncore_pci_ids[] = {
 
 static const struct pci_device_id skl_uncore_pci_ids[] = {
{ /* IMC */
-   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_IMC),
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_Y_IMC),
.driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
},
{ /* IMC */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_U_IMC),
.driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
},
+   { /* IMC */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_HD_IMC),
+   .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+   },
+   { /* IMC */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_HQ_IMC),
+   .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+   },
+   { /* IMC */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_SD_IMC),
+   .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+   },
+   { /* IMC */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_SQ_IMC),
+   .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+   },
 
{ /* end: all zeroes */ },
 };
@@ -666,8 +686,12 @@ static const struct imc_uncore_pci_dev 
desktop_imc_pci_ids[] = {
IMC_DEV(HSW_IMC, _uncore_pci_driver),/* 4th Gen Core Processor 
*/
IMC_DEV(HSW_U_IMC, _uncore_pci_driver),  /* 4th Gen Core ULT Mobile 
Processor */
IMC_DEV(BDW_IMC, _uncore_pci_driver),/* 5th Gen Core U */
-   IMC_DEV(SKL_IMC, _uncore_pci_driver),/* 6th Gen Core */
+   IMC_DEV(SKL_Y_IMC, _uncore_pci_driver),  /* 6th Gen Core Y */
IMC_DEV(SKL_U_IMC, _uncore_pci_driver),  /* 6th Gen Core U */
+   IMC_DEV(SKL_HD_IMC, _uncore_pci_driver),  /* 6th Gen Core H Dual 
Core */
+   IMC_DEV(SKL_HQ_IMC, _uncore_pci_driver),  /* 6th Gen Core H Quad 
Core */
+   IMC_DEV(SKL_SD_IMC, _uncore_pci_driver),  /* 6th Gen Core S Dual 
Core */
+   IMC_DEV(SKL_SQ_IMC, _uncore_pci_driver),  /* 6th Gen Core S Quad 
Core */
{  /* end marker */ }
 };
 
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 47be9299..a53fef0c673b 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1337,8 +1337,8 @@ static int hist_browser__show_hierarchy_entry(struct 
hist_browser *browser,
}
 
if (first) {
-   ui_browser__printf(>b, "%c", folded_sign);
-   width--;
+   ui_browser__printf(>b, "%c ", folded_sign);
+   width -= 2;
first = false;
} else {

[GIT PULL] perf fixes

[Ingo Molnar]

Linus,

Please pull the latest perf-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
perf-urgent-for-linus

   # HEAD: ce75632cc4012f1832bd56efd97c2ba75ca964bb Merge tag 
'perf-hists-hierarchy-fixes-for-mingo-2016' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

An uncore PMU driver hardware enablement change for Intel SkyLake uncore PMUs 
(Skylake Y, U, H and S platforms), plus a number of tooling fixes for the 
histogram handling/displaying code.

 Thanks,

Ingo

-->
Kan Liang (1):
  perf/x86/intel/uncore: Add more Intel uncore IMC PCI IDs for SkyLake

Namhyung Kim (5):
  perf hist browser: Fix hierarchy column counts
  perf hists browser: Fix indentation of folded sign on --hierarchy
  perf hists browser: Show folded sign properly on --hierarchy
  perf hists browser: Fix column indentation on --hierarchy
  perf hists: Fix column length on --hierarchy


 arch/x86/events/intel/uncore_snb.c | 32 +
 tools/perf/ui/browsers/hists.c | 48 +-
 tools/perf/util/hist.c | 12 +-
 3 files changed, 71 insertions(+), 21 deletions(-)

diff --git a/arch/x86/events/intel/uncore_snb.c 
b/arch/x86/events/intel/uncore_snb.c
index 5f845eef9a4d..81195cca7eae 100644
--- a/arch/x86/events/intel/uncore_snb.c
+++ b/arch/x86/events/intel/uncore_snb.c
@@ -8,8 +8,12 @@
 #define PCI_DEVICE_ID_INTEL_HSW_IMC0x0c00
 #define PCI_DEVICE_ID_INTEL_HSW_U_IMC  0x0a04
 #define PCI_DEVICE_ID_INTEL_BDW_IMC0x1604
-#define PCI_DEVICE_ID_INTEL_SKL_IMC0x191f
-#define PCI_DEVICE_ID_INTEL_SKL_U_IMC  0x190c
+#define PCI_DEVICE_ID_INTEL_SKL_U_IMC  0x1904
+#define PCI_DEVICE_ID_INTEL_SKL_Y_IMC  0x190c
+#define PCI_DEVICE_ID_INTEL_SKL_HD_IMC 0x1900
+#define PCI_DEVICE_ID_INTEL_SKL_HQ_IMC 0x1910
+#define PCI_DEVICE_ID_INTEL_SKL_SD_IMC 0x190f
+#define PCI_DEVICE_ID_INTEL_SKL_SQ_IMC 0x191f
 
 /* SNB event control */
 #define SNB_UNC_CTL_EV_SEL_MASK0x00ff
@@ -616,13 +620,29 @@ static const struct pci_device_id bdw_uncore_pci_ids[] = {
 
 static const struct pci_device_id skl_uncore_pci_ids[] = {
{ /* IMC */
-   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_IMC),
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_Y_IMC),
.driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
},
{ /* IMC */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_U_IMC),
.driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
},
+   { /* IMC */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_HD_IMC),
+   .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+   },
+   { /* IMC */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_HQ_IMC),
+   .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+   },
+   { /* IMC */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_SD_IMC),
+   .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+   },
+   { /* IMC */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_SQ_IMC),
+   .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+   },
 
{ /* end: all zeroes */ },
 };
@@ -666,8 +686,12 @@ static const struct imc_uncore_pci_dev 
desktop_imc_pci_ids[] = {
IMC_DEV(HSW_IMC, _uncore_pci_driver),/* 4th Gen Core Processor 
*/
IMC_DEV(HSW_U_IMC, _uncore_pci_driver),  /* 4th Gen Core ULT Mobile 
Processor */
IMC_DEV(BDW_IMC, _uncore_pci_driver),/* 5th Gen Core U */
-   IMC_DEV(SKL_IMC, _uncore_pci_driver),/* 6th Gen Core */
+   IMC_DEV(SKL_Y_IMC, _uncore_pci_driver),  /* 6th Gen Core Y */
IMC_DEV(SKL_U_IMC, _uncore_pci_driver),  /* 6th Gen Core U */
+   IMC_DEV(SKL_HD_IMC, _uncore_pci_driver),  /* 6th Gen Core H Dual 
Core */
+   IMC_DEV(SKL_HQ_IMC, _uncore_pci_driver),  /* 6th Gen Core H Quad 
Core */
+   IMC_DEV(SKL_SD_IMC, _uncore_pci_driver),  /* 6th Gen Core S Dual 
Core */
+   IMC_DEV(SKL_SQ_IMC, _uncore_pci_driver),  /* 6th Gen Core S Quad 
Core */
{  /* end marker */ }
 };
 
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 47be9299..a53fef0c673b 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1337,8 +1337,8 @@ static int hist_browser__show_hierarchy_entry(struct 
hist_browser *browser,
}
 
if (first) {
-   ui_browser__printf(>b, "%c", folded_sign);
-   width--;
+   ui_browser__printf(>b, "%c ", folded_sign);
+   width -= 2;
first = false;
} else {

Re: [PATCH 4.8 00/35] 4.8.8-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 10:18:51AM -0800, kernelci.org bot wrote:
> stable-rc boot: 146 boots: 0 failed, 144 passed with 2 offline 
> (v4.8.7-36-g06d2f2c881c0)

Nice!  Thanks for testing.

greg k-h

Re: [PATCH 4.8 00/35] 4.8.8-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 10:18:51AM -0800, kernelci.org bot wrote:
> stable-rc boot: 146 boots: 0 failed, 144 passed with 2 offline 
> (v4.8.7-36-g06d2f2c881c0)

Nice!  Thanks for testing.

greg k-h

Re: [PATCH 4.4 00/34] 4.4.32-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 12:58:52PM -0800, kernelci.org bot wrote:
> stable-rc boot: 139 boots: 1 failed, 136 passed with 2 offline 
> (v4.4.31-35-g02bf66f6a361)
> 
> Full Boot Summary: 
> https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.31-35-g02bf66f6a361/
> Full Build Summary: 
> https://kernelci.org/build/stable-rc/kernel/v4.4.31-35-g02bf66f6a361/
> 
> Tree: stable-rc
> Branch: local/linux-4.4.y
> Git Describe: v4.4.31-35-g02bf66f6a361
> Git Commit: 02bf66f6a36157b5a3b1040981a718b8e7e1662f
> Git URL: 
> http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 36 unique boards, 12 SoC families, 16 builds out of 202
> 
> Boot Failure Detected: 
> https://kernelci.org/boot/?v4.4.31-35-g02bf66f6a361
> 
> arm:
> 
> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> at91-sama5d3_xplained: 1 failed lab

Well, at least it isn't 2 machines failing for this option :)

thanks,

greg k-h

PLEASE VIEW THE ATTACHED FILE AND CONTACT ME.

[Dr. Felix Collins]

FROM FIRST NATIONAL BANK OF SOUTH AFRICA (F.N.B)..rtf
Description: MS-Word document

Re: [PATCH 4.4 00/34] 4.4.32-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 12:58:52PM -0800, kernelci.org bot wrote:
> stable-rc boot: 139 boots: 1 failed, 136 passed with 2 offline 
> (v4.4.31-35-g02bf66f6a361)
> 
> Full Boot Summary: 
> https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.31-35-g02bf66f6a361/
> Full Build Summary: 
> https://kernelci.org/build/stable-rc/kernel/v4.4.31-35-g02bf66f6a361/
> 
> Tree: stable-rc
> Branch: local/linux-4.4.y
> Git Describe: v4.4.31-35-g02bf66f6a361
> Git Commit: 02bf66f6a36157b5a3b1040981a718b8e7e1662f
> Git URL: 
> http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 36 unique boards, 12 SoC families, 16 builds out of 202
> 
> Boot Failure Detected: 
> https://kernelci.org/boot/?v4.4.31-35-g02bf66f6a361
> 
> arm:
> 
> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> at91-sama5d3_xplained: 1 failed lab

Well, at least it isn't 2 machines failing for this option :)

thanks,

greg k-h

PLEASE VIEW THE ATTACHED FILE AND CONTACT ME.

[Dr. Felix Collins]

FROM FIRST NATIONAL BANK OF SOUTH AFRICA (F.N.B)..rtf
Description: MS-Word document

[GIT PULL] EFI fixes

[Ingo Molnar]

Linus,

Please pull the latest efi-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
efi-urgent-for-linus

   # HEAD: f6697df36bdf0bf7fce984605c2918d4a7b4269f x86/efi: Prevent mixed mode 
boot corruption with CONFIG_VMAP_STACK=y

A boot crash fix and a build warning fix.

 Thanks,

Ingo

-->
Borislav Petkov (1):
  x86/efi: Fix EFI memmap pointer size warning

Matt Fleming (1):
  x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y


 arch/x86/platform/efi/efi.c|  2 +-
 arch/x86/platform/efi/efi_64.c | 80 ++
 2 files changed, 58 insertions(+), 24 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index bf99aa7005eb..936a488d6cf6 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -861,7 +861,7 @@ static void __init __efi_enter_virtual_mode(void)
int count = 0, pg_shift = 0;
void *new_memmap = NULL;
efi_status_t status;
-   phys_addr_t pa;
+   unsigned long pa;
 
efi.systab = NULL;
 
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 58b0f801f66f..319148bd4b05 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -211,6 +212,35 @@ void efi_sync_low_kernel_mappings(void)
memcpy(pud_efi, pud_k, sizeof(pud_t) * num_entries);
 }
 
+/*
+ * Wrapper for slow_virt_to_phys() that handles NULL addresses.
+ */
+static inline phys_addr_t
+virt_to_phys_or_null_size(void *va, unsigned long size)
+{
+   bool bad_size;
+
+   if (!va)
+   return 0;
+
+   if (virt_addr_valid(va))
+   return virt_to_phys(va);
+
+   /*
+* A fully aligned variable on the stack is guaranteed not to
+* cross a page bounary. Try to catch strings on the stack by
+* checking that 'size' is a power of two.
+*/
+   bad_size = size > PAGE_SIZE || !is_power_of_2(size);
+
+   WARN_ON(!IS_ALIGNED((unsigned long)va, size) || bad_size);
+
+   return slow_virt_to_phys(va);
+}
+
+#define virt_to_phys_or_null(addr) \
+   virt_to_phys_or_null_size((addr), sizeof(*(addr)))
+
 int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
 {
unsigned long pfn, text;
@@ -494,8 +524,8 @@ static efi_status_t efi_thunk_get_time(efi_time_t *tm, 
efi_time_cap_t *tc)
 
spin_lock(_lock);
 
-   phys_tm = virt_to_phys(tm);
-   phys_tc = virt_to_phys(tc);
+   phys_tm = virt_to_phys_or_null(tm);
+   phys_tc = virt_to_phys_or_null(tc);
 
status = efi_thunk(get_time, phys_tm, phys_tc);
 
@@ -511,7 +541,7 @@ static efi_status_t efi_thunk_set_time(efi_time_t *tm)
 
spin_lock(_lock);
 
-   phys_tm = virt_to_phys(tm);
+   phys_tm = virt_to_phys_or_null(tm);
 
status = efi_thunk(set_time, phys_tm);
 
@@ -529,9 +559,9 @@ efi_thunk_get_wakeup_time(efi_bool_t *enabled, efi_bool_t 
*pending,
 
spin_lock(_lock);
 
-   phys_enabled = virt_to_phys(enabled);
-   phys_pending = virt_to_phys(pending);
-   phys_tm = virt_to_phys(tm);
+   phys_enabled = virt_to_phys_or_null(enabled);
+   phys_pending = virt_to_phys_or_null(pending);
+   phys_tm = virt_to_phys_or_null(tm);
 
status = efi_thunk(get_wakeup_time, phys_enabled,
 phys_pending, phys_tm);
@@ -549,7 +579,7 @@ efi_thunk_set_wakeup_time(efi_bool_t enabled, efi_time_t 
*tm)
 
spin_lock(_lock);
 
-   phys_tm = virt_to_phys(tm);
+   phys_tm = virt_to_phys_or_null(tm);
 
status = efi_thunk(set_wakeup_time, enabled, phys_tm);
 
@@ -558,6 +588,10 @@ efi_thunk_set_wakeup_time(efi_bool_t enabled, efi_time_t 
*tm)
return status;
 }
 
+static unsigned long efi_name_size(efi_char16_t *name)
+{
+   return ucs2_strsize(name, EFI_VAR_NAME_LEN) + 1;
+}
 
 static efi_status_t
 efi_thunk_get_variable(efi_char16_t *name, efi_guid_t *vendor,
@@ -567,11 +601,11 @@ efi_thunk_get_variable(efi_char16_t *name, efi_guid_t 
*vendor,
u32 phys_name, phys_vendor, phys_attr;
u32 phys_data_size, phys_data;
 
-   phys_data_size = virt_to_phys(data_size);
-   phys_vendor = virt_to_phys(vendor);
-   phys_name = virt_to_phys(name);
-   phys_attr = virt_to_phys(attr);
-   phys_data = virt_to_phys(data);
+   phys_data_size = virt_to_phys_or_null(data_size);
+   phys_vendor = virt_to_phys_or_null(vendor);
+   phys_name = virt_to_phys_or_null_size(name, efi_name_size(name));
+   phys_attr = virt_to_phys_or_null(attr);
+   phys_data = virt_to_phys_or_null_size(data, *data_size);
 
status = efi_thunk(get_variable, phys_name, phys_vendor,
   phys_attr, phys_data_size, phys_data);
@@ -586,9 +620,9 @@ 

[GIT PULL] EFI fixes

[Ingo Molnar]

Linus,

Please pull the latest efi-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
efi-urgent-for-linus

   # HEAD: f6697df36bdf0bf7fce984605c2918d4a7b4269f x86/efi: Prevent mixed mode 
boot corruption with CONFIG_VMAP_STACK=y

A boot crash fix and a build warning fix.

 Thanks,

Ingo

-->
Borislav Petkov (1):
  x86/efi: Fix EFI memmap pointer size warning

Matt Fleming (1):
  x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y


 arch/x86/platform/efi/efi.c|  2 +-
 arch/x86/platform/efi/efi_64.c | 80 ++
 2 files changed, 58 insertions(+), 24 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index bf99aa7005eb..936a488d6cf6 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -861,7 +861,7 @@ static void __init __efi_enter_virtual_mode(void)
int count = 0, pg_shift = 0;
void *new_memmap = NULL;
efi_status_t status;
-   phys_addr_t pa;
+   unsigned long pa;
 
efi.systab = NULL;
 
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 58b0f801f66f..319148bd4b05 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -211,6 +212,35 @@ void efi_sync_low_kernel_mappings(void)
memcpy(pud_efi, pud_k, sizeof(pud_t) * num_entries);
 }
 
+/*
+ * Wrapper for slow_virt_to_phys() that handles NULL addresses.
+ */
+static inline phys_addr_t
+virt_to_phys_or_null_size(void *va, unsigned long size)
+{
+   bool bad_size;
+
+   if (!va)
+   return 0;
+
+   if (virt_addr_valid(va))
+   return virt_to_phys(va);
+
+   /*
+* A fully aligned variable on the stack is guaranteed not to
+* cross a page bounary. Try to catch strings on the stack by
+* checking that 'size' is a power of two.
+*/
+   bad_size = size > PAGE_SIZE || !is_power_of_2(size);
+
+   WARN_ON(!IS_ALIGNED((unsigned long)va, size) || bad_size);
+
+   return slow_virt_to_phys(va);
+}
+
+#define virt_to_phys_or_null(addr) \
+   virt_to_phys_or_null_size((addr), sizeof(*(addr)))
+
 int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
 {
unsigned long pfn, text;
@@ -494,8 +524,8 @@ static efi_status_t efi_thunk_get_time(efi_time_t *tm, 
efi_time_cap_t *tc)
 
spin_lock(_lock);
 
-   phys_tm = virt_to_phys(tm);
-   phys_tc = virt_to_phys(tc);
+   phys_tm = virt_to_phys_or_null(tm);
+   phys_tc = virt_to_phys_or_null(tc);
 
status = efi_thunk(get_time, phys_tm, phys_tc);
 
@@ -511,7 +541,7 @@ static efi_status_t efi_thunk_set_time(efi_time_t *tm)
 
spin_lock(_lock);
 
-   phys_tm = virt_to_phys(tm);
+   phys_tm = virt_to_phys_or_null(tm);
 
status = efi_thunk(set_time, phys_tm);
 
@@ -529,9 +559,9 @@ efi_thunk_get_wakeup_time(efi_bool_t *enabled, efi_bool_t 
*pending,
 
spin_lock(_lock);
 
-   phys_enabled = virt_to_phys(enabled);
-   phys_pending = virt_to_phys(pending);
-   phys_tm = virt_to_phys(tm);
+   phys_enabled = virt_to_phys_or_null(enabled);
+   phys_pending = virt_to_phys_or_null(pending);
+   phys_tm = virt_to_phys_or_null(tm);
 
status = efi_thunk(get_wakeup_time, phys_enabled,
 phys_pending, phys_tm);
@@ -549,7 +579,7 @@ efi_thunk_set_wakeup_time(efi_bool_t enabled, efi_time_t 
*tm)
 
spin_lock(_lock);
 
-   phys_tm = virt_to_phys(tm);
+   phys_tm = virt_to_phys_or_null(tm);
 
status = efi_thunk(set_wakeup_time, enabled, phys_tm);
 
@@ -558,6 +588,10 @@ efi_thunk_set_wakeup_time(efi_bool_t enabled, efi_time_t 
*tm)
return status;
 }
 
+static unsigned long efi_name_size(efi_char16_t *name)
+{
+   return ucs2_strsize(name, EFI_VAR_NAME_LEN) + 1;
+}
 
 static efi_status_t
 efi_thunk_get_variable(efi_char16_t *name, efi_guid_t *vendor,
@@ -567,11 +601,11 @@ efi_thunk_get_variable(efi_char16_t *name, efi_guid_t 
*vendor,
u32 phys_name, phys_vendor, phys_attr;
u32 phys_data_size, phys_data;
 
-   phys_data_size = virt_to_phys(data_size);
-   phys_vendor = virt_to_phys(vendor);
-   phys_name = virt_to_phys(name);
-   phys_attr = virt_to_phys(attr);
-   phys_data = virt_to_phys(data);
+   phys_data_size = virt_to_phys_or_null(data_size);
+   phys_vendor = virt_to_phys_or_null(vendor);
+   phys_name = virt_to_phys_or_null_size(name, efi_name_size(name));
+   phys_attr = virt_to_phys_or_null(attr);
+   phys_data = virt_to_phys_or_null_size(data, *data_size);
 
status = efi_thunk(get_variable, phys_name, phys_vendor,
   phys_attr, phys_data_size, phys_data);
@@ -586,9 +620,9 @@ 

Re: [PATCH 4.4 00/34] 4.4.32-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 04:34:46PM +0100, Philip Müller wrote:
> Hi Greg,
> 
> with inclusion of 'Fix data integrity failure for JBOD (passthrough)
> devices' in v4.4.31, we currently have a regression with SCSI and macro
> MEGASAS_IS_LOGICAL.
> 
> To fix it, commit 5e5ec17[1] is needed or that patch JBOD patch[2]
> reverted until it is merged in mainline.

Ah crap, I didn't mean for that to get into 4.4-stable, sorry, I only
removed it from the 4.8-stable queue for some foolish reason...

I'll go fix this up now...

greg k-h

Re: [PATCH 4.4 00/34] 4.4.32-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 04:34:46PM +0100, Philip Müller wrote:
> Hi Greg,
> 
> with inclusion of 'Fix data integrity failure for JBOD (passthrough)
> devices' in v4.4.31, we currently have a regression with SCSI and macro
> MEGASAS_IS_LOGICAL.
> 
> To fix it, commit 5e5ec17[1] is needed or that patch JBOD patch[2]
> reverted until it is merged in mainline.

Ah crap, I didn't mean for that to get into 4.4-stable, sorry, I only
removed it from the 4.8-stable queue for some foolish reason...

I'll go fix this up now...

greg k-h

Re: [PATCH v9 00/10] MT2701 DRM support

[Bibby Hsieh]

Hi, YT

On Fri, 2016-11-11 at 19:55 +0800, YT Shen wrote:
> This is MT2701 DRM support PATCH v9, based on 4.9-rc1.
> We add DSI interrupt control, transfer function for MIPI DSI panel support.
> Most codes are the same, except some register changed.
> 
> For example:
>  - DISP_OVL address offset changed, color format definition changed.
>  - DISP_RDMA fifo size changed.
>  - DISP_COLOR offset changed.
>  - MIPI_TX setting changed.
> 
> We add a new component DDP_COMPONENT_BLS, and the connections are updated.
> OVL -> RDMA -> COLOR -> BLS -> DSI
> RDMA -> DPI
> And we have shadow register support in MT2701.
> 
> We remove dts patch from the patch series, which depends on MT2701 CCF and 
> scpsys.
> 

I test this series on MT8173 platform, it looks pretty good to me,
thanks for your patches.

Tested-by: Bibby Hsieh 

> Changes since v8:
> - enable 3 DSI interrupts only
> - move mtk_dsi_wait_for_irq_done() to the patch of irq control
> - use the name BLS in DRM driver part
> - move BLS declaration to a separate patch
> - update mtk_dsi_switch_to_cmd_mode()
> - update mtk_output_dsi_enable() and mtk_output_dsi_disable()
> 
> Changes since v7:
> - Remove redundant codes
> - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update 
> display module connections"
> - Move _dsi_irq_wait_queue into platform driver data
> - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt 
> control"
> - Add more descriptions in the commit messages
> 
> Changes since v6:
> - Change data type of irq_data to u32
> - Rewrite mtk_dsi_host_transfer() for simplify
> - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for 
> different hardware settings".
> - Remove device tree from this patch series
> 
> Changes since v5:
> - Remove DPI device tree and compatible string
> - Use one wait queue to handle interrupt status
> - Update the interrupt check flow and DSI_INT_ALL_BITS
> - Use same function for host read/write command
> - various fixes
> 
> Changes since v4:
> - Add messages when timeout in mtk_disp_mutex_acquire()
> - Add descriptions for DISP_REG_MUTEX registers
> - Move connection settings for display modules to a separate patch
> - Remove 'mt2701-disp-wdma' because it is unused
> - Move cleaning up and renaming to a separate patch
> - Use wait_event_interruptible_timeout() to replace polling
> - Remove irq_num from mtk_dsi structure
> - Remove redundant and debug codes
> 
> Changes since v3:
> - Add DSI support for MIPI DSI panels
> - Update BLS binding to PWM nodes
> - Remove ufoe device nodes
> - Remove redundant parentheses
> - Remove global variable initialization
> 
> Changes since v2:
> - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel
> - Update mt2701_mtk_ddp_ext components
> - Changed to prefix naming
> - Reorder the patch series
> - Use of_device_get_match_data() to get driver private data
> - Use iopoll macros to implement mtk_disp_mutex_acquire()
> - Removed empty device tree nodes
> 
> Changes since v1:
> - Removed BLS bindings and codes, which belong to pwm driver
> - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config()
> - Split patch into smaller parts
> - Added const keyword to constant structure
> - Removed codes for special memory align
> 
> Thanks,
> yt.shen
> 
> YT Shen (8):
>   drm/mediatek: rename macros, add chip prefix
>   drm/mediatek: add *driver_data for different hardware settings
>   drm/mediatek: add shadow register support
>   drm/mediatek: add BLS component
>   drm/mediatek: update display module connections
>   drm/mediatek: cleaning up and refine
>   drm/mediatek: update DSI sub driver flow for sending commands to panel
>   drm/mediatek: add support for Mediatek SoC MT2701
> 
> shaoming chen (2):
>   drm/mediatek: add dsi interrupt control
>   drm/mediatek: add dsi transfer function
> 
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  33 ++-
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  17 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  76 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 138 ++---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |   2 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  38 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  15 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  54 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   9 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  | 429 
> 
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |  70 +++--
>  11 files changed, 715 insertions(+), 166 deletions(-)
> 

-- 
Bibby

Re: [PATCH v9 00/10] MT2701 DRM support

[Bibby Hsieh]

Hi, YT

On Fri, 2016-11-11 at 19:55 +0800, YT Shen wrote:
> This is MT2701 DRM support PATCH v9, based on 4.9-rc1.
> We add DSI interrupt control, transfer function for MIPI DSI panel support.
> Most codes are the same, except some register changed.
> 
> For example:
>  - DISP_OVL address offset changed, color format definition changed.
>  - DISP_RDMA fifo size changed.
>  - DISP_COLOR offset changed.
>  - MIPI_TX setting changed.
> 
> We add a new component DDP_COMPONENT_BLS, and the connections are updated.
> OVL -> RDMA -> COLOR -> BLS -> DSI
> RDMA -> DPI
> And we have shadow register support in MT2701.
> 
> We remove dts patch from the patch series, which depends on MT2701 CCF and 
> scpsys.
> 

I test this series on MT8173 platform, it looks pretty good to me,
thanks for your patches.

Tested-by: Bibby Hsieh 

> Changes since v8:
> - enable 3 DSI interrupts only
> - move mtk_dsi_wait_for_irq_done() to the patch of irq control
> - use the name BLS in DRM driver part
> - move BLS declaration to a separate patch
> - update mtk_dsi_switch_to_cmd_mode()
> - update mtk_output_dsi_enable() and mtk_output_dsi_disable()
> 
> Changes since v7:
> - Remove redundant codes
> - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update 
> display module connections"
> - Move _dsi_irq_wait_queue into platform driver data
> - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt 
> control"
> - Add more descriptions in the commit messages
> 
> Changes since v6:
> - Change data type of irq_data to u32
> - Rewrite mtk_dsi_host_transfer() for simplify
> - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for 
> different hardware settings".
> - Remove device tree from this patch series
> 
> Changes since v5:
> - Remove DPI device tree and compatible string
> - Use one wait queue to handle interrupt status
> - Update the interrupt check flow and DSI_INT_ALL_BITS
> - Use same function for host read/write command
> - various fixes
> 
> Changes since v4:
> - Add messages when timeout in mtk_disp_mutex_acquire()
> - Add descriptions for DISP_REG_MUTEX registers
> - Move connection settings for display modules to a separate patch
> - Remove 'mt2701-disp-wdma' because it is unused
> - Move cleaning up and renaming to a separate patch
> - Use wait_event_interruptible_timeout() to replace polling
> - Remove irq_num from mtk_dsi structure
> - Remove redundant and debug codes
> 
> Changes since v3:
> - Add DSI support for MIPI DSI panels
> - Update BLS binding to PWM nodes
> - Remove ufoe device nodes
> - Remove redundant parentheses
> - Remove global variable initialization
> 
> Changes since v2:
> - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel
> - Update mt2701_mtk_ddp_ext components
> - Changed to prefix naming
> - Reorder the patch series
> - Use of_device_get_match_data() to get driver private data
> - Use iopoll macros to implement mtk_disp_mutex_acquire()
> - Removed empty device tree nodes
> 
> Changes since v1:
> - Removed BLS bindings and codes, which belong to pwm driver
> - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config()
> - Split patch into smaller parts
> - Added const keyword to constant structure
> - Removed codes for special memory align
> 
> Thanks,
> yt.shen
> 
> YT Shen (8):
>   drm/mediatek: rename macros, add chip prefix
>   drm/mediatek: add *driver_data for different hardware settings
>   drm/mediatek: add shadow register support
>   drm/mediatek: add BLS component
>   drm/mediatek: update display module connections
>   drm/mediatek: cleaning up and refine
>   drm/mediatek: update DSI sub driver flow for sending commands to panel
>   drm/mediatek: add support for Mediatek SoC MT2701
> 
> shaoming chen (2):
>   drm/mediatek: add dsi interrupt control
>   drm/mediatek: add dsi transfer function
> 
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  33 ++-
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  17 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  76 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 138 ++---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |   2 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  38 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  15 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  54 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   9 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  | 429 
> 
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |  70 +++--
>  11 files changed, 715 insertions(+), 166 deletions(-)
> 

-- 
Bibby

Re: [PATHCv10 0/2] USB Type-C Connector class

[Greg KH]

On Fri, Nov 11, 2016 at 01:04:24PM +0200, Heikki Krogerus wrote:
> On Thu, Nov 10, 2016 at 01:36:09PM -0800, Guenter Roeck wrote:
> > On Mon, Sep 19, 2016 at 02:16:55PM +0300, Heikki Krogerus wrote:
> > > The USB Type-C class is meant to provide unified interface to the
> > > userspace to present the USB Type-C ports in a system.
> > > 
> > Any idea what is happening with this patch series ?
> > 
> > There was no further feedback (at least as far as I know), the series
> > seems to be ready to go, yet I don't see it in -next.
> 
> I think Greg has only started to put together his usb-next branch for
> this cycle.

I was waiting to see if anyone else had objections about this before
reviewing it myself :)

I'll get to it later today...

thanks,

greg k-h

Re: [PATHCv10 0/2] USB Type-C Connector class

[Greg KH]

On Fri, Nov 11, 2016 at 01:04:24PM +0200, Heikki Krogerus wrote:
> On Thu, Nov 10, 2016 at 01:36:09PM -0800, Guenter Roeck wrote:
> > On Mon, Sep 19, 2016 at 02:16:55PM +0300, Heikki Krogerus wrote:
> > > The USB Type-C class is meant to provide unified interface to the
> > > userspace to present the USB Type-C ports in a system.
> > > 
> > Any idea what is happening with this patch series ?
> > 
> > There was no further feedback (at least as far as I know), the series
> > seems to be ready to go, yet I don't see it in -next.
> 
> I think Greg has only started to put together his usb-next branch for
> this cycle.

I was waiting to see if anyone else had objections about this before
reviewing it myself :)

I'll get to it later today...

thanks,

greg k-h

Re: [PATCH 4.8 00/35] 4.8.8-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 12:41:54PM -0800, Guenter Roeck wrote:
> On 11/13/2016 03:27 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.8.8 release.
> > There are 35 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Tue Nov 15 11:24:10 UTC 2016.
> > Anything received after that time might be too late.
> > 
> 
> 
> Build results:
>   total: 149 pass: 149 fail: 0
> Qemu test results:
>   total: 114 pass: 114 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing both trees and letting me know.

greg k-h

Re: [PATCH 4.4 00/34] 4.4.32-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 08:45:39PM +0200, Thomas Backlund wrote:
> Den 13.11.2016 kl. 17:34, skrev Philip Müller:
> > Hi Greg,
> > 
> > with inclusion of 'Fix data integrity failure for JBOD (passthrough)
> > devices' in v4.4.31, we currently have a regression with SCSI and macro
> > MEGASAS_IS_LOGICAL.
> > 
> > To fix it, commit 5e5ec17[1] is needed or that patch JBOD patch[2]
> > reverted until it is merged in mainline.
> > 
> > The other patches seem fine.
> > 
> > kind regards, Philip Müller - Manjaro Project Lead
> > 
> > ---
> > 
> > [1]
> > http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8
> > [2]
> > https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/releases/4.4.31/scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-devices.patch
> > 
> 
> 
> The needed fix is now upstream as:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8

Now applied, thanks.

greg k-h

Re: [PATCH 4.8 00/35] 4.8.8-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 12:41:54PM -0800, Guenter Roeck wrote:
> On 11/13/2016 03:27 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.8.8 release.
> > There are 35 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Tue Nov 15 11:24:10 UTC 2016.
> > Anything received after that time might be too late.
> > 
> 
> 
> Build results:
>   total: 149 pass: 149 fail: 0
> Qemu test results:
>   total: 114 pass: 114 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing both trees and letting me know.

greg k-h

Re: [PATCH 4.4 00/34] 4.4.32-stable review

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 08:45:39PM +0200, Thomas Backlund wrote:
> Den 13.11.2016 kl. 17:34, skrev Philip Müller:
> > Hi Greg,
> > 
> > with inclusion of 'Fix data integrity failure for JBOD (passthrough)
> > devices' in v4.4.31, we currently have a regression with SCSI and macro
> > MEGASAS_IS_LOGICAL.
> > 
> > To fix it, commit 5e5ec17[1] is needed or that patch JBOD patch[2]
> > reverted until it is merged in mainline.
> > 
> > The other patches seem fine.
> > 
> > kind regards, Philip Müller - Manjaro Project Lead
> > 
> > ---
> > 
> > [1]
> > http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8
> > [2]
> > https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/releases/4.4.31/scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-devices.patch
> > 
> 
> 
> The needed fix is now upstream as:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8

Now applied, thanks.

greg k-h

Re: [PATCH net] net: stmmac: Fix lack of link transition for fixed PHYs

[Giuseppe CAVALLARO]

On 11/14/2016 2:50 AM, Florian Fainelli wrote:

Commit 52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch
is attached") added some logic to avoid polling the fixed PHY and
therefore invoking the adjust_link callback more than once, since this
is a fixed PHY and link events won't be generated.

This works fine the first time, because we start with phydev->irq =
PHY_POLL, so we call adjust_link, then we set phydev->irq =
PHY_IGNORE_INTERRUPT and we stop polling the PHY.

Now, if we called ndo_close(), which calls both phy_stop() and does an
explicit netif_carrier_off(), we end up with a link down. Upon calling
ndo_open() again, despite starting the PHY state machine, we have
PHY_IGNORE_INTERRUPT set, and we generate no link event at all, so the
link is permanently down.

52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch is attached")
Signed-off-by: Florian Fainelli 
---
Alexandre, Peppe,

The original patch is already a hack, but since this is a bugfix, I took the
same approach that you did here to backport this to -stable kernels.



Acked-by: Giuseppe Cavallaro 



 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 10909c9c0033..03dbf8e89c4c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -882,6 +882,13 @@ static int stmmac_init_phy(struct net_device *dev)
return -ENODEV;
}

+   /* stmmac_adjust_link will change this to PHY_IGNORE_INTERRUPT to avoid
+* subsequent PHY polling, make sure we force a link transition if
+* we have a UP/DOWN/UP transition
+*/
+   if (phydev->is_pseudo_fixed_link)
+   phydev->irq = PHY_POLL;
+
pr_debug("stmmac_init_phy:  %s: attached to PHY (UID 0x%x)"
 " Link = %d\n", dev->name, phydev->phy_id, phydev->link);

Re: [PATCH net] net: stmmac: Fix lack of link transition for fixed PHYs

[Giuseppe CAVALLARO]

On 11/14/2016 2:50 AM, Florian Fainelli wrote:

Commit 52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch
is attached") added some logic to avoid polling the fixed PHY and
therefore invoking the adjust_link callback more than once, since this
is a fixed PHY and link events won't be generated.

This works fine the first time, because we start with phydev->irq =
PHY_POLL, so we call adjust_link, then we set phydev->irq =
PHY_IGNORE_INTERRUPT and we stop polling the PHY.

Now, if we called ndo_close(), which calls both phy_stop() and does an
explicit netif_carrier_off(), we end up with a link down. Upon calling
ndo_open() again, despite starting the PHY state machine, we have
PHY_IGNORE_INTERRUPT set, and we generate no link event at all, so the
link is permanently down.

52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch is attached")
Signed-off-by: Florian Fainelli 
---
Alexandre, Peppe,

The original patch is already a hack, but since this is a bugfix, I took the
same approach that you did here to backport this to -stable kernels.



Acked-by: Giuseppe Cavallaro 



 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 10909c9c0033..03dbf8e89c4c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -882,6 +882,13 @@ static int stmmac_init_phy(struct net_device *dev)
return -ENODEV;
}

+   /* stmmac_adjust_link will change this to PHY_IGNORE_INTERRUPT to avoid
+* subsequent PHY polling, make sure we force a link transition if
+* we have a UP/DOWN/UP transition
+*/
+   if (phydev->is_pseudo_fixed_link)
+   phydev->irq = PHY_POLL;
+
pr_debug("stmmac_init_phy:  %s: attached to PHY (UID 0x%x)"
 " Link = %d\n", dev->name, phydev->phy_id, phydev->link);

linux-next: Tree for Nov 14

[Stephen Rothwell]

Hi all,

Changes since 2016:

The sound tree gained conflicts against the jc_docs tree.

The sound-asoc tree gained a build failure, so I used the version from
next-2016.

The driver-core tree gained a conflict against the pm tree.

The rpmsg tree gained a conflict against the slave-dma tree.

The akpm-current tree gained a conflict against the tip tree.

Non-merge commits (relative to Linus' tree): 5170
 5512 files changed, 336261 insertions(+), 113086 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 246 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (a25f0944ba9b Linux 4.9-rc5)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (cc6acc11cad1 kbuild: be more careful about 
matching preprocessed asm ___EXPORT_SYMBOL)
Merging arc-current/for-curr (0a0a047def15 ARCv2: MCIP: Use IDU_M_DISTRI_DEST 
mode if there is only 1 destination core)
Merging arm-current/fixes (6127d124ee4e ARM: wire up new pkey syscalls)
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (2ffd04dee0da powerpc/oops: Fix missing pr_cont()s 
in instruction dump)
Merging sparc/master (07b5ab3f71d3 sparc32: Fix inverted invalid_frame_pointer 
checks on sigreturns)
Merging net/master (7774d46b2037 net: ethernet: ixp4xx_eth: fix spelling 
mistake in debug message)
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (9b6c14d51bd2 net: tcp response should set oif only if 
it is L3 master)
Merging ipvs/master (b73b8a1ba598 netfilter: nft_dup: do not use sreg_dev if 
the user doesn't specify it)
Merging wireless-drivers/master (d3532ea6ce4e brcmfmac: avoid 
maybe-uninitialized warning in brcmf_cfg80211_start_ap)
Merging mac80211/master (269ebce4531b xen-netfront: cast grant table reference 
first to type int)
Merging sound-current/for-linus (2ecb704a1290 ALSA: hda - add a new condition 
to check if it is thinkpad)
Merging pci-current/for-linus (bc79c9851a76 PCI: VMD: Update filename to 
reflect move)
Merging driver-core.current/driver-core-linus (bdacd1b426db driver core: fix 
smatch warning on dev->bus check)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (18266403f3fe USB: cdc-acm: fix TIOCMIWAIT)
Merging usb-gadget-fixes/fixes (fd9afd3cbe40 usb: gadget: u_ether: remove 
interrupt throttling)
Merging usb-serial-fixes/usb-linus (9bfef729a3d1 USB: serial: ftdi_sio: add 
support for TI CC3200 LaunchPad)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (d70674eeaa5e iio: maxim_thermocouple: 
detect invalid storage size in read())
Merging char-misc.current/char-misc-linus (b13d14339baa ppdev: fix double-free 
of pp->pdev->name)
Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup 
Focaltech code)
Merging crypto-current/master (83d2c9a9c17b crypto: caam - do not register 
AES-XTS mode on LP units)
Merging ide/master 

RE: [PATCH net 2/2] r8152: rx descriptor check

[Hayes Wang]

Mark Lord [mailto:ml...@pobox.com]
> Sent: Monday, November 14, 2016 4:34 AM
[...]
> Perhaps the driver
> is somehow accessing the buffer space again after doing usb_submit_urb()?
> That would certainly produce this kind of behaviour.

I don't think so. First, the driver only read the received buffer.
That is, the driver would not change (or write) the data. Second,
The driver would lose the point address of the received buffer
after submitting the urb to the USB host controller, until the
transfer is completed by the USB host controller. That is, the
driver doesn't how to access the buffer after calling usb_submit_urb().

Best Regards,
Hayes

RE: [PATCH net 2/2] r8152: rx descriptor check

[Hayes Wang]

Mark Lord [mailto:ml...@pobox.com]
> Sent: Monday, November 14, 2016 4:34 AM
[...]
> Perhaps the driver
> is somehow accessing the buffer space again after doing usb_submit_urb()?
> That would certainly produce this kind of behaviour.

I don't think so. First, the driver only read the received buffer.
That is, the driver would not change (or write) the data. Second,
The driver would lose the point address of the received buffer
after submitting the urb to the USB host controller, until the
transfer is completed by the USB host controller. That is, the
driver doesn't how to access the buffer after calling usb_submit_urb().

Best Regards,
Hayes

linux-next: Tree for Nov 14

[Stephen Rothwell]

Hi all,

Changes since 2016:

The sound tree gained conflicts against the jc_docs tree.

The sound-asoc tree gained a build failure, so I used the version from
next-2016.

The driver-core tree gained a conflict against the pm tree.

The rpmsg tree gained a conflict against the slave-dma tree.

The akpm-current tree gained a conflict against the tip tree.

Non-merge commits (relative to Linus' tree): 5170
 5512 files changed, 336261 insertions(+), 113086 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 246 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (a25f0944ba9b Linux 4.9-rc5)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (cc6acc11cad1 kbuild: be more careful about 
matching preprocessed asm ___EXPORT_SYMBOL)
Merging arc-current/for-curr (0a0a047def15 ARCv2: MCIP: Use IDU_M_DISTRI_DEST 
mode if there is only 1 destination core)
Merging arm-current/fixes (6127d124ee4e ARM: wire up new pkey syscalls)
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (2ffd04dee0da powerpc/oops: Fix missing pr_cont()s 
in instruction dump)
Merging sparc/master (07b5ab3f71d3 sparc32: Fix inverted invalid_frame_pointer 
checks on sigreturns)
Merging net/master (7774d46b2037 net: ethernet: ixp4xx_eth: fix spelling 
mistake in debug message)
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (9b6c14d51bd2 net: tcp response should set oif only if 
it is L3 master)
Merging ipvs/master (b73b8a1ba598 netfilter: nft_dup: do not use sreg_dev if 
the user doesn't specify it)
Merging wireless-drivers/master (d3532ea6ce4e brcmfmac: avoid 
maybe-uninitialized warning in brcmf_cfg80211_start_ap)
Merging mac80211/master (269ebce4531b xen-netfront: cast grant table reference 
first to type int)
Merging sound-current/for-linus (2ecb704a1290 ALSA: hda - add a new condition 
to check if it is thinkpad)
Merging pci-current/for-linus (bc79c9851a76 PCI: VMD: Update filename to 
reflect move)
Merging driver-core.current/driver-core-linus (bdacd1b426db driver core: fix 
smatch warning on dev->bus check)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (18266403f3fe USB: cdc-acm: fix TIOCMIWAIT)
Merging usb-gadget-fixes/fixes (fd9afd3cbe40 usb: gadget: u_ether: remove 
interrupt throttling)
Merging usb-serial-fixes/usb-linus (9bfef729a3d1 USB: serial: ftdi_sio: add 
support for TI CC3200 LaunchPad)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (d70674eeaa5e iio: maxim_thermocouple: 
detect invalid storage size in read())
Merging char-misc.current/char-misc-linus (b13d14339baa ppdev: fix double-free 
of pp->pdev->name)
Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup 
Focaltech code)
Merging crypto-current/master (83d2c9a9c17b crypto: caam - do not register 
AES-XTS mode on LP units)
Merging ide/master 

Re: [patch v3 1/1] platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

[Andy Shevchenko]

On Tue, Nov 8, 2016 at 8:19 AM, Vadim Pasternak  wrote:
> Hi,
>
> Could this patch be merged to for-next for 4.10?
> When it's merged I'd like to submit another small patch on top of it.

First of all, please avoid top posting.
I will process the pdx86 mailing list and queue this week.

P.S. Are you sure that is the right fix "Remove "select MLX_PLATFORM"
from Kconfig, since it has unmet direct dependencies (X86 &&
X86_PLATFORM_DEVICES && X86_64)"?

>> On Mon, 31 Oct 2016, Vadim Pasternak wrote:
>>
>> > Since mlx-platform is not an architectural driver, it is moved out of
>> > arch/x86/platform to drivers/platform/x86.
>> > Relevant Makefile and Kconfig are updated.
>> >
>> > Signed-off-by: Vadim Pasternak 
>>
>> Acked-by: Thomas Gleixner 

-- 
With Best Regards,
Andy Shevchenko

Re: [patch v3 1/1] platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

[Andy Shevchenko]

On Tue, Nov 8, 2016 at 8:19 AM, Vadim Pasternak  wrote:
> Hi,
>
> Could this patch be merged to for-next for 4.10?
> When it's merged I'd like to submit another small patch on top of it.

First of all, please avoid top posting.
I will process the pdx86 mailing list and queue this week.

P.S. Are you sure that is the right fix "Remove "select MLX_PLATFORM"
from Kconfig, since it has unmet direct dependencies (X86 &&
X86_PLATFORM_DEVICES && X86_64)"?

>> On Mon, 31 Oct 2016, Vadim Pasternak wrote:
>>
>> > Since mlx-platform is not an architectural driver, it is moved out of
>> > arch/x86/platform to drivers/platform/x86.
>> > Relevant Makefile and Kconfig are updated.
>> >
>> > Signed-off-by: Vadim Pasternak 
>>
>> Acked-by: Thomas Gleixner 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v9 00/10] MT2701 DRM support

[CK Hu]

Hi, YT:

On Fri, 2016-11-11 at 19:55 +0800, YT Shen wrote:
> This is MT2701 DRM support PATCH v9, based on 4.9-rc1.
> We add DSI interrupt control, transfer function for MIPI DSI panel support.
> Most codes are the same, except some register changed.
> 
> For example:
>  - DISP_OVL address offset changed, color format definition changed.
>  - DISP_RDMA fifo size changed.
>  - DISP_COLOR offset changed.
>  - MIPI_TX setting changed.
> 
> We add a new component DDP_COMPONENT_BLS, and the connections are updated.
> OVL -> RDMA -> COLOR -> BLS -> DSI
> RDMA -> DPI
> And we have shadow register support in MT2701.
> 
> We remove dts patch from the patch series, which depends on MT2701 CCF and 
> scpsys.

For this series, it looks good to me.
Acked-by: CK Hu 

> 
> Changes since v8:
> - enable 3 DSI interrupts only
> - move mtk_dsi_wait_for_irq_done() to the patch of irq control
> - use the name BLS in DRM driver part
> - move BLS declaration to a separate patch
> - update mtk_dsi_switch_to_cmd_mode()
> - update mtk_output_dsi_enable() and mtk_output_dsi_disable()
> 
> Changes since v7:
> - Remove redundant codes
> - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update 
> display module connections"
> - Move _dsi_irq_wait_queue into platform driver data
> - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt 
> control"
> - Add more descriptions in the commit messages
> 
> Changes since v6:
> - Change data type of irq_data to u32
> - Rewrite mtk_dsi_host_transfer() for simplify
> - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for 
> different hardware settings".
> - Remove device tree from this patch series
> 
> Changes since v5:
> - Remove DPI device tree and compatible string
> - Use one wait queue to handle interrupt status
> - Update the interrupt check flow and DSI_INT_ALL_BITS
> - Use same function for host read/write command
> - various fixes
> 
> Changes since v4:
> - Add messages when timeout in mtk_disp_mutex_acquire()
> - Add descriptions for DISP_REG_MUTEX registers
> - Move connection settings for display modules to a separate patch
> - Remove 'mt2701-disp-wdma' because it is unused
> - Move cleaning up and renaming to a separate patch
> - Use wait_event_interruptible_timeout() to replace polling
> - Remove irq_num from mtk_dsi structure
> - Remove redundant and debug codes
> 
> Changes since v3:
> - Add DSI support for MIPI DSI panels
> - Update BLS binding to PWM nodes
> - Remove ufoe device nodes
> - Remove redundant parentheses
> - Remove global variable initialization
> 
> Changes since v2:
> - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel
> - Update mt2701_mtk_ddp_ext components
> - Changed to prefix naming
> - Reorder the patch series
> - Use of_device_get_match_data() to get driver private data
> - Use iopoll macros to implement mtk_disp_mutex_acquire()
> - Removed empty device tree nodes
> 
> Changes since v1:
> - Removed BLS bindings and codes, which belong to pwm driver
> - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config()
> - Split patch into smaller parts
> - Added const keyword to constant structure
> - Removed codes for special memory align
> 
> Thanks,
> yt.shen
> 
> YT Shen (8):
>   drm/mediatek: rename macros, add chip prefix
>   drm/mediatek: add *driver_data for different hardware settings
>   drm/mediatek: add shadow register support
>   drm/mediatek: add BLS component
>   drm/mediatek: update display module connections
>   drm/mediatek: cleaning up and refine
>   drm/mediatek: update DSI sub driver flow for sending commands to panel
>   drm/mediatek: add support for Mediatek SoC MT2701
> 
> shaoming chen (2):
>   drm/mediatek: add dsi interrupt control
>   drm/mediatek: add dsi transfer function
> 
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  33 ++-
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  17 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  76 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 138 ++---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |   2 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  38 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  15 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  54 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   9 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  | 429 
> 
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |  70 +++--
>  11 files changed, 715 insertions(+), 166 deletions(-)
> 

Re: [PATCH v9 00/10] MT2701 DRM support

[CK Hu]

Hi, YT:

On Fri, 2016-11-11 at 19:55 +0800, YT Shen wrote:
> This is MT2701 DRM support PATCH v9, based on 4.9-rc1.
> We add DSI interrupt control, transfer function for MIPI DSI panel support.
> Most codes are the same, except some register changed.
> 
> For example:
>  - DISP_OVL address offset changed, color format definition changed.
>  - DISP_RDMA fifo size changed.
>  - DISP_COLOR offset changed.
>  - MIPI_TX setting changed.
> 
> We add a new component DDP_COMPONENT_BLS, and the connections are updated.
> OVL -> RDMA -> COLOR -> BLS -> DSI
> RDMA -> DPI
> And we have shadow register support in MT2701.
> 
> We remove dts patch from the patch series, which depends on MT2701 CCF and 
> scpsys.

For this series, it looks good to me.
Acked-by: CK Hu 

> 
> Changes since v8:
> - enable 3 DSI interrupts only
> - move mtk_dsi_wait_for_irq_done() to the patch of irq control
> - use the name BLS in DRM driver part
> - move BLS declaration to a separate patch
> - update mtk_dsi_switch_to_cmd_mode()
> - update mtk_output_dsi_enable() and mtk_output_dsi_disable()
> 
> Changes since v7:
> - Remove redundant codes
> - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update 
> display module connections"
> - Move _dsi_irq_wait_queue into platform driver data
> - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt 
> control"
> - Add more descriptions in the commit messages
> 
> Changes since v6:
> - Change data type of irq_data to u32
> - Rewrite mtk_dsi_host_transfer() for simplify
> - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for 
> different hardware settings".
> - Remove device tree from this patch series
> 
> Changes since v5:
> - Remove DPI device tree and compatible string
> - Use one wait queue to handle interrupt status
> - Update the interrupt check flow and DSI_INT_ALL_BITS
> - Use same function for host read/write command
> - various fixes
> 
> Changes since v4:
> - Add messages when timeout in mtk_disp_mutex_acquire()
> - Add descriptions for DISP_REG_MUTEX registers
> - Move connection settings for display modules to a separate patch
> - Remove 'mt2701-disp-wdma' because it is unused
> - Move cleaning up and renaming to a separate patch
> - Use wait_event_interruptible_timeout() to replace polling
> - Remove irq_num from mtk_dsi structure
> - Remove redundant and debug codes
> 
> Changes since v3:
> - Add DSI support for MIPI DSI panels
> - Update BLS binding to PWM nodes
> - Remove ufoe device nodes
> - Remove redundant parentheses
> - Remove global variable initialization
> 
> Changes since v2:
> - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel
> - Update mt2701_mtk_ddp_ext components
> - Changed to prefix naming
> - Reorder the patch series
> - Use of_device_get_match_data() to get driver private data
> - Use iopoll macros to implement mtk_disp_mutex_acquire()
> - Removed empty device tree nodes
> 
> Changes since v1:
> - Removed BLS bindings and codes, which belong to pwm driver
> - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config()
> - Split patch into smaller parts
> - Added const keyword to constant structure
> - Removed codes for special memory align
> 
> Thanks,
> yt.shen
> 
> YT Shen (8):
>   drm/mediatek: rename macros, add chip prefix
>   drm/mediatek: add *driver_data for different hardware settings
>   drm/mediatek: add shadow register support
>   drm/mediatek: add BLS component
>   drm/mediatek: update display module connections
>   drm/mediatek: cleaning up and refine
>   drm/mediatek: update DSI sub driver flow for sending commands to panel
>   drm/mediatek: add support for Mediatek SoC MT2701
> 
> shaoming chen (2):
>   drm/mediatek: add dsi interrupt control
>   drm/mediatek: add dsi transfer function
> 
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  33 ++-
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  17 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  76 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 138 ++---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |   2 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  38 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  15 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  54 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   9 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  | 429 
> 
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |  70 +++--
>  11 files changed, 715 insertions(+), 166 deletions(-)
> 

Re: Linux 4.8.6

[Greg KH]

On Mon, Oct 31, 2016 at 04:26:39PM -0400, Levin, Alexander wrote:
> On Mon, Oct 31, 2016 at 06:47:10AM -0600, Greg KH wrote:
> > I'm announcing the release of the 4.8.6 kernel.
> 
> Hey Greg,
> 
> I've put more work into improving my filters to find stable commits upstream.
> 
> The list below, taken from v4.8..v4.9-rc2 commits contains mostly commits 
> that aren't tagged for stable, but should probably be there. In this case, it 
> also includes one CVE fix that falls under that description.
> 
> Note that I've filtered "prerequisite" commits out to leave only the actual 
> commits we're interested in, so for example - for the first commit on the 
> list you'd need either bbdc070 ("drm/i915: rename macro parameter(ring) to 
> (engine)") or backport those changes yourself. If the list below looks good 
> to you I can send you a pull request with a complete branch.

[what happened to wrapping email lines...]

This looks good, but it's a lot of patches, what are you using to
determine what "should be here"?  I should have caught up with all of
the patches marked as "stable@", and almost all of the ones that looked
correct that were marked with "fixes:", so is there any way you can
rebase your tree to see what is left?

And yes, a git tree would be great to pull from, that makes it easier to
look at for me.

thanks,

greg k-h

Re: Linux 4.8.6

[Greg KH]

On Mon, Oct 31, 2016 at 04:26:39PM -0400, Levin, Alexander wrote:
> On Mon, Oct 31, 2016 at 06:47:10AM -0600, Greg KH wrote:
> > I'm announcing the release of the 4.8.6 kernel.
> 
> Hey Greg,
> 
> I've put more work into improving my filters to find stable commits upstream.
> 
> The list below, taken from v4.8..v4.9-rc2 commits contains mostly commits 
> that aren't tagged for stable, but should probably be there. In this case, it 
> also includes one CVE fix that falls under that description.
> 
> Note that I've filtered "prerequisite" commits out to leave only the actual 
> commits we're interested in, so for example - for the first commit on the 
> list you'd need either bbdc070 ("drm/i915: rename macro parameter(ring) to 
> (engine)") or backport those changes yourself. If the list below looks good 
> to you I can send you a pull request with a complete branch.

[what happened to wrapping email lines...]

This looks good, but it's a lot of patches, what are you using to
determine what "should be here"?  I should have caught up with all of
the patches marked as "stable@", and almost all of the ones that looked
correct that were marked with "fixes:", so is there any way you can
rebase your tree to see what is left?

And yes, a git tree would be great to pull from, that makes it easier to
look at for me.

thanks,

greg k-h

[PATCH] perf symbol: Print symbol offsets conditionally

[Namhyung Kim]

The __symbol__fprintf_symname_offs() always shows symbol offsets.  So
there's no difference between 'perf script -F ip,sym' and 'perf script
-F ip,sym,symoff'.  I don't think it's a desired behavior..

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/evsel_fprintf.c  |  6 --
 tools/perf/util/symbol.h |  3 ++-
 tools/perf/util/symbol_fprintf.c | 11 ++-
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/perf/util/evsel_fprintf.c b/tools/perf/util/evsel_fprintf.c
index 3674e77ad640..c039cdb22b5d 100644
--- a/tools/perf/util/evsel_fprintf.c
+++ b/tools/perf/util/evsel_fprintf.c
@@ -140,7 +140,8 @@ int sample__fprintf_callchain(struct perf_sample *sample, 
int left_alignment,
 
if (print_symoffset) {
printed += 
__symbol__fprintf_symname_offs(node->sym, _al,
-   
  print_unknown_as_addr, fp);
+   
  print_unknown_as_addr,
+   
  true, fp);
} else {
printed += 
__symbol__fprintf_symname(node->sym, _al,
 
print_unknown_as_addr, fp);
@@ -191,7 +192,8 @@ int sample__fprintf_sym(struct perf_sample *sample, struct 
addr_location *al,
printed += fprintf(fp, " ");
if (print_symoffset) {
printed += 
__symbol__fprintf_symname_offs(al->sym, al,
- 
print_unknown_as_addr, fp);
+ 
print_unknown_as_addr,
+ true, 
fp);
} else {
printed += __symbol__fprintf_symname(al->sym, 
al,
 
print_unknown_as_addr, fp);
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 699f7cbcfe72..bfae76bd973e 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -280,7 +280,8 @@ void symbol__elf_init(void);
 struct symbol *symbol__new(u64 start, u64 len, u8 binding, const char *name);
 size_t __symbol__fprintf_symname_offs(const struct symbol *sym,
  const struct addr_location *al,
- bool unknown_as_addr, FILE *fp);
+ bool unknown_as_addr,
+ bool print_offsets, FILE *fp);
 size_t symbol__fprintf_symname_offs(const struct symbol *sym,
const struct addr_location *al, FILE *fp);
 size_t __symbol__fprintf_symname(const struct symbol *sym,
diff --git a/tools/perf/util/symbol_fprintf.c b/tools/perf/util/symbol_fprintf.c
index a680bdaa65dc..7c6b33e8e2d2 100644
--- a/tools/perf/util/symbol_fprintf.c
+++ b/tools/perf/util/symbol_fprintf.c
@@ -15,14 +15,15 @@ size_t symbol__fprintf(struct symbol *sym, FILE *fp)
 
 size_t __symbol__fprintf_symname_offs(const struct symbol *sym,
  const struct addr_location *al,
- bool unknown_as_addr, FILE *fp)
+ bool unknown_as_addr,
+ bool print_offsets, FILE *fp)
 {
unsigned long offset;
size_t length;
 
if (sym && sym->name) {
length = fprintf(fp, "%s", sym->name);
-   if (al) {
+   if (al && print_offsets) {
if (al->addr < sym->end)
offset = al->addr - sym->start;
else
@@ -40,19 +41,19 @@ size_t symbol__fprintf_symname_offs(const struct symbol 
*sym,
const struct addr_location *al,
FILE *fp)
 {
-   return __symbol__fprintf_symname_offs(sym, al, false, fp);
+   return __symbol__fprintf_symname_offs(sym, al, false, true, fp);
 }
 
 size_t __symbol__fprintf_symname(const struct symbol *sym,
 const struct addr_location *al,
 bool unknown_as_addr, FILE *fp)
 {
-   return __symbol__fprintf_symname_offs(sym, al, unknown_as_addr, fp);
+   return __symbol__fprintf_symname_offs(sym, al, unknown_as_addr, false, 
fp);
 }
 
 size_t symbol__fprintf_symname(const struct symbol *sym, FILE *fp)
 {
-   return __symbol__fprintf_symname_offs(sym, NULL, false, fp);
+   return __symbol__fprintf_symname_offs(sym, NULL, false, false, fp);
 }
 
 size_t 

[PATCH] perf symbol: Print symbol offsets conditionally

[Namhyung Kim]

The __symbol__fprintf_symname_offs() always shows symbol offsets.  So
there's no difference between 'perf script -F ip,sym' and 'perf script
-F ip,sym,symoff'.  I don't think it's a desired behavior..

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/evsel_fprintf.c  |  6 --
 tools/perf/util/symbol.h |  3 ++-
 tools/perf/util/symbol_fprintf.c | 11 ++-
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/perf/util/evsel_fprintf.c b/tools/perf/util/evsel_fprintf.c
index 3674e77ad640..c039cdb22b5d 100644
--- a/tools/perf/util/evsel_fprintf.c
+++ b/tools/perf/util/evsel_fprintf.c
@@ -140,7 +140,8 @@ int sample__fprintf_callchain(struct perf_sample *sample, 
int left_alignment,
 
if (print_symoffset) {
printed += 
__symbol__fprintf_symname_offs(node->sym, _al,
-   
  print_unknown_as_addr, fp);
+   
  print_unknown_as_addr,
+   
  true, fp);
} else {
printed += 
__symbol__fprintf_symname(node->sym, _al,
 
print_unknown_as_addr, fp);
@@ -191,7 +192,8 @@ int sample__fprintf_sym(struct perf_sample *sample, struct 
addr_location *al,
printed += fprintf(fp, " ");
if (print_symoffset) {
printed += 
__symbol__fprintf_symname_offs(al->sym, al,
- 
print_unknown_as_addr, fp);
+ 
print_unknown_as_addr,
+ true, 
fp);
} else {
printed += __symbol__fprintf_symname(al->sym, 
al,
 
print_unknown_as_addr, fp);
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 699f7cbcfe72..bfae76bd973e 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -280,7 +280,8 @@ void symbol__elf_init(void);
 struct symbol *symbol__new(u64 start, u64 len, u8 binding, const char *name);
 size_t __symbol__fprintf_symname_offs(const struct symbol *sym,
  const struct addr_location *al,
- bool unknown_as_addr, FILE *fp);
+ bool unknown_as_addr,
+ bool print_offsets, FILE *fp);
 size_t symbol__fprintf_symname_offs(const struct symbol *sym,
const struct addr_location *al, FILE *fp);
 size_t __symbol__fprintf_symname(const struct symbol *sym,
diff --git a/tools/perf/util/symbol_fprintf.c b/tools/perf/util/symbol_fprintf.c
index a680bdaa65dc..7c6b33e8e2d2 100644
--- a/tools/perf/util/symbol_fprintf.c
+++ b/tools/perf/util/symbol_fprintf.c
@@ -15,14 +15,15 @@ size_t symbol__fprintf(struct symbol *sym, FILE *fp)
 
 size_t __symbol__fprintf_symname_offs(const struct symbol *sym,
  const struct addr_location *al,
- bool unknown_as_addr, FILE *fp)
+ bool unknown_as_addr,
+ bool print_offsets, FILE *fp)
 {
unsigned long offset;
size_t length;
 
if (sym && sym->name) {
length = fprintf(fp, "%s", sym->name);
-   if (al) {
+   if (al && print_offsets) {
if (al->addr < sym->end)
offset = al->addr - sym->start;
else
@@ -40,19 +41,19 @@ size_t symbol__fprintf_symname_offs(const struct symbol 
*sym,
const struct addr_location *al,
FILE *fp)
 {
-   return __symbol__fprintf_symname_offs(sym, al, false, fp);
+   return __symbol__fprintf_symname_offs(sym, al, false, true, fp);
 }
 
 size_t __symbol__fprintf_symname(const struct symbol *sym,
 const struct addr_location *al,
 bool unknown_as_addr, FILE *fp)
 {
-   return __symbol__fprintf_symname_offs(sym, al, unknown_as_addr, fp);
+   return __symbol__fprintf_symname_offs(sym, al, unknown_as_addr, false, 
fp);
 }
 
 size_t symbol__fprintf_symname(const struct symbol *sym, FILE *fp)
 {
-   return __symbol__fprintf_symname_offs(sym, NULL, false, fp);
+   return __symbol__fprintf_symname_offs(sym, NULL, false, false, fp);
 }
 
 size_t dso__fprintf_symbols_by_name(struct dso *dso,
-- 

Re: [PATCH 4.4 10/34] net/sched: act_vlan: Push skb->data to mac_header prior calling skb_vlan_*() functions

[Shmulik Ladkani]

On Sun, 13 Nov 2016 12:24:42 +0100
Greg Kroah-Hartman  wrote:

> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 

Looks ok, thanks.
Reviewed-by: Shmulik Ladkani 

Re: [PATCH 4.4 10/34] net/sched: act_vlan: Push skb->data to mac_header prior calling skb_vlan_*() functions

[Shmulik Ladkani]

On Sun, 13 Nov 2016 12:24:42 +0100
Greg Kroah-Hartman  wrote:

> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 

Looks ok, thanks.
Reviewed-by: Shmulik Ladkani 

[PATCH v2 0/2] phy: rockchip-inno-usb2: correct 480MHz clk_ops callbacks and stable time

[William Wu]

This series try to correct the 480MHz output clock of USB2 PHY
clk_ops callback and fix the delay time. It aims to make the
480MHz clock more sensible and stable.

Tested on rk3366/rk3399 EVB board.

William Wu (2):
  phy: rockchip-inno-usb2: correct clk_ops callback
  phy: rockchip-inno-usb2: correct 480MHz output clock stable time

 drivers/phy/phy-rockchip-inno-usb2.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

-- 
2.0.0

RE: [PATCH net 2/2] r8152: rx descriptor check

[Hayes Wang]

David Miller [mailto:da...@davemloft.net]
> Sent: Monday, November 14, 2016 1:40 AM
[...]
> If you add this patch now, there is a much smaller likelyhood that you
> will work with a high priority to figure out _why_ this is happening.
> 
> For all we know this could be a platform bug in the DMA API for the
> systems in question.
> 
> It could also be a bug elsewhere in the driver, either in setting up
> the descriptor DMA mappings or how the chip is programmed.
> 
> Either way the true cause must be found before we start throwing
> changes like this into the driver.

Our hw engineer could check our device, and I could check the
driver. However, for the other parts, such as the USB host
controller or memory, it is difficult for me to make sure whether
they are correct or not. I could only promise our devices and
driver work fine.

Best Regards,
Hayes

[PATCH v2 0/2] phy: rockchip-inno-usb2: correct 480MHz clk_ops callbacks and stable time

[William Wu]

This series try to correct the 480MHz output clock of USB2 PHY
clk_ops callback and fix the delay time. It aims to make the
480MHz clock more sensible and stable.

Tested on rk3366/rk3399 EVB board.

William Wu (2):
  phy: rockchip-inno-usb2: correct clk_ops callback
  phy: rockchip-inno-usb2: correct 480MHz output clock stable time

 drivers/phy/phy-rockchip-inno-usb2.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

-- 
2.0.0

RE: [PATCH net 2/2] r8152: rx descriptor check

[Hayes Wang]

David Miller [mailto:da...@davemloft.net]
> Sent: Monday, November 14, 2016 1:40 AM
[...]
> If you add this patch now, there is a much smaller likelyhood that you
> will work with a high priority to figure out _why_ this is happening.
> 
> For all we know this could be a platform bug in the DMA API for the
> systems in question.
> 
> It could also be a bug elsewhere in the driver, either in setting up
> the descriptor DMA mappings or how the chip is programmed.
> 
> Either way the true cause must be found before we start throwing
> changes like this into the driver.

Our hw engineer could check our device, and I could check the
driver. However, for the other parts, such as the USB host
controller or memory, it is difficult for me to make sure whether
they are correct or not. I could only promise our devices and
driver work fine.

Best Regards,
Hayes

Re: [PATCH v2] cpufreq: conservative: Decrease frequency faster when the update deferred

[Viresh Kumar]

On 12-11-16, 23:04, Stratos Karafotis wrote:
> diff --git a/drivers/cpufreq/cpufreq_conservative.c 
> b/drivers/cpufreq/cpufreq_conservative.c
> index fa5ece3..d787772 100644
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -73,7 +73,19 @@ static unsigned int cs_dbs_update(struct cpufreq_policy 
> *policy)
>*/
>   if (cs_tuners->freq_step == 0)
>   goto out;
> -
> + /*
> +  * Decrease requested_freq for each idle period that we didn't
> +  * update the frequency

Add a full stop (.) here.

> +  */

I am wondering if we should be adding this code after the below 'if' block where
we check if the policy->min/max have changed ?

> + if (policy_dbs->idle_periods < UINT_MAX) {
> + unsigned int freq_target = policy_dbs->idle_periods *
> + get_freq_target(cs_tuners, policy);

I get confused every time I look at this routine (get_freq_target()). I have
sent an update to this file just now to get that fixed. If Rafael applies that
one, please rebase over it.

> + if (requested_freq > freq_target)
> + requested_freq -= freq_target;
> + else
> + requested_freq = policy->min;
> + policy_dbs->idle_periods = UINT_MAX;
> + }

Need a blank line here.

-- 
viresh

Re: [PATCH v2] cpufreq: conservative: Decrease frequency faster when the update deferred

[Viresh Kumar]

On 12-11-16, 23:04, Stratos Karafotis wrote:
> diff --git a/drivers/cpufreq/cpufreq_conservative.c 
> b/drivers/cpufreq/cpufreq_conservative.c
> index fa5ece3..d787772 100644
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -73,7 +73,19 @@ static unsigned int cs_dbs_update(struct cpufreq_policy 
> *policy)
>*/
>   if (cs_tuners->freq_step == 0)
>   goto out;
> -
> + /*
> +  * Decrease requested_freq for each idle period that we didn't
> +  * update the frequency

Add a full stop (.) here.

> +  */

I am wondering if we should be adding this code after the below 'if' block where
we check if the policy->min/max have changed ?

> + if (policy_dbs->idle_periods < UINT_MAX) {
> + unsigned int freq_target = policy_dbs->idle_periods *
> + get_freq_target(cs_tuners, policy);

I get confused every time I look at this routine (get_freq_target()). I have
sent an update to this file just now to get that fixed. If Rafael applies that
one, please rebase over it.

> + if (requested_freq > freq_target)
> + requested_freq -= freq_target;
> + else
> + requested_freq = policy->min;
> + policy_dbs->idle_periods = UINT_MAX;
> + }

Need a blank line here.

-- 
viresh

[PATCH v2 2/2] phy: rockchip-inno-usb2: correct 480MHz output clock stable time

[William Wu]

We found that the system crashed due to 480MHz output clock of
USB2 PHY was unstable after clock had been enabled by gpu module.

Theoretically, 1 millisecond is a critical value for 480MHz
output clock stable time, so we try to change the delay time
to 1.2 millisecond to avoid this issue.

And the commit ed907fb1d7c3 ("phy: rockchip-inno-usb2: correct
clk_ops callback") used prepare callbacks instead of enable
callbacks to support gate a clk if the operation may sleep. So
we can switch from delay to sleep functions.

Signed-off-by: William Wu 
---
Changes in v2:
- use usleep_range() function instead of mdelay()

 drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
b/drivers/phy/phy-rockchip-inno-usb2.c
index 365e077..578290b 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -166,7 +166,7 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw 
*hw)
return ret;
 
/* waitting for the clk become stable */
-   mdelay(1);
+   usleep_range(1200);
}
 
return 0;
-- 
2.0.0

[PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback

[William Wu]

Since we needs to delay ~1ms to wait for 480MHz output clock
of USB2 PHY to become stable after turn on it, the delay time
is pretty long for something that's supposed to be "atomic"
like a clk_enable(). Consider that clk_enable() will disable
interrupt and that a 1ms interrupt latency is not sensible.

The 480MHz output clock should be handled in prepare callbacks
which support gate a clk if the operation may sleep.

Signed-off-by: William Wu 
---
 drivers/phy/phy-rockchip-inno-usb2.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
b/drivers/phy/phy-rockchip-inno-usb2.c
index ac20310..365e077 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -153,7 +153,7 @@ static inline bool property_enabled(struct rockchip_usb2phy 
*rphy,
return tmp == reg->enable;
 }
 
-static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
 {
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -172,7 +172,7 @@ static int rockchip_usb2phy_clk480m_enable(struct clk_hw 
*hw)
return 0;
 }
 
-static void rockchip_usb2phy_clk480m_disable(struct clk_hw *hw)
+static void rockchip_usb2phy_clk480m_unprepare(struct clk_hw *hw)
 {
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -181,7 +181,7 @@ static void rockchip_usb2phy_clk480m_disable(struct clk_hw 
*hw)
property_enable(rphy, >phy_cfg->clkout_ctl, false);
 }
 
-static int rockchip_usb2phy_clk480m_enabled(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepared(struct clk_hw *hw)
 {
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -197,9 +197,9 @@ rockchip_usb2phy_clk480m_recalc_rate(struct clk_hw *hw,
 }
 
 static const struct clk_ops rockchip_usb2phy_clkout_ops = {
-   .enable = rockchip_usb2phy_clk480m_enable,
-   .disable = rockchip_usb2phy_clk480m_disable,
-   .is_enabled = rockchip_usb2phy_clk480m_enabled,
+   .prepare = rockchip_usb2phy_clk480m_prepare,
+   .unprepare = rockchip_usb2phy_clk480m_unprepare,
+   .is_prepared = rockchip_usb2phy_clk480m_prepared,
.recalc_rate = rockchip_usb2phy_clk480m_recalc_rate,
 };
 
-- 
2.0.0

[PATCH v2 2/2] phy: rockchip-inno-usb2: correct 480MHz output clock stable time

[William Wu]

We found that the system crashed due to 480MHz output clock of
USB2 PHY was unstable after clock had been enabled by gpu module.

Theoretically, 1 millisecond is a critical value for 480MHz
output clock stable time, so we try to change the delay time
to 1.2 millisecond to avoid this issue.

And the commit ed907fb1d7c3 ("phy: rockchip-inno-usb2: correct
clk_ops callback") used prepare callbacks instead of enable
callbacks to support gate a clk if the operation may sleep. So
we can switch from delay to sleep functions.

Signed-off-by: William Wu 
---
Changes in v2:
- use usleep_range() function instead of mdelay()

 drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
b/drivers/phy/phy-rockchip-inno-usb2.c
index 365e077..578290b 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -166,7 +166,7 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw 
*hw)
return ret;
 
/* waitting for the clk become stable */
-   mdelay(1);
+   usleep_range(1200);
}
 
return 0;
-- 
2.0.0

[PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback

[William Wu]

Since we needs to delay ~1ms to wait for 480MHz output clock
of USB2 PHY to become stable after turn on it, the delay time
is pretty long for something that's supposed to be "atomic"
like a clk_enable(). Consider that clk_enable() will disable
interrupt and that a 1ms interrupt latency is not sensible.

The 480MHz output clock should be handled in prepare callbacks
which support gate a clk if the operation may sleep.

Signed-off-by: William Wu 
---
 drivers/phy/phy-rockchip-inno-usb2.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
b/drivers/phy/phy-rockchip-inno-usb2.c
index ac20310..365e077 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -153,7 +153,7 @@ static inline bool property_enabled(struct rockchip_usb2phy 
*rphy,
return tmp == reg->enable;
 }
 
-static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
 {
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -172,7 +172,7 @@ static int rockchip_usb2phy_clk480m_enable(struct clk_hw 
*hw)
return 0;
 }
 
-static void rockchip_usb2phy_clk480m_disable(struct clk_hw *hw)
+static void rockchip_usb2phy_clk480m_unprepare(struct clk_hw *hw)
 {
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -181,7 +181,7 @@ static void rockchip_usb2phy_clk480m_disable(struct clk_hw 
*hw)
property_enable(rphy, >phy_cfg->clkout_ctl, false);
 }
 
-static int rockchip_usb2phy_clk480m_enabled(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepared(struct clk_hw *hw)
 {
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -197,9 +197,9 @@ rockchip_usb2phy_clk480m_recalc_rate(struct clk_hw *hw,
 }
 
 static const struct clk_ops rockchip_usb2phy_clkout_ops = {
-   .enable = rockchip_usb2phy_clk480m_enable,
-   .disable = rockchip_usb2phy_clk480m_disable,
-   .is_enabled = rockchip_usb2phy_clk480m_enabled,
+   .prepare = rockchip_usb2phy_clk480m_prepare,
+   .unprepare = rockchip_usb2phy_clk480m_unprepare,
+   .is_prepared = rockchip_usb2phy_clk480m_prepared,
.recalc_rate = rockchip_usb2phy_clk480m_recalc_rate,
 };
 
-- 
2.0.0

[PATCH] cpufreq: conservative: Rename get_freq_target() to get_freq_step()

[Viresh Kumar]

What's returned from this function is the delta by which the frequency
must be increased or decreased and not the final frequency that should
be selected.

Name it properly to match its purpose. Also update the variables used to
store that value.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_conservative.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index fa5ece3915a1..0681fcff5aae 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -37,16 +37,16 @@ struct cs_dbs_tuners {
 #define DEF_SAMPLING_DOWN_FACTOR   (1)
 #define MAX_SAMPLING_DOWN_FACTOR   (10)
 
-static inline unsigned int get_freq_target(struct cs_dbs_tuners *cs_tuners,
-  struct cpufreq_policy *policy)
+static inline unsigned int get_freq_step(struct cs_dbs_tuners *cs_tuners,
+struct cpufreq_policy *policy)
 {
-   unsigned int freq_target = (cs_tuners->freq_step * policy->max) / 100;
+   unsigned int freq_step = (cs_tuners->freq_step * policy->max) / 100;
 
/* max freq cannot be less than 100. But who knows... */
-   if (unlikely(freq_target == 0))
-   freq_target = DEF_FREQUENCY_STEP;
+   if (unlikely(freq_step == 0))
+   freq_step = DEF_FREQUENCY_STEP;
 
-   return freq_target;
+   return freq_step;
 }
 
 /*
@@ -90,7 +90,7 @@ static unsigned int cs_dbs_update(struct cpufreq_policy 
*policy)
if (requested_freq == policy->max)
goto out;
 
-   requested_freq += get_freq_target(cs_tuners, policy);
+   requested_freq += get_freq_step(cs_tuners, policy);
if (requested_freq > policy->max)
requested_freq = policy->max;
 
@@ -106,16 +106,16 @@ static unsigned int cs_dbs_update(struct cpufreq_policy 
*policy)
 
/* Check for frequency decrease */
if (load < cs_tuners->down_threshold) {
-   unsigned int freq_target;
+   unsigned int freq_step;
/*
 * if we cannot reduce the frequency anymore, break out early
 */
if (requested_freq == policy->min)
goto out;
 
-   freq_target = get_freq_target(cs_tuners, policy);
-   if (requested_freq > freq_target)
-   requested_freq -= freq_target;
+   freq_step = get_freq_step(cs_tuners, policy);
+   if (requested_freq > freq_step)
+   requested_freq -= freq_step;
else
requested_freq = policy->min;
 
-- 
2.7.1.410.g6faf27b

[PATCH] cpufreq: conservative: Rename get_freq_target() to get_freq_step()

[Viresh Kumar]

What's returned from this function is the delta by which the frequency
must be increased or decreased and not the final frequency that should
be selected.

Name it properly to match its purpose. Also update the variables used to
store that value.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_conservative.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index fa5ece3915a1..0681fcff5aae 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -37,16 +37,16 @@ struct cs_dbs_tuners {
 #define DEF_SAMPLING_DOWN_FACTOR   (1)
 #define MAX_SAMPLING_DOWN_FACTOR   (10)
 
-static inline unsigned int get_freq_target(struct cs_dbs_tuners *cs_tuners,
-  struct cpufreq_policy *policy)
+static inline unsigned int get_freq_step(struct cs_dbs_tuners *cs_tuners,
+struct cpufreq_policy *policy)
 {
-   unsigned int freq_target = (cs_tuners->freq_step * policy->max) / 100;
+   unsigned int freq_step = (cs_tuners->freq_step * policy->max) / 100;
 
/* max freq cannot be less than 100. But who knows... */
-   if (unlikely(freq_target == 0))
-   freq_target = DEF_FREQUENCY_STEP;
+   if (unlikely(freq_step == 0))
+   freq_step = DEF_FREQUENCY_STEP;
 
-   return freq_target;
+   return freq_step;
 }
 
 /*
@@ -90,7 +90,7 @@ static unsigned int cs_dbs_update(struct cpufreq_policy 
*policy)
if (requested_freq == policy->max)
goto out;
 
-   requested_freq += get_freq_target(cs_tuners, policy);
+   requested_freq += get_freq_step(cs_tuners, policy);
if (requested_freq > policy->max)
requested_freq = policy->max;
 
@@ -106,16 +106,16 @@ static unsigned int cs_dbs_update(struct cpufreq_policy 
*policy)
 
/* Check for frequency decrease */
if (load < cs_tuners->down_threshold) {
-   unsigned int freq_target;
+   unsigned int freq_step;
/*
 * if we cannot reduce the frequency anymore, break out early
 */
if (requested_freq == policy->min)
goto out;
 
-   freq_target = get_freq_target(cs_tuners, policy);
-   if (requested_freq > freq_target)
-   requested_freq -= freq_target;
+   freq_step = get_freq_step(cs_tuners, policy);
+   if (requested_freq > freq_step)
+   requested_freq -= freq_step;
else
requested_freq = policy->min;
 
-- 
2.7.1.410.g6faf27b

Re: [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU

[Jisheng Zhang]

On Mon, 14 Nov 2016 14:12:51 +0800 Jisheng Zhang wrote:

> Hi Pankaj,
> 
> On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:
> 
> > Many platforms are duplicating code for enabling SCU, lets add
> > common code to enable SCU by parsing SCU device node so the duplication
> > in each platform can be avoided.
> > 
> > CC: Krzysztof Kozlowski 
> > CC: Jisheng Zhang 
> > CC: Russell King 
> > CC: Dinh Nguyen 
> > CC: Patrice Chotard 
> > CC: Linus Walleij 
> > CC: Liviu Dudau 
> > CC: Ray Jui 
> > CC: Stephen Warren 
> > CC: Heiko Stuebner 
> > CC: Shawn Guo 
> > CC: Michal Simek 
> > CC: Wei Xu 
> > CC: Andrew Lunn 
> > CC: Jun Nie  
> > Suggested-by: Arnd Bergmann 
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  arch/arm/include/asm/smp_scu.h |  4 +++
> >  arch/arm/kernel/smp_scu.c  | 56 
> > ++
> >  2 files changed, 60 insertions(+)
> > 
> > diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> > index bfe163c..fdeec07 100644
> > --- a/arch/arm/include/asm/smp_scu.h
> > +++ b/arch/arm/include/asm/smp_scu.h
> > @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, 
> > unsigned int mode)
> >  
> >  #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> >  void scu_enable(void __iomem *scu_base);
> > +void __iomem *of_scu_get_base(void);
> > +int of_scu_enable(void);
> >  #else
> >  static inline void scu_enable(void __iomem *scu_base) {}
> > +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> > +static inline int of_scu_enable(void) {return 0; }
> >  #endif
> >  
> >  #endif
> > diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> > index 72f9241..d0ac3ed 100644
> > --- a/arch/arm/kernel/smp_scu.c
> > +++ b/arch/arm/kernel/smp_scu.c
> > @@ -10,6 +10,7 @@
> >   */
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
> >  */
> > flush_cache_all();
> >  }
> > +
> > +static const struct of_device_id scu_match[] = {
> > +   { .compatible = "arm,cortex-a9-scu", },
> > +   { .compatible = "arm,cortex-a5-scu", },
> > +   { }
> > +};
> > +
> > +/*
> > + * Helper API to get SCU base address
> > + * In case platform DT do not have SCU node, or iomap fails
> > + * this call will fallback and will try to map via call to
> > + * scu_a9_get_base.
> > + * This will return ownership of scu_base to the caller
> > + */
> > +void __iomem *of_scu_get_base(void)
> > +{
> > +   unsigned long base = 0;
> > +   struct device_node *np;
> > +   void __iomem *scu_base;
> > +
> > +   np = of_find_matching_node(NULL, scu_match);  
> 
> could we check np before calling of_iomap()?
> 
> > +   scu_base = of_iomap(np, 0);
> > +   of_node_put(np);
> > +   if (!scu_base) {
> > +   pr_err("%s failed to map scu_base via DT\n", __func__);  
> 
> For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> what does it mean, but it may confuse normal users. In current version,
> berlin doesn't complain like this for non-ca9 SoCs

oops, I just realized that the non-ca9 berlin arm SoC version isn't upstreamed.
Below is the draft version I planed. Basically speaking, the code tries to
find "arm,cortex-a9-scu" node from DT, if can't, we think we don't need to
worry about SCU. Is there any elegant solution for my situation?

Thanks,
Jisheng


8<---
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -56,22 +56,25 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
max_cpus)
void __iomem *vectors_base;
 
np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   scu_base = of_iomap(np, 0);
-   of_node_put(np);
-   if (!scu_base)
-   return;
+   if (np) {
+   scu_base = of_iomap(np, 0);
+   of_node_put(np);
+   if (!scu_base)
+   return;
+   scu_enable(scu_base);
+   iounmap(scu_base);
+   }
 
np = of_find_compatible_node(NULL, NULL, "marvell,berlin-cpu-ctrl");
cpu_ctrl = of_iomap(np, 0);
of_node_put(np);
if (!cpu_ctrl)
-   goto unmap_scu;
+   return;
 
vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
if (!vectors_base)
-   goto unmap_scu;
+   return;
 
-   scu_enable(scu_base);
flush_cache_all();
 
/*
@@ -87,8 +90,6 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
max_cpus)
writel(virt_to_phys(secondary_startup), 

Re: [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU

[Jisheng Zhang]

On Mon, 14 Nov 2016 14:12:51 +0800 Jisheng Zhang wrote:

> Hi Pankaj,
> 
> On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:
> 
> > Many platforms are duplicating code for enabling SCU, lets add
> > common code to enable SCU by parsing SCU device node so the duplication
> > in each platform can be avoided.
> > 
> > CC: Krzysztof Kozlowski 
> > CC: Jisheng Zhang 
> > CC: Russell King 
> > CC: Dinh Nguyen 
> > CC: Patrice Chotard 
> > CC: Linus Walleij 
> > CC: Liviu Dudau 
> > CC: Ray Jui 
> > CC: Stephen Warren 
> > CC: Heiko Stuebner 
> > CC: Shawn Guo 
> > CC: Michal Simek 
> > CC: Wei Xu 
> > CC: Andrew Lunn 
> > CC: Jun Nie  
> > Suggested-by: Arnd Bergmann 
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  arch/arm/include/asm/smp_scu.h |  4 +++
> >  arch/arm/kernel/smp_scu.c  | 56 
> > ++
> >  2 files changed, 60 insertions(+)
> > 
> > diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> > index bfe163c..fdeec07 100644
> > --- a/arch/arm/include/asm/smp_scu.h
> > +++ b/arch/arm/include/asm/smp_scu.h
> > @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, 
> > unsigned int mode)
> >  
> >  #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> >  void scu_enable(void __iomem *scu_base);
> > +void __iomem *of_scu_get_base(void);
> > +int of_scu_enable(void);
> >  #else
> >  static inline void scu_enable(void __iomem *scu_base) {}
> > +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> > +static inline int of_scu_enable(void) {return 0; }
> >  #endif
> >  
> >  #endif
> > diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> > index 72f9241..d0ac3ed 100644
> > --- a/arch/arm/kernel/smp_scu.c
> > +++ b/arch/arm/kernel/smp_scu.c
> > @@ -10,6 +10,7 @@
> >   */
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
> >  */
> > flush_cache_all();
> >  }
> > +
> > +static const struct of_device_id scu_match[] = {
> > +   { .compatible = "arm,cortex-a9-scu", },
> > +   { .compatible = "arm,cortex-a5-scu", },
> > +   { }
> > +};
> > +
> > +/*
> > + * Helper API to get SCU base address
> > + * In case platform DT do not have SCU node, or iomap fails
> > + * this call will fallback and will try to map via call to
> > + * scu_a9_get_base.
> > + * This will return ownership of scu_base to the caller
> > + */
> > +void __iomem *of_scu_get_base(void)
> > +{
> > +   unsigned long base = 0;
> > +   struct device_node *np;
> > +   void __iomem *scu_base;
> > +
> > +   np = of_find_matching_node(NULL, scu_match);  
> 
> could we check np before calling of_iomap()?
> 
> > +   scu_base = of_iomap(np, 0);
> > +   of_node_put(np);
> > +   if (!scu_base) {
> > +   pr_err("%s failed to map scu_base via DT\n", __func__);  
> 
> For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> what does it mean, but it may confuse normal users. In current version,
> berlin doesn't complain like this for non-ca9 SoCs

oops, I just realized that the non-ca9 berlin arm SoC version isn't upstreamed.
Below is the draft version I planed. Basically speaking, the code tries to
find "arm,cortex-a9-scu" node from DT, if can't, we think we don't need to
worry about SCU. Is there any elegant solution for my situation?

Thanks,
Jisheng


8<---
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -56,22 +56,25 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
max_cpus)
void __iomem *vectors_base;
 
np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   scu_base = of_iomap(np, 0);
-   of_node_put(np);
-   if (!scu_base)
-   return;
+   if (np) {
+   scu_base = of_iomap(np, 0);
+   of_node_put(np);
+   if (!scu_base)
+   return;
+   scu_enable(scu_base);
+   iounmap(scu_base);
+   }
 
np = of_find_compatible_node(NULL, NULL, "marvell,berlin-cpu-ctrl");
cpu_ctrl = of_iomap(np, 0);
of_node_put(np);
if (!cpu_ctrl)
-   goto unmap_scu;
+   return;
 
vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
if (!vectors_base)
-   goto unmap_scu;
+   return;
 
-   scu_enable(scu_base);
flush_cache_all();
 
/*
@@ -87,8 +90,6 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
max_cpus)
writel(virt_to_phys(secondary_startup), vectors_base + SW_RESET_ADDR);
 
iounmap(vectors_base);
-unmap_scu:
-   iounmap(scu_base);
 }
 
 static struct smp_operations berlin_smp_ops __initdata = {


> 
> > +   if (scu_a9_has_base()) {
> > +   base = scu_a9_get_base();
> > +   scu_base = ioremap(base, SZ_4K);
> > +   }
> > +   if (!scu_base) 

Re: [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid

[Stefan Agner]

On 2016-11-09 17:44, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.

FWIW, r3p2 is also the revision according to the cache registers...

Acked-by: Stefan Agner 

--
Stefan


> 
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/mach-imx/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 9155b63..936c59d 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -557,7 +557,6 @@ config SOC_VF610
>   bool "Vybrid Family VF610 support"
>   select ARM_GIC if ARCH_MULTI_V7
>   select PINCTRL_VF610
> - select PL310_ERRATA_769419 if CACHE_L2X0
>  
>   help
> This enables support for Freescale Vybrid VF610 processor.

Re: [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid

[Stefan Agner]

On 2016-11-09 17:44, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.

FWIW, r3p2 is also the revision according to the cache registers...

Acked-by: Stefan Agner 

--
Stefan


> 
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/mach-imx/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 9155b63..936c59d 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -557,7 +557,6 @@ config SOC_VF610
>   bool "Vybrid Family VF610 support"
>   select ARM_GIC if ARCH_MULTI_V7
>   select PINCTRL_VF610
> - select PL310_ERRATA_769419 if CACHE_L2X0
>  
>   help
> This enables support for Freescale Vybrid VF610 processor.

Re: [PATCH v5] USB hub_probe: rework ugly goto-into-compound-statement

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 03:53:58PM +0300, Eugene Korenevsky wrote:
> Rework smelling code (goto inside compound statement). Perhaps this is
> legacy. Anyway such code is not appropriate for Linux kernel.
> 
> Signed-off-by: Eugene Korenevsky 
> ---
> Changes in v5: make `bool` a return type of `hub_check_descriptor_sanity()`
> Changes in v4: fix typo
> Changes in v3: extract the code to static function
> Changes in v2: fix spaces instead of tab, add missing 'Signed-off-by'
> 
>  drivers/usb/core/hub.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index cbb1467..1a316a1 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1722,10 +1722,25 @@ static void hub_disconnect(struct usb_interface *intf)
>   kref_put(>kref, hub_release);
>  }
>  
> +static bool hub_check_descriptor_sanity(struct usb_host_interface *desc)
> +{
> + /* Some hubs have a subclass of 1, which AFAICT according to the */
> + /*  specs is not defined, but it works */
> + if (desc->desc.bInterfaceSubClass != 0 &&
> + desc->desc.bInterfaceSubClass != 1)
> + return false;
> +
> + /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> + if (desc->desc.bNumEndpoints != 1)
> + return false;
> +
> + /* If it's not an interrupt in endpoint, we'd better punt! */
> + return usb_endpoint_is_int_in(>endpoint[0].desc) != 0;

Also, the comment should say:
/* If the first endpoint is not interrupt IN, we... */

Re: [PATCH v5] USB hub_probe: rework ugly goto-into-compound-statement

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 03:53:58PM +0300, Eugene Korenevsky wrote:
> Rework smelling code (goto inside compound statement). Perhaps this is
> legacy. Anyway such code is not appropriate for Linux kernel.
> 
> Signed-off-by: Eugene Korenevsky 
> ---
> Changes in v5: make `bool` a return type of `hub_check_descriptor_sanity()`
> Changes in v4: fix typo
> Changes in v3: extract the code to static function
> Changes in v2: fix spaces instead of tab, add missing 'Signed-off-by'
> 
>  drivers/usb/core/hub.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index cbb1467..1a316a1 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1722,10 +1722,25 @@ static void hub_disconnect(struct usb_interface *intf)
>   kref_put(>kref, hub_release);
>  }
>  
> +static bool hub_check_descriptor_sanity(struct usb_host_interface *desc)
> +{
> + /* Some hubs have a subclass of 1, which AFAICT according to the */
> + /*  specs is not defined, but it works */
> + if (desc->desc.bInterfaceSubClass != 0 &&
> + desc->desc.bInterfaceSubClass != 1)
> + return false;
> +
> + /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> + if (desc->desc.bNumEndpoints != 1)
> + return false;
> +
> + /* If it's not an interrupt in endpoint, we'd better punt! */
> + return usb_endpoint_is_int_in(>endpoint[0].desc) != 0;

Also, the comment should say:
/* If the first endpoint is not interrupt IN, we... */

Re: [PATCH v5] USB hub_probe: rework ugly goto-into-compound-statement

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 03:53:58PM +0300, Eugene Korenevsky wrote:
> Rework smelling code (goto inside compound statement). Perhaps this is
> legacy. Anyway such code is not appropriate for Linux kernel.
> 
> Signed-off-by: Eugene Korenevsky 
> ---
> Changes in v5: make `bool` a return type of `hub_check_descriptor_sanity()`
> Changes in v4: fix typo
> Changes in v3: extract the code to static function
> Changes in v2: fix spaces instead of tab, add missing 'Signed-off-by'
> 
>  drivers/usb/core/hub.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index cbb1467..1a316a1 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1722,10 +1722,25 @@ static void hub_disconnect(struct usb_interface *intf)
>   kref_put(>kref, hub_release);
>  }
>  
> +static bool hub_check_descriptor_sanity(struct usb_host_interface *desc)
> +{
> + /* Some hubs have a subclass of 1, which AFAICT according to the */
> + /*  specs is not defined, but it works */
> + if (desc->desc.bInterfaceSubClass != 0 &&
> + desc->desc.bInterfaceSubClass != 1)
> + return false;
> +
> + /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> + if (desc->desc.bNumEndpoints != 1)
> + return false;
> +
> + /* If it's not an interrupt in endpoint, we'd better punt! */
> + return usb_endpoint_is_int_in(>endpoint[0].desc) != 0;

Ok, I'm going to be really pedantic here and ask that you spell this
last statement out:
if (usb...)
return true;
return false;

thanks,

greg k-h

Re: [PATCH v5] USB hub_probe: rework ugly goto-into-compound-statement

[Greg Kroah-Hartman]

On Sun, Nov 13, 2016 at 03:53:58PM +0300, Eugene Korenevsky wrote:
> Rework smelling code (goto inside compound statement). Perhaps this is
> legacy. Anyway such code is not appropriate for Linux kernel.
> 
> Signed-off-by: Eugene Korenevsky 
> ---
> Changes in v5: make `bool` a return type of `hub_check_descriptor_sanity()`
> Changes in v4: fix typo
> Changes in v3: extract the code to static function
> Changes in v2: fix spaces instead of tab, add missing 'Signed-off-by'
> 
>  drivers/usb/core/hub.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index cbb1467..1a316a1 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1722,10 +1722,25 @@ static void hub_disconnect(struct usb_interface *intf)
>   kref_put(>kref, hub_release);
>  }
>  
> +static bool hub_check_descriptor_sanity(struct usb_host_interface *desc)
> +{
> + /* Some hubs have a subclass of 1, which AFAICT according to the */
> + /*  specs is not defined, but it works */
> + if (desc->desc.bInterfaceSubClass != 0 &&
> + desc->desc.bInterfaceSubClass != 1)
> + return false;
> +
> + /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> + if (desc->desc.bNumEndpoints != 1)
> + return false;
> +
> + /* If it's not an interrupt in endpoint, we'd better punt! */
> + return usb_endpoint_is_int_in(>endpoint[0].desc) != 0;

Ok, I'm going to be really pedantic here and ask that you spell this
last statement out:
if (usb...)
return true;
return false;

thanks,

greg k-h

Re: Long delays creating a netns after deleting one (possibly RCU related)

[Cong Wang]

On Fri, Nov 11, 2016 at 4:55 PM, Cong Wang  wrote:
> On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney
>  wrote:
>>
>> Ah!  This net_mutex is different than RTNL.  Should synchronize_net() be
>> modified to check for net_mutex being held in addition to the current
>> checks for RTNL being held?
>>
>
> Good point!
>
> Like commit be3fc413da9eb17cce0991f214ab0, checking
> for net_mutex for this case seems to be an optimization, I assume
> synchronize_rcu_expedited() and synchronize_rcu() have the same
> behavior...

Thinking a bit more, I think commit be3fc413da9eb17cce0991f
gets wrong on rtnl_is_locked(), the lock could be locked by other
process not by the current one, therefore it should be
lockdep_rtnl_is_held() which, however, is defined only when LOCKDEP
is enabled... Sigh.

I don't see any better way than letting callers decide if they want the
expedited version or not, but this requires changes of all callers of
synchronize_net(). Hm.

Re: Long delays creating a netns after deleting one (possibly RCU related)

[Cong Wang]

On Fri, Nov 11, 2016 at 4:55 PM, Cong Wang  wrote:
> On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney
>  wrote:
>>
>> Ah!  This net_mutex is different than RTNL.  Should synchronize_net() be
>> modified to check for net_mutex being held in addition to the current
>> checks for RTNL being held?
>>
>
> Good point!
>
> Like commit be3fc413da9eb17cce0991f214ab0, checking
> for net_mutex for this case seems to be an optimization, I assume
> synchronize_rcu_expedited() and synchronize_rcu() have the same
> behavior...

Thinking a bit more, I think commit be3fc413da9eb17cce0991f
gets wrong on rtnl_is_locked(), the lock could be locked by other
process not by the current one, therefore it should be
lockdep_rtnl_is_held() which, however, is defined only when LOCKDEP
is enabled... Sigh.

I don't see any better way than letting callers decide if they want the
expedited version or not, but this requires changes of all callers of
synchronize_net(). Hm.

Re: [PATCH RESEND] drm/ast: free correct pointer in astfb_create() error paths

[Daniel Vetter]

On Mon, Nov 14, 2016 at 02:03:59PM +1100, Andrew Donnellan wrote:
> In the err_free_vram and err_release_fbi error paths in astfb_create(), we
> attempt to free afbdev->sysram. The only jumps to these error paths occur
> before we assign afbdev->sysram = sysram. Free sysram instead.
> 
> Signed-off-by: Andrew Donnellan 

Applied to drm-misc, thanks.
-Daniel

> 
> ---
> 
> Found by Coverity Scan. Compile tested only.
> ---
>  drivers/gpu/drm/ast/ast_fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index 7a86e24..d6f5ec6 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -253,7 +253,7 @@ static int astfb_create(struct drm_fb_helper *helper,
>  err_release_fbi:
>   drm_fb_helper_release_fbi(helper);
>  err_free_vram:
> - vfree(afbdev->sysram);
> + vfree(sysram);
>   return ret;
>  }
>  
> -- 
> Andrew Donnellan  OzLabs, ADL Canberra
> andrew.donnel...@au1.ibm.com  IBM Australia Limited
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH RESEND] drm/ast: free correct pointer in astfb_create() error paths

[Daniel Vetter]

On Mon, Nov 14, 2016 at 02:03:59PM +1100, Andrew Donnellan wrote:
> In the err_free_vram and err_release_fbi error paths in astfb_create(), we
> attempt to free afbdev->sysram. The only jumps to these error paths occur
> before we assign afbdev->sysram = sysram. Free sysram instead.
> 
> Signed-off-by: Andrew Donnellan 

Applied to drm-misc, thanks.
-Daniel

> 
> ---
> 
> Found by Coverity Scan. Compile tested only.
> ---
>  drivers/gpu/drm/ast/ast_fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index 7a86e24..d6f5ec6 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -253,7 +253,7 @@ static int astfb_create(struct drm_fb_helper *helper,
>  err_release_fbi:
>   drm_fb_helper_release_fbi(helper);
>  err_free_vram:
> - vfree(afbdev->sysram);
> + vfree(sysram);
>   return ret;
>  }
>  
> -- 
> Andrew Donnellan  OzLabs, ADL Canberra
> andrew.donnel...@au1.ibm.com  IBM Australia Limited
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid

[Shawn Guo]

On Wed, Nov 09, 2016 at 08:44:10AM -0800, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.
> 
> Signed-off-by: Andrey Smirnov 

I updated subject prefix a bit and applied the patch.

Shawn

Re: [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid

[Shawn Guo]

On Wed, Nov 09, 2016 at 08:44:10AM -0800, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.
> 
> Signed-off-by: Andrey Smirnov 

I updated subject prefix a bit and applied the patch.

Shawn

RE: [PATCH net 2/2] r8152: rx descriptor check

[Hayes Wang]

Francois Romieu [mailto:rom...@fr.zoreil.com]
> Sent: Friday, November 11, 2016 8:13 PM
[...]
> Invalid packet size corrupted receive descriptors in Realtek's device
> reminds of CVE-2009-4537.

Do you mean that the driver would get a packet exceed the size
which is set to RxMaxSize? I check it with our hw engineers.
They don't get any issue about RxMaxSize. And their test for
RxMaxSize register is fine.

> Is the silicium of both devices different enough to prevent the same
> exploit to happen ?

For this case, I don't think the device provide a invalid value
for the receive descriptors. However, the driver sees a different
value. That is why I say the memory is unbelievable.

Best Regards,
Hayes

RE: [PATCH net 2/2] r8152: rx descriptor check

[Hayes Wang]

Francois Romieu [mailto:rom...@fr.zoreil.com]
> Sent: Friday, November 11, 2016 8:13 PM
[...]
> Invalid packet size corrupted receive descriptors in Realtek's device
> reminds of CVE-2009-4537.

Do you mean that the driver would get a packet exceed the size
which is set to RxMaxSize? I check it with our hw engineers.
They don't get any issue about RxMaxSize. And their test for
RxMaxSize register is fine.

> Is the silicium of both devices different enough to prevent the same
> exploit to happen ?

For this case, I don't think the device provide a invalid value
for the receive descriptors. However, the driver sees a different
value. That is why I say the memory is unbelievable.

Best Regards,
Hayes

Re: [PATCH] ARM: dts: imx7d-pinfunc: fix UART pinmux defines

[Shawn Guo]

On Tue, Nov 08, 2016 at 06:44:56PM -0800, Stefan Agner wrote:
> The UART pinmux defines for the pins which are part of the LPSR
> pinmux controller are wrong: Output signals configure the input
> sel value and the pinmux defines allow not to distinguish between
> DCE/DTE mode. Follow the usual pattern using DTE/DCE as part of
> the define to denote the two UART configuration options.
> 
> Signed-off-by: Stefan Agner 

Applied, thanks.

Re: [PATCH] ARM: dts: imx7d-pinfunc: fix UART pinmux defines

[Shawn Guo]

On Tue, Nov 08, 2016 at 06:44:56PM -0800, Stefan Agner wrote:
> The UART pinmux defines for the pins which are part of the LPSR
> pinmux controller are wrong: Output signals configure the input
> sel value and the pinmux defines allow not to distinguish between
> DCE/DTE mode. Follow the usual pattern using DTE/DCE as part of
> the define to denote the two UART configuration options.
> 
> Signed-off-by: Stefan Agner 

Applied, thanks.

Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task

[Viresh Kumar]

On 13-11-16, 23:44, Rafael J. Wysocki wrote:
> To a minimum, there should be a comment regarding that in the patches.

Wanted to get the comment written properly before sending that in the patch. Can
you please rectify this based on what you are looking for ?

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index c6bc60078e21..e43f4fd42fb4 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -313,6 +313,20 @@ static void sugov_irq_work(struct irq_work *irq_work)
struct sugov_policy *sg_policy;
 
sg_policy = container_of(irq_work, struct sugov_policy, irq_work);
+
+   /*
+* For Real Time and Deadline tasks, schedutil governor shoots the
+* frequency to maximum. And special care must be taken to ensure that
+* this kthread doesn't result in that.
+*
+* This is (mostly) guaranteed by the work_in_progress flag. The flag is
+* updated only at the end of the sugov_work() and before that schedutil
+* rejects all other frequency scaling requests.
+*
+* Though there is a very rare case where the RT thread yields right
+* after the work_in_progress flag is cleared. The effects of that are
+* neglected for now.
+*/
kthread_queue_work(_policy->worker, _policy->work);
 }
 
> In any case, the clearing of work_in_progress might still be deferred
> by queuing a regular (non-RT) work item to do that from the kthread
> work (that will guarantee "hiding" the kthread work from the
> governor), but admittedly that would be a sledgehammer of sorts (and
> it might defeat the purpose of the whole exercise) ...

I agree.

-- 
viresh

Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task

[Viresh Kumar]

On 13-11-16, 23:44, Rafael J. Wysocki wrote:
> To a minimum, there should be a comment regarding that in the patches.

Wanted to get the comment written properly before sending that in the patch. Can
you please rectify this based on what you are looking for ?

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index c6bc60078e21..e43f4fd42fb4 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -313,6 +313,20 @@ static void sugov_irq_work(struct irq_work *irq_work)
struct sugov_policy *sg_policy;
 
sg_policy = container_of(irq_work, struct sugov_policy, irq_work);
+
+   /*
+* For Real Time and Deadline tasks, schedutil governor shoots the
+* frequency to maximum. And special care must be taken to ensure that
+* this kthread doesn't result in that.
+*
+* This is (mostly) guaranteed by the work_in_progress flag. The flag is
+* updated only at the end of the sugov_work() and before that schedutil
+* rejects all other frequency scaling requests.
+*
+* Though there is a very rare case where the RT thread yields right
+* after the work_in_progress flag is cleared. The effects of that are
+* neglected for now.
+*/
kthread_queue_work(_policy->worker, _policy->work);
 }
 
> In any case, the clearing of work_in_progress might still be deferred
> by queuing a regular (non-RT) work item to do that from the kthread
> work (that will guarantee "hiding" the kthread work from the
> governor), but admittedly that would be a sledgehammer of sorts (and
> it might defeat the purpose of the whole exercise) ...

I agree.

-- 
viresh

Re: [PATCH] x86/topology: Document cpu_llc_id

[Borislav Petkov]

On Wed, Sep 07, 2016 at 12:36:41PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 07, 2016 at 11:22:19AM +0200, Borislav Petkov wrote:
> > From: Borislav Petkov 
> > 
> > It means different things on Intel and AMD so write it down so that
> > there's no confusion.
> > 
> > Signed-off-by: Borislav Petkov 
> > Cc: Peter Zijlstra 
> > Cc: Thomas Gleixner 
> > ---
> >  Documentation/x86/topology.txt | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/x86/topology.txt b/Documentation/x86/topology.txt
> > index 06afac252f5b..7a5485730476 100644
> > --- a/Documentation/x86/topology.txt
> > +++ b/Documentation/x86/topology.txt
> > @@ -63,6 +63,12 @@ The topology of a system is described in the units of:
> >  The maximum possible number of packages in the system. Helpful for per
> >  package facilities to preallocate per package information.
> >  
> > +  - cpu_llc_id:
> > +
> > +A per-CPU variable containing:
> > +- On Intel, the first APIC ID of the list of CPUs sharing the Last 
> > Level
> > +Cache
> > +- On AMD, the Node ID containing the Last Level Cache.
> 
> And there are no AMD parts where there are multiple LLCs on a Node? Like
> where there isn't an L3 and the L2 is only per cluster?

Yes there are (now), see:

http://git.kernel.org/tip/b0b6e86846093c5f8820386bc01515f857dd8faa

But those LLC ID numbers are still increasing IDs of either nodes or
core complexes in Zen's case. So I think the text should say:

"- On AMD, the Node ID or Core Complex ID containing the Last Level Cache. In
   general, numbers identifying an LLC uniquely on the system."

How's that?

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] x86/topology: Document cpu_llc_id

[Borislav Petkov]

On Wed, Sep 07, 2016 at 12:36:41PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 07, 2016 at 11:22:19AM +0200, Borislav Petkov wrote:
> > From: Borislav Petkov 
> > 
> > It means different things on Intel and AMD so write it down so that
> > there's no confusion.
> > 
> > Signed-off-by: Borislav Petkov 
> > Cc: Peter Zijlstra 
> > Cc: Thomas Gleixner 
> > ---
> >  Documentation/x86/topology.txt | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/x86/topology.txt b/Documentation/x86/topology.txt
> > index 06afac252f5b..7a5485730476 100644
> > --- a/Documentation/x86/topology.txt
> > +++ b/Documentation/x86/topology.txt
> > @@ -63,6 +63,12 @@ The topology of a system is described in the units of:
> >  The maximum possible number of packages in the system. Helpful for per
> >  package facilities to preallocate per package information.
> >  
> > +  - cpu_llc_id:
> > +
> > +A per-CPU variable containing:
> > +- On Intel, the first APIC ID of the list of CPUs sharing the Last 
> > Level
> > +Cache
> > +- On AMD, the Node ID containing the Last Level Cache.
> 
> And there are no AMD parts where there are multiple LLCs on a Node? Like
> where there isn't an L3 and the L2 is only per cluster?

Yes there are (now), see:

http://git.kernel.org/tip/b0b6e86846093c5f8820386bc01515f857dd8faa

But those LLC ID numbers are still increasing IDs of either nodes or
core complexes in Zen's case. So I think the text should say:

"- On AMD, the Node ID or Core Complex ID containing the Last Level Cache. In
   general, numbers identifying an LLC uniquely on the system."

How's that?

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] genetlink: fix unsigned int comparison with less than zero

[Cong Wang]

On Sun, Nov 13, 2016 at 9:15 AM, David Miller  wrote:
> I've commited the following to net-next:
>
> 
> [PATCH] genetlink: Make family a signed integer.
>
> The idr_alloc(), idr_remove(), et al. routines all expect IDs to be
> signed integers.  Therefore make the genl_family member 'id' signed
> too.

This is exactly what I replied to Johannes.

Thanks for the fix!

Re: [PATCH] genetlink: fix unsigned int comparison with less than zero

[Cong Wang]

On Sun, Nov 13, 2016 at 9:15 AM, David Miller  wrote:
> I've commited the following to net-next:
>
> 
> [PATCH] genetlink: Make family a signed integer.
>
> The idr_alloc(), idr_remove(), et al. routines all expect IDs to be
> signed integers.  Therefore make the genl_family member 'id' signed
> too.

This is exactly what I replied to Johannes.

Thanks for the fix!

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

[Borislav Petkov]

On Sun, Nov 13, 2016 at 08:15:01AM -0800, Andy Lutomirski wrote:
> How about dropping the __ in front of the copy?

In front of __copy_from_user_inatomic()?

If so, is there even a global helper by that name?

$ git grep -E "[^_]copy_from_user_inatomic"
drivers/gpu/drm/msm/msm_gem_submit.c:98:ret = 
copy_from_user_inatomic(_bo, userptr, sizeof(submit_bo));

is all I can find.

-- 
Regards/Gruss,
Boris.

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

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

[Borislav Petkov]

On Sun, Nov 13, 2016 at 08:15:01AM -0800, Andy Lutomirski wrote:
> How about dropping the __ in front of the copy?

In front of __copy_from_user_inatomic()?

If so, is there even a global helper by that name?

$ git grep -E "[^_]copy_from_user_inatomic"
drivers/gpu/drm/msm/msm_gem_submit.c:98:ret = 
copy_from_user_inatomic(_bo, userptr, sizeof(submit_bo));

is all I can find.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU

[Jisheng Zhang]

Hi Pankaj,

On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:

> Many platforms are duplicating code for enabling SCU, lets add
> common code to enable SCU by parsing SCU device node so the duplication
> in each platform can be avoided.
> 
> CC: Krzysztof Kozlowski 
> CC: Jisheng Zhang 
> CC: Russell King 
> CC: Dinh Nguyen 
> CC: Patrice Chotard 
> CC: Linus Walleij 
> CC: Liviu Dudau 
> CC: Ray Jui 
> CC: Stephen Warren 
> CC: Heiko Stuebner 
> CC: Shawn Guo 
> CC: Michal Simek 
> CC: Wei Xu 
> CC: Andrew Lunn 
> CC: Jun Nie  
> Suggested-by: Arnd Bergmann 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/include/asm/smp_scu.h |  4 +++
>  arch/arm/kernel/smp_scu.c  | 56 
> ++
>  2 files changed, 60 insertions(+)
> 
> diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> index bfe163c..fdeec07 100644
> --- a/arch/arm/include/asm/smp_scu.h
> +++ b/arch/arm/include/asm/smp_scu.h
> @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, 
> unsigned int mode)
>  
>  #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
>  void scu_enable(void __iomem *scu_base);
> +void __iomem *of_scu_get_base(void);
> +int of_scu_enable(void);
>  #else
>  static inline void scu_enable(void __iomem *scu_base) {}
> +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> +static inline int of_scu_enable(void) {return 0; }
>  #endif
>  
>  #endif
> diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> index 72f9241..d0ac3ed 100644
> --- a/arch/arm/kernel/smp_scu.c
> +++ b/arch/arm/kernel/smp_scu.c
> @@ -10,6 +10,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
>*/
>   flush_cache_all();
>  }
> +
> +static const struct of_device_id scu_match[] = {
> + { .compatible = "arm,cortex-a9-scu", },
> + { .compatible = "arm,cortex-a5-scu", },
> + { }
> +};
> +
> +/*
> + * Helper API to get SCU base address
> + * In case platform DT do not have SCU node, or iomap fails
> + * this call will fallback and will try to map via call to
> + * scu_a9_get_base.
> + * This will return ownership of scu_base to the caller
> + */
> +void __iomem *of_scu_get_base(void)
> +{
> + unsigned long base = 0;
> + struct device_node *np;
> + void __iomem *scu_base;
> +
> + np = of_find_matching_node(NULL, scu_match);

could we check np before calling of_iomap()?

> + scu_base = of_iomap(np, 0);
> + of_node_put(np);
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base via DT\n", __func__);

For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
what does it mean, but it may confuse normal users. In current version,
berlin doesn't complain like this for non-ca9 SoCs

> + if (scu_a9_has_base()) {
> + base = scu_a9_get_base();
> + scu_base = ioremap(base, SZ_4K);
> + }
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base\n", __func__);

ditto

> + return IOMEM_ERR_PTR(-ENOMEM);
> + }
> + }
> + return scu_base;
> +}
> +
> +/*
> + * Enable SCU via mapping scu_base DT
> + * If scu_base mapped successfully scu will be enabled and in case of
> + * failure if will return non-zero error code
> + */
> +int of_scu_enable(void)
> +{
> + void __iomem *scu_base;
> +
> + scu_base = of_scu_get_base();
> + if (!IS_ERR(scu_base)) {
> + scu_enable(scu_base);
> + iounmap(scu_base);
> + return 0;
> + }
> + return PTR_ERR(scu_base);
> +}
> +
>  #endif
>  
>  /*

Re: [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU

[Jisheng Zhang]

Hi Pankaj,

On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:

> Many platforms are duplicating code for enabling SCU, lets add
> common code to enable SCU by parsing SCU device node so the duplication
> in each platform can be avoided.
> 
> CC: Krzysztof Kozlowski 
> CC: Jisheng Zhang 
> CC: Russell King 
> CC: Dinh Nguyen 
> CC: Patrice Chotard 
> CC: Linus Walleij 
> CC: Liviu Dudau 
> CC: Ray Jui 
> CC: Stephen Warren 
> CC: Heiko Stuebner 
> CC: Shawn Guo 
> CC: Michal Simek 
> CC: Wei Xu 
> CC: Andrew Lunn 
> CC: Jun Nie  
> Suggested-by: Arnd Bergmann 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/include/asm/smp_scu.h |  4 +++
>  arch/arm/kernel/smp_scu.c  | 56 
> ++
>  2 files changed, 60 insertions(+)
> 
> diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> index bfe163c..fdeec07 100644
> --- a/arch/arm/include/asm/smp_scu.h
> +++ b/arch/arm/include/asm/smp_scu.h
> @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, 
> unsigned int mode)
>  
>  #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
>  void scu_enable(void __iomem *scu_base);
> +void __iomem *of_scu_get_base(void);
> +int of_scu_enable(void);
>  #else
>  static inline void scu_enable(void __iomem *scu_base) {}
> +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> +static inline int of_scu_enable(void) {return 0; }
>  #endif
>  
>  #endif
> diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> index 72f9241..d0ac3ed 100644
> --- a/arch/arm/kernel/smp_scu.c
> +++ b/arch/arm/kernel/smp_scu.c
> @@ -10,6 +10,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
>*/
>   flush_cache_all();
>  }
> +
> +static const struct of_device_id scu_match[] = {
> + { .compatible = "arm,cortex-a9-scu", },
> + { .compatible = "arm,cortex-a5-scu", },
> + { }
> +};
> +
> +/*
> + * Helper API to get SCU base address
> + * In case platform DT do not have SCU node, or iomap fails
> + * this call will fallback and will try to map via call to
> + * scu_a9_get_base.
> + * This will return ownership of scu_base to the caller
> + */
> +void __iomem *of_scu_get_base(void)
> +{
> + unsigned long base = 0;
> + struct device_node *np;
> + void __iomem *scu_base;
> +
> + np = of_find_matching_node(NULL, scu_match);

could we check np before calling of_iomap()?

> + scu_base = of_iomap(np, 0);
> + of_node_put(np);
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base via DT\n", __func__);

For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
what does it mean, but it may confuse normal users. In current version,
berlin doesn't complain like this for non-ca9 SoCs

> + if (scu_a9_has_base()) {
> + base = scu_a9_get_base();
> + scu_base = ioremap(base, SZ_4K);
> + }
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base\n", __func__);

ditto

> + return IOMEM_ERR_PTR(-ENOMEM);
> + }
> + }
> + return scu_base;
> +}
> +
> +/*
> + * Enable SCU via mapping scu_base DT
> + * If scu_base mapped successfully scu will be enabled and in case of
> + * failure if will return non-zero error code
> + */
> +int of_scu_enable(void)
> +{
> + void __iomem *scu_base;
> +
> + scu_base = of_scu_get_base();
> + if (!IS_ERR(scu_base)) {
> + scu_enable(scu_base);
> + iounmap(scu_base);
> + return 0;
> + }
> + return PTR_ERR(scu_base);
> +}
> +
>  #endif
>  
>  /*

[PATCH v3] module: extend 'rodata=off' boot cmdline parameter to module mappings

[AKASHI Takahiro]

The current "rodata=off" parameter disables read-only kernel mappings
under CONFIG_DEBUG_RODATA:
commit d2aa1acad22f ("mm/init: Add 'rodata=off' boot cmdline parameter
to disable read-only kernel mappings")

This patch is a logical extension to module mappings ie. read-only mappings
at module loading can be disabled even if CONFIG_DEBUG_SET_MODULE_RONX
(mainly for debug use). Please note, however, that it only affects RO/RW
permissions, keeping NX set.

This is the first step to make CONFIG_DEBUG_SET_MODULE_RONX mandatory
(always-on) in the future as CONFIG_DEBUG_RODATA on x86 and arm64.

Suggested-by: and Acked-by: Mark Rutland 
Signed-off-by: AKASHI Takahiro 
Reviewed-by: Kees Cook 
Cc: Rusty Russell 
Cc: Jessica Yu 
---
v3:
  * merge if-statements in disable_ro_nx()
v2:
  * use CONFIG_DEBUG_RODATA/SET_MODULE_RONX guards better where appropriate
  * make "rodata_enabled" variable as __ro_after_init
v1:
  * remove RFC's "module_ronx=" and merge it with "rodata="
  * always keep NX set if CONFIG_SET_MODULE_RONX

 include/linux/init.h |  3 +++
 init/main.c  |  7 +--
 kernel/module.c  | 20 +---
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index e30104c..885c3e6 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -126,6 +126,9 @@ void prepare_namespace(void);
 void __init load_default_modules(void);
 int __init init_rootfs(void);
 
+#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
+extern bool rodata_enabled;
+#endif
 #ifdef CONFIG_DEBUG_RODATA
 void mark_rodata_ro(void);
 #endif
diff --git a/init/main.c b/init/main.c
index 2858be7..959a242 100644
--- a/init/main.c
+++ b/init/main.c
@@ -81,6 +81,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -914,14 +915,16 @@ static int try_to_run_init_process(const char 
*init_filename)
 
 static noinline void __init kernel_init_freeable(void);
 
-#ifdef CONFIG_DEBUG_RODATA
-static bool rodata_enabled = true;
+#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_SET_MODULE_RONX)
+bool rodata_enabled __ro_after_init = true;
 static int __init set_debug_rodata(char *str)
 {
return strtobool(str, _enabled);
 }
 __setup("rodata=", set_debug_rodata);
+#endif
 
+#ifdef CONFIG_DEBUG_RODATA
 static void mark_readonly(void)
 {
if (rodata_enabled)
diff --git a/kernel/module.c b/kernel/module.c
index f57dd63..6ad4b3f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1910,6 +1910,9 @@ static void frob_writable_data(const struct module_layout 
*layout,
 /* livepatching wants to disable read-only so it can frob module. */
 void module_disable_ro(const struct module *mod)
 {
+   if (!rodata_enabled)
+   return;
+
frob_text(>core_layout, set_memory_rw);
frob_rodata(>core_layout, set_memory_rw);
frob_ro_after_init(>core_layout, set_memory_rw);
@@ -1919,6 +1922,9 @@ void module_disable_ro(const struct module *mod)
 
 void module_enable_ro(const struct module *mod, bool after_init)
 {
+   if (!rodata_enabled)
+   return;
+
frob_text(>core_layout, set_memory_ro);
frob_rodata(>core_layout, set_memory_ro);
frob_text(>init_layout, set_memory_ro);
@@ -1951,6 +1957,9 @@ void set_all_modules_text_rw(void)
 {
struct module *mod;
 
+   if (!rodata_enabled)
+   return;
+
mutex_lock(_mutex);
list_for_each_entry_rcu(mod, , list) {
if (mod->state == MODULE_STATE_UNFORMED)
@@ -1967,6 +1976,9 @@ void set_all_modules_text_ro(void)
 {
struct module *mod;
 
+   if (!rodata_enabled)
+   return;
+
mutex_lock(_mutex);
list_for_each_entry_rcu(mod, , list) {
if (mod->state == MODULE_STATE_UNFORMED)
@@ -1980,10 +1992,12 @@ void set_all_modules_text_ro(void)
 
 static void disable_ro_nx(const struct module_layout *layout)
 {
-   frob_text(layout, set_memory_rw);
-   frob_rodata(layout, set_memory_rw);
+   if (rodata_enabled) {
+   frob_text(layout, set_memory_rw);
+   frob_rodata(layout, set_memory_rw);
+   frob_ro_after_init(layout, set_memory_rw);
+   }
frob_rodata(layout, set_memory_x);
-   frob_ro_after_init(layout, set_memory_rw);
frob_ro_after_init(layout, set_memory_x);
frob_writable_data(layout, set_memory_x);
 }
-- 
2.10.0

[PATCH v3] module: extend 'rodata=off' boot cmdline parameter to module mappings

[AKASHI Takahiro]

The current "rodata=off" parameter disables read-only kernel mappings
under CONFIG_DEBUG_RODATA:
commit d2aa1acad22f ("mm/init: Add 'rodata=off' boot cmdline parameter
to disable read-only kernel mappings")

This patch is a logical extension to module mappings ie. read-only mappings
at module loading can be disabled even if CONFIG_DEBUG_SET_MODULE_RONX
(mainly for debug use). Please note, however, that it only affects RO/RW
permissions, keeping NX set.

This is the first step to make CONFIG_DEBUG_SET_MODULE_RONX mandatory
(always-on) in the future as CONFIG_DEBUG_RODATA on x86 and arm64.

Suggested-by: and Acked-by: Mark Rutland 
Signed-off-by: AKASHI Takahiro 
Reviewed-by: Kees Cook 
Cc: Rusty Russell 
Cc: Jessica Yu 
---
v3:
  * merge if-statements in disable_ro_nx()
v2:
  * use CONFIG_DEBUG_RODATA/SET_MODULE_RONX guards better where appropriate
  * make "rodata_enabled" variable as __ro_after_init
v1:
  * remove RFC's "module_ronx=" and merge it with "rodata="
  * always keep NX set if CONFIG_SET_MODULE_RONX

 include/linux/init.h |  3 +++
 init/main.c  |  7 +--
 kernel/module.c  | 20 +---
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index e30104c..885c3e6 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -126,6 +126,9 @@ void prepare_namespace(void);
 void __init load_default_modules(void);
 int __init init_rootfs(void);
 
+#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
+extern bool rodata_enabled;
+#endif
 #ifdef CONFIG_DEBUG_RODATA
 void mark_rodata_ro(void);
 #endif
diff --git a/init/main.c b/init/main.c
index 2858be7..959a242 100644
--- a/init/main.c
+++ b/init/main.c
@@ -81,6 +81,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -914,14 +915,16 @@ static int try_to_run_init_process(const char 
*init_filename)
 
 static noinline void __init kernel_init_freeable(void);
 
-#ifdef CONFIG_DEBUG_RODATA
-static bool rodata_enabled = true;
+#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_SET_MODULE_RONX)
+bool rodata_enabled __ro_after_init = true;
 static int __init set_debug_rodata(char *str)
 {
return strtobool(str, _enabled);
 }
 __setup("rodata=", set_debug_rodata);
+#endif
 
+#ifdef CONFIG_DEBUG_RODATA
 static void mark_readonly(void)
 {
if (rodata_enabled)
diff --git a/kernel/module.c b/kernel/module.c
index f57dd63..6ad4b3f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1910,6 +1910,9 @@ static void frob_writable_data(const struct module_layout 
*layout,
 /* livepatching wants to disable read-only so it can frob module. */
 void module_disable_ro(const struct module *mod)
 {
+   if (!rodata_enabled)
+   return;
+
frob_text(>core_layout, set_memory_rw);
frob_rodata(>core_layout, set_memory_rw);
frob_ro_after_init(>core_layout, set_memory_rw);
@@ -1919,6 +1922,9 @@ void module_disable_ro(const struct module *mod)
 
 void module_enable_ro(const struct module *mod, bool after_init)
 {
+   if (!rodata_enabled)
+   return;
+
frob_text(>core_layout, set_memory_ro);
frob_rodata(>core_layout, set_memory_ro);
frob_text(>init_layout, set_memory_ro);
@@ -1951,6 +1957,9 @@ void set_all_modules_text_rw(void)
 {
struct module *mod;
 
+   if (!rodata_enabled)
+   return;
+
mutex_lock(_mutex);
list_for_each_entry_rcu(mod, , list) {
if (mod->state == MODULE_STATE_UNFORMED)
@@ -1967,6 +1976,9 @@ void set_all_modules_text_ro(void)
 {
struct module *mod;
 
+   if (!rodata_enabled)
+   return;
+
mutex_lock(_mutex);
list_for_each_entry_rcu(mod, , list) {
if (mod->state == MODULE_STATE_UNFORMED)
@@ -1980,10 +1992,12 @@ void set_all_modules_text_ro(void)
 
 static void disable_ro_nx(const struct module_layout *layout)
 {
-   frob_text(layout, set_memory_rw);
-   frob_rodata(layout, set_memory_rw);
+   if (rodata_enabled) {
+   frob_text(layout, set_memory_rw);
+   frob_rodata(layout, set_memory_rw);
+   frob_ro_after_init(layout, set_memory_rw);
+   }
frob_rodata(layout, set_memory_x);
-   frob_ro_after_init(layout, set_memory_rw);
frob_ro_after_init(layout, set_memory_x);
frob_writable_data(layout, set_memory_x);
 }
-- 
2.10.0

Re: [PATCH 09/16] ARM: BCM: use generic API for enabling SCU

[Florian Fainelli]

Le 13/11/2016 à 21:02, Pankaj Dubey a écrit :
> Now as we have of_scu_enable which takes care of mapping
> scu base from DT, lets use it.
> 
> CC: Florian Fainelli 
> CC: Ray Jui 
> CC: Scott Branden 
> CC: bcm-kernel-feedback-l...@broadcom.com
> Signed-off-by: Pankaj Dubey 

Reviewed-by: Florian Fainelli 

Let me know if I need to pick this and submit via ARM SoC pull requests,
thanks!
-- 
Florian

Re: [PATCH 09/16] ARM: BCM: use generic API for enabling SCU

[Florian Fainelli]

Le 13/11/2016 à 21:02, Pankaj Dubey a écrit :
> Now as we have of_scu_enable which takes care of mapping
> scu base from DT, lets use it.
> 
> CC: Florian Fainelli 
> CC: Ray Jui 
> CC: Scott Branden 
> CC: bcm-kernel-feedback-l...@broadcom.com
> Signed-off-by: Pankaj Dubey 

Reviewed-by: Florian Fainelli 

Let me know if I need to pick this and submit via ARM SoC pull requests,
thanks!
-- 
Florian

linux-next: manual merge of the akpm-current tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/memcontrol.c

between commit:

  308167fcb330 ("mm/memcg: Convert to hotplug state machine")

from the tip tree and commit:

  2558c318449d ("mm: memcontrol: use special workqueue for creating per-memcg 
caches")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/memcontrol.c
index 6c2043509fb5,91dfc7c5ce8f..
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -5774,8 -5785,18 +5776,19 @@@ static int __init mem_cgroup_init(void
  {
int cpu, node;
  
+ #ifndef CONFIG_SLOB
+   /*
+* Kmem cache creation is mostly done with the slab_mutex held,
+* so use a special workqueue to avoid stalling all worker
+* threads in case lots of cgroups are created simultaneously.
+*/
+   memcg_kmem_cache_create_wq =
+   alloc_ordered_workqueue("memcg_kmem_cache_create", 0);
+   BUG_ON(!memcg_kmem_cache_create_wq);
+ #endif
+ 
 -  hotcpu_notifier(memcg_cpu_hotplug_callback, 0);
 +  cpuhp_setup_state_nocalls(CPUHP_MM_MEMCQ_DEAD, "mm/memctrl:dead", NULL,
 +memcg_hotplug_cpu_dead);
  
for_each_possible_cpu(cpu)
INIT_WORK(_cpu_ptr(_stock, cpu)->work,

linux-next: manual merge of the akpm-current tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/memcontrol.c

between commit:

  308167fcb330 ("mm/memcg: Convert to hotplug state machine")

from the tip tree and commit:

  2558c318449d ("mm: memcontrol: use special workqueue for creating per-memcg 
caches")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/memcontrol.c
index 6c2043509fb5,91dfc7c5ce8f..
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -5774,8 -5785,18 +5776,19 @@@ static int __init mem_cgroup_init(void
  {
int cpu, node;
  
+ #ifndef CONFIG_SLOB
+   /*
+* Kmem cache creation is mostly done with the slab_mutex held,
+* so use a special workqueue to avoid stalling all worker
+* threads in case lots of cgroups are created simultaneously.
+*/
+   memcg_kmem_cache_create_wq =
+   alloc_ordered_workqueue("memcg_kmem_cache_create", 0);
+   BUG_ON(!memcg_kmem_cache_create_wq);
+ #endif
+ 
 -  hotcpu_notifier(memcg_cpu_hotplug_callback, 0);
 +  cpuhp_setup_state_nocalls(CPUHP_MM_MEMCQ_DEAD, "mm/memctrl:dead", NULL,
 +memcg_hotplug_cpu_dead);
  
for_each_possible_cpu(cpu)
INIT_WORK(_cpu_ptr(_stock, cpu)->work,

Re: [PATCH V3 1/2] mm: move vma_is_anonymous check within pmd_move_must_withdraw

[Balbir Singh]

On 14/11/16 02:00, Aneesh Kumar K.V wrote:
> Architectures like ppc64 want to use page table deposit/withraw
> even with huge pmd dax entries. Allow arch to override the
> vma_is_anonymous check by moving that to pmd_move_must_withdraw
> function
> 

I think the changelog can be reworded a bit

Independent of whether the vma is for anonymous memory, some arches
like ppc64 would like to override pmd_move_must_withdraw(). One option
is to encapsulate the vma_is_anonymous() check for general architectures
inside pmd_move_must_withdraw() so that is always called and architectures
that need unconditional overriding can override this function. ppc64
needs to override the function when the MMU is configured to use hash
PTE's.

What do you think?

Balbir Singh.

Re: [PATCH V3 1/2] mm: move vma_is_anonymous check within pmd_move_must_withdraw

[Balbir Singh]

On 14/11/16 02:00, Aneesh Kumar K.V wrote:
> Architectures like ppc64 want to use page table deposit/withraw
> even with huge pmd dax entries. Allow arch to override the
> vma_is_anonymous check by moving that to pmd_move_must_withdraw
> function
> 

I think the changelog can be reworded a bit

Independent of whether the vma is for anonymous memory, some arches
like ppc64 would like to override pmd_move_must_withdraw(). One option
is to encapsulate the vma_is_anonymous() check for general architectures
inside pmd_move_must_withdraw() so that is always called and architectures
that need unconditional overriding can override this function. ppc64
needs to override the function when the MMU is configured to use hash
PTE's.

What do you think?

Balbir Singh.

Re: [PATCH v2] inotify: Convert to using per-namespace limits

[Serge E. Hallyn]

On Tue, Oct 11, 2016 at 10:36:22AM +0300, Nikolay Borisov wrote:
> This patchset converts inotify to using the newly introduced
> per-userns sysctl infrastructure.
> 
> Currently the inotify instances/watches are being accounted in the
> user_struct structure. This means that in setups where multiple
> users in unprivileged containers map to the same underlying
> real user (i.e. pointing to the same user_struct) the inotify limits
> are going to be shared as well, allowing one user(or application) to exhaust
> all others limits.
> 
> Fix this by switching the inotify sysctls to using the
> per-namespace/per-user limits. This will allow the server admin to
> set sensible global limits, which can further be tuned inside every
> individual user namespace. Additionally, in order to preserve the
> sysctl ABI make the existing inotify instances/watches sysctls
> modify the values of the initial user namespace.
> 
> Signed-off-by: Nikolay Borisov 

If I'm reading the existing ucounts code correctly, this looks
good, thanks.

Acked-by: Serge Hallyn 


> ---
> 
> So here is a revised version which retains the existing sysctls,
> and hooks them to the init_user_ns values. 
> 
>  fs/notify/inotify/inotify.h  | 17 +
>  fs/notify/inotify/inotify_fsnotify.c |  6 ++
>  fs/notify/inotify/inotify_user.c | 34 +-
>  include/linux/fsnotify_backend.h |  3 ++-
>  include/linux/sched.h|  4 
>  include/linux/user_namespace.h   |  4 
>  kernel/ucount.c  |  6 +-
>  7 files changed, 47 insertions(+), 27 deletions(-)
> 
> diff --git a/fs/notify/inotify/inotify.h b/fs/notify/inotify/inotify.h
> index ed855ef6f077..b5536f8ad3e0 100644
> --- a/fs/notify/inotify/inotify.h
> +++ b/fs/notify/inotify/inotify.h
> @@ -30,3 +30,20 @@ extern int inotify_handle_event(struct fsnotify_group 
> *group,
>   const unsigned char *file_name, u32 cookie);
>  
>  extern const struct fsnotify_ops inotify_fsnotify_ops;
> +
> +#ifdef CONFIG_INOTIFY_USER
> +static void dec_inotify_instances(struct ucounts *ucounts)
> +{
> + dec_ucount(ucounts, UCOUNT_INOTIFY_INSTANCES);
> +}
> +
> +static struct ucounts *inc_inotify_watches(struct ucounts *ucounts)
> +{
> + return inc_ucount(ucounts->ns, ucounts->uid, UCOUNT_INOTIFY_WATCHES);
> +}
> +
> +static void dec_inotify_watches(struct ucounts *ucounts)
> +{
> + dec_ucount(ucounts, UCOUNT_INOTIFY_WATCHES);
> +}
> +#endif
> diff --git a/fs/notify/inotify/inotify_fsnotify.c 
> b/fs/notify/inotify/inotify_fsnotify.c
> index 2cd900c2c737..1e6b3cfc2cfd 100644
> --- a/fs/notify/inotify/inotify_fsnotify.c
> +++ b/fs/notify/inotify/inotify_fsnotify.c
> @@ -165,10 +165,8 @@ static void inotify_free_group_priv(struct 
> fsnotify_group *group)
>   /* ideally the idr is empty and we won't hit the BUG in the callback */
>   idr_for_each(>inotify_data.idr, idr_callback, group);
>   idr_destroy(>inotify_data.idr);
> - if (group->inotify_data.user) {
> - atomic_dec(>inotify_data.user->inotify_devs);
> - free_uid(group->inotify_data.user);
> - }
> + if (group->inotify_data.ucounts)
> + dec_inotify_instances(group->inotify_data.ucounts);
>  }
>  
>  static void inotify_free_event(struct fsnotify_event *fsn_event)
> diff --git a/fs/notify/inotify/inotify_user.c 
> b/fs/notify/inotify/inotify_user.c
> index b8d08d0d0a4d..7d769a824742 100644
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -44,10 +44,8 @@
>  
>  #include 
>  
> -/* these are configurable via /proc/sys/fs/inotify/ */
> -static int inotify_max_user_instances __read_mostly;
> +/* configurable via /proc/sys/fs/inotify/ */
>  static int inotify_max_queued_events __read_mostly;
> -static int inotify_max_user_watches __read_mostly;
>  
>  static struct kmem_cache *inotify_inode_mark_cachep __read_mostly;
>  
> @@ -60,7 +58,7 @@ static int zero;
>  struct ctl_table inotify_table[] = {
>   {
>   .procname   = "max_user_instances",
> - .data   = _max_user_instances,
> + .data   = 
> _user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES],
>   .maxlen = sizeof(int),
>   .mode   = 0644,
>   .proc_handler   = proc_dointvec_minmax,
> @@ -68,7 +66,7 @@ struct ctl_table inotify_table[] = {
>   },
>   {
>   .procname   = "max_user_watches",
> - .data   = _max_user_watches,
> + .data   = 
> _user_ns.ucount_max[UCOUNT_INOTIFY_WATCHES],
>   .maxlen = sizeof(int),
>   .mode   = 0644,
>   .proc_handler   = proc_dointvec_minmax,
> @@ -500,7 +498,7 @@ void inotify_ignored_and_remove_idr(struct fsnotify_mark 
> *fsn_mark,
>   /* remove this mark from the idr */
>   

Re: [PATCH v2] inotify: Convert to using per-namespace limits

[Serge E. Hallyn]

On Tue, Oct 11, 2016 at 10:36:22AM +0300, Nikolay Borisov wrote:
> This patchset converts inotify to using the newly introduced
> per-userns sysctl infrastructure.
> 
> Currently the inotify instances/watches are being accounted in the
> user_struct structure. This means that in setups where multiple
> users in unprivileged containers map to the same underlying
> real user (i.e. pointing to the same user_struct) the inotify limits
> are going to be shared as well, allowing one user(or application) to exhaust
> all others limits.
> 
> Fix this by switching the inotify sysctls to using the
> per-namespace/per-user limits. This will allow the server admin to
> set sensible global limits, which can further be tuned inside every
> individual user namespace. Additionally, in order to preserve the
> sysctl ABI make the existing inotify instances/watches sysctls
> modify the values of the initial user namespace.
> 
> Signed-off-by: Nikolay Borisov 

If I'm reading the existing ucounts code correctly, this looks
good, thanks.

Acked-by: Serge Hallyn 


> ---
> 
> So here is a revised version which retains the existing sysctls,
> and hooks them to the init_user_ns values. 
> 
>  fs/notify/inotify/inotify.h  | 17 +
>  fs/notify/inotify/inotify_fsnotify.c |  6 ++
>  fs/notify/inotify/inotify_user.c | 34 +-
>  include/linux/fsnotify_backend.h |  3 ++-
>  include/linux/sched.h|  4 
>  include/linux/user_namespace.h   |  4 
>  kernel/ucount.c  |  6 +-
>  7 files changed, 47 insertions(+), 27 deletions(-)
> 
> diff --git a/fs/notify/inotify/inotify.h b/fs/notify/inotify/inotify.h
> index ed855ef6f077..b5536f8ad3e0 100644
> --- a/fs/notify/inotify/inotify.h
> +++ b/fs/notify/inotify/inotify.h
> @@ -30,3 +30,20 @@ extern int inotify_handle_event(struct fsnotify_group 
> *group,
>   const unsigned char *file_name, u32 cookie);
>  
>  extern const struct fsnotify_ops inotify_fsnotify_ops;
> +
> +#ifdef CONFIG_INOTIFY_USER
> +static void dec_inotify_instances(struct ucounts *ucounts)
> +{
> + dec_ucount(ucounts, UCOUNT_INOTIFY_INSTANCES);
> +}
> +
> +static struct ucounts *inc_inotify_watches(struct ucounts *ucounts)
> +{
> + return inc_ucount(ucounts->ns, ucounts->uid, UCOUNT_INOTIFY_WATCHES);
> +}
> +
> +static void dec_inotify_watches(struct ucounts *ucounts)
> +{
> + dec_ucount(ucounts, UCOUNT_INOTIFY_WATCHES);
> +}
> +#endif
> diff --git a/fs/notify/inotify/inotify_fsnotify.c 
> b/fs/notify/inotify/inotify_fsnotify.c
> index 2cd900c2c737..1e6b3cfc2cfd 100644
> --- a/fs/notify/inotify/inotify_fsnotify.c
> +++ b/fs/notify/inotify/inotify_fsnotify.c
> @@ -165,10 +165,8 @@ static void inotify_free_group_priv(struct 
> fsnotify_group *group)
>   /* ideally the idr is empty and we won't hit the BUG in the callback */
>   idr_for_each(>inotify_data.idr, idr_callback, group);
>   idr_destroy(>inotify_data.idr);
> - if (group->inotify_data.user) {
> - atomic_dec(>inotify_data.user->inotify_devs);
> - free_uid(group->inotify_data.user);
> - }
> + if (group->inotify_data.ucounts)
> + dec_inotify_instances(group->inotify_data.ucounts);
>  }
>  
>  static void inotify_free_event(struct fsnotify_event *fsn_event)
> diff --git a/fs/notify/inotify/inotify_user.c 
> b/fs/notify/inotify/inotify_user.c
> index b8d08d0d0a4d..7d769a824742 100644
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -44,10 +44,8 @@
>  
>  #include 
>  
> -/* these are configurable via /proc/sys/fs/inotify/ */
> -static int inotify_max_user_instances __read_mostly;
> +/* configurable via /proc/sys/fs/inotify/ */
>  static int inotify_max_queued_events __read_mostly;
> -static int inotify_max_user_watches __read_mostly;
>  
>  static struct kmem_cache *inotify_inode_mark_cachep __read_mostly;
>  
> @@ -60,7 +58,7 @@ static int zero;
>  struct ctl_table inotify_table[] = {
>   {
>   .procname   = "max_user_instances",
> - .data   = _max_user_instances,
> + .data   = 
> _user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES],
>   .maxlen = sizeof(int),
>   .mode   = 0644,
>   .proc_handler   = proc_dointvec_minmax,
> @@ -68,7 +66,7 @@ struct ctl_table inotify_table[] = {
>   },
>   {
>   .procname   = "max_user_watches",
> - .data   = _max_user_watches,
> + .data   = 
> _user_ns.ucount_max[UCOUNT_INOTIFY_WATCHES],
>   .maxlen = sizeof(int),
>   .mode   = 0644,
>   .proc_handler   = proc_dointvec_minmax,
> @@ -500,7 +498,7 @@ void inotify_ignored_and_remove_idr(struct fsnotify_mark 
> *fsn_mark,
>   /* remove this mark from the idr */
>   inotify_remove_from_idr(group, i_mark);
>  
> - 

Re: module: extend 'rodata=off' boot cmdline parameter to module mappings

[AKASHI Takahiro]

On Sat, Nov 12, 2016 at 07:04:22PM -0800, Jessica Yu wrote:
> +++ AKASHI Takahiro [21/10/16 10:13 +0900]:
> >The current "rodata=off" parameter disables read-only kernel mappings
> >under CONFIG_DEBUG_RODATA:
> >   commit d2aa1acad22f ("mm/init: Add 'rodata=off' boot cmdline parameter
> >   to disable read-only kernel mappings")
> >
> >This patch is a logical extension to module mappings ie. read-only mappings
> >at module loading can be disabled even if CONFIG_DEBUG_SET_MODULE_RONX
> >(mainly for debug use). Please note, however, that it only affects RO/RW
> >permissions, keeping NX set.
> >
> >This is the first step to make CONFIG_DEBUG_SET_MODULE_RONX mandatory
> >(always-on) in the future as CONFIG_DEBUG_RODATA on x86 and arm64.
> >
> >Suggested-by: Mark Rutland 
> >Signed-off-by: AKASHI Takahiro 
> >Reviewed-by: Kees Cook 
> >Cc: Rusty Russell 
> >---
> >v2:
> > * use CONFIG_DEBUG_RODATA/SET_MODULE_RONX guards better where appropriate
> > * make "rodata_enabled" variable as __ro_after_init
> >v1:
> > * remove RFC's "module_ronx=" and merge it with "rodata="
> > * always keep NX set if CONFIG_SET_MODULE_RONX
> >
> >include/linux/init.h |  3 +++
> >init/main.c  |  7 +--
> >kernel/module.c  | 21 ++---
> >3 files changed, 26 insertions(+), 5 deletions(-)
> >
> >diff --git a/include/linux/init.h b/include/linux/init.h
> >index e30104c..885c3e6 100644
> >--- a/include/linux/init.h
> >+++ b/include/linux/init.h
> >@@ -126,6 +126,9 @@ void prepare_namespace(void);
> >void __init load_default_modules(void);
> >int __init init_rootfs(void);
> >
> >+#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
> >+extern bool rodata_enabled;
> >+#endif
> >#ifdef CONFIG_DEBUG_RODATA
> >void mark_rodata_ro(void);
> >#endif
> >diff --git a/init/main.c b/init/main.c
> >index 2858be7..959a242 100644
> >--- a/init/main.c
> >+++ b/init/main.c
> >@@ -81,6 +81,7 @@
> >#include 
> >#include 
> >#include 
> >+#include 
> >
> >#include 
> >#include 
> >@@ -914,14 +915,16 @@ static int try_to_run_init_process(const char 
> >*init_filename)
> >
> >static noinline void __init kernel_init_freeable(void);
> >
> >-#ifdef CONFIG_DEBUG_RODATA
> >-static bool rodata_enabled = true;
> >+#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_SET_MODULE_RONX)
> >+bool rodata_enabled __ro_after_init = true;
> >static int __init set_debug_rodata(char *str)
> >{
> > return strtobool(str, _enabled);
> >}
> >__setup("rodata=", set_debug_rodata);
> >+#endif
> >
> >+#ifdef CONFIG_DEBUG_RODATA
> >static void mark_readonly(void)
> >{
> > if (rodata_enabled)
> >diff --git a/kernel/module.c b/kernel/module.c
> >index f57dd63..34d1880 100644
> >--- a/kernel/module.c
> >+++ b/kernel/module.c
> >@@ -1910,6 +1910,9 @@ static void frob_writable_data(const struct 
> >module_layout *layout,
> >/* livepatching wants to disable read-only so it can frob module. */
> >void module_disable_ro(const struct module *mod)
> >{
> >+if (!rodata_enabled)
> >+return;
> >+
> > frob_text(>core_layout, set_memory_rw);
> > frob_rodata(>core_layout, set_memory_rw);
> > frob_ro_after_init(>core_layout, set_memory_rw);
> >@@ -1919,6 +1922,9 @@ void module_disable_ro(const struct module *mod)
> >
> >void module_enable_ro(const struct module *mod, bool after_init)
> >{
> >+if (!rodata_enabled)
> >+return;
> >+
> > frob_text(>core_layout, set_memory_ro);
> > frob_rodata(>core_layout, set_memory_ro);
> > frob_text(>init_layout, set_memory_ro);
> >@@ -1951,6 +1957,9 @@ void set_all_modules_text_rw(void)
> >{
> > struct module *mod;
> >
> >+if (!rodata_enabled)
> >+return;
> >+
> > mutex_lock(_mutex);
> > list_for_each_entry_rcu(mod, , list) {
> > if (mod->state == MODULE_STATE_UNFORMED)
> >@@ -1967,6 +1976,9 @@ void set_all_modules_text_ro(void)
> >{
> > struct module *mod;
> >
> >+if (!rodata_enabled)
> >+return;
> >+
> > mutex_lock(_mutex);
> > list_for_each_entry_rcu(mod, , list) {
> > if (mod->state == MODULE_STATE_UNFORMED)
> >@@ -1980,10 +1992,13 @@ void set_all_modules_text_ro(void)
> >
> >static void disable_ro_nx(const struct module_layout *layout)
> >{
> >-frob_text(layout, set_memory_rw);
> >-frob_rodata(layout, set_memory_rw);
> >+if (rodata_enabled) {
> >+frob_text(layout, set_memory_rw);
> >+frob_rodata(layout, set_memory_rw);
> >+}
> > frob_rodata(layout, set_memory_x);
> >-frob_ro_after_init(layout, set_memory_rw);
> >+if (rodata_enabled)
> >+frob_ro_after_init(layout, set_memory_rw);
> 
> Why not merge this hunk with the previous if (rodata_enabled) check?
> I think it's more readable that way. In any case, the rest of the
> patch looks good to me.

Sure. See my v3.

Thanks,
-Takahiro AKASHI

> Jessica

Re: module: extend 'rodata=off' boot cmdline parameter to module mappings

[AKASHI Takahiro]

On Sat, Nov 12, 2016 at 07:04:22PM -0800, Jessica Yu wrote:
> +++ AKASHI Takahiro [21/10/16 10:13 +0900]:
> >The current "rodata=off" parameter disables read-only kernel mappings
> >under CONFIG_DEBUG_RODATA:
> >   commit d2aa1acad22f ("mm/init: Add 'rodata=off' boot cmdline parameter
> >   to disable read-only kernel mappings")
> >
> >This patch is a logical extension to module mappings ie. read-only mappings
> >at module loading can be disabled even if CONFIG_DEBUG_SET_MODULE_RONX
> >(mainly for debug use). Please note, however, that it only affects RO/RW
> >permissions, keeping NX set.
> >
> >This is the first step to make CONFIG_DEBUG_SET_MODULE_RONX mandatory
> >(always-on) in the future as CONFIG_DEBUG_RODATA on x86 and arm64.
> >
> >Suggested-by: Mark Rutland 
> >Signed-off-by: AKASHI Takahiro 
> >Reviewed-by: Kees Cook 
> >Cc: Rusty Russell 
> >---
> >v2:
> > * use CONFIG_DEBUG_RODATA/SET_MODULE_RONX guards better where appropriate
> > * make "rodata_enabled" variable as __ro_after_init
> >v1:
> > * remove RFC's "module_ronx=" and merge it with "rodata="
> > * always keep NX set if CONFIG_SET_MODULE_RONX
> >
> >include/linux/init.h |  3 +++
> >init/main.c  |  7 +--
> >kernel/module.c  | 21 ++---
> >3 files changed, 26 insertions(+), 5 deletions(-)
> >
> >diff --git a/include/linux/init.h b/include/linux/init.h
> >index e30104c..885c3e6 100644
> >--- a/include/linux/init.h
> >+++ b/include/linux/init.h
> >@@ -126,6 +126,9 @@ void prepare_namespace(void);
> >void __init load_default_modules(void);
> >int __init init_rootfs(void);
> >
> >+#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
> >+extern bool rodata_enabled;
> >+#endif
> >#ifdef CONFIG_DEBUG_RODATA
> >void mark_rodata_ro(void);
> >#endif
> >diff --git a/init/main.c b/init/main.c
> >index 2858be7..959a242 100644
> >--- a/init/main.c
> >+++ b/init/main.c
> >@@ -81,6 +81,7 @@
> >#include 
> >#include 
> >#include 
> >+#include 
> >
> >#include 
> >#include 
> >@@ -914,14 +915,16 @@ static int try_to_run_init_process(const char 
> >*init_filename)
> >
> >static noinline void __init kernel_init_freeable(void);
> >
> >-#ifdef CONFIG_DEBUG_RODATA
> >-static bool rodata_enabled = true;
> >+#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_SET_MODULE_RONX)
> >+bool rodata_enabled __ro_after_init = true;
> >static int __init set_debug_rodata(char *str)
> >{
> > return strtobool(str, _enabled);
> >}
> >__setup("rodata=", set_debug_rodata);
> >+#endif
> >
> >+#ifdef CONFIG_DEBUG_RODATA
> >static void mark_readonly(void)
> >{
> > if (rodata_enabled)
> >diff --git a/kernel/module.c b/kernel/module.c
> >index f57dd63..34d1880 100644
> >--- a/kernel/module.c
> >+++ b/kernel/module.c
> >@@ -1910,6 +1910,9 @@ static void frob_writable_data(const struct 
> >module_layout *layout,
> >/* livepatching wants to disable read-only so it can frob module. */
> >void module_disable_ro(const struct module *mod)
> >{
> >+if (!rodata_enabled)
> >+return;
> >+
> > frob_text(>core_layout, set_memory_rw);
> > frob_rodata(>core_layout, set_memory_rw);
> > frob_ro_after_init(>core_layout, set_memory_rw);
> >@@ -1919,6 +1922,9 @@ void module_disable_ro(const struct module *mod)
> >
> >void module_enable_ro(const struct module *mod, bool after_init)
> >{
> >+if (!rodata_enabled)
> >+return;
> >+
> > frob_text(>core_layout, set_memory_ro);
> > frob_rodata(>core_layout, set_memory_ro);
> > frob_text(>init_layout, set_memory_ro);
> >@@ -1951,6 +1957,9 @@ void set_all_modules_text_rw(void)
> >{
> > struct module *mod;
> >
> >+if (!rodata_enabled)
> >+return;
> >+
> > mutex_lock(_mutex);
> > list_for_each_entry_rcu(mod, , list) {
> > if (mod->state == MODULE_STATE_UNFORMED)
> >@@ -1967,6 +1976,9 @@ void set_all_modules_text_ro(void)
> >{
> > struct module *mod;
> >
> >+if (!rodata_enabled)
> >+return;
> >+
> > mutex_lock(_mutex);
> > list_for_each_entry_rcu(mod, , list) {
> > if (mod->state == MODULE_STATE_UNFORMED)
> >@@ -1980,10 +1992,13 @@ void set_all_modules_text_ro(void)
> >
> >static void disable_ro_nx(const struct module_layout *layout)
> >{
> >-frob_text(layout, set_memory_rw);
> >-frob_rodata(layout, set_memory_rw);
> >+if (rodata_enabled) {
> >+frob_text(layout, set_memory_rw);
> >+frob_rodata(layout, set_memory_rw);
> >+}
> > frob_rodata(layout, set_memory_x);
> >-frob_ro_after_init(layout, set_memory_rw);
> >+if (rodata_enabled)
> >+frob_ro_after_init(layout, set_memory_rw);
> 
> Why not merge this hunk with the previous if (rodata_enabled) check?
> I think it's more readable that way. In any case, the rest of the
> patch looks good to me.

Sure. See my v3.

Thanks,
-Takahiro AKASHI

> Jessica

Re: [PATCH v2 1/2] arm64: dts: Add level for cpu dt node for exynos7

[Alim Akhtar]

Hi Krzysztof,

On 11/13/2016 12:43 AM, Krzysztof Kozlowski wrote:

On Sat, Nov 12, 2016 at 6:00 PM, Alim Akhtar  wrote:

Hi Javier,

On Sat, Nov 12, 2016 at 7:54 PM, Javier Martinez Canillas
 wrote:

Hello Alim,

On 11/12/2016 07:17 AM, Alim Akhtar wrote:

This patch adds level for cpu dt node, so that these levels can be used


Do you mean s/level/label here? I'm asking because you are using level
consistently in the subject line and commit message but I'm not sure
what it means in this context.



Ah!! my bad. Its __label__. If required, will respin.
Thanks for review.


I think there is no need of respin because this should be squashed
with previous patch. This is quite small and there are no functional
changes here (labels are transparent, except of course conflict
cases). Without the 2/2,  this patch does not have much sense yet.

The reason why I kept the _label_ changes are separate patch is to keep 
git bisect happy. If you think there won't be a case for that, then lets 
merge the two in single patch.

Let me know if you want me to respin or you will take care.


Best regards,
Krzysztof

Re: [PATCH] IB/usnic: simplify IS_ERR_OR_NULL to IS_ERR

[Leon Romanovsky]

On Fri, Nov 11, 2016 at 08:04:26PM +0100, Julia Lawall wrote:
> The function usnic_ib_qp_grp_get_chunk only returns an ERR_PTR value or a
> valid pointer, never NULL.  The same is true of get_qp_res_chunk, which
> just returns the result of calling usnic_ib_qp_grp_get_chunk.  Simplify
> IS_ERR_OR_NULL to IS_ERR in both cases.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // 
> @@
> expression t,e;
> @@
>
> t = \(usnic_ib_qp_grp_get_chunk(...)\|get_qp_res_chunk(...)\)
> ... when != t=e
> - IS_ERR_OR_NULL(t)
> + IS_ERR(t)
>
> @@
> expression t,e,e1;
> @@
>
> t = \(usnic_ib_qp_grp_get_chunk(...)\|get_qp_res_chunk(...)\)
> ... when != t=e
> ?- t ? PTR_ERR(t) : e1
> + PTR_ERR(t)
> ... when any
> // 
>
> Signed-off-by: Julia Lawall 

Thanks, Julia.
Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] arm64: dts: Add level for cpu dt node for exynos7

[Alim Akhtar]

Hi Krzysztof,

On 11/13/2016 12:43 AM, Krzysztof Kozlowski wrote:

On Sat, Nov 12, 2016 at 6:00 PM, Alim Akhtar  wrote:

Hi Javier,

On Sat, Nov 12, 2016 at 7:54 PM, Javier Martinez Canillas
 wrote:

Hello Alim,

On 11/12/2016 07:17 AM, Alim Akhtar wrote:

This patch adds level for cpu dt node, so that these levels can be used


Do you mean s/level/label here? I'm asking because you are using level
consistently in the subject line and commit message but I'm not sure
what it means in this context.



Ah!! my bad. Its __label__. If required, will respin.
Thanks for review.


I think there is no need of respin because this should be squashed
with previous patch. This is quite small and there are no functional
changes here (labels are transparent, except of course conflict
cases). Without the 2/2,  this patch does not have much sense yet.

The reason why I kept the _label_ changes are separate patch is to keep 
git bisect happy. If you think there won't be a case for that, then lets 
merge the two in single patch.

Let me know if you want me to respin or you will take care.


Best regards,
Krzysztof

Re: [PATCH] IB/usnic: simplify IS_ERR_OR_NULL to IS_ERR

[Leon Romanovsky]

On Fri, Nov 11, 2016 at 08:04:26PM +0100, Julia Lawall wrote:
> The function usnic_ib_qp_grp_get_chunk only returns an ERR_PTR value or a
> valid pointer, never NULL.  The same is true of get_qp_res_chunk, which
> just returns the result of calling usnic_ib_qp_grp_get_chunk.  Simplify
> IS_ERR_OR_NULL to IS_ERR in both cases.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // 
> @@
> expression t,e;
> @@
>
> t = \(usnic_ib_qp_grp_get_chunk(...)\|get_qp_res_chunk(...)\)
> ... when != t=e
> - IS_ERR_OR_NULL(t)
> + IS_ERR(t)
>
> @@
> expression t,e,e1;
> @@
>
> t = \(usnic_ib_qp_grp_get_chunk(...)\|get_qp_res_chunk(...)\)
> ... when != t=e
> ?- t ? PTR_ERR(t) : e1
> + PTR_ERR(t)
> ... when any
> // 
>
> Signed-off-by: Julia Lawall 

Thanks, Julia.
Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

Re: [PATCH v6 3/3] x86/kvm: Add AVX512_4VNNIW and AVX512_4FMAPS support

[Borislav Petkov]

On Mon, Nov 14, 2016 at 09:41:04AM +0800, He Chen wrote:
> Yep, Luwei wrote it and I send it on behalf of him.

Then it needs to have the following format so that tools can pick up the
proper author:

"From: Luwei ...



Signed-off-by: He Chen...
Signed-off-by: Luwei...
...
"

git format-patch gives that formatting.

If you want to change the ownership, do the following on the local
commit:

$ git commit --amend --author="Luwei Kang "

in case it lists you locally as author.

HTH.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH v6 3/3] x86/kvm: Add AVX512_4VNNIW and AVX512_4FMAPS support

[Borislav Petkov]

On Mon, Nov 14, 2016 at 09:41:04AM +0800, He Chen wrote:
> Yep, Luwei wrote it and I send it on behalf of him.

Then it needs to have the following format so that tools can pick up the
proper author:

"From: Luwei ...



Signed-off-by: He Chen...
Signed-off-by: Luwei...
...
"

git format-patch gives that formatting.

If you want to change the ownership, do the following on the local
commit:

$ git commit --amend --author="Luwei Kang "

in case it lists you locally as author.

HTH.

-- 
Regards/Gruss,
Boris.

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

[PATCH] [STYLE]staging:xgifb:vb_util.h No space after cast

[Walt Feasel]

Make suggested modification from checkpatch in reference
to: CHECK: No space is necessary after a cast

Signed-off-by: Walt Feasel 
---
 drivers/staging/xgifb/vb_util.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/xgifb/vb_util.h b/drivers/staging/xgifb/vb_util.h
index 08db58b..052694e 100644
--- a/drivers/staging/xgifb/vb_util.h
+++ b/drivers/staging/xgifb/vb_util.h
@@ -18,7 +18,7 @@ static inline void xgifb_reg_and_or(unsigned long port, u8 
index,
u8 temp;
 
temp = xgifb_reg_get(port, index);
-   temp = (u8) ((temp & data_and) | data_or);
+   temp = (u8)((temp & data_and) | data_or);
xgifb_reg_set(port, index, temp);
 }
 
@@ -28,7 +28,7 @@ static inline void xgifb_reg_and(unsigned long port, u8 index,
u8 temp;
 
temp = xgifb_reg_get(port, index);
-   temp = (u8) (temp & data_and);
+   temp = (u8)(temp & data_and);
xgifb_reg_set(port, index, temp);
 }
 
-- 
2.1.4

[PATCH] [STYLE]staging:xgifb:vb_util.h No space after cast

[Walt Feasel]

Make suggested modification from checkpatch in reference
to: CHECK: No space is necessary after a cast

Signed-off-by: Walt Feasel 
---
 drivers/staging/xgifb/vb_util.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/xgifb/vb_util.h b/drivers/staging/xgifb/vb_util.h
index 08db58b..052694e 100644
--- a/drivers/staging/xgifb/vb_util.h
+++ b/drivers/staging/xgifb/vb_util.h
@@ -18,7 +18,7 @@ static inline void xgifb_reg_and_or(unsigned long port, u8 
index,
u8 temp;
 
temp = xgifb_reg_get(port, index);
-   temp = (u8) ((temp & data_and) | data_or);
+   temp = (u8)((temp & data_and) | data_or);
xgifb_reg_set(port, index, temp);
 }
 
@@ -28,7 +28,7 @@ static inline void xgifb_reg_and(unsigned long port, u8 index,
u8 temp;
 
temp = xgifb_reg_get(port, index);
-   temp = (u8) (temp & data_and);
+   temp = (u8)(temp & data_and);
xgifb_reg_set(port, index, temp);
 }
 
-- 
2.1.4

Re: [PATCH 3.16 000/346] 3.16.39-rc1 review

[Guenter Roeck]

On 11/13/2016 04:14 PM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.16.39 release.
There are 346 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Nov 10 00:00:00 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 140 pass: 140 fail: 0
Qemu test results:
total: 99 pass: 99 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 3.16 000/346] 3.16.39-rc1 review

[Guenter Roeck]

On 11/13/2016 04:14 PM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.16.39 release.
There are 346 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Nov 10 00:00:00 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 140 pass: 140 fail: 0
Qemu test results:
total: 99 pass: 99 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter