Re: [PATCH] ARM: dts: uniphier: add NAND pinmux node

[Masahiro Yamada]

2016-04-15 19:35 GMT+09:00 Masahiro Yamada :
> Signed-off-by: Masahiro Yamada 
> ---
>


This patch was replaced with v2:

https://patchwork.kernel.org/patch/8895761/


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] ARM: dts: uniphier: add NAND pinmux node

[Masahiro Yamada]

2016-04-15 19:35 GMT+09:00 Masahiro Yamada :
> Signed-off-by: Masahiro Yamada 
> ---
>


This patch was replaced with v2:

https://patchwork.kernel.org/patch/8895761/


-- 
Best Regards
Masahiro Yamada

RE: [PATCH 2/2] dmaengine: vdma: Add clock support

[Appana Durga Kedareswara Rao]

Hi Moritz,

Thanks for the review...

> -Original Message-
> From: Moritz Fischer [mailto:moritz.fisc...@ettus.com]
> Sent: Thursday, April 21, 2016 12:09 AM
> To: Appana Durga Kedareswara Rao 
> Cc: Rob Herring ; pawel.m...@arm.com; Mark Rutland
> ; Ian Campbell ;
> Kumar Gala ; Michal Simek ;
> Soren Brinkmann ; Vinod Koul ;
> Dan Williams ; Appana Durga Kedareswara Rao
> ; Laurent Pinchart
> ; Luis de Bethencourt
> ; Anirudha Sarangi ; Punnaiah
> Choudary Kalluri ; Devicetree List
> ; linux-arm-kernel  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; dmaeng...@vger.kernel.org
> Subject: Re: [PATCH 2/2] dmaengine: vdma: Add clock support
>
> Hi,
>
> thanks for looking into this.
>
> On Wed, Apr 20, 2016 at 12:20 AM, Kedareswara rao Appana
>  wrote:
>
> > +static int xdma_clk_init(struct xilinx_dma_device *xdev, bool enable)
> > +{
> > +   int i = 0, ret;
> > +
> > +   for (i = 0; i < xdev->numclks; i++) {
> > +   if (enable) {
> > +   ret = clk_prepare_enable(xdev->clks[i]);
> > +   if (ret) {
> > +   dev_err(xdev->dev,
> > +   "failed to enable the axidma 
> > clock\n");
> > +   return ret;
>
> What happens to the ones you already turned on, if say the third fails?

Will fix in the next version of the patch...

Regards,
Kedar.
>
> Cheers,
>
> Moritz


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

RE: [PATCH 2/2] dmaengine: vdma: Add clock support

[Appana Durga Kedareswara Rao]

Hi Moritz,

Thanks for the review...

> -Original Message-
> From: Moritz Fischer [mailto:moritz.fisc...@ettus.com]
> Sent: Thursday, April 21, 2016 12:09 AM
> To: Appana Durga Kedareswara Rao 
> Cc: Rob Herring ; pawel.m...@arm.com; Mark Rutland
> ; Ian Campbell ;
> Kumar Gala ; Michal Simek ;
> Soren Brinkmann ; Vinod Koul ;
> Dan Williams ; Appana Durga Kedareswara Rao
> ; Laurent Pinchart
> ; Luis de Bethencourt
> ; Anirudha Sarangi ; Punnaiah
> Choudary Kalluri ; Devicetree List
> ; linux-arm-kernel  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; dmaeng...@vger.kernel.org
> Subject: Re: [PATCH 2/2] dmaengine: vdma: Add clock support
>
> Hi,
>
> thanks for looking into this.
>
> On Wed, Apr 20, 2016 at 12:20 AM, Kedareswara rao Appana
>  wrote:
>
> > +static int xdma_clk_init(struct xilinx_dma_device *xdev, bool enable)
> > +{
> > +   int i = 0, ret;
> > +
> > +   for (i = 0; i < xdev->numclks; i++) {
> > +   if (enable) {
> > +   ret = clk_prepare_enable(xdev->clks[i]);
> > +   if (ret) {
> > +   dev_err(xdev->dev,
> > +   "failed to enable the axidma 
> > clock\n");
> > +   return ret;
>
> What happens to the ones you already turned on, if say the third fails?

Will fix in the next version of the patch...

Regards,
Kedar.
>
> Cheers,
>
> Moritz


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

Re: [PATCH 2/4] net: thunderx: Add multiqset support for dataplane apps

[kbuild test robot]

Hi,

[auto build test ERROR on net/master]
[also build test ERROR on v4.6-rc4 next-20160420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/sunil-kovvuri-gmail-com/net-thunderx-Add-multiqset-support-for-DPDK/20160419-213640
config: x86_64-randconfig-s4-04211222 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/net/ethernet/cavium/thunder/nic_main.c: In function 
'nic_get_vf_pdev':
>> drivers/net/ethernet/cavium/thunder/nic_main.c:600:12: error: 'struct 
>> pci_dev' has no member named 'physfn'
  if (vfdev->physfn != pdev)
   ^

vim +600 drivers/net/ethernet/cavium/thunder/nic_main.c

   594  pci_read_config_word(pdev, pos + PCI_SRIOV_VF_DID, );
   595  
   596  vfdev = pci_get_device(vid, devid, NULL);
   597  for (; vfdev; vfdev = pci_get_device(vid, devid, vfdev)) {
   598  if (!vfdev->is_virtfn)
   599  continue;
 > 600  if (vfdev->physfn != pdev)
   601  continue;
   602  if (vf >= vf_en)
   603  continue;

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


.config.gz
Description: Binary data

Re: [PATCH 2/4] net: thunderx: Add multiqset support for dataplane apps

[kbuild test robot]

Hi,

[auto build test ERROR on net/master]
[also build test ERROR on v4.6-rc4 next-20160420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/sunil-kovvuri-gmail-com/net-thunderx-Add-multiqset-support-for-DPDK/20160419-213640
config: x86_64-randconfig-s4-04211222 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/net/ethernet/cavium/thunder/nic_main.c: In function 
'nic_get_vf_pdev':
>> drivers/net/ethernet/cavium/thunder/nic_main.c:600:12: error: 'struct 
>> pci_dev' has no member named 'physfn'
  if (vfdev->physfn != pdev)
   ^

vim +600 drivers/net/ethernet/cavium/thunder/nic_main.c

   594  pci_read_config_word(pdev, pos + PCI_SRIOV_VF_DID, );
   595  
   596  vfdev = pci_get_device(vid, devid, NULL);
   597  for (; vfdev; vfdev = pci_get_device(vid, devid, vfdev)) {
   598  if (!vfdev->is_virtfn)
   599  continue;
 > 600  if (vfdev->physfn != pdev)
   601  continue;
   602  if (vf >= vf_en)
   603  continue;

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


.config.gz
Description: Binary data

Re: [PATCH] thermal: qcom: tsens-8960: fix semicolon.cocci warnings

[Julia Lawall]

On Wed, 20 Apr 2016, Eduardo Valentin wrote:

> On Wed, Apr 06, 2016 at 08:14:34AM +0200, Julia Lawall wrote:
> > Remove unneeded semicolon.
> > 
> > Generated by: scripts/coccinelle/misc/semicolon.cocci
> > 
> > Signed-off-by: Fengguang Wu 
> > Signed-off-by: Julia Lawall 
> > ---
> > 
> >  tsens-8960.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- a/drivers/thermal/qcom/tsens-8960.c
> > +++ b/drivers/thermal/qcom/tsens-8960.c
> 
> To which tree this patch applies to?

Sorry, I should have preserved that information, but I don't have it any 
more.

julia

> > @@ -247,7 +247,7 @@ static inline int code_to_mdegC(u32 adc_
> > u32 slope;
> > int offset;
> >  
> > -   slope = thermal_zone_get_slope(s->tzd);;
> > +   slope = thermal_zone_get_slope(s->tzd);
> > offset = CAL_MDEGC - slope * s->offset;
> >  
> > return adc_code * slope + offset;
> 

Re: [PATCH] thermal: qcom: tsens-8960: fix semicolon.cocci warnings

[Julia Lawall]

On Wed, 20 Apr 2016, Eduardo Valentin wrote:

> On Wed, Apr 06, 2016 at 08:14:34AM +0200, Julia Lawall wrote:
> > Remove unneeded semicolon.
> > 
> > Generated by: scripts/coccinelle/misc/semicolon.cocci
> > 
> > Signed-off-by: Fengguang Wu 
> > Signed-off-by: Julia Lawall 
> > ---
> > 
> >  tsens-8960.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- a/drivers/thermal/qcom/tsens-8960.c
> > +++ b/drivers/thermal/qcom/tsens-8960.c
> 
> To which tree this patch applies to?

Sorry, I should have preserved that information, but I don't have it any 
more.

julia

> > @@ -247,7 +247,7 @@ static inline int code_to_mdegC(u32 adc_
> > u32 slope;
> > int offset;
> >  
> > -   slope = thermal_zone_get_slope(s->tzd);;
> > +   slope = thermal_zone_get_slope(s->tzd);
> > offset = CAL_MDEGC - slope * s->offset;
> >  
> > return adc_code * slope + offset;
> 

[PATCH] cpu/hotplug: handle unbalanced hotplug enable/disable

[Lianwei Wang]

Currently it just print a warning message but did not
reset cpu_hotplug_disabled when the enable/disable is
unbalanced. The unbalanced enable/disable will lead
the cpu hotplug work abnormally.

Reset it to 0 when an unablanced enable detected.

Signed-off-by: Lianwei Wang 
---
 kernel/cpu.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 6ea42e8da861..fef6caed77a3 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -243,6 +243,19 @@ void cpu_hotplug_done(void)
cpuhp_lock_release();
 }
 
+static void _cpu_hotplug_disable(void)
+{
+   cpu_hotplug_disabled++;
+}
+
+static void _cpu_hotplug_enable(void)
+{
+   if (--cpu_hotplug_disabled < 0) {
+   WARN(1, "unbalanced hotplug enable %d\n", cpu_hotplug_disabled);
+   cpu_hotplug_disabled = 0;
+   }
+}
+
 /*
  * Wait for currently running CPU hotplug operations to complete (if any) and
  * disable future CPU hotplug (from sysfs). The 'cpu_add_remove_lock' protects
@@ -253,7 +266,7 @@ void cpu_hotplug_done(void)
 void cpu_hotplug_disable(void)
 {
cpu_maps_update_begin();
-   cpu_hotplug_disabled++;
+   _cpu_hotplug_disable();
cpu_maps_update_done();
 }
 EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
@@ -261,7 +274,7 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
 void cpu_hotplug_enable(void)
 {
cpu_maps_update_begin();
-   WARN_ON(--cpu_hotplug_disabled < 0);
+   _cpu_hotplug_enable();
cpu_maps_update_done();
 }
 EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
@@ -1053,7 +1066,7 @@ int disable_nonboot_cpus(void)
 * this even in case of failure as all disable_nonboot_cpus() users are
 * supposed to do enable_nonboot_cpus() on the failure path.
 */
-   cpu_hotplug_disabled++;
+   _cpu_hotplug_disable();
 
cpu_maps_update_done();
return error;
@@ -1073,7 +1086,7 @@ void enable_nonboot_cpus(void)
 
/* Allow everyone to use the CPU hotplug again */
cpu_maps_update_begin();
-   WARN_ON(--cpu_hotplug_disabled < 0);
+   _cpu_hotplug_enable();
if (cpumask_empty(frozen_cpus))
goto out;
 
-- 
1.9.1

[PATCH] cpu/hotplug: handle unbalanced hotplug enable/disable

[Lianwei Wang]

Currently it just print a warning message but did not
reset cpu_hotplug_disabled when the enable/disable is
unbalanced. The unbalanced enable/disable will lead
the cpu hotplug work abnormally.

Reset it to 0 when an unablanced enable detected.

Signed-off-by: Lianwei Wang 
---
 kernel/cpu.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 6ea42e8da861..fef6caed77a3 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -243,6 +243,19 @@ void cpu_hotplug_done(void)
cpuhp_lock_release();
 }
 
+static void _cpu_hotplug_disable(void)
+{
+   cpu_hotplug_disabled++;
+}
+
+static void _cpu_hotplug_enable(void)
+{
+   if (--cpu_hotplug_disabled < 0) {
+   WARN(1, "unbalanced hotplug enable %d\n", cpu_hotplug_disabled);
+   cpu_hotplug_disabled = 0;
+   }
+}
+
 /*
  * Wait for currently running CPU hotplug operations to complete (if any) and
  * disable future CPU hotplug (from sysfs). The 'cpu_add_remove_lock' protects
@@ -253,7 +266,7 @@ void cpu_hotplug_done(void)
 void cpu_hotplug_disable(void)
 {
cpu_maps_update_begin();
-   cpu_hotplug_disabled++;
+   _cpu_hotplug_disable();
cpu_maps_update_done();
 }
 EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
@@ -261,7 +274,7 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
 void cpu_hotplug_enable(void)
 {
cpu_maps_update_begin();
-   WARN_ON(--cpu_hotplug_disabled < 0);
+   _cpu_hotplug_enable();
cpu_maps_update_done();
 }
 EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
@@ -1053,7 +1066,7 @@ int disable_nonboot_cpus(void)
 * this even in case of failure as all disable_nonboot_cpus() users are
 * supposed to do enable_nonboot_cpus() on the failure path.
 */
-   cpu_hotplug_disabled++;
+   _cpu_hotplug_disable();
 
cpu_maps_update_done();
return error;
@@ -1073,7 +1086,7 @@ void enable_nonboot_cpus(void)
 
/* Allow everyone to use the CPU hotplug again */
cpu_maps_update_begin();
-   WARN_ON(--cpu_hotplug_disabled < 0);
+   _cpu_hotplug_enable();
if (cpumask_empty(frozen_cpus))
goto out;
 
-- 
1.9.1

Re: [kbuild-all] mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'

[Fengguang Wu]

Hi Ralf,

On Wed, Apr 20, 2016 at 03:30:21PM +0200, Ralf Baechle wrote:
> On Wed, Apr 20, 2016 at 01:44:28PM +0800, kbuild test robot wrote:
> 
> > FYI, the error/warning still remains.
> > 
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > master
> > head:   12566cc35d0e68308bde7aad615743d560cb097b
> > commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch 
> > policy to be changed
> > date:   6 months ago
> > config: mips-malta_qemu_32r6_defconfig (attached as .config)
> > reproduce:
> > wget 
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> >  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout c1a0e9bc885d46e519fd87d35af6a7937abfb986
> > # save the attached .config to linux build tree
> > make.cross ARCH=mips 
> > 
> > All errors (new ones prefixed by >>):
> > 
> > >> mipsel-linux-gnu-gcc: error: unrecognized command line option 
> > >> '-mcompact-branches=optimal'
> > >> mipsel-linux-gnu-gcc: error: unrecognized command line option 
> > >> '-mcompact-branches=optimal'
> 
> -mcompact-branches=optimal is an option for the latest version of the MIPS
> architecture which is enabled by mips-malta_qemu_32r6_defconfig but your
> compiler is too old, doesn't support R6.  Unfortunately there's no simple
> way to run a test on the build environment from kconfig or even before
> kconfig runs so we've just ignord this particular build issue.  Plus
> there being the additional issue that we only know the toolchain to be
> used after certain options have been picked.

We are running Debian's mips cross compiler.

% mips-linux-gnu-gcc --version
mips-linux-gnu-gcc (Debian 5.2.1-16) 5.2.1 20150903
Copyright (C) 2015 Free Software Foundation, Inc.

How about temporarily disable that error, until we upgrade to a new
gcc version which supports the -mcompact-branches option?

Thanks,
Fengguang

Re: [kbuild-all] mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'

[Fengguang Wu]

Hi Ralf,

On Wed, Apr 20, 2016 at 03:30:21PM +0200, Ralf Baechle wrote:
> On Wed, Apr 20, 2016 at 01:44:28PM +0800, kbuild test robot wrote:
> 
> > FYI, the error/warning still remains.
> > 
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > master
> > head:   12566cc35d0e68308bde7aad615743d560cb097b
> > commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch 
> > policy to be changed
> > date:   6 months ago
> > config: mips-malta_qemu_32r6_defconfig (attached as .config)
> > reproduce:
> > wget 
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> >  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout c1a0e9bc885d46e519fd87d35af6a7937abfb986
> > # save the attached .config to linux build tree
> > make.cross ARCH=mips 
> > 
> > All errors (new ones prefixed by >>):
> > 
> > >> mipsel-linux-gnu-gcc: error: unrecognized command line option 
> > >> '-mcompact-branches=optimal'
> > >> mipsel-linux-gnu-gcc: error: unrecognized command line option 
> > >> '-mcompact-branches=optimal'
> 
> -mcompact-branches=optimal is an option for the latest version of the MIPS
> architecture which is enabled by mips-malta_qemu_32r6_defconfig but your
> compiler is too old, doesn't support R6.  Unfortunately there's no simple
> way to run a test on the build environment from kconfig or even before
> kconfig runs so we've just ignord this particular build issue.  Plus
> there being the additional issue that we only know the toolchain to be
> used after certain options have been picked.

We are running Debian's mips cross compiler.

% mips-linux-gnu-gcc --version
mips-linux-gnu-gcc (Debian 5.2.1-16) 5.2.1 20150903
Copyright (C) 2015 Free Software Foundation, Inc.

How about temporarily disable that error, until we upgrade to a new
gcc version which supports the -mcompact-branches option?

Thanks,
Fengguang

Re: [PATCH 01/14] vmscan: consider classzone_idx in compaction_ready

[Hillf Danton]

> 
> From: Michal Hocko 
> 
> while playing with the oom detection rework [1] I have noticed
> that my heavy order-9 (hugetlb) load close to OOM ended up in an
> endless loop where the reclaim hasn't made any progress but
> did_some_progress didn't reflect that and compaction_suitable
> was backing off because no zone is above low wmark + 1 << order.
> 
> It turned out that this is in fact an old standing bug in compaction_ready
> which ignores the requested_highidx and did the watermark check for
> 0 classzone_idx. This succeeds for zone DMA most of the time as the zone
> is mostly unused because of lowmem protection. This also means that the
> OOM killer wouldn't be triggered for higher order requests even when
> there is no reclaim progress and we essentially rely on order-0 request
> to find this out. 

Thanks.

> This has been broken in one way or another since
> fe4b1b244bdb ("mm: vmscan: when reclaiming for compaction, ensure there
> are sufficient free pages available") but only since 7335084d446b ("mm:
> vmscan: do not OOM if aborting reclaim to start compaction") we are not
> invoking the OOM killer based on the wrong calculation.
> 
> Propagate requested_highidx down to compaction_ready and use it for both
> the watermak check and compaction_suitable to fix this issue.
> 
> [1] 
> http://lkml.kernel.org/r/1459855533-4600-1-git-send-email-mho...@kernel.org
> 
> Acked-by: Vlastimil Babka 
> Signed-off-by: Michal Hocko 
> ---

Acked-by: Hillf Danton 

>  mm/vmscan.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c839adc13efd..3e6347e2a5fc 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2482,7 +2482,7 @@ static bool shrink_zone(struct zone *zone, struct 
> scan_control *sc,
>   * Returns true if compaction should go ahead for a high-order request, or
>   * the high-order allocation would succeed without compaction.
>   */
> -static inline bool compaction_ready(struct zone *zone, int order)
> +static inline bool compaction_ready(struct zone *zone, int order, int 
> classzone_idx)
>  {
>   unsigned long balance_gap, watermark;
>   bool watermark_ok;
> @@ -2496,7 +2496,7 @@ static inline bool compaction_ready(struct zone *zone, 
> int order)
>   balance_gap = min(low_wmark_pages(zone), DIV_ROUND_UP(
>   zone->managed_pages, KSWAPD_ZONE_BALANCE_GAP_RATIO));
>   watermark = high_wmark_pages(zone) + balance_gap + (2UL << order);
> - watermark_ok = zone_watermark_ok_safe(zone, 0, watermark, 0);
> + watermark_ok = zone_watermark_ok_safe(zone, 0, watermark, 
> classzone_idx);
> 
>   /*
>* If compaction is deferred, reclaim up to a point where
> @@ -2509,7 +2509,7 @@ static inline bool compaction_ready(struct zone *zone, 
> int order)
>* If compaction is not ready to start and allocation is not likely
>* to succeed without it, then keep reclaiming.
>*/
> - if (compaction_suitable(zone, order, 0, 0) == COMPACT_SKIPPED)
> + if (compaction_suitable(zone, order, 0, classzone_idx) == 
> COMPACT_SKIPPED)
>   return false;
> 
>   return watermark_ok;
> @@ -2589,7 +2589,7 @@ static bool shrink_zones(struct zonelist *zonelist, 
> struct scan_control *sc)
>   if (IS_ENABLED(CONFIG_COMPACTION) &&
>   sc->order > PAGE_ALLOC_COSTLY_ORDER &&
>   zonelist_zone_idx(z) <= requested_highidx &&
> - compaction_ready(zone, sc->order)) {
> + compaction_ready(zone, sc->order, 
> requested_highidx)) {
>   sc->compaction_ready = true;
>   continue;
>   }
> --
> 2.8.0.rc3

Re: [PATCH 01/14] vmscan: consider classzone_idx in compaction_ready

[Hillf Danton]

> 
> From: Michal Hocko 
> 
> while playing with the oom detection rework [1] I have noticed
> that my heavy order-9 (hugetlb) load close to OOM ended up in an
> endless loop where the reclaim hasn't made any progress but
> did_some_progress didn't reflect that and compaction_suitable
> was backing off because no zone is above low wmark + 1 << order.
> 
> It turned out that this is in fact an old standing bug in compaction_ready
> which ignores the requested_highidx and did the watermark check for
> 0 classzone_idx. This succeeds for zone DMA most of the time as the zone
> is mostly unused because of lowmem protection. This also means that the
> OOM killer wouldn't be triggered for higher order requests even when
> there is no reclaim progress and we essentially rely on order-0 request
> to find this out. 

Thanks.

> This has been broken in one way or another since
> fe4b1b244bdb ("mm: vmscan: when reclaiming for compaction, ensure there
> are sufficient free pages available") but only since 7335084d446b ("mm:
> vmscan: do not OOM if aborting reclaim to start compaction") we are not
> invoking the OOM killer based on the wrong calculation.
> 
> Propagate requested_highidx down to compaction_ready and use it for both
> the watermak check and compaction_suitable to fix this issue.
> 
> [1] 
> http://lkml.kernel.org/r/1459855533-4600-1-git-send-email-mho...@kernel.org
> 
> Acked-by: Vlastimil Babka 
> Signed-off-by: Michal Hocko 
> ---

Acked-by: Hillf Danton 

>  mm/vmscan.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c839adc13efd..3e6347e2a5fc 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2482,7 +2482,7 @@ static bool shrink_zone(struct zone *zone, struct 
> scan_control *sc,
>   * Returns true if compaction should go ahead for a high-order request, or
>   * the high-order allocation would succeed without compaction.
>   */
> -static inline bool compaction_ready(struct zone *zone, int order)
> +static inline bool compaction_ready(struct zone *zone, int order, int 
> classzone_idx)
>  {
>   unsigned long balance_gap, watermark;
>   bool watermark_ok;
> @@ -2496,7 +2496,7 @@ static inline bool compaction_ready(struct zone *zone, 
> int order)
>   balance_gap = min(low_wmark_pages(zone), DIV_ROUND_UP(
>   zone->managed_pages, KSWAPD_ZONE_BALANCE_GAP_RATIO));
>   watermark = high_wmark_pages(zone) + balance_gap + (2UL << order);
> - watermark_ok = zone_watermark_ok_safe(zone, 0, watermark, 0);
> + watermark_ok = zone_watermark_ok_safe(zone, 0, watermark, 
> classzone_idx);
> 
>   /*
>* If compaction is deferred, reclaim up to a point where
> @@ -2509,7 +2509,7 @@ static inline bool compaction_ready(struct zone *zone, 
> int order)
>* If compaction is not ready to start and allocation is not likely
>* to succeed without it, then keep reclaiming.
>*/
> - if (compaction_suitable(zone, order, 0, 0) == COMPACT_SKIPPED)
> + if (compaction_suitable(zone, order, 0, classzone_idx) == 
> COMPACT_SKIPPED)
>   return false;
> 
>   return watermark_ok;
> @@ -2589,7 +2589,7 @@ static bool shrink_zones(struct zonelist *zonelist, 
> struct scan_control *sc)
>   if (IS_ENABLED(CONFIG_COMPACTION) &&
>   sc->order > PAGE_ALLOC_COSTLY_ORDER &&
>   zonelist_zone_idx(z) <= requested_highidx &&
> - compaction_ready(zone, sc->order)) {
> + compaction_ready(zone, sc->order, 
> requested_highidx)) {
>   sc->compaction_ready = true;
>   continue;
>   }
> --
> 2.8.0.rc3

Re: watchdog: deadlock warning with imx2_wdt driver and systemd

[Guenter Roeck]

On 04/17/2016 08:41 AM, Clemens Gruber wrote:

Hi,

I have an i.MX6Q board with the current mainline tree from Linus and
systemd 229, which also acts as watchdog daemon.
(RuntimeWatchdogSec=60)

Since commit 11d7aba9ceb7 ("watchdog: imx2: Convert to use
infrastructure triggered keepalives") I get a kernel lockdep warning
after systemd launches.

However, according to the backtrace, this happens in watchdog_dev.c
(watchdog_release and watchdog_ping_work) which was not even touched
by said commit.

It also only occurs during the first boot. (I added some initialization
tasks there, e.g. generating SSH keys, expanding filesystems, etc.,
which takes about one minute and must be connected to this somehow,
because on all subsequent boots without that delay, it does not appear
anymore)

Log output:

[5.426747] ==
[5.432941] [ INFO: possible circular locking dependency detected ]
[5.439221] 4.6.0-rc3-00191-gfabf418 #162 Not tainted
[5.444283] ---
[5.450552] systemd/1 is trying to acquire lock:
[5.455172]  ((&(_data->work)->work)){+.+...}, at: [<80141650>] 
flush_work+0x0/0x280
[5.463271]
but task is already holding lock:
[5.469114]  (_data->lock){+.+...}, at: [<804acfa8>] 
watchdog_release+0x18/0x190
[5.476860]
which lock already depends on the new lock.

[5.485050]
the existing dependency chain (in reverse order) is:
[5.492543]
-> #1 (_data->lock){+.+...}:
[5.496967][<80662310>] mutex_lock_nested+0x64/0x4a8
[5.502666][<804aca4c>] watchdog_ping_work+0x18/0x4c
[5.508359][<80143128>] process_one_work+0x1ac/0x500
[5.514044][<801434b4>] worker_thread+0x38/0x554
[5.519389][<80149510>] kthread+0xf4/0x108
[5.524217][<80107c10>] ret_from_fork+0x14/0x24
[5.529482]
-> #0 ((&(_data->work)->work)){+.+...}:
[5.534883][<8017c4e8>] lock_acquire+0x70/0x90
[5.540061][<8014169c>] flush_work+0x4c/0x280
[5.545144][<801440f8>] __cancel_work_timer+0x9c/0x1e0
[5.551008][<804acfcc>] watchdog_release+0x3c/0x190
[5.556612][<8022c5e8>] __fput+0x80/0x1c8
[5.561354][<80147b28>] task_work_run+0x94/0xc8
[5.566613][<8010b998>] do_work_pending+0x8c/0xb4
[5.572049][<80107ba8>] slow_work_pending+0xc/0x20
[5.577568]
other info that might help us debug this:

[5.585585]  Possible unsafe locking scenario:

[5.591516]CPU0CPU1
[5.596055]
[5.600593]   lock(_data->lock);
[5.604130]lock((&(_data->work)->work));
[5.611137]lock(_data->lock);
[5.617191]   lock((&(_data->work)->work));
[5.621681]
 *** DEADLOCK ***

[5.627615] 1 lock held by systemd/1:
[5.631286]  #0:  (_data->lock){+.+...}, at: [<804acfa8>] 
watchdog_release+0x18/0x190
[5.639488]
stack backtrace:
[5.643861] CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 
#162
[5.651353] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[5.657909] [<8010f5e4>] (unwind_backtrace) from [<8010c038>] 
(show_stack+0x10/0x14)
[5.665671] [<8010c038>] (show_stack) from [<8039d7fc>] 
(dump_stack+0xa8/0xd4)
[5.672911] [<8039d7fc>] (dump_stack) from [<80177ee0>] 
(print_circular_bug+0x214/0x334)
[5.681012] [<80177ee0>] (print_circular_bug) from [<80179230>] 
(check_prevs_add+0x4dc/0x8e8)
[5.689556] [<80179230>] (check_prevs_add) from [<8017b3d8>] 
(__lock_acquire+0xc6c/0x14ec)
[5.697831] [<8017b3d8>] (__lock_acquire) from [<8017c4e8>] 
(lock_acquire+0x70/0x90)
[5.705584] [<8017c4e8>] (lock_acquire) from [<8014169c>] 
(flush_work+0x4c/0x280)
[5.713076] [<8014169c>] (flush_work) from [<801440f8>] 
(__cancel_work_timer+0x9c/0x1e0)
[5.721183] [<801440f8>] (__cancel_work_timer) from [<804acfcc>] 
(watchdog_release+0x3c/0x190)
[5.729815] [<804acfcc>] (watchdog_release) from [<8022c5e8>] 
(__fput+0x80/0x1c8)
[5.737316] [<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8)
[5.744465] [<80147b28>] (task_work_run) from [<8010b998>] 
(do_work_pending+0x8c/0xb4)
[5.752401] [<8010b998>] (do_work_pending) from [<80107ba8>] 
(slow_work_pending+0xc/0x20)

If you can't reproduce it but have an idea how to fix this, I would be
happy to test your idea or patch.



Hi Clemens,

fix is to drop the call to cancel_delayed_work_sync() from watchdog_release().
Turns out the call is not necessary.

I'll send a proper patch in the next couple of days.

Guenter

Re: watchdog: deadlock warning with imx2_wdt driver and systemd

[Guenter Roeck]

On 04/17/2016 08:41 AM, Clemens Gruber wrote:

Hi,

I have an i.MX6Q board with the current mainline tree from Linus and
systemd 229, which also acts as watchdog daemon.
(RuntimeWatchdogSec=60)

Since commit 11d7aba9ceb7 ("watchdog: imx2: Convert to use
infrastructure triggered keepalives") I get a kernel lockdep warning
after systemd launches.

However, according to the backtrace, this happens in watchdog_dev.c
(watchdog_release and watchdog_ping_work) which was not even touched
by said commit.

It also only occurs during the first boot. (I added some initialization
tasks there, e.g. generating SSH keys, expanding filesystems, etc.,
which takes about one minute and must be connected to this somehow,
because on all subsequent boots without that delay, it does not appear
anymore)

Log output:

[5.426747] ==
[5.432941] [ INFO: possible circular locking dependency detected ]
[5.439221] 4.6.0-rc3-00191-gfabf418 #162 Not tainted
[5.444283] ---
[5.450552] systemd/1 is trying to acquire lock:
[5.455172]  ((&(_data->work)->work)){+.+...}, at: [<80141650>] 
flush_work+0x0/0x280
[5.463271]
but task is already holding lock:
[5.469114]  (_data->lock){+.+...}, at: [<804acfa8>] 
watchdog_release+0x18/0x190
[5.476860]
which lock already depends on the new lock.

[5.485050]
the existing dependency chain (in reverse order) is:
[5.492543]
-> #1 (_data->lock){+.+...}:
[5.496967][<80662310>] mutex_lock_nested+0x64/0x4a8
[5.502666][<804aca4c>] watchdog_ping_work+0x18/0x4c
[5.508359][<80143128>] process_one_work+0x1ac/0x500
[5.514044][<801434b4>] worker_thread+0x38/0x554
[5.519389][<80149510>] kthread+0xf4/0x108
[5.524217][<80107c10>] ret_from_fork+0x14/0x24
[5.529482]
-> #0 ((&(_data->work)->work)){+.+...}:
[5.534883][<8017c4e8>] lock_acquire+0x70/0x90
[5.540061][<8014169c>] flush_work+0x4c/0x280
[5.545144][<801440f8>] __cancel_work_timer+0x9c/0x1e0
[5.551008][<804acfcc>] watchdog_release+0x3c/0x190
[5.556612][<8022c5e8>] __fput+0x80/0x1c8
[5.561354][<80147b28>] task_work_run+0x94/0xc8
[5.566613][<8010b998>] do_work_pending+0x8c/0xb4
[5.572049][<80107ba8>] slow_work_pending+0xc/0x20
[5.577568]
other info that might help us debug this:

[5.585585]  Possible unsafe locking scenario:

[5.591516]CPU0CPU1
[5.596055]
[5.600593]   lock(_data->lock);
[5.604130]lock((&(_data->work)->work));
[5.611137]lock(_data->lock);
[5.617191]   lock((&(_data->work)->work));
[5.621681]
 *** DEADLOCK ***

[5.627615] 1 lock held by systemd/1:
[5.631286]  #0:  (_data->lock){+.+...}, at: [<804acfa8>] 
watchdog_release+0x18/0x190
[5.639488]
stack backtrace:
[5.643861] CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 
#162
[5.651353] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[5.657909] [<8010f5e4>] (unwind_backtrace) from [<8010c038>] 
(show_stack+0x10/0x14)
[5.665671] [<8010c038>] (show_stack) from [<8039d7fc>] 
(dump_stack+0xa8/0xd4)
[5.672911] [<8039d7fc>] (dump_stack) from [<80177ee0>] 
(print_circular_bug+0x214/0x334)
[5.681012] [<80177ee0>] (print_circular_bug) from [<80179230>] 
(check_prevs_add+0x4dc/0x8e8)
[5.689556] [<80179230>] (check_prevs_add) from [<8017b3d8>] 
(__lock_acquire+0xc6c/0x14ec)
[5.697831] [<8017b3d8>] (__lock_acquire) from [<8017c4e8>] 
(lock_acquire+0x70/0x90)
[5.705584] [<8017c4e8>] (lock_acquire) from [<8014169c>] 
(flush_work+0x4c/0x280)
[5.713076] [<8014169c>] (flush_work) from [<801440f8>] 
(__cancel_work_timer+0x9c/0x1e0)
[5.721183] [<801440f8>] (__cancel_work_timer) from [<804acfcc>] 
(watchdog_release+0x3c/0x190)
[5.729815] [<804acfcc>] (watchdog_release) from [<8022c5e8>] 
(__fput+0x80/0x1c8)
[5.737316] [<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8)
[5.744465] [<80147b28>] (task_work_run) from [<8010b998>] 
(do_work_pending+0x8c/0xb4)
[5.752401] [<8010b998>] (do_work_pending) from [<80107ba8>] 
(slow_work_pending+0xc/0x20)

If you can't reproduce it but have an idea how to fix this, I would be
happy to test your idea or patch.



Hi Clemens,

fix is to drop the call to cancel_delayed_work_sync() from watchdog_release().
Turns out the call is not necessary.

I'll send a proper patch in the next couple of days.

Guenter

[PATCH v2] drm/dsi: Implement set tear scanline compile fix

[Vinay Simha BN]

Provide a small convenience wrapper that transmits
a set_tear_scanline command.

Cc: Archit Taneja 
Cc: Sumit Semwal 
Cc: John Stultz 
Cc: Thierry Reding 
Signed-off-by: Vinay Simha BN 
---
 drivers/gpu/drm/drm_mipi_dsi.c | 23 +++
 include/drm/drm_mipi_dsi.h |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index f5d8083..2f0b85c 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -983,6 +983,29 @@ int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
 EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_on);
 
 /**
+ * mipi_dsi_set_tear_scanline() - turn on the display module's Tearing Effect
+ * output signal on the TE signal line when display module reaches line N
+ * defined by STS[n:0].
+ * @dsi: DSI peripheral device
+ * @param1: STS[10:8]
+ * @param2: STS[7:0]
+ * Return: 0 on success or a negative error code on failure
+ */
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi,
+  u8 param1, u8 param2)
+{
+   u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, param1, param2};
+   ssize_t err;
+
+   err = mipi_dsi_generic_write(dsi, , sizeof(payload));
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_set_tear_scanline);
+
+/**
  * mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB image
  *data used by the interface
  * @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7a9840f..2788dbe 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -263,6 +263,8 @@ int mipi_dsi_dcs_set_column_address(struct mipi_dsi_device 
*dsi, u16 start,
u16 end);
 int mipi_dsi_dcs_set_page_address(struct mipi_dsi_device *dsi, u16 start,
  u16 end);
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u8 param1,
+  u8 param2);
 int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
 int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
 enum mipi_dsi_dcs_tear_mode mode);
-- 
2.1.2

[PATCH v2] drm/dsi: Implement set tear scanline compile fix

[Vinay Simha BN]

Provide a small convenience wrapper that transmits
a set_tear_scanline command.

Cc: Archit Taneja 
Cc: Sumit Semwal 
Cc: John Stultz 
Cc: Thierry Reding 
Signed-off-by: Vinay Simha BN 
---
 drivers/gpu/drm/drm_mipi_dsi.c | 23 +++
 include/drm/drm_mipi_dsi.h |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index f5d8083..2f0b85c 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -983,6 +983,29 @@ int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
 EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_on);
 
 /**
+ * mipi_dsi_set_tear_scanline() - turn on the display module's Tearing Effect
+ * output signal on the TE signal line when display module reaches line N
+ * defined by STS[n:0].
+ * @dsi: DSI peripheral device
+ * @param1: STS[10:8]
+ * @param2: STS[7:0]
+ * Return: 0 on success or a negative error code on failure
+ */
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi,
+  u8 param1, u8 param2)
+{
+   u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, param1, param2};
+   ssize_t err;
+
+   err = mipi_dsi_generic_write(dsi, , sizeof(payload));
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_set_tear_scanline);
+
+/**
  * mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB image
  *data used by the interface
  * @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7a9840f..2788dbe 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -263,6 +263,8 @@ int mipi_dsi_dcs_set_column_address(struct mipi_dsi_device 
*dsi, u16 start,
u16 end);
 int mipi_dsi_dcs_set_page_address(struct mipi_dsi_device *dsi, u16 start,
  u16 end);
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u8 param1,
+  u8 param2);
 int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
 int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
 enum mipi_dsi_dcs_tear_mode mode);
-- 
2.1.2

Re: [PATCH] objtool: Fix Makefile to properly see if libelf is supported

[Josh Poimboeuf]

On Wed, Apr 20, 2016 at 11:32:35AM -0400, Steven Rostedt wrote:
> When doing a make allmodconfig, I hit the following compile error:
> 
> In file included from builtin-check.c:32:0:
> elf.h:22:18: fatal error: gelf.h: No such file or directory
> compilation terminated.
> In file included from special.h:22:0,
>  from special.c:26:
> elf.h:22:18: fatal error: gelf.h: No such file or directory
> compilation terminated.
> In file included from elf.c:30:0:
> elf.h:22:18: fatal error: gelf.h: No such file or directory
> compilation terminated.
> mv: cannot stat 'tools/objtool/.elf.o.tmp': No such file or directory
> tools/build/Makefile.build:77: recipe for target 'tools/objtool/elf.o' failed
> make[4]: *** [tools/objtool/elf.o] Error 1
> make[4]: *** Waiting for unfinished jobs
> 
> Digging into it, it appears that the $(shell ..) command in the Makefile does
> not give the proper result when it fails to find -lelf, and continues to
> compile objtool.
> 
> Instead, use the "try-run" makefile macro to perform the test. This gives a
> proper result for both cases.
> 
> Fixes: 442f04c34a1a4 ("objtool: Add tool to perform compile-time stack 
> metadata validation")
> Signed-off-by: Steven Rostedt 

Thanks!

Acked-by: Josh Poimboeuf 

-- 
Josh

Re: [PATCH] objtool: Fix Makefile to properly see if libelf is supported

[Josh Poimboeuf]

On Wed, Apr 20, 2016 at 11:32:35AM -0400, Steven Rostedt wrote:
> When doing a make allmodconfig, I hit the following compile error:
> 
> In file included from builtin-check.c:32:0:
> elf.h:22:18: fatal error: gelf.h: No such file or directory
> compilation terminated.
> In file included from special.h:22:0,
>  from special.c:26:
> elf.h:22:18: fatal error: gelf.h: No such file or directory
> compilation terminated.
> In file included from elf.c:30:0:
> elf.h:22:18: fatal error: gelf.h: No such file or directory
> compilation terminated.
> mv: cannot stat 'tools/objtool/.elf.o.tmp': No such file or directory
> tools/build/Makefile.build:77: recipe for target 'tools/objtool/elf.o' failed
> make[4]: *** [tools/objtool/elf.o] Error 1
> make[4]: *** Waiting for unfinished jobs
> 
> Digging into it, it appears that the $(shell ..) command in the Makefile does
> not give the proper result when it fails to find -lelf, and continues to
> compile objtool.
> 
> Instead, use the "try-run" makefile macro to perform the test. This gives a
> proper result for both cases.
> 
> Fixes: 442f04c34a1a4 ("objtool: Add tool to perform compile-time stack 
> metadata validation")
> Signed-off-by: Steven Rostedt 

Thanks!

Acked-by: Josh Poimboeuf 

-- 
Josh

Re: [PATCH] lib: make sg_pool explicitly non-modular

[Ming Lin]

On Wed, 2016-04-20 at 23:02 -0400, Paul Gortmaker wrote:
> 
> > 
> > So the .config will have CONFIG_SG_POOL=m
> 
> That is impossible currently, since as per above, the variable is
> bool
> and not tristate.  Did you mean to make it tristate?

I didn't notice that.

Yes, it should be tristate.

Re: [PATCH] lib: make sg_pool explicitly non-modular

[Ming Lin]

On Wed, 2016-04-20 at 23:02 -0400, Paul Gortmaker wrote:
> 
> > 
> > So the .config will have CONFIG_SG_POOL=m
> 
> That is impossible currently, since as per above, the variable is
> bool
> and not tristate.  Did you mean to make it tristate?

I didn't notice that.

Yes, it should be tristate.

Re: [PATCH net v2 0/3] drivers: net: cpsw: phy-handle fixes

[David Rivshin (Allworx)]

Sorry all for the noise. Gmail seems to be deciding that this outgoing 
mail is spammy, and starts blocking it part-way through. I've tried 
cutting down the CC list, but still no luck. If anyone knows how to get 
around this (while still having a reasonable patch submission), please 
let me know. 

For tonight, I guess I have no choice but to give up. I'll try again
tomorrow in hopes gmail becomes sane again.


On Wed, 20 Apr 2016 23:24:39 -0400
"David Rivshin (Allworx)"  wrote:

> From: David Rivshin 
> 
> The first patch fixes a bug that makes dual_emac mode break if
> either slave uses the phy-handle property in the devicetree.
> 
> The second patch fixes some cosmetic problems with error messages,
> and also makes the binding documentation more explicit.
> 
> The third patch cleans up the fixed-link case to work like
> the now-fixed phy-handle case.
> 
> I have tested on the following hardware configurations:
>  - (EVMSK) dual emac, phy_id property in both slaves
>  - (EVMSK) dual emac, phy-handle property in both slaves
>  - (BeagleBoneBlack) single emac, phy_id property
>  - (custom) single emac, fixed-link subnode
> 
> Nicolas Chauvet reported testing on an HP t410 (dm8148).
> 
> Markus Brunner reported testing v1 on the following [1]:
>  - emac0 with phy_id and emac1 with fixed phy
>  - emac0 with phy-handle and emac1 with fixed phy
>  - emac0 with fixed phy and emac1 with fixed phy
> 
> 
> Changes since v1 [2]:
> - Rebased
> - Added Tested-by from Nicolas Chauvet on all patches
> - Added Acked-by from Rob Herring for the binding change in patch 2 [3]
> 
> [1] http://www.spinics.net/lists/netdev/msg357890.html
> [2] http://www.spinics.net/lists/netdev/msg357772.html
> [3] http://www.spinics.net/lists/netdev/msg358254.html
> 
> David Rivshin (3):
>   drivers: net: cpsw: fix parsing of phy-handle DT property in dual_emac
> config
>   drivers: net: cpsw: fix error messages when using phy-handle DT
> property
>   drivers: net: cpsw: use of_phy_connect() in fixed-link case
> 
>  Documentation/devicetree/bindings/net/cpsw.txt |  4 +--
>  drivers/net/ethernet/ti/cpsw.c | 41 
> +-
>  drivers/net/ethernet/ti/cpsw.h |  1 +
>  3 files changed, 23 insertions(+), 23 deletions(-)
> 

Re: [PATCH net v2 0/3] drivers: net: cpsw: phy-handle fixes

[David Rivshin (Allworx)]

Sorry all for the noise. Gmail seems to be deciding that this outgoing 
mail is spammy, and starts blocking it part-way through. I've tried 
cutting down the CC list, but still no luck. If anyone knows how to get 
around this (while still having a reasonable patch submission), please 
let me know. 

For tonight, I guess I have no choice but to give up. I'll try again
tomorrow in hopes gmail becomes sane again.


On Wed, 20 Apr 2016 23:24:39 -0400
"David Rivshin (Allworx)"  wrote:

> From: David Rivshin 
> 
> The first patch fixes a bug that makes dual_emac mode break if
> either slave uses the phy-handle property in the devicetree.
> 
> The second patch fixes some cosmetic problems with error messages,
> and also makes the binding documentation more explicit.
> 
> The third patch cleans up the fixed-link case to work like
> the now-fixed phy-handle case.
> 
> I have tested on the following hardware configurations:
>  - (EVMSK) dual emac, phy_id property in both slaves
>  - (EVMSK) dual emac, phy-handle property in both slaves
>  - (BeagleBoneBlack) single emac, phy_id property
>  - (custom) single emac, fixed-link subnode
> 
> Nicolas Chauvet reported testing on an HP t410 (dm8148).
> 
> Markus Brunner reported testing v1 on the following [1]:
>  - emac0 with phy_id and emac1 with fixed phy
>  - emac0 with phy-handle and emac1 with fixed phy
>  - emac0 with fixed phy and emac1 with fixed phy
> 
> 
> Changes since v1 [2]:
> - Rebased
> - Added Tested-by from Nicolas Chauvet on all patches
> - Added Acked-by from Rob Herring for the binding change in patch 2 [3]
> 
> [1] http://www.spinics.net/lists/netdev/msg357890.html
> [2] http://www.spinics.net/lists/netdev/msg357772.html
> [3] http://www.spinics.net/lists/netdev/msg358254.html
> 
> David Rivshin (3):
>   drivers: net: cpsw: fix parsing of phy-handle DT property in dual_emac
> config
>   drivers: net: cpsw: fix error messages when using phy-handle DT
> property
>   drivers: net: cpsw: use of_phy_connect() in fixed-link case
> 
>  Documentation/devicetree/bindings/net/cpsw.txt |  4 +--
>  drivers/net/ethernet/ti/cpsw.c | 41 
> +-
>  drivers/net/ethernet/ti/cpsw.h |  1 +
>  3 files changed, 23 insertions(+), 23 deletions(-)
> 

Re: [RESEND][PATCH 3/3] arm64: dts: mt8173: Add dynamic power node.

[dawei chien]

On Tue, 2016-03-15 at 16:10 +0800, Dawei Chien (錢大衛) wrote:
> This device node is for calculating dynamic power in mW.
> Since mt8173 has two clusters, there are two dynamic power
> coefficient as well.
> 
> Signed-off-by: Dawei Chien 
> ---
> This patch is base on patchset:
> https://lkml.org/lkml/2015/11/17/251

Sorry for miss one dependence for this device node.
https://lkml.org/lkml/2015/7/9/206

> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index f9c44cc..5cb6b4e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -71,6 +71,7 @@
> #cooling-cells = <2>;
> #cooling-min-level = <0>;
> #cooling-max-level = <7>;
> +   dynamic-power-coefficient = <263>;
> };
> 
> cpu1: cpu@1 {
> @@ -95,6 +96,7 @@
> #cooling-cells = <2>;
> #cooling-min-level = <0>;
> #cooling-max-level = <7>;
> +   dynamic-power-coefficient = <263>;
> };
> 
> cpu2: cpu@100 {
> @@ -119,6 +121,7 @@
> #cooling-cells = <2>;
> #cooling-min-level = <0>;
> #cooling-max-level = <7>;
> +   dynamic-power-coefficient = <530>;
> };
> 
> cpu3: cpu@101 {
> @@ -143,6 +146,7 @@
> #cooling-cells = <2>;
> #cooling-min-level = <0>;
> #cooling-max-level = <7>;
> +   dynamic-power-coefficient = <530>;
> };
> 
> idle-states {
> --
> 1.7.9.5
> 

Re: [RESEND][PATCH 3/3] arm64: dts: mt8173: Add dynamic power node.

[dawei chien]

On Tue, 2016-03-15 at 16:10 +0800, Dawei Chien (錢大衛) wrote:
> This device node is for calculating dynamic power in mW.
> Since mt8173 has two clusters, there are two dynamic power
> coefficient as well.
> 
> Signed-off-by: Dawei Chien 
> ---
> This patch is base on patchset:
> https://lkml.org/lkml/2015/11/17/251

Sorry for miss one dependence for this device node.
https://lkml.org/lkml/2015/7/9/206

> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index f9c44cc..5cb6b4e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -71,6 +71,7 @@
> #cooling-cells = <2>;
> #cooling-min-level = <0>;
> #cooling-max-level = <7>;
> +   dynamic-power-coefficient = <263>;
> };
> 
> cpu1: cpu@1 {
> @@ -95,6 +96,7 @@
> #cooling-cells = <2>;
> #cooling-min-level = <0>;
> #cooling-max-level = <7>;
> +   dynamic-power-coefficient = <263>;
> };
> 
> cpu2: cpu@100 {
> @@ -119,6 +121,7 @@
> #cooling-cells = <2>;
> #cooling-min-level = <0>;
> #cooling-max-level = <7>;
> +   dynamic-power-coefficient = <530>;
> };
> 
> cpu3: cpu@101 {
> @@ -143,6 +146,7 @@
> #cooling-cells = <2>;
> #cooling-min-level = <0>;
> #cooling-max-level = <7>;
> +   dynamic-power-coefficient = <530>;
> };
> 
> idle-states {
> --
> 1.7.9.5
> 

[PATCH] perf tools: Add arch/*/include/generated/ to .gitignore

[Taeung Song]

Commit 1b700c9975008615ad470cf79acc8455ce60a695 ("perf tools: Build
syscall table .c header from kernel's syscall_64.tbl") that automatically
generate per-arch syscall table arrays e.g.

arch/x86/include/generated/asm/syscalls_64.c

So add this directory to .gitignore

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Wang Nan 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore
index 3d1bb80..4bef135 100644
--- a/tools/perf/.gitignore
+++ b/tools/perf/.gitignore
@@ -30,3 +30,4 @@ config.mak.autogen
 *.pyo
 .config-detected
 util/intel-pt-decoder/inat-tables.c
+arch/*/include/generated/
\ No newline at end of file
-- 
2.5.0

[PATCH] perf tools: Add arch/*/include/generated/ to .gitignore

[Taeung Song]

Commit 1b700c9975008615ad470cf79acc8455ce60a695 ("perf tools: Build
syscall table .c header from kernel's syscall_64.tbl") that automatically
generate per-arch syscall table arrays e.g.

arch/x86/include/generated/asm/syscalls_64.c

So add this directory to .gitignore

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Wang Nan 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore
index 3d1bb80..4bef135 100644
--- a/tools/perf/.gitignore
+++ b/tools/perf/.gitignore
@@ -30,3 +30,4 @@ config.mak.autogen
 *.pyo
 .config-detected
 util/intel-pt-decoder/inat-tables.c
+arch/*/include/generated/
\ No newline at end of file
-- 
2.5.0

Re: /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_set_encrypt_key does not evaluate to a constant

[Philip Li]

On Mon, Apr 18, 2016 at 05:08:41PM +0200, Oleg Nesterov wrote:
> On 04/17, kbuild test robot wrote:
> >
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > master
> > head:   b9f5dba225aede4518ab0a7374c2dc38c7c049ce
> > commit: 5eeb50de42fd3251845d03c556db012267c72b3f uprobes: Change 
> > handle_trampoline() to flush the frames invalidated by longjmp()
> > date:   9 months ago
> 
> and this patch changed the single function in arch-neutral 
> kernel/events/uprobes.c,
> this certainly looks like a false positive.

thanks for feedback, we will look into this to fix the false positive.

> 
> > config: powerpc-allyesconfig (attached as .config)
> > reproduce:
> > wget 
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> >  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout 5eeb50de42fd3251845d03c556db012267c72b3f
> > # save the attached .config to linux build tree
> > make.cross ARCH=powerpc 
> > 
> > All errors (new ones prefixed by >>):
> > 
> >/tmp/ccTcF8pg.s: Assembler messages:
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_set_encrypt_key does 
> > >> not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_set_encrypt_key 
> > >> does not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_set_decrypt_key does 
> > >> not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_set_decrypt_key 
> > >> does not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_encrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_encrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_decrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_decrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_cbc_encrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_cbc_encrypt does 
> > >> not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_ctr32_encrypt_blocks 
> > >> does not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for 
> > >> .aes_p8_ctr32_encrypt_blocks does not evaluate to a constant
> > --
> >/tmp/ccB2I6Jo.s: Assembler messages:
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for gcm_init_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for .gcm_init_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for gcm_gmult_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for .gcm_gmult_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for gcm_ghash_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for .gcm_ghash_p8 does not 
> > >> evaluate to a constant
> > 
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation
> 
> 
> 

Re: /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_set_encrypt_key does not evaluate to a constant

[Philip Li]

On Mon, Apr 18, 2016 at 05:08:41PM +0200, Oleg Nesterov wrote:
> On 04/17, kbuild test robot wrote:
> >
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > master
> > head:   b9f5dba225aede4518ab0a7374c2dc38c7c049ce
> > commit: 5eeb50de42fd3251845d03c556db012267c72b3f uprobes: Change 
> > handle_trampoline() to flush the frames invalidated by longjmp()
> > date:   9 months ago
> 
> and this patch changed the single function in arch-neutral 
> kernel/events/uprobes.c,
> this certainly looks like a false positive.

thanks for feedback, we will look into this to fix the false positive.

> 
> > config: powerpc-allyesconfig (attached as .config)
> > reproduce:
> > wget 
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> >  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout 5eeb50de42fd3251845d03c556db012267c72b3f
> > # save the attached .config to linux build tree
> > make.cross ARCH=powerpc 
> > 
> > All errors (new ones prefixed by >>):
> > 
> >/tmp/ccTcF8pg.s: Assembler messages:
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_set_encrypt_key does 
> > >> not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_set_encrypt_key 
> > >> does not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_set_decrypt_key does 
> > >> not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_set_decrypt_key 
> > >> does not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_encrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_encrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_decrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_decrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_cbc_encrypt does not 
> > >> evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for .aes_p8_cbc_encrypt does 
> > >> not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_ctr32_encrypt_blocks 
> > >> does not evaluate to a constant
> > >> /tmp/ccTcF8pg.s: Error: .size expression for 
> > >> .aes_p8_ctr32_encrypt_blocks does not evaluate to a constant
> > --
> >/tmp/ccB2I6Jo.s: Assembler messages:
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for gcm_init_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for .gcm_init_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for gcm_gmult_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for .gcm_gmult_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for gcm_ghash_p8 does not 
> > >> evaluate to a constant
> > >> /tmp/ccB2I6Jo.s: Error: .size expression for .gcm_ghash_p8 does not 
> > >> evaluate to a constant
> > 
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation
> 
> 
> 

[PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Jianqun Xu]

This patch adds rk3399.dtsi for rk3399 found on Rockchip
RK3399 SoCs, also add rk3399-evb.dts for Rockchip RK3399
Evaluation Board.

Patch is tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
 arch/arm64/boot/dts/rockchip/Makefile   |1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts |  537 
 arch/arm64/boot/dts/rockchip/rk3399.dtsi| 1757 +++
 3 files changed, 2295 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..4cb0028
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,537 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Rockchip RK3399 Evaluation Board";
+   compatible = "rockchip,evb", "rockchip,rk3399-evb";
+
+   chosen {
+   bootargs = "console=uart,mmio32,0xff1a";
+   };
+
+   ramoops_mem: ramoops_mem {
+   reg = <0x0 0x10 0x0 0x10>;
+   reg-names = "ramoops_mem";
+   };
+
+   ramoops {
+   compatible = "ramoops";
+   record-size = <0x0 0x2>;
+   console-size = <0x0 0x8>;
+   ftrace-size = <0x0 0x1>;
+   pmsg-size = <0x0 0x5>;
+   memory-region = <_mem>;
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+ 

[PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Jianqun Xu]

This patch adds rk3399.dtsi for rk3399 found on Rockchip
RK3399 SoCs, also add rk3399-evb.dts for Rockchip RK3399
Evaluation Board.

Patch is tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
 arch/arm64/boot/dts/rockchip/Makefile   |1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts |  537 
 arch/arm64/boot/dts/rockchip/rk3399.dtsi| 1757 +++
 3 files changed, 2295 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..4cb0028
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,537 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Rockchip RK3399 Evaluation Board";
+   compatible = "rockchip,evb", "rockchip,rk3399-evb";
+
+   chosen {
+   bootargs = "console=uart,mmio32,0xff1a";
+   };
+
+   ramoops_mem: ramoops_mem {
+   reg = <0x0 0x10 0x0 0x10>;
+   reg-names = "ramoops_mem";
+   };
+
+   ramoops {
+   compatible = "ramoops";
+   record-size = <0x0 0x2>;
+   console-size = <0x0 0x8>;
+   ftrace-size = <0x0 0x1>;
+   pmsg-size = <0x0 0x5>;
+   memory-region = <_mem>;
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  

[PATCH]powerpc/perf: Replace raw event hex values with #def

[Madhavan Srinivasan]

Minor cleanup patch to replace the raw event hex values in
power8-pmu.c with #def.

Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power8-events-list.h | 42 ++
 arch/powerpc/perf/power8-pmu.c | 41 +
 2 files changed, 63 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/perf/power8-events-list.h 
b/arch/powerpc/perf/power8-events-list.h
index 741b77edd03e..fc9ff370b199 100644
--- a/arch/powerpc/perf/power8-events-list.h
+++ b/arch/powerpc/perf/power8-events-list.h
@@ -49,3 +49,45 @@ EVENT(PM_L3_PREF_ALL,0x4e052)
 EVENT(PM_DTLB_MISS,0x300fc)
 /* ITLB Reloaded */
 EVENT(PM_ITLB_MISS,0x400fc)
+/* Run_Instructions */
+EVENT(PM_RUN_INST_CMPL,0x500fa)
+/* Alternate event code for PM_RUN_INST_CMPL */
+EVENT(_PM_RUN_INST_CMPL,   0x400fa)
+/* Run_cycles */
+EVENT(PM_RUN_CYC,  0x600f4)
+/* Alternate event code for Run_cycles */
+EVENT(_PM_RUN_CYC, 0x200f4)
+/* Marked store completed */
+EVENT(PM_MRK_ST_CMPL,  0x10134)
+/* Alternate event code for Marked store completed */
+EVENT(_PM_MRK_ST_CMPL, 0x301e2)
+/* PM_BR_MRK_2PATH */
+EVENT(PM_BR_MRK_2PATH, 0x10138)
+/* Alternate event code for PM_BR_MRK_2PATH */
+EVENT(PM_BR_MRK_2PATH, 0x40138)
+/* PM_L3_CO_MEPF */
+EVENT(PM_L3_CO_MEPF,   0x18082)
+/* Alternate event code for PM_L3_CO_MEPF */
+EVENT(_PM_L3_CO_MEPF,  0x3e05e)
+/* PM_MRK_DATA_FROM_L2MISS */
+EVENT(PM_MRK_DATA_FROM_L2MISS, 0x1d14e)
+/* Alternate event code for PM_MRK_DATA_FROM_L2MISS */
+EVENT(_PM_MRK_DATA_FROM_L2MISS,0x401e8)
+/* PM_CMPLU_STALL */
+EVENT(PM_CMPLU_STALL,  0x1e054)
+/* Alternate event code for  PM_CMPLU_STALL */
+EVENT(_PM_CMPLU_STALL, 0x4000a)
+/* PM_BR_2PATH */
+EVENT(PM_BR_2PATH, 0x20036)
+/* Alternate event code for PM_BR_2PATH */
+EVENT(_PM_BR_2PATH,0x40036)
+/* PM_INST_DISP */
+EVENT(PM_INST_DISP,0x200f2)
+/* Alternate event code for PM_INST_DISP */
+EVENT(_PM_INST_DISP,   0x300f2)
+/* PM_MRK_FILT_MATCH */
+EVENT(PM_MRK_FILT_MATCH,   0x2013c)
+/* Alternate event code for PM_MRK_FILT_MATCH */
+EVENT(_PM_MRK_FILT_MATCH,  0x3012e)
+/* Alternate event code for PM_LD_MISS_L1 */
+EVENT(_PM_LD_MISS_L1,  0x400f0)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 690d9186a855..0d7a176fcd74 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -274,7 +274,8 @@ static int power8_get_constraint(u64 event, unsigned long 
*maskp, unsigned long
/* Ignore Linux defined bits when checking event below */
base_event = event & ~EVENT_LINUX_MASK;
 
-   if (pmc >= 5 && base_event != 0x500fa && base_event != 0x600f4)
+   if (pmc >= 5 && base_event != PM_RUN_INST_CMPL &&
+   base_event != PM_RUN_CYC)
return -1;
 
mask  |= CNST_PMC_MASK(pmc);
@@ -488,17 +489,17 @@ static int power8_compute_mmcr(u64 event[], int n_ev,
 
 /* Table of alternatives, sorted by column 0 */
 static const unsigned int event_alternatives[][MAX_ALT] = {
-   { 0x10134, 0x301e2 },   /* PM_MRK_ST_CMPL */
-   { 0x10138, 0x40138 },   /* PM_BR_MRK_2PATH */
-   { 0x18082, 0x3e05e },   /* PM_L3_CO_MEPF */
-   { 0x1d14e, 0x401e8 },   /* PM_MRK_DATA_FROM_L2MISS */
-   { 0x1e054, 0x4000a },   /* PM_CMPLU_STALL */
-   { 0x20036, 0x40036 },   /* PM_BR_2PATH */
-   { 0x200f2, 0x300f2 },   /* PM_INST_DISP */
-   { 0x200f4, 0x600f4 },   /* PM_RUN_CYC */
-   { 0x2013c, 0x3012e },   /* PM_MRK_FILT_MATCH */
-   { 0x3e054, 0x400f0 },   /* PM_LD_MISS_L1 */
-   { 0x400fa, 0x500fa },   /* PM_RUN_INST_CMPL */
+   { PM_MRK_ST_CMPL,   _PM_MRK_ST_CMPL },
+   { PM_BR_MRK_2PATH,  _PM_BR_MRK_2PATH },
+   { PM_L3_CO_MEPF,_PM_L3_CO_MEPF },
+   { PM_MRK_DATA_FROM_L2MISS,  _PM_MRK_DATA_FROM_L2MISS },
+   { PM_CMPLU_STALL,   _PM_CMPLU_STALL },
+   { PM_BR_2PATH,  _PM_BR_2PATH },
+   { PM_INST_DISP, _PM_INST_DISP },
+   { _PM_RUN_CYC,  PM_RUN_CYC },
+   { PM_MRK_FILT_MATCH,_PM_MRK_FILT_MATCH },
+   { PM_LD_MISS_L1,_PM_LD_MISS_L1 },
+   { _PM_RUN_INST_CMPL,PM_RUN_INST_CMPL 

[PATCH]powerpc/perf: Replace raw event hex values with #def

[Madhavan Srinivasan]

Minor cleanup patch to replace the raw event hex values in
power8-pmu.c with #def.

Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power8-events-list.h | 42 ++
 arch/powerpc/perf/power8-pmu.c | 41 +
 2 files changed, 63 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/perf/power8-events-list.h 
b/arch/powerpc/perf/power8-events-list.h
index 741b77edd03e..fc9ff370b199 100644
--- a/arch/powerpc/perf/power8-events-list.h
+++ b/arch/powerpc/perf/power8-events-list.h
@@ -49,3 +49,45 @@ EVENT(PM_L3_PREF_ALL,0x4e052)
 EVENT(PM_DTLB_MISS,0x300fc)
 /* ITLB Reloaded */
 EVENT(PM_ITLB_MISS,0x400fc)
+/* Run_Instructions */
+EVENT(PM_RUN_INST_CMPL,0x500fa)
+/* Alternate event code for PM_RUN_INST_CMPL */
+EVENT(_PM_RUN_INST_CMPL,   0x400fa)
+/* Run_cycles */
+EVENT(PM_RUN_CYC,  0x600f4)
+/* Alternate event code for Run_cycles */
+EVENT(_PM_RUN_CYC, 0x200f4)
+/* Marked store completed */
+EVENT(PM_MRK_ST_CMPL,  0x10134)
+/* Alternate event code for Marked store completed */
+EVENT(_PM_MRK_ST_CMPL, 0x301e2)
+/* PM_BR_MRK_2PATH */
+EVENT(PM_BR_MRK_2PATH, 0x10138)
+/* Alternate event code for PM_BR_MRK_2PATH */
+EVENT(PM_BR_MRK_2PATH, 0x40138)
+/* PM_L3_CO_MEPF */
+EVENT(PM_L3_CO_MEPF,   0x18082)
+/* Alternate event code for PM_L3_CO_MEPF */
+EVENT(_PM_L3_CO_MEPF,  0x3e05e)
+/* PM_MRK_DATA_FROM_L2MISS */
+EVENT(PM_MRK_DATA_FROM_L2MISS, 0x1d14e)
+/* Alternate event code for PM_MRK_DATA_FROM_L2MISS */
+EVENT(_PM_MRK_DATA_FROM_L2MISS,0x401e8)
+/* PM_CMPLU_STALL */
+EVENT(PM_CMPLU_STALL,  0x1e054)
+/* Alternate event code for  PM_CMPLU_STALL */
+EVENT(_PM_CMPLU_STALL, 0x4000a)
+/* PM_BR_2PATH */
+EVENT(PM_BR_2PATH, 0x20036)
+/* Alternate event code for PM_BR_2PATH */
+EVENT(_PM_BR_2PATH,0x40036)
+/* PM_INST_DISP */
+EVENT(PM_INST_DISP,0x200f2)
+/* Alternate event code for PM_INST_DISP */
+EVENT(_PM_INST_DISP,   0x300f2)
+/* PM_MRK_FILT_MATCH */
+EVENT(PM_MRK_FILT_MATCH,   0x2013c)
+/* Alternate event code for PM_MRK_FILT_MATCH */
+EVENT(_PM_MRK_FILT_MATCH,  0x3012e)
+/* Alternate event code for PM_LD_MISS_L1 */
+EVENT(_PM_LD_MISS_L1,  0x400f0)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 690d9186a855..0d7a176fcd74 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -274,7 +274,8 @@ static int power8_get_constraint(u64 event, unsigned long 
*maskp, unsigned long
/* Ignore Linux defined bits when checking event below */
base_event = event & ~EVENT_LINUX_MASK;
 
-   if (pmc >= 5 && base_event != 0x500fa && base_event != 0x600f4)
+   if (pmc >= 5 && base_event != PM_RUN_INST_CMPL &&
+   base_event != PM_RUN_CYC)
return -1;
 
mask  |= CNST_PMC_MASK(pmc);
@@ -488,17 +489,17 @@ static int power8_compute_mmcr(u64 event[], int n_ev,
 
 /* Table of alternatives, sorted by column 0 */
 static const unsigned int event_alternatives[][MAX_ALT] = {
-   { 0x10134, 0x301e2 },   /* PM_MRK_ST_CMPL */
-   { 0x10138, 0x40138 },   /* PM_BR_MRK_2PATH */
-   { 0x18082, 0x3e05e },   /* PM_L3_CO_MEPF */
-   { 0x1d14e, 0x401e8 },   /* PM_MRK_DATA_FROM_L2MISS */
-   { 0x1e054, 0x4000a },   /* PM_CMPLU_STALL */
-   { 0x20036, 0x40036 },   /* PM_BR_2PATH */
-   { 0x200f2, 0x300f2 },   /* PM_INST_DISP */
-   { 0x200f4, 0x600f4 },   /* PM_RUN_CYC */
-   { 0x2013c, 0x3012e },   /* PM_MRK_FILT_MATCH */
-   { 0x3e054, 0x400f0 },   /* PM_LD_MISS_L1 */
-   { 0x400fa, 0x500fa },   /* PM_RUN_INST_CMPL */
+   { PM_MRK_ST_CMPL,   _PM_MRK_ST_CMPL },
+   { PM_BR_MRK_2PATH,  _PM_BR_MRK_2PATH },
+   { PM_L3_CO_MEPF,_PM_L3_CO_MEPF },
+   { PM_MRK_DATA_FROM_L2MISS,  _PM_MRK_DATA_FROM_L2MISS },
+   { PM_CMPLU_STALL,   _PM_CMPLU_STALL },
+   { PM_BR_2PATH,  _PM_BR_2PATH },
+   { PM_INST_DISP, _PM_INST_DISP },
+   { _PM_RUN_CYC,  PM_RUN_CYC },
+   { PM_MRK_FILT_MATCH,_PM_MRK_FILT_MATCH },
+   { PM_LD_MISS_L1,_PM_LD_MISS_L1 },
+   { _PM_RUN_INST_CMPL,PM_RUN_INST_CMPL },
 };
 
 /*
@@ -546,17 

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

[Dong Aisheng]

On Fri, Jan 29, 2016 at 02:49:23PM -0800, Stefan Agner wrote:
> If a clock gets enabled early during boot time, it can lead to a PLL
> startup. The wait_lock function makes sure that the PLL is really
> stareted up before it gets used. However, the function sleeps which
> leads to scheduling and an error:
> bad: scheduling from the idle thread!
> ...
> 
> Use udelay in case IRQ's are still disabled.
> 
> Signed-off-by: Stefan Agner 
> ---
>  drivers/clk/imx/clk-pllv3.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index c05c43d..b5ff561 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -63,7 +63,10 @@ static int clk_pllv3_wait_lock(struct clk_pllv3 *pll)
>   break;
>   if (time_after(jiffies, timeout))
>   break;
> - usleep_range(50, 500);
> + if (unlikely(irqs_disabled()))

This causes a bit confusion that clk_pllv3_prepare is sleepable.
But this line indicates it's possible to be called in irq context.
Although it's only happened during kernel boot phase where irq is
still not enabled.
It seems schedule_debug() somehow did not catch it during early boot
phase. Maybe schedule guys can help explain.

My question is if it's really worthy to introduce this confusion
to fix the issue since the delay is minor?

Furthermore, shouldn't it be udelay(500)?

Shawn,
What's your idea?

Regards
Dong Aisheng

> + udelay(50);
> + else
> + usleep_range(50, 500);
>   } while (1);
>  
>   return readl_relaxed(pll->base) & BM_PLL_LOCK ? 0 : -ETIMEDOUT;
> -- 
> 2.7.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

[Dong Aisheng]

On Fri, Jan 29, 2016 at 02:49:23PM -0800, Stefan Agner wrote:
> If a clock gets enabled early during boot time, it can lead to a PLL
> startup. The wait_lock function makes sure that the PLL is really
> stareted up before it gets used. However, the function sleeps which
> leads to scheduling and an error:
> bad: scheduling from the idle thread!
> ...
> 
> Use udelay in case IRQ's are still disabled.
> 
> Signed-off-by: Stefan Agner 
> ---
>  drivers/clk/imx/clk-pllv3.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index c05c43d..b5ff561 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -63,7 +63,10 @@ static int clk_pllv3_wait_lock(struct clk_pllv3 *pll)
>   break;
>   if (time_after(jiffies, timeout))
>   break;
> - usleep_range(50, 500);
> + if (unlikely(irqs_disabled()))

This causes a bit confusion that clk_pllv3_prepare is sleepable.
But this line indicates it's possible to be called in irq context.
Although it's only happened during kernel boot phase where irq is
still not enabled.
It seems schedule_debug() somehow did not catch it during early boot
phase. Maybe schedule guys can help explain.

My question is if it's really worthy to introduce this confusion
to fix the issue since the delay is minor?

Furthermore, shouldn't it be udelay(500)?

Shawn,
What's your idea?

Regards
Dong Aisheng

> + udelay(50);
> + else
> + usleep_range(50, 500);
>   } while (1);
>  
>   return readl_relaxed(pll->base) & BM_PLL_LOCK ? 0 : -ETIMEDOUT;
> -- 
> 2.7.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v2 0/3] drivers: net: cpsw: phy-handle fixes

[David Rivshin (Allworx)]

From: David Rivshin 

The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.

The second patch fixes some cosmetic problems with error messages,
and also makes the binding documentation more explicit.

The third patch cleans up the fixed-link case to work like
the now-fixed phy-handle case.

I have tested on the following hardware configurations:
 - (EVMSK) dual emac, phy_id property in both slaves
 - (EVMSK) dual emac, phy-handle property in both slaves
 - (BeagleBoneBlack) single emac, phy_id property
 - (custom) single emac, fixed-link subnode

Nicolas Chauvet reported testing on an HP t410 (dm8148).

Markus Brunner reported testing v1 on the following [1]:
 - emac0 with phy_id and emac1 with fixed phy
 - emac0 with phy-handle and emac1 with fixed phy
 - emac0 with fixed phy and emac1 with fixed phy


Changes since v1 [2]:
- Rebased
- Added Tested-by from Nicolas Chauvet on all patches
- Added Acked-by from Rob Herring for the binding change in patch 2 [3]

[1] http://www.spinics.net/lists/netdev/msg357890.html
[2] http://www.spinics.net/lists/netdev/msg357772.html
[3] http://www.spinics.net/lists/netdev/msg358254.html

David Rivshin (3):
  drivers: net: cpsw: fix parsing of phy-handle DT property in dual_emac
config
  drivers: net: cpsw: fix error messages when using phy-handle DT
property
  drivers: net: cpsw: use of_phy_connect() in fixed-link case

 Documentation/devicetree/bindings/net/cpsw.txt |  4 +--
 drivers/net/ethernet/ti/cpsw.c | 41 +-
 drivers/net/ethernet/ti/cpsw.h |  1 +
 3 files changed, 23 insertions(+), 23 deletions(-)

-- 
2.5.5

[PATCH net v2 0/3] drivers: net: cpsw: phy-handle fixes

[David Rivshin (Allworx)]

From: David Rivshin 

The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.

The second patch fixes some cosmetic problems with error messages,
and also makes the binding documentation more explicit.

The third patch cleans up the fixed-link case to work like
the now-fixed phy-handle case.

I have tested on the following hardware configurations:
 - (EVMSK) dual emac, phy_id property in both slaves
 - (EVMSK) dual emac, phy-handle property in both slaves
 - (BeagleBoneBlack) single emac, phy_id property
 - (custom) single emac, fixed-link subnode

Nicolas Chauvet reported testing on an HP t410 (dm8148).

Markus Brunner reported testing v1 on the following [1]:
 - emac0 with phy_id and emac1 with fixed phy
 - emac0 with phy-handle and emac1 with fixed phy
 - emac0 with fixed phy and emac1 with fixed phy


Changes since v1 [2]:
- Rebased
- Added Tested-by from Nicolas Chauvet on all patches
- Added Acked-by from Rob Herring for the binding change in patch 2 [3]

[1] http://www.spinics.net/lists/netdev/msg357890.html
[2] http://www.spinics.net/lists/netdev/msg357772.html
[3] http://www.spinics.net/lists/netdev/msg358254.html

David Rivshin (3):
  drivers: net: cpsw: fix parsing of phy-handle DT property in dual_emac
config
  drivers: net: cpsw: fix error messages when using phy-handle DT
property
  drivers: net: cpsw: use of_phy_connect() in fixed-link case

 Documentation/devicetree/bindings/net/cpsw.txt |  4 +--
 drivers/net/ethernet/ti/cpsw.c | 41 +-
 drivers/net/ethernet/ti/cpsw.h |  1 +
 3 files changed, 23 insertions(+), 23 deletions(-)

-- 
2.5.5

Re: [RESEND][PATCH 1/3] thermal: mediatek: Add cpu dynamic power cooling model.

[Eduardo Valentin]

On Wed, Apr 20, 2016 at 08:01:41PM -0700, Eduardo Valentin wrote:
> On Thu, Apr 21, 2016 at 02:41:24AM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, April 20, 2016 01:58:07 PM Matthias Brugger wrote:
> > > Hi Rafael,
> > > 
> > > On 13/04/16 06:52, Rafael J. Wysocki wrote:
> > > > On Tue, Apr 12, 2016 at 7:38 AM, Viresh Kumar  
> > > > wrote:
> > > >> Hi Rafael,
> > > >>
> > > >> On 15-03-16, 16:10, Dawei Chien wrote:
> > > >>> MT8173 cpufreq driver select of_cpufreq_power_cooling_register 
> > > >>> registering
> > > >>> cooling devices with dynamic power coefficient.
> > > >>>
> > > >>> Signed-off-by: Dawei Chien 
> > > >>> Acked-by: Viresh Kumar 
> > > >>
> > > >> Can you please apply this patch from Dawei ?
> > > >
> > > > I can, but I'm traveling this week, so that's rather going to happen 
> > > > next week.
> > > >
> > > 
> > > I don't see the patch in linux-next, did you forget to pick/push it?
> > 
> > No, I didn't.  I just didn't have the time to get to them before.
> > 
> > Now, given that they are thermal patches, they really should go in via
> > linux-soc-thermal.git.
> > 
> > Eduardo, any chance to take care of these?
> 
> Yes I can add this one, given that they have the proper acked-by. I was
> a bit hesitant to just get them because they are touching
> drivers/cpufreq. 
> 
> Anyways, I am adding this to my branch to the next merge window.

Added the driver changes. The dt parts should go via your platform tree.
And you can add my 
Acked-by: Eduardo Valentin 

on the dt changes.

> 
> 
> > 
> > Thanks,
> > Rafael
> > 

Re: [RESEND][PATCH 1/3] thermal: mediatek: Add cpu dynamic power cooling model.

[Eduardo Valentin]

On Wed, Apr 20, 2016 at 08:01:41PM -0700, Eduardo Valentin wrote:
> On Thu, Apr 21, 2016 at 02:41:24AM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, April 20, 2016 01:58:07 PM Matthias Brugger wrote:
> > > Hi Rafael,
> > > 
> > > On 13/04/16 06:52, Rafael J. Wysocki wrote:
> > > > On Tue, Apr 12, 2016 at 7:38 AM, Viresh Kumar  
> > > > wrote:
> > > >> Hi Rafael,
> > > >>
> > > >> On 15-03-16, 16:10, Dawei Chien wrote:
> > > >>> MT8173 cpufreq driver select of_cpufreq_power_cooling_register 
> > > >>> registering
> > > >>> cooling devices with dynamic power coefficient.
> > > >>>
> > > >>> Signed-off-by: Dawei Chien 
> > > >>> Acked-by: Viresh Kumar 
> > > >>
> > > >> Can you please apply this patch from Dawei ?
> > > >
> > > > I can, but I'm traveling this week, so that's rather going to happen 
> > > > next week.
> > > >
> > > 
> > > I don't see the patch in linux-next, did you forget to pick/push it?
> > 
> > No, I didn't.  I just didn't have the time to get to them before.
> > 
> > Now, given that they are thermal patches, they really should go in via
> > linux-soc-thermal.git.
> > 
> > Eduardo, any chance to take care of these?
> 
> Yes I can add this one, given that they have the proper acked-by. I was
> a bit hesitant to just get them because they are touching
> drivers/cpufreq. 
> 
> Anyways, I am adding this to my branch to the next merge window.

Added the driver changes. The dt parts should go via your platform tree.
And you can add my 
Acked-by: Eduardo Valentin 

on the dt changes.

> 
> 
> > 
> > Thanks,
> > Rafael
> > 

Re: [PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge()

[Michal Hocko]

On Wed 20-04-16 17:29:22, Tejun Heo wrote:
> Hello, Michal.
> 
> On Sun, Apr 17, 2016 at 08:07:48AM -0400, Michal Hocko wrote:
[...]
> > I liked your proposal when mem_cgroup_move_charge would be called from a
> > context which doesn't hold the problematic rwsem much more. Would that
> > be too intrusive for the stable backport?
> 
> Yeah, I'm working on the fix but let's plug this one first as it seems
> really easy to trigger.  I got a couple off-list reports (in and
> outside fb) of this triggering.

Sure, I think we can use this for an immediate workaround. Nevertheless
we want to have a full fix and do not rely on this being the only
problem. I would eventually like to reintroduce the draining later when
we have a better fix because even though this is not a correctness
problem I think we should try hard to not leave anything behind.

That being said:
Acked-by: Michal Hocko 
-- 
Michal Hocko
SUSE Labs

Re: [PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge()

[Michal Hocko]

On Wed 20-04-16 17:29:22, Tejun Heo wrote:
> Hello, Michal.
> 
> On Sun, Apr 17, 2016 at 08:07:48AM -0400, Michal Hocko wrote:
[...]
> > I liked your proposal when mem_cgroup_move_charge would be called from a
> > context which doesn't hold the problematic rwsem much more. Would that
> > be too intrusive for the stable backport?
> 
> Yeah, I'm working on the fix but let's plug this one first as it seems
> really easy to trigger.  I got a couple off-list reports (in and
> outside fb) of this triggering.

Sure, I think we can use this for an immediate workaround. Nevertheless
we want to have a full fix and do not rely on this being the only
problem. I would eventually like to reintroduce the draining later when
we have a better fix because even though this is not a correctness
problem I think we should try hard to not leave anything behind.

That being said:
Acked-by: Michal Hocko 
-- 
Michal Hocko
SUSE Labs

Re: mce: a question about memory_failure_early_kill in memory_failure()

[Xishi Qiu]

On 2016/4/21 7:15, Naoya Horiguchi wrote:

> On Wed, Apr 20, 2016 at 06:58:59PM +0800, Xishi Qiu wrote:
>> On 2016/4/20 18:51, Xishi Qiu wrote:
>>
>>> On 2016/4/20 15:07, Naoya Horiguchi wrote:
>>>
 On Tue, Apr 19, 2016 at 07:13:34PM +0800, Xishi Qiu wrote:
> /proc/sys/vm/memory_failure_early_kill
>
> 1: means kill all processes that have the corrupted and not reloadable 
> page mapped.
> 0: means only unmap the corrupted page from all processes and only kill a 
> process
> who tries to access it.
>
> If set memory_failure_early_kill to 0, and memory_failure() has been 
> called.
> memory_failure()
>   hwpoison_user_mappings()
>   collect_procs()  // the task(with no PF_MCE_PROCESS flag) is 
> not in the tokill list
>   try_to_unmap()
>
> If the task access the memory, there will be a page fault,
> so the task can not access the original page again, right?

 Yes, right. That's the behavior in default "late kill" case.

>>>
>>> Hi Naoya,
>>>
>>> Thanks for your reply, my confusion is that after try_to_unmap(), there 
>>> will be a
>>> page fault if the task access the memory, and we will alloc a new page for 
>>> it.
> 
> When try_to_unmap() is called for PageHWPoison(page) without 
> TTU_IGNORE_HWPOISON,
> page table entries mapping the error page are replaced with hwpoison entries,

Hi Naoya,

That's right, I missed the "hwpoison entry" in try_to_unmap().

Thanks,
Xishi Qiu

> which changes the bahavior of a subsequent page fault. Then, the page fault 
> will
> fail with VM_FAULT_HWPOISON, so finally the process will be killed without 
> allocating
> a new page.
> 
>>
>> Hi Naoya,
>>
>> If we alloc a new page, the task won't access the poisioned page again, so 
>> it won't be
>> killed by mce(late kill), right?
> 
> Allocating a new page for virtual address affected by memory error is 
> dangerous
> because if the error page was dirty (or anonymous as you mentioned), the data
> is lost and new page allocation means that the data lost is ignored. The first
> priority of hwpoison mechanism is to avoid consuming corrupted data.
> 
>> If the poisioned page is anon, we will lost data, right?
> 
> Yes, that's the idea.
> 
>>
>>> So how the hardware(mce) know this page fault is relate to the poisioned 
>>> page which
>>> is unmapped from the task? 
>>>
>>> Will we record something in pte when after try_to_unmap() in 
>>> memory_failure()?
> 
> As mentioned above, hwpoison entry does this job.
> 
> Thanks,
> Naoya Horiguchi
> .
> 

Re: mce: a question about memory_failure_early_kill in memory_failure()

[Xishi Qiu]

On 2016/4/21 7:15, Naoya Horiguchi wrote:

> On Wed, Apr 20, 2016 at 06:58:59PM +0800, Xishi Qiu wrote:
>> On 2016/4/20 18:51, Xishi Qiu wrote:
>>
>>> On 2016/4/20 15:07, Naoya Horiguchi wrote:
>>>
 On Tue, Apr 19, 2016 at 07:13:34PM +0800, Xishi Qiu wrote:
> /proc/sys/vm/memory_failure_early_kill
>
> 1: means kill all processes that have the corrupted and not reloadable 
> page mapped.
> 0: means only unmap the corrupted page from all processes and only kill a 
> process
> who tries to access it.
>
> If set memory_failure_early_kill to 0, and memory_failure() has been 
> called.
> memory_failure()
>   hwpoison_user_mappings()
>   collect_procs()  // the task(with no PF_MCE_PROCESS flag) is 
> not in the tokill list
>   try_to_unmap()
>
> If the task access the memory, there will be a page fault,
> so the task can not access the original page again, right?

 Yes, right. That's the behavior in default "late kill" case.

>>>
>>> Hi Naoya,
>>>
>>> Thanks for your reply, my confusion is that after try_to_unmap(), there 
>>> will be a
>>> page fault if the task access the memory, and we will alloc a new page for 
>>> it.
> 
> When try_to_unmap() is called for PageHWPoison(page) without 
> TTU_IGNORE_HWPOISON,
> page table entries mapping the error page are replaced with hwpoison entries,

Hi Naoya,

That's right, I missed the "hwpoison entry" in try_to_unmap().

Thanks,
Xishi Qiu

> which changes the bahavior of a subsequent page fault. Then, the page fault 
> will
> fail with VM_FAULT_HWPOISON, so finally the process will be killed without 
> allocating
> a new page.
> 
>>
>> Hi Naoya,
>>
>> If we alloc a new page, the task won't access the poisioned page again, so 
>> it won't be
>> killed by mce(late kill), right?
> 
> Allocating a new page for virtual address affected by memory error is 
> dangerous
> because if the error page was dirty (or anonymous as you mentioned), the data
> is lost and new page allocation means that the data lost is ignored. The first
> priority of hwpoison mechanism is to avoid consuming corrupted data.
> 
>> If the poisioned page is anon, we will lost data, right?
> 
> Yes, that's the idea.
> 
>>
>>> So how the hardware(mce) know this page fault is relate to the poisioned 
>>> page which
>>> is unmapped from the task? 
>>>
>>> Will we record something in pte when after try_to_unmap() in 
>>> memory_failure()?
> 
> As mentioned above, hwpoison entry does this job.
> 
> Thanks,
> Naoya Horiguchi
> .
> 

Re: linux-next crash during very early boot

[Valdis . Kletnieks]

On Fri, 15 Apr 2016 10:10:33 -0400, valdis.kletni...@vt.edu said:
> On Thu, 14 Apr 2016 10:35:47 +0900, Joonsoo Kim said:
> > On Wed, Apr 13, 2016 at 08:29:46PM -0400, Valdis Kletnieks wrote:
> > > I'm seeing my laptop crash/wedge up/something during very early
> > > boot - before it can write anything to the console.  Nothing in pstore,
> > > need to hold down the power button for 6 seconds and reboot.
> > >
> > > git bisect points at:
> > >
> > > commit 7a6bacb133752beacb76775797fd550417e9d3a2
> > > Author: Joonsoo Kim <iamjoonsoo@lge.com>
> > > Date:   Thu Apr 7 13:59:39 2016 +1000
> > >
> > > mm/slab: factor out kmem_cache_node initialization code
> > >
> > > It can be reused on other place, so factor out it.  Following patch 
> > > will
> > > use it.
> > >
> > >
> > > Not sure what the problem is - the logic *looks* ok at first read.  The
> > > patch *does* remove a spin_lock_irq() - but I find it difficult to
> > > believe that with it gone, my laptop is able to hit the race condition
> > > the spinlock protects against *every single boot*.
> > >
> > > The only other thing I see is that n->free_limit used to be assigned
> > > every time, and now it's only assigned at initial creation.
> >
> > Hello,
> >
> > My fault. It should be assgined every time. Please test below patch.
> > I will send it with proper SOB after you confirm the problem disappear.
> > Thanks for report and analysis!
>
> Following up - I verified that it was your patch series and not a bad bisect
> by starting with a clean next-20160413 and reverting that series - and the
> resulting kernel boots fine.

Following up some more - next-20160420 seems to work just fine, even with
no sign in 'git log -- mm/slab.c' of the fix-patch

I'm obviously having a very bad "things that go bump in the night" with
kernels lately - this makes 3 different "makes no sense" things I've posted
in the last 6 hours... :)


pgpl0clM2riRP.pgp
Description: PGP signature

[PATCH] perf/bench-futex: Simplify wrapper for LOCK_PI

[Davidlohr Bueso]

Given that the 'val' parameter is ignored for FUTEX_LOCK_PI,
get rid of the bogus deadlock detection flag in the wrapper
code and avoid the extra argument, making it resemble its unlock
counterpart. And if nothing else, we already only pass 0 anyway.

Signed-off-by: Davidlohr Bueso 
---
 tools/perf/bench/futex-lock-pi.c | 2 +-
 tools/perf/bench/futex.h | 6 ++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/tools/perf/bench/futex-lock-pi.c b/tools/perf/bench/futex-lock-pi.c
index 6a18ce21f865..6952db65508a 100644
--- a/tools/perf/bench/futex-lock-pi.c
+++ b/tools/perf/bench/futex-lock-pi.c
@@ -83,7 +83,7 @@ static void *workerfn(void *arg)
do {
int ret;
again:
-   ret = futex_lock_pi(w->futex, NULL, 0, futex_flag);
+   ret = futex_lock_pi(w->futex, NULL, futex_flag);
 
if (ret) { /* handle lock acquisition */
if (!silent)
diff --git a/tools/perf/bench/futex.h b/tools/perf/bench/futex.h
index aca900fdc788..f0501edba0e7 100644
--- a/tools/perf/bench/futex.h
+++ b/tools/perf/bench/futex.h
@@ -57,13 +57,11 @@ futex_wake(u_int32_t *uaddr, int nr_wake, int opflags)
 
 /**
  * futex_lock_pi() - block on uaddr as a PI mutex
- * @detect:whether (1) or not (0) to perform deadlock detection
  */
 static inline int
-futex_lock_pi(u_int32_t *uaddr, struct timespec *timeout, int detect,
- int opflags)
+futex_lock_pi(u_int32_t *uaddr, struct timespec *timeout, int opflags)
 {
-   return futex(uaddr, FUTEX_LOCK_PI, detect, timeout, NULL, 0, opflags);
+   return futex(uaddr, FUTEX_LOCK_PI, 0, timeout, NULL, 0, opflags);
 }
 
 /**
-- 
2.8.1

Re: linux-next crash during very early boot

[Valdis . Kletnieks]

On Fri, 15 Apr 2016 10:10:33 -0400, valdis.kletni...@vt.edu said:
> On Thu, 14 Apr 2016 10:35:47 +0900, Joonsoo Kim said:
> > On Wed, Apr 13, 2016 at 08:29:46PM -0400, Valdis Kletnieks wrote:
> > > I'm seeing my laptop crash/wedge up/something during very early
> > > boot - before it can write anything to the console.  Nothing in pstore,
> > > need to hold down the power button for 6 seconds and reboot.
> > >
> > > git bisect points at:
> > >
> > > commit 7a6bacb133752beacb76775797fd550417e9d3a2
> > > Author: Joonsoo Kim 
> > > Date:   Thu Apr 7 13:59:39 2016 +1000
> > >
> > > mm/slab: factor out kmem_cache_node initialization code
> > >
> > > It can be reused on other place, so factor out it.  Following patch 
> > > will
> > > use it.
> > >
> > >
> > > Not sure what the problem is - the logic *looks* ok at first read.  The
> > > patch *does* remove a spin_lock_irq() - but I find it difficult to
> > > believe that with it gone, my laptop is able to hit the race condition
> > > the spinlock protects against *every single boot*.
> > >
> > > The only other thing I see is that n->free_limit used to be assigned
> > > every time, and now it's only assigned at initial creation.
> >
> > Hello,
> >
> > My fault. It should be assgined every time. Please test below patch.
> > I will send it with proper SOB after you confirm the problem disappear.
> > Thanks for report and analysis!
>
> Following up - I verified that it was your patch series and not a bad bisect
> by starting with a clean next-20160413 and reverting that series - and the
> resulting kernel boots fine.

Following up some more - next-20160420 seems to work just fine, even with
no sign in 'git log -- mm/slab.c' of the fix-patch

I'm obviously having a very bad "things that go bump in the night" with
kernels lately - this makes 3 different "makes no sense" things I've posted
in the last 6 hours... :)


pgpl0clM2riRP.pgp
Description: PGP signature

[PATCH] perf/bench-futex: Simplify wrapper for LOCK_PI

[Davidlohr Bueso]

Given that the 'val' parameter is ignored for FUTEX_LOCK_PI,
get rid of the bogus deadlock detection flag in the wrapper
code and avoid the extra argument, making it resemble its unlock
counterpart. And if nothing else, we already only pass 0 anyway.

Signed-off-by: Davidlohr Bueso 
---
 tools/perf/bench/futex-lock-pi.c | 2 +-
 tools/perf/bench/futex.h | 6 ++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/tools/perf/bench/futex-lock-pi.c b/tools/perf/bench/futex-lock-pi.c
index 6a18ce21f865..6952db65508a 100644
--- a/tools/perf/bench/futex-lock-pi.c
+++ b/tools/perf/bench/futex-lock-pi.c
@@ -83,7 +83,7 @@ static void *workerfn(void *arg)
do {
int ret;
again:
-   ret = futex_lock_pi(w->futex, NULL, 0, futex_flag);
+   ret = futex_lock_pi(w->futex, NULL, futex_flag);
 
if (ret) { /* handle lock acquisition */
if (!silent)
diff --git a/tools/perf/bench/futex.h b/tools/perf/bench/futex.h
index aca900fdc788..f0501edba0e7 100644
--- a/tools/perf/bench/futex.h
+++ b/tools/perf/bench/futex.h
@@ -57,13 +57,11 @@ futex_wake(u_int32_t *uaddr, int nr_wake, int opflags)
 
 /**
  * futex_lock_pi() - block on uaddr as a PI mutex
- * @detect:whether (1) or not (0) to perform deadlock detection
  */
 static inline int
-futex_lock_pi(u_int32_t *uaddr, struct timespec *timeout, int detect,
- int opflags)
+futex_lock_pi(u_int32_t *uaddr, struct timespec *timeout, int opflags)
 {
-   return futex(uaddr, FUTEX_LOCK_PI, detect, timeout, NULL, 0, opflags);
+   return futex(uaddr, FUTEX_LOCK_PI, 0, timeout, NULL, 0, opflags);
 }
 
 /**
-- 
2.8.1

Re: [PATCH 1/4] i2c: designware-platdrv: Fix runtime PM initialization

[Jisheng Zhang]

Dear Jarkko,

On Wed, 20 Apr 2016 16:53:08 +0300 Jarkko Nikula wrote:

> On 04/14/2016 03:53 PM, Jisheng Zhang wrote:
> > When pm_runtime_enable() was being called, the device's usage counter
> > was 0, causing the PM layer to runtime-suspend the device.  We then
> > went on to call i2c_dw_probe() on a suspended device, which could hung.
> >
> > Fix this by incrementing the usage counter before pm_runtime_enable().
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> >   drivers/i2c/busses/i2c-designware-platdrv.c | 14 +-
> >   1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
> > b/drivers/i2c/busses/i2c-designware-platdrv.c
> > index d656657..00f9e99 100644
> > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > @@ -246,6 +246,7 @@ static int dw_i2c_plat_probe(struct platform_device 
> > *pdev)
> > if (dev->pm_runtime_disabled) {
> > pm_runtime_forbid(>dev);
> > } else {
> > +   pm_runtime_get_noresume(>dev);
> > pm_runtime_set_autosuspend_delay(>dev, 1000);
> > pm_runtime_use_autosuspend(>dev);
> > pm_runtime_set_active(>dev);  
> 
> pm_runtime_enable() here after pm_runtime_set_active() shouldn't suspend 
> as far as I understand which made me thinking if there is some other 

FWICT, on arm DT platform, the device usage counter is zero at the beginning,
once we enable rpm, the i2c have chance to runtime suspend.

Thanks,
Jisheng

> issue that cause the symptoms what you are seeing? Like race with 
> runtime PM or similar.
> 

Re: [PATCH 1/4] i2c: designware-platdrv: Fix runtime PM initialization

[Jisheng Zhang]

Dear Jarkko,

On Wed, 20 Apr 2016 16:53:08 +0300 Jarkko Nikula wrote:

> On 04/14/2016 03:53 PM, Jisheng Zhang wrote:
> > When pm_runtime_enable() was being called, the device's usage counter
> > was 0, causing the PM layer to runtime-suspend the device.  We then
> > went on to call i2c_dw_probe() on a suspended device, which could hung.
> >
> > Fix this by incrementing the usage counter before pm_runtime_enable().
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> >   drivers/i2c/busses/i2c-designware-platdrv.c | 14 +-
> >   1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
> > b/drivers/i2c/busses/i2c-designware-platdrv.c
> > index d656657..00f9e99 100644
> > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > @@ -246,6 +246,7 @@ static int dw_i2c_plat_probe(struct platform_device 
> > *pdev)
> > if (dev->pm_runtime_disabled) {
> > pm_runtime_forbid(>dev);
> > } else {
> > +   pm_runtime_get_noresume(>dev);
> > pm_runtime_set_autosuspend_delay(>dev, 1000);
> > pm_runtime_use_autosuspend(>dev);
> > pm_runtime_set_active(>dev);  
> 
> pm_runtime_enable() here after pm_runtime_set_active() shouldn't suspend 
> as far as I understand which made me thinking if there is some other 

FWICT, on arm DT platform, the device usage counter is zero at the beginning,
once we enable rpm, the i2c have chance to runtime suspend.

Thanks,
Jisheng

> issue that cause the symptoms what you are seeing? Like race with 
> runtime PM or similar.
> 

Re: [PATCH v2] drivers/idle: make intel_idle.c driver more explicitly non-modular

[Paul Gortmaker]

[Re: [PATCH v2] drivers/idle: make intel_idle.c driver more explicitly 
non-modular] On 20/04/2016 (Wed 20:13) Daniel Lezcano wrote:

> On Wed, Apr 20, 2016 at 11:25:06AM -0400, Paul Gortmaker wrote:
> > The Kconfig for this driver is currently declared with:
> > 
> > config INTEL_IDLE
> > bool "Cpuidle Driver for Intel Processors"
> > 
> > ...meaning that it currently is not being built as a module by anyone.
> > 
> > This was done in commit 6ce9cd8669fa1195fdc21643370e34523c7ac988
> > ("intel_idle: disable module support") since "...the module capability
> > is cauing more trouble than it is worth."
> > 
> > This was done over 5y ago, and Daniel adds that:
> > 
> > ...the modular support has been removed from almost all the cpuidle
> > drivers and the cpuidle framework is no longer assuming driver could
> > be unloaded.
> > 
> > Removing the modular dead code in the driver makes sense as this
> > what have been done in the others drivers.
> > 
> > So lets remove the modular code that is essentially orphaned, so that
> > when reading the driver there is no doubt it is builtin-only.
> > 
> > Since module_init translates to device_initcall in the non-modular
> > case, the init ordering remains unchanged with this commit.  At a
> > later date we might want to consider whether subsys_init or another
> > init category seems more appropriate than device_init.
> > 
> > We replace module.h with moduleparam.h since the file does declare
> > some module parameters, and leaving them as such is currently the
> > easiest way to remain compatible with existing boot arg use cases.
> 
> What about using __setup() ? so module* disappear from the file.

No, it can't be __setup since moduleparam uses an instance of the
filename as a prefix to the boot arg, and __setup does not.  And we
should stay compatible with existing boot arg use cases for people
who have embedded such a setting in their grub config a long time
ago and forgot it.  It would take looking at and likely extending the
early_param macro to provide a syntax compatible instance of what
the module_param currently does if I recall correctly -- hence the
above comment in the commit log.

Paul.
--

> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/block/brd.c#n463
>  
> > Note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> > 
> > Also note that we can't remove intel_idle_cpuidle_devices_uninit() as
> > that is still used for unwind purposes if the init fails.
> > 
> > We also delete the MODULE_LICENSE tag etc. since all that information
> > is already contained at the top of the file in the comments.
> > 
> > Cc: Len Brown 
> > Cc: Daniel Lezcano 
> > Cc: rcoch...@linutronix.de
> > Cc: linux...@vger.kernel.org
> > Signed-off-by: Paul Gortmaker 

Re: [PATCH v2] drivers/idle: make intel_idle.c driver more explicitly non-modular

[Paul Gortmaker]

[Re: [PATCH v2] drivers/idle: make intel_idle.c driver more explicitly 
non-modular] On 20/04/2016 (Wed 20:13) Daniel Lezcano wrote:

> On Wed, Apr 20, 2016 at 11:25:06AM -0400, Paul Gortmaker wrote:
> > The Kconfig for this driver is currently declared with:
> > 
> > config INTEL_IDLE
> > bool "Cpuidle Driver for Intel Processors"
> > 
> > ...meaning that it currently is not being built as a module by anyone.
> > 
> > This was done in commit 6ce9cd8669fa1195fdc21643370e34523c7ac988
> > ("intel_idle: disable module support") since "...the module capability
> > is cauing more trouble than it is worth."
> > 
> > This was done over 5y ago, and Daniel adds that:
> > 
> > ...the modular support has been removed from almost all the cpuidle
> > drivers and the cpuidle framework is no longer assuming driver could
> > be unloaded.
> > 
> > Removing the modular dead code in the driver makes sense as this
> > what have been done in the others drivers.
> > 
> > So lets remove the modular code that is essentially orphaned, so that
> > when reading the driver there is no doubt it is builtin-only.
> > 
> > Since module_init translates to device_initcall in the non-modular
> > case, the init ordering remains unchanged with this commit.  At a
> > later date we might want to consider whether subsys_init or another
> > init category seems more appropriate than device_init.
> > 
> > We replace module.h with moduleparam.h since the file does declare
> > some module parameters, and leaving them as such is currently the
> > easiest way to remain compatible with existing boot arg use cases.
> 
> What about using __setup() ? so module* disappear from the file.

No, it can't be __setup since moduleparam uses an instance of the
filename as a prefix to the boot arg, and __setup does not.  And we
should stay compatible with existing boot arg use cases for people
who have embedded such a setting in their grub config a long time
ago and forgot it.  It would take looking at and likely extending the
early_param macro to provide a syntax compatible instance of what
the module_param currently does if I recall correctly -- hence the
above comment in the commit log.

Paul.
--

> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/block/brd.c#n463
>  
> > Note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> > 
> > Also note that we can't remove intel_idle_cpuidle_devices_uninit() as
> > that is still used for unwind purposes if the init fails.
> > 
> > We also delete the MODULE_LICENSE tag etc. since all that information
> > is already contained at the top of the file in the comments.
> > 
> > Cc: Len Brown 
> > Cc: Daniel Lezcano 
> > Cc: rcoch...@linutronix.de
> > Cc: linux...@vger.kernel.org
> > Signed-off-by: Paul Gortmaker 

Re: [PATCH 0/8] STMPE fixes/rework and add STMPE1600 support

[Marcel Ziswiler]

On Wed, 2016-04-20 at 10:02 -0600, Stephen Warren wrote:
> On 04/20/2016 01:40 AM, Patrice Chotard wrote:
> > 
> > On 04/19/2016 05:53 PM, Stephen Warren wrote:
> > > 
> > > On 04/19/2016 06:18 AM, patrice.chot...@st.com wrote:
> > > > 
> > > > From: Patrice Chotard <patrice.chot...@st.com>
> > > > 
> > > > This series cleans and fixes some bugs in MFD/GPIO STMPE
> > > > drivers and
> > > > prepare
> > > >   the ground to add new STMPE1600 support.
> > > > 
> > > > STMPE1600 datasheet is available here :
> > > > http://www2.st.com/content/st_com/en/products/interfaces-and-tr
> > > > ansceivers/
> > > > 
> > > > i-o-expanders-and-level-translators/i-o-
> > > > expanders/stmpe1600.html
> > > > 
> > > > Only STMPE1600 has been tested on STM32 platform. As i have no
> > > > board
> > > > with
> > > > others STMPE
> > > > variant(STMPE610/STMPE801/STMPE811/STMPE1601/STMPE1801/STMPE240
> > > > 1
> > > > and STMPE2403), i put in CC boards's maintainers which are
> > > > using
> > > > others STMPE variant.
> > > > 
> > > > If they can kindly check that no regression has been introduce
> > > > by
> > > > this series
> > > > 
> > > > For TEGRA ARCHITECTURE SUPPORT
> > > > _ Stephen Warren <swar...@wwwdotorg.org>
> > > > _ Thierry Reding <thierry.red...@gmail.com>
> > > > _ Alexandre Courbot <gnu...@gmail.com>
> > > I don't know what STMPE is, and I don't believe it is used on
> > > Tegra;
> > > what makes you think it is?
> ...
> > 
> > I put you in copy as STMPE811 is used on tegra30-apalis and
> > tegra30-colibri platforms.
> Ah. You'd best contact the individual board owners, since those are 
> 3rd-party Tegra boards and I don't believe anyone at NVIDIA has them
> to 
> test with etc. I added likely candidates to Cc and dropped all the 
> individuals unrelated to Tegra to keep the CC list low.

I gave the whole series a spin on Apalis T30 2GB V1.1A featuring a
STMPE811 and the EDT VGA touch panel connected to it still works
perfectly running LXDE on top of the modesetting X driver.
Unfortunately the 4.6.0-rc4-next-20160420 I used for testing is broken
beyond easy quick repair on i.MX 6 so I was unable to validate it on
there, sorry.


Tested-by: Marcel Ziswiler <marcel.ziswi...@toradex.com>

Re: [PATCH 0/8] STMPE fixes/rework and add STMPE1600 support

[Marcel Ziswiler]

On Wed, 2016-04-20 at 10:02 -0600, Stephen Warren wrote:
> On 04/20/2016 01:40 AM, Patrice Chotard wrote:
> > 
> > On 04/19/2016 05:53 PM, Stephen Warren wrote:
> > > 
> > > On 04/19/2016 06:18 AM, patrice.chot...@st.com wrote:
> > > > 
> > > > From: Patrice Chotard 
> > > > 
> > > > This series cleans and fixes some bugs in MFD/GPIO STMPE
> > > > drivers and
> > > > prepare
> > > >   the ground to add new STMPE1600 support.
> > > > 
> > > > STMPE1600 datasheet is available here :
> > > > http://www2.st.com/content/st_com/en/products/interfaces-and-tr
> > > > ansceivers/
> > > > 
> > > > i-o-expanders-and-level-translators/i-o-
> > > > expanders/stmpe1600.html
> > > > 
> > > > Only STMPE1600 has been tested on STM32 platform. As i have no
> > > > board
> > > > with
> > > > others STMPE
> > > > variant(STMPE610/STMPE801/STMPE811/STMPE1601/STMPE1801/STMPE240
> > > > 1
> > > > and STMPE2403), i put in CC boards's maintainers which are
> > > > using
> > > > others STMPE variant.
> > > > 
> > > > If they can kindly check that no regression has been introduce
> > > > by
> > > > this series
> > > > 
> > > > For TEGRA ARCHITECTURE SUPPORT
> > > > _ Stephen Warren 
> > > > _ Thierry Reding 
> > > > _ Alexandre Courbot 
> > > I don't know what STMPE is, and I don't believe it is used on
> > > Tegra;
> > > what makes you think it is?
> ...
> > 
> > I put you in copy as STMPE811 is used on tegra30-apalis and
> > tegra30-colibri platforms.
> Ah. You'd best contact the individual board owners, since those are 
> 3rd-party Tegra boards and I don't believe anyone at NVIDIA has them
> to 
> test with etc. I added likely candidates to Cc and dropped all the 
> individuals unrelated to Tegra to keep the CC list low.

I gave the whole series a spin on Apalis T30 2GB V1.1A featuring a
STMPE811 and the EDT VGA touch panel connected to it still works
perfectly running LXDE on top of the modesetting X driver.
Unfortunately the 4.6.0-rc4-next-20160420 I used for testing is broken
beyond easy quick repair on i.MX 6 so I was unable to validate it on
there, sorry.


Tested-by: Marcel Ziswiler 

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

[Toshi Kani]

On 4/19/2016 2:23 PM, Matthew Wilcox wrote:

On Mon, Apr 18, 2016 at 10:26:10PM +0200, Jan Kara wrote:

On Fri 15-04-16 22:05:31, Andrew Morton wrote:

On Thu, 14 Apr 2016 10:48:29 -0600 Toshi Kani  wrote:


When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page
size.  This feature relies on both mmap virtual address and FS
block (i.e. physical address) to be aligned by the pmd page size.
Users can use mkfs options to specify FS to align block allocations.
However, aligning mmap address requires code changes to existing
applications for providing a pmd-aligned address to mmap().

For instance, fio with "ioengine=mmap" performs I/Os with mmap() [1].
It calls mmap() with a NULL address, which needs to be changed to
provide a pmd-aligned address for testing with DAX pmd mappings.
Changing all applications that call mmap() with NULL is undesirable.

This patch-set extends filesystems to align an mmap address for
a DAX file so that unmodified applications can use DAX pmd mappings.

Matthew sounded unconvinced about the need for this patchset, but I
must say that

: The point is that we do not need to modify existing applications for using
: DAX PMD mappings.
:
: For instance, fio with "ioengine=mmap" performs I/Os with mmap().
: https://github.com/caius/fio/blob/master/engines/mmap.c
:
: With this change, unmodified fio can be used for testing with DAX PMD
: mappings.  There are many examples like this, and I do not think we want
: to modify all applications that we want to evaluate/test with.

sounds pretty convincing?


And if we go ahead with this, it looks like 4.7 material to me - it
affects ABI and we want to get that stabilized asap.  What do people
think?

So I think Mathew didn't question the patch set as a whole. I think we all
agree that we should align the virtual address we map to so that PMD
mappings can be used. What Mathew was questioning was whether we really
need to play tricks when logical offset in the file where mmap is starting
is not aligned (and similarly for map length). Whether allowing PMD
mappings for unaligned file offsets is worth the complication is IMO a
valid question.

I was questioning the approach as a whole ... since we have userspace
already doing this in the form of NVML, do we really need the kernel to
do this for us?

Now, a further wrinkle.  We have two competing patch sets (from Kirill
and Hugh) which are going to give us THP for page cache filesystems.
I would suggest that this is not DAX functionality but rather VFS
functionality to opportunistically align all mmaps on files which are
reasonably likely to be able to use THP.

I hadn't thought about this until earlier today, and I'm sorry I didn't
raise it further.  Perhaps we can do a lightning session on this later
today at LSFMM since all six (Toshi, Andrew, Jan, Hugh, Kirill and myself)
are here.


How about moving the function (as is) to mm/huge_memory.c, rename it to
get_hugepage_unmapped_area(), which is defined to NULL in huge_mm.h
when TRANSPARENT_HUGEPAGE is unset?

Thanks,
-Toshi

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

[Toshi Kani]

On 4/19/2016 2:23 PM, Matthew Wilcox wrote:

On Mon, Apr 18, 2016 at 10:26:10PM +0200, Jan Kara wrote:

On Fri 15-04-16 22:05:31, Andrew Morton wrote:

On Thu, 14 Apr 2016 10:48:29 -0600 Toshi Kani  wrote:


When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page
size.  This feature relies on both mmap virtual address and FS
block (i.e. physical address) to be aligned by the pmd page size.
Users can use mkfs options to specify FS to align block allocations.
However, aligning mmap address requires code changes to existing
applications for providing a pmd-aligned address to mmap().

For instance, fio with "ioengine=mmap" performs I/Os with mmap() [1].
It calls mmap() with a NULL address, which needs to be changed to
provide a pmd-aligned address for testing with DAX pmd mappings.
Changing all applications that call mmap() with NULL is undesirable.

This patch-set extends filesystems to align an mmap address for
a DAX file so that unmodified applications can use DAX pmd mappings.

Matthew sounded unconvinced about the need for this patchset, but I
must say that

: The point is that we do not need to modify existing applications for using
: DAX PMD mappings.
:
: For instance, fio with "ioengine=mmap" performs I/Os with mmap().
: https://github.com/caius/fio/blob/master/engines/mmap.c
:
: With this change, unmodified fio can be used for testing with DAX PMD
: mappings.  There are many examples like this, and I do not think we want
: to modify all applications that we want to evaluate/test with.

sounds pretty convincing?


And if we go ahead with this, it looks like 4.7 material to me - it
affects ABI and we want to get that stabilized asap.  What do people
think?

So I think Mathew didn't question the patch set as a whole. I think we all
agree that we should align the virtual address we map to so that PMD
mappings can be used. What Mathew was questioning was whether we really
need to play tricks when logical offset in the file where mmap is starting
is not aligned (and similarly for map length). Whether allowing PMD
mappings for unaligned file offsets is worth the complication is IMO a
valid question.

I was questioning the approach as a whole ... since we have userspace
already doing this in the form of NVML, do we really need the kernel to
do this for us?

Now, a further wrinkle.  We have two competing patch sets (from Kirill
and Hugh) which are going to give us THP for page cache filesystems.
I would suggest that this is not DAX functionality but rather VFS
functionality to opportunistically align all mmaps on files which are
reasonably likely to be able to use THP.

I hadn't thought about this until earlier today, and I'm sorry I didn't
raise it further.  Perhaps we can do a lightning session on this later
today at LSFMM since all six (Toshi, Andrew, Jan, Hugh, Kirill and myself)
are here.


How about moving the function (as is) to mm/huge_memory.c, rename it to
get_hugepage_unmapped_area(), which is defined to NULL in huge_mm.h
when TRANSPARENT_HUGEPAGE is unset?

Thanks,
-Toshi

[PATCH -tip] futex: Acknowledge a new waiter in counter before plist

[Davidlohr Bueso]

Otherwise an incoming waker on the dest hash bucket can miss
the waiter adding itself to the plist during the lockless
check optimization (small window but still the correct way
of doing this); similarly to the decrement counterpart.

Cc: sta...@kernel.org (since v3.14+)
Suggested-by: Peter Zijlstra 
Signed-off-by: Davidlohr Bueso 
---
 kernel/futex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index e66e8d4fccff..913f05cfe8b8 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1745,8 +1745,8 @@ void requeue_futex(struct futex_q *q, struct 
futex_hash_bucket *hb1,
if (likely(>chain != >chain)) {
hb_remove_q(q, hb1);
hb_waiters_dec(hb1);
-   plist_add(>list, >chain);
hb_waiters_inc(hb2);
+   plist_add(>list, >chain);
q->lock_ptr = >lock;
}
get_futex_key_refs(key2);
-- 
2.8.1

[PATCH -tip] futex: Acknowledge a new waiter in counter before plist

[Davidlohr Bueso]

Otherwise an incoming waker on the dest hash bucket can miss
the waiter adding itself to the plist during the lockless
check optimization (small window but still the correct way
of doing this); similarly to the decrement counterpart.

Cc: sta...@kernel.org (since v3.14+)
Suggested-by: Peter Zijlstra 
Signed-off-by: Davidlohr Bueso 
---
 kernel/futex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index e66e8d4fccff..913f05cfe8b8 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1745,8 +1745,8 @@ void requeue_futex(struct futex_q *q, struct 
futex_hash_bucket *hb1,
if (likely(>chain != >chain)) {
hb_remove_q(q, hb1);
hb_waiters_dec(hb1);
-   plist_add(>list, >chain);
hb_waiters_inc(hb2);
+   plist_add(>list, >chain);
q->lock_ptr = >lock;
}
get_futex_key_refs(key2);
-- 
2.8.1

Linux 4.5.2

[Greg KH]

I'm announcing the release of the 4.5.2 kernel.

All users of the 4.5 kernel series must upgrade.

The updated 4.5.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.5.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt |   12 
 Documentation/kernel-parameters.txt |2 
 Makefile|2 
 arch/arm/kernel/setup.c |2 
 arch/arm64/include/asm/opcodes.h|4 
 arch/arm64/kernel/debug-monitors.c  |   21 -
 arch/mips/alchemy/devboards/db1000.c|   18 -
 arch/mips/alchemy/devboards/db1550.c|4 
 arch/mips/kernel/unaligned.c|   51 ++-
 arch/parisc/Kconfig |1 
 arch/parisc/include/asm/compat.h|7 
 arch/parisc/include/asm/syscall.h   |   13 
 arch/parisc/include/asm/uaccess.h   |1 
 arch/parisc/kernel/asm-offsets.c|1 
 arch/parisc/kernel/parisc_ksyms.c   |   10 
 arch/parisc/kernel/ptrace.c |9 
 arch/parisc/kernel/signal32.c   |5 
 arch/parisc/kernel/syscall.S|2 
 arch/parisc/kernel/traps.c  |3 
 arch/parisc/lib/fixup.S |6 
 arch/parisc/mm/fault.c  |1 
 arch/powerpc/kernel/process.c   |2 
 arch/powerpc/mm/hugetlbpage.c   |4 
 arch/s390/mm/gup.c  |8 
 arch/x86/include/asm/kvm_host.h |2 
 arch/x86/kvm/x86.c  |   20 -
 crypto/asymmetric_keys/pkcs7_trust.c|2 
 drivers/block/rbd.c |6 
 drivers/gpio/gpio-pca953x.c |3 
 drivers/gpio/gpio-pxa.c |4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c |   13 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   |   16 -
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   |   23 +
 drivers/gpu/drm/drm_dp_helper.c |   27 +
 drivers/gpu/drm/radeon/si_dpm.c |6 
 drivers/gpu/drm/udl/udl_fb.c|2 
 drivers/gpu/drm/udl/udl_gem.c   |2 
 drivers/hid/usbhid/hid-core.c   |   73 
++---
 drivers/hid/wacom_wac.c |   11 
 drivers/hwmon/max.c |6 
 drivers/iio/accel/bmc150-accel-core.c   |7 
 drivers/iio/gyro/bmg160_core.c  |9 
 drivers/iio/industrialio-buffer.c   |1 
 drivers/iio/magnetometer/st_magn.h  |1 
 drivers/iommu/iommu.c   |3 
 drivers/media/platform/coda/coda-common.c   |   10 
 drivers/media/platform/vsp1/vsp1_sru.c  |1 
 drivers/media/usb/au0828/au0828-core.c  |2 
 drivers/media/usb/au0828/au0828-input.c |4 
 drivers/media/usb/au0828/au0828-video.c |   63 ++--
 drivers/media/usb/au0828/au0828.h   |9 
 drivers/mmc/host/sdhci-pci-core.c   |   25 +
 drivers/mmc/host/sdhci-pci.h|3 
 drivers/mmc/host/sdhci-pxav3.c  |   22 +
 drivers/mmc/host/sdhci.c|   39 ++
 drivers/mmc/host/sdhci.h|4 
 drivers/net/bonding/bond_main.c |   65 ++--
 drivers/net/ethernet/broadcom/genet/bcmgenet.c  |4 
 drivers/net/ethernet/marvell/mvneta.c   |   11 
 

Linux 4.5.2

[Greg KH]

I'm announcing the release of the 4.5.2 kernel.

All users of the 4.5 kernel series must upgrade.

The updated 4.5.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.5.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt |   12 
 Documentation/kernel-parameters.txt |2 
 Makefile|2 
 arch/arm/kernel/setup.c |2 
 arch/arm64/include/asm/opcodes.h|4 
 arch/arm64/kernel/debug-monitors.c  |   21 -
 arch/mips/alchemy/devboards/db1000.c|   18 -
 arch/mips/alchemy/devboards/db1550.c|4 
 arch/mips/kernel/unaligned.c|   51 ++-
 arch/parisc/Kconfig |1 
 arch/parisc/include/asm/compat.h|7 
 arch/parisc/include/asm/syscall.h   |   13 
 arch/parisc/include/asm/uaccess.h   |1 
 arch/parisc/kernel/asm-offsets.c|1 
 arch/parisc/kernel/parisc_ksyms.c   |   10 
 arch/parisc/kernel/ptrace.c |9 
 arch/parisc/kernel/signal32.c   |5 
 arch/parisc/kernel/syscall.S|2 
 arch/parisc/kernel/traps.c  |3 
 arch/parisc/lib/fixup.S |6 
 arch/parisc/mm/fault.c  |1 
 arch/powerpc/kernel/process.c   |2 
 arch/powerpc/mm/hugetlbpage.c   |4 
 arch/s390/mm/gup.c  |8 
 arch/x86/include/asm/kvm_host.h |2 
 arch/x86/kvm/x86.c  |   20 -
 crypto/asymmetric_keys/pkcs7_trust.c|2 
 drivers/block/rbd.c |6 
 drivers/gpio/gpio-pca953x.c |3 
 drivers/gpio/gpio-pxa.c |4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c |   13 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   |   16 -
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   |   23 +
 drivers/gpu/drm/drm_dp_helper.c |   27 +
 drivers/gpu/drm/radeon/si_dpm.c |6 
 drivers/gpu/drm/udl/udl_fb.c|2 
 drivers/gpu/drm/udl/udl_gem.c   |2 
 drivers/hid/usbhid/hid-core.c   |   73 
++---
 drivers/hid/wacom_wac.c |   11 
 drivers/hwmon/max.c |6 
 drivers/iio/accel/bmc150-accel-core.c   |7 
 drivers/iio/gyro/bmg160_core.c  |9 
 drivers/iio/industrialio-buffer.c   |1 
 drivers/iio/magnetometer/st_magn.h  |1 
 drivers/iommu/iommu.c   |3 
 drivers/media/platform/coda/coda-common.c   |   10 
 drivers/media/platform/vsp1/vsp1_sru.c  |1 
 drivers/media/usb/au0828/au0828-core.c  |2 
 drivers/media/usb/au0828/au0828-input.c |4 
 drivers/media/usb/au0828/au0828-video.c |   63 ++--
 drivers/media/usb/au0828/au0828.h   |9 
 drivers/mmc/host/sdhci-pci-core.c   |   25 +
 drivers/mmc/host/sdhci-pci.h|3 
 drivers/mmc/host/sdhci-pxav3.c  |   22 +
 drivers/mmc/host/sdhci.c|   39 ++
 drivers/mmc/host/sdhci.h|4 
 drivers/net/bonding/bond_main.c |   65 ++--
 drivers/net/ethernet/broadcom/genet/bcmgenet.c  |4 
 drivers/net/ethernet/marvell/mvneta.c   |   11 
 

Linux 4.4.8

[Greg KH]

I'm announcing the release of the 4.4.8 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt |   12 
 Documentation/kernel-parameters.txt |2 
 Makefile|2 
 arch/arm64/include/asm/opcodes.h|4 
 arch/arm64/kernel/debug-monitors.c  |   21 -
 arch/mips/alchemy/devboards/db1000.c|   18 -
 arch/mips/alchemy/devboards/db1550.c|4 
 arch/mips/kernel/unaligned.c|   51 ++-
 arch/parisc/include/asm/uaccess.h   |1 
 arch/parisc/kernel/asm-offsets.c|1 
 arch/parisc/kernel/parisc_ksyms.c   |   10 
 arch/parisc/kernel/traps.c  |3 
 arch/parisc/lib/fixup.S |6 
 arch/parisc/mm/fault.c  |1 
 arch/powerpc/mm/hugetlbpage.c   |4 
 arch/x86/include/asm/kvm_host.h |2 
 arch/x86/include/asm/pci_x86.h  |2 
 arch/x86/kvm/x86.c  |   20 -
 arch/x86/pci/common.c   |   26 -
 arch/x86/pci/intel_mid_pci.c|9 
 arch/x86/pci/irq.c  |   23 +
 crypto/asymmetric_keys/pkcs7_trust.c|2 
 drivers/acpi/pci_irq.c  |   17 -
 drivers/block/rbd.c |6 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   |   16 -
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   |   23 +
 drivers/gpu/drm/drm_dp_helper.c |   27 +
 drivers/gpu/drm/radeon/si_dpm.c |6 
 drivers/gpu/drm/udl/udl_fb.c|2 
 drivers/gpu/drm/udl/udl_gem.c   |2 
 drivers/hid/usbhid/hid-core.c   |   73 
++---
 drivers/hid/wacom_wac.c |   11 
 drivers/hwmon/max.c |6 
 drivers/iio/accel/bmc150-accel-core.c   |7 
 drivers/iio/gyro/bmg160_core.c  |9 
 drivers/iio/magnetometer/st_magn.h  |1 
 drivers/iommu/iommu.c   |3 
 drivers/media/platform/coda/coda-common.c   |   10 
 drivers/media/platform/vsp1/vsp1_sru.c  |1 
 drivers/media/usb/au0828/au0828-core.c  |2 
 drivers/media/usb/au0828/au0828-input.c |4 
 drivers/media/usb/au0828/au0828-video.c |   63 ++--
 drivers/media/usb/au0828/au0828.h   |9 
 drivers/media/usb/usbvision/usbvision-video.c   |   16 +
 drivers/mmc/host/sdhci-pci-core.c   |   25 +
 drivers/mmc/host/sdhci-pci.h|3 
 drivers/net/bonding/bond_main.c |   65 ++--
 drivers/net/ethernet/broadcom/genet/bcmgenet.c  |4 
 drivers/net/ethernet/jme.c  |3 
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c   |3 
 drivers/net/ethernet/mellanox/mlxsw/spectrum.h  |2 
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c|9 
 drivers/net/ethernet/qlogic/qlcnic/qlcnic.h |3 
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c |   24 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c |3 
 drivers/net/ethernet/qlogic/qlge/qlge_main.c|   11 
 drivers/net/ethernet/qualcomm/qca_spi.c |2 
 drivers/net/ethernet/renesas/sh_eth.c   |   10 
 drivers/net/ethernet/rocker/rocker.c|   10 
 

Re: Linux 3.14.67

[Greg KH]

diff --git a/Makefile b/Makefile
index 9053bda13f60..0a28325ef49c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 14
-SUBLEVEL = 66
+SUBLEVEL = 67
 EXTRAVERSION =
 NAME = Remembering Coco
 
diff --git a/arch/parisc/kernel/parisc_ksyms.c 
b/arch/parisc/kernel/parisc_ksyms.c
index 568b2c61ea02..3cad8aadc69e 100644
--- a/arch/parisc/kernel/parisc_ksyms.c
+++ b/arch/parisc/kernel/parisc_ksyms.c
@@ -47,11 +47,11 @@ EXPORT_SYMBOL(__cmpxchg_u64);
 EXPORT_SYMBOL(lclear_user);
 EXPORT_SYMBOL(lstrnlen_user);
 
-/* Global fixups */
-extern void fixup_get_user_skip_1(void);
-extern void fixup_get_user_skip_2(void);
-extern void fixup_put_user_skip_1(void);
-extern void fixup_put_user_skip_2(void);
+/* Global fixups - defined as int to avoid creation of function pointers */
+extern int fixup_get_user_skip_1;
+extern int fixup_get_user_skip_2;
+extern int fixup_put_user_skip_1;
+extern int fixup_put_user_skip_2;
 EXPORT_SYMBOL(fixup_get_user_skip_1);
 EXPORT_SYMBOL(fixup_get_user_skip_2);
 EXPORT_SYMBOL(fixup_put_user_skip_1);
diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
index 47ee620d15d2..05aab1333dfa 100644
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -802,6 +802,9 @@ void notrace handle_interruption(int code, struct pt_regs 
*regs)
 
if (fault_space == 0 && !in_atomic())
{
+   /* Clean up and return if in exception table. */
+   if (fixup_exception(regs))
+   return;
pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
parisc_terminate("Kernel Fault", regs, code, fault_address);
}
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c 
b/drivers/gpu/drm/radeon/radeon_sa.c
index a1d684266549..d92ab57bffaf 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -349,8 +349,10 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
/* see if we can skip over some allocations */
} while (radeon_sa_bo_next_hole(sa_manager, fences, tries));
 
-   for (i = 0; i < RADEON_NUM_RINGS; ++i)
-   radeon_fence_ref(fences[i]);
+   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+   if (fences[i])
+   radeon_fence_ref(fences[i]);
+   }
 
spin_unlock(_manager->wq.lock);
r = radeon_fence_wait_any(rdev, fences, false);
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index c9053f799abe..93abc111307f 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2914,6 +2914,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = {
/* PITCAIRN - https://bugs.freedesktop.org/show_bug.cgi?id=76490 */
{ PCI_VENDOR_ID_ATI, 0x6810, 0x1462, 0x3036, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 12 },
+   { PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0x2015, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 9 },
{ 0, 0, 0, 0 },
 };
@@ -3006,6 +3007,10 @@ static void si_apply_state_adjust_rules(struct 
radeon_device *rdev,
ps->performance_levels[i].sclk = max_sclk;
}
}
+   /* limit mclk on all R7 370 parts for stability */
+   if (rdev->pdev->device == 0x6811 &&
+   rdev->pdev->revision == 0x81)
+   max_mclk = 12;
 
/* XXX validate the min clocks required for display */
 
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index ced6d61c1787..63de05743259 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -940,14 +940,6 @@ static int usbhid_output_raw_report(struct hid_device 
*hid, __u8 *buf, size_t co
return ret;
 }
 
-static void usbhid_restart_queues(struct usbhid_device *usbhid)
-{
-   if (usbhid->urbout && !test_bit(HID_OUT_RUNNING, >iofl))
-   usbhid_restart_out_queue(usbhid);
-   if (!test_bit(HID_CTRL_RUNNING, >iofl))
-   usbhid_restart_ctrl_queue(usbhid);
-}
-
 static void hid_free_buffers(struct usb_device *dev, struct hid_device *hid)
 {
struct usbhid_device *usbhid = hid->driver_data;
@@ -1376,6 +1368,37 @@ static void hid_cease_io(struct usbhid_device *usbhid)
usb_kill_urb(usbhid->urbout);
 }
 
+static void hid_restart_io(struct hid_device *hid)
+{
+   struct usbhid_device *usbhid = hid->driver_data;
+   int clear_halt = test_bit(HID_CLEAR_HALT, >iofl);
+   int reset_pending = test_bit(HID_RESET_PENDING, >iofl);
+
+   spin_lock_irq(>lock);
+   clear_bit(HID_SUSPENDED, >iofl);
+   usbhid_mark_busy(usbhid);
+
+   if (clear_halt || reset_pending)
+   schedule_work(>reset_work);
+   usbhid->retry_delay = 0;
+   spin_unlock_irq(>lock);
+
+   if (reset_pending || 

Linux 4.4.8

[Greg KH]

I'm announcing the release of the 4.4.8 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt |   12 
 Documentation/kernel-parameters.txt |2 
 Makefile|2 
 arch/arm64/include/asm/opcodes.h|4 
 arch/arm64/kernel/debug-monitors.c  |   21 -
 arch/mips/alchemy/devboards/db1000.c|   18 -
 arch/mips/alchemy/devboards/db1550.c|4 
 arch/mips/kernel/unaligned.c|   51 ++-
 arch/parisc/include/asm/uaccess.h   |1 
 arch/parisc/kernel/asm-offsets.c|1 
 arch/parisc/kernel/parisc_ksyms.c   |   10 
 arch/parisc/kernel/traps.c  |3 
 arch/parisc/lib/fixup.S |6 
 arch/parisc/mm/fault.c  |1 
 arch/powerpc/mm/hugetlbpage.c   |4 
 arch/x86/include/asm/kvm_host.h |2 
 arch/x86/include/asm/pci_x86.h  |2 
 arch/x86/kvm/x86.c  |   20 -
 arch/x86/pci/common.c   |   26 -
 arch/x86/pci/intel_mid_pci.c|9 
 arch/x86/pci/irq.c  |   23 +
 crypto/asymmetric_keys/pkcs7_trust.c|2 
 drivers/acpi/pci_irq.c  |   17 -
 drivers/block/rbd.c |6 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   |   16 -
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   |   23 +
 drivers/gpu/drm/drm_dp_helper.c |   27 +
 drivers/gpu/drm/radeon/si_dpm.c |6 
 drivers/gpu/drm/udl/udl_fb.c|2 
 drivers/gpu/drm/udl/udl_gem.c   |2 
 drivers/hid/usbhid/hid-core.c   |   73 
++---
 drivers/hid/wacom_wac.c |   11 
 drivers/hwmon/max.c |6 
 drivers/iio/accel/bmc150-accel-core.c   |7 
 drivers/iio/gyro/bmg160_core.c  |9 
 drivers/iio/magnetometer/st_magn.h  |1 
 drivers/iommu/iommu.c   |3 
 drivers/media/platform/coda/coda-common.c   |   10 
 drivers/media/platform/vsp1/vsp1_sru.c  |1 
 drivers/media/usb/au0828/au0828-core.c  |2 
 drivers/media/usb/au0828/au0828-input.c |4 
 drivers/media/usb/au0828/au0828-video.c |   63 ++--
 drivers/media/usb/au0828/au0828.h   |9 
 drivers/media/usb/usbvision/usbvision-video.c   |   16 +
 drivers/mmc/host/sdhci-pci-core.c   |   25 +
 drivers/mmc/host/sdhci-pci.h|3 
 drivers/net/bonding/bond_main.c |   65 ++--
 drivers/net/ethernet/broadcom/genet/bcmgenet.c  |4 
 drivers/net/ethernet/jme.c  |3 
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c   |3 
 drivers/net/ethernet/mellanox/mlxsw/spectrum.h  |2 
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c|9 
 drivers/net/ethernet/qlogic/qlcnic/qlcnic.h |3 
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c |   24 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c |3 
 drivers/net/ethernet/qlogic/qlge/qlge_main.c|   11 
 drivers/net/ethernet/qualcomm/qca_spi.c |2 
 drivers/net/ethernet/renesas/sh_eth.c   |   10 
 drivers/net/ethernet/rocker/rocker.c|   10 
 

Re: Linux 3.14.67

[Greg KH]

diff --git a/Makefile b/Makefile
index 9053bda13f60..0a28325ef49c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 14
-SUBLEVEL = 66
+SUBLEVEL = 67
 EXTRAVERSION =
 NAME = Remembering Coco
 
diff --git a/arch/parisc/kernel/parisc_ksyms.c 
b/arch/parisc/kernel/parisc_ksyms.c
index 568b2c61ea02..3cad8aadc69e 100644
--- a/arch/parisc/kernel/parisc_ksyms.c
+++ b/arch/parisc/kernel/parisc_ksyms.c
@@ -47,11 +47,11 @@ EXPORT_SYMBOL(__cmpxchg_u64);
 EXPORT_SYMBOL(lclear_user);
 EXPORT_SYMBOL(lstrnlen_user);
 
-/* Global fixups */
-extern void fixup_get_user_skip_1(void);
-extern void fixup_get_user_skip_2(void);
-extern void fixup_put_user_skip_1(void);
-extern void fixup_put_user_skip_2(void);
+/* Global fixups - defined as int to avoid creation of function pointers */
+extern int fixup_get_user_skip_1;
+extern int fixup_get_user_skip_2;
+extern int fixup_put_user_skip_1;
+extern int fixup_put_user_skip_2;
 EXPORT_SYMBOL(fixup_get_user_skip_1);
 EXPORT_SYMBOL(fixup_get_user_skip_2);
 EXPORT_SYMBOL(fixup_put_user_skip_1);
diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
index 47ee620d15d2..05aab1333dfa 100644
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -802,6 +802,9 @@ void notrace handle_interruption(int code, struct pt_regs 
*regs)
 
if (fault_space == 0 && !in_atomic())
{
+   /* Clean up and return if in exception table. */
+   if (fixup_exception(regs))
+   return;
pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
parisc_terminate("Kernel Fault", regs, code, fault_address);
}
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c 
b/drivers/gpu/drm/radeon/radeon_sa.c
index a1d684266549..d92ab57bffaf 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -349,8 +349,10 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
/* see if we can skip over some allocations */
} while (radeon_sa_bo_next_hole(sa_manager, fences, tries));
 
-   for (i = 0; i < RADEON_NUM_RINGS; ++i)
-   radeon_fence_ref(fences[i]);
+   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+   if (fences[i])
+   radeon_fence_ref(fences[i]);
+   }
 
spin_unlock(_manager->wq.lock);
r = radeon_fence_wait_any(rdev, fences, false);
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index c9053f799abe..93abc111307f 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2914,6 +2914,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = {
/* PITCAIRN - https://bugs.freedesktop.org/show_bug.cgi?id=76490 */
{ PCI_VENDOR_ID_ATI, 0x6810, 0x1462, 0x3036, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 12 },
+   { PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0x2015, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 9 },
{ 0, 0, 0, 0 },
 };
@@ -3006,6 +3007,10 @@ static void si_apply_state_adjust_rules(struct 
radeon_device *rdev,
ps->performance_levels[i].sclk = max_sclk;
}
}
+   /* limit mclk on all R7 370 parts for stability */
+   if (rdev->pdev->device == 0x6811 &&
+   rdev->pdev->revision == 0x81)
+   max_mclk = 12;
 
/* XXX validate the min clocks required for display */
 
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index ced6d61c1787..63de05743259 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -940,14 +940,6 @@ static int usbhid_output_raw_report(struct hid_device 
*hid, __u8 *buf, size_t co
return ret;
 }
 
-static void usbhid_restart_queues(struct usbhid_device *usbhid)
-{
-   if (usbhid->urbout && !test_bit(HID_OUT_RUNNING, >iofl))
-   usbhid_restart_out_queue(usbhid);
-   if (!test_bit(HID_CTRL_RUNNING, >iofl))
-   usbhid_restart_ctrl_queue(usbhid);
-}
-
 static void hid_free_buffers(struct usb_device *dev, struct hid_device *hid)
 {
struct usbhid_device *usbhid = hid->driver_data;
@@ -1376,6 +1368,37 @@ static void hid_cease_io(struct usbhid_device *usbhid)
usb_kill_urb(usbhid->urbout);
 }
 
+static void hid_restart_io(struct hid_device *hid)
+{
+   struct usbhid_device *usbhid = hid->driver_data;
+   int clear_halt = test_bit(HID_CLEAR_HALT, >iofl);
+   int reset_pending = test_bit(HID_RESET_PENDING, >iofl);
+
+   spin_lock_irq(>lock);
+   clear_bit(HID_SUSPENDED, >iofl);
+   usbhid_mark_busy(usbhid);
+
+   if (clear_halt || reset_pending)
+   schedule_work(>reset_work);
+   usbhid->retry_delay = 0;
+   spin_unlock_irq(>lock);
+
+   if (reset_pending || 

Linux 3.14.67

[Greg KH]

I'm announcing the release of the 3.14.67 kernel.

All users of the 3.14 kernel series must upgrade.

The updated 3.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/parisc/kernel/parisc_ksyms.c |   10 +--
 arch/parisc/kernel/traps.c|3 +
 drivers/gpu/drm/radeon/radeon_sa.c|6 +-
 drivers/gpu/drm/radeon/si_dpm.c   |5 +
 drivers/hid/usbhid/hid-core.c |   73 +-
 drivers/hwmon/max.c   |6 ++
 drivers/media/usb/usbvision/usbvision-video.c |   40 +++---
 drivers/net/ethernet/jme.c|3 -
 drivers/net/ethernet/qlogic/qlge/qlge_main.c  |   11 +++
 drivers/net/ethernet/renesas/sh_eth.c |3 -
 drivers/net/ppp/ppp_generic.c |4 +
 drivers/net/usb/cdc_ncm.c |6 +-
 drivers/net/usb/qmi_wwan.c|1 
 drivers/net/usb/usbnet.c  |7 ++
 drivers/net/wan/farsync.c |2 
 drivers/net/wireless/ath/ath9k/eeprom.c   |7 +-
 drivers/usb/core/hub.c|8 +-
 drivers/usb/renesas_usbhs/fifo.c  |4 +
 drivers/xen/events/events_base.c  |   28 -
 fs/ext4/ext4.h|   23 
 fs/ext4/move_extent.c |   11 +++
 fs/ext4/super.c   |   25 
 kernel/events/core.c  |6 +-
 mm/page_isolation.c   |8 +-
 net/ipv4/udp.c|   12 ++--
 net/ipv6/exthdrs_core.c   |6 +-
 net/ipv6/ip6_tunnel.c |2 
 net/ipv6/udp.c|6 --
 net/l2tp/l2tp_ip.c|8 +-
 net/l2tp/l2tp_ip6.c   |8 +-
 net/mac80211/rx.c |5 +
 net/sctp/ipv6.c   |2 
 net/socket.c  |   38 ++---
 sound/core/timer.c|4 -
 35 files changed, 272 insertions(+), 121 deletions(-)

Alan Stern (1):
  HID: usbhid: fix inconsistent reset/resume/reset-resume behavior

Alex Deucher (2):
  drm/radeon: add a dpm quirk for sapphire Dual-X R7 370 2G D5
  drm/radeon: add a dpm quirk for all R7 370 parts

Alexey Khoroshilov (1):
  usbvision: fix leak of usb_dev on failure paths in usbvision_probe()

Arnaldo Carvalho de Melo (1):
  net: Fix use after free in the recvmmsg exit path

Arnd Bergmann (2):
  farsync: fix off-by-one bug in fst_add_one
  ath9k: fix buffer overrun for ar9287

Bill Sommerfeld (1):
  udp6: fix UDP/IPv6 encap resubmit path

Bjørn Mork (2):
  cdc_ncm: toggle altsetting to force reset before setup
  qmi_wwan: add "D-Link DWM-221 B1" device id

Boris Ostrovsky (1):
  xen/events: Mask a moving irq

Diego Viola (1):
  net: jme: fix suspend/resume on JMC260

Florian Westphal (1):
  ipv6: re-enable fragment header matching in ipv6_find_hdr

Greg Kroah-Hartman (3):
  Revert bad backport of "drm/radeon: hold reference to fences in 
radeon_sa_bo_new"
  Revert "usb: hub: do not clear BOS field during reset device"
  Linux 3.14.67

Guenter Roeck (1):
  hwmon: (max) Return -ENODEV from max_read_channel if not 
instantiated

Guillaume Nault (1):
  ppp: take reference on channels netns

Haishuang Yan (2):
  ipv4: l2tp: fix a potential issue in l2tp_ip_recv
  ipv6: l2tp: fix a potential issue in l2tp_ip6_recv

Helge Deller (2):
  parisc: Avoid function pointers for kernel exception routines
  parisc: Fix kernel crash with reversed copy_from_user()

Manish Chopra (1):
  qlge: Fix receive packets drop.

Michal Kazior (1):
  mac80211: fix unnecessary frame drops in mesh fwding

Nicolai Hähnle (1):
  drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older)

Oliver Neukum (1):
  usbnet: cleanup after bind() in probe()

Paolo Abeni (1):
  ipv4: fix broadcast packets reception

Peter Zijlstra (1):
  perf: Cure event->pending_disable race

Sergei Shtylyov (1):
  sh_eth: fix NULL pointer dereference in sh_eth_ring_format()

Takashi Iwai (1):
  ALSA: timer: Use mod_timer() for rearming the system timer

Thadeu Lima de Souza Cascardo (1):
  ip6_tunnel: set rtnl_link_ops before calling register_netdevice

Theodore Ts'o (1):
  ext4: add lockdep annotations for i_data_sem

Vladis Dronov (1):
  usbvision: fix crash on detecting device with invalid configuration

Xin Long (1):

Linux 3.14.67

[Greg KH]

I'm announcing the release of the 3.14.67 kernel.

All users of the 3.14 kernel series must upgrade.

The updated 3.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/parisc/kernel/parisc_ksyms.c |   10 +--
 arch/parisc/kernel/traps.c|3 +
 drivers/gpu/drm/radeon/radeon_sa.c|6 +-
 drivers/gpu/drm/radeon/si_dpm.c   |5 +
 drivers/hid/usbhid/hid-core.c |   73 +-
 drivers/hwmon/max.c   |6 ++
 drivers/media/usb/usbvision/usbvision-video.c |   40 +++---
 drivers/net/ethernet/jme.c|3 -
 drivers/net/ethernet/qlogic/qlge/qlge_main.c  |   11 +++
 drivers/net/ethernet/renesas/sh_eth.c |3 -
 drivers/net/ppp/ppp_generic.c |4 +
 drivers/net/usb/cdc_ncm.c |6 +-
 drivers/net/usb/qmi_wwan.c|1 
 drivers/net/usb/usbnet.c  |7 ++
 drivers/net/wan/farsync.c |2 
 drivers/net/wireless/ath/ath9k/eeprom.c   |7 +-
 drivers/usb/core/hub.c|8 +-
 drivers/usb/renesas_usbhs/fifo.c  |4 +
 drivers/xen/events/events_base.c  |   28 -
 fs/ext4/ext4.h|   23 
 fs/ext4/move_extent.c |   11 +++
 fs/ext4/super.c   |   25 
 kernel/events/core.c  |6 +-
 mm/page_isolation.c   |8 +-
 net/ipv4/udp.c|   12 ++--
 net/ipv6/exthdrs_core.c   |6 +-
 net/ipv6/ip6_tunnel.c |2 
 net/ipv6/udp.c|6 --
 net/l2tp/l2tp_ip.c|8 +-
 net/l2tp/l2tp_ip6.c   |8 +-
 net/mac80211/rx.c |5 +
 net/sctp/ipv6.c   |2 
 net/socket.c  |   38 ++---
 sound/core/timer.c|4 -
 35 files changed, 272 insertions(+), 121 deletions(-)

Alan Stern (1):
  HID: usbhid: fix inconsistent reset/resume/reset-resume behavior

Alex Deucher (2):
  drm/radeon: add a dpm quirk for sapphire Dual-X R7 370 2G D5
  drm/radeon: add a dpm quirk for all R7 370 parts

Alexey Khoroshilov (1):
  usbvision: fix leak of usb_dev on failure paths in usbvision_probe()

Arnaldo Carvalho de Melo (1):
  net: Fix use after free in the recvmmsg exit path

Arnd Bergmann (2):
  farsync: fix off-by-one bug in fst_add_one
  ath9k: fix buffer overrun for ar9287

Bill Sommerfeld (1):
  udp6: fix UDP/IPv6 encap resubmit path

Bjørn Mork (2):
  cdc_ncm: toggle altsetting to force reset before setup
  qmi_wwan: add "D-Link DWM-221 B1" device id

Boris Ostrovsky (1):
  xen/events: Mask a moving irq

Diego Viola (1):
  net: jme: fix suspend/resume on JMC260

Florian Westphal (1):
  ipv6: re-enable fragment header matching in ipv6_find_hdr

Greg Kroah-Hartman (3):
  Revert bad backport of "drm/radeon: hold reference to fences in 
radeon_sa_bo_new"
  Revert "usb: hub: do not clear BOS field during reset device"
  Linux 3.14.67

Guenter Roeck (1):
  hwmon: (max) Return -ENODEV from max_read_channel if not 
instantiated

Guillaume Nault (1):
  ppp: take reference on channels netns

Haishuang Yan (2):
  ipv4: l2tp: fix a potential issue in l2tp_ip_recv
  ipv6: l2tp: fix a potential issue in l2tp_ip6_recv

Helge Deller (2):
  parisc: Avoid function pointers for kernel exception routines
  parisc: Fix kernel crash with reversed copy_from_user()

Manish Chopra (1):
  qlge: Fix receive packets drop.

Michal Kazior (1):
  mac80211: fix unnecessary frame drops in mesh fwding

Nicolai Hähnle (1):
  drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older)

Oliver Neukum (1):
  usbnet: cleanup after bind() in probe()

Paolo Abeni (1):
  ipv4: fix broadcast packets reception

Peter Zijlstra (1):
  perf: Cure event->pending_disable race

Sergei Shtylyov (1):
  sh_eth: fix NULL pointer dereference in sh_eth_ring_format()

Takashi Iwai (1):
  ALSA: timer: Use mod_timer() for rearming the system timer

Thadeu Lima de Souza Cascardo (1):
  ip6_tunnel: set rtnl_link_ops before calling register_netdevice

Theodore Ts'o (1):
  ext4: add lockdep annotations for i_data_sem

Vladis Dronov (1):
  usbvision: fix crash on detecting device with invalid configuration

Xin Long (1):

Re: [PATCH] lib: make sg_pool explicitly non-modular

[Paul Gortmaker]

[Re: [PATCH] lib: make sg_pool explicitly non-modular] On 20/04/2016 (Wed 
13:28) Ming Lin wrote:

> On Wed, 2016-04-20 at 15:13 -0400, Paul Gortmaker wrote:
> > The recently added Kconfig controlling compilation of this code is:
> > 
> > lib/Kconfig:config SG_POOL
> > lib/Kconfig:def_bool n
> > 
> > ...meaning that it currently is not being built as a module by anyone.
> > 
> > Lets remove the modular code that is essentially orphaned, so that
> > when reading the driver there is no doubt it is builtin-only.
> > 
> > Since module_init translates to device_initcall in the non-modular
> > case, the init ordering remains unchanged with this commit.  However
> > one might want to consider moving it to subsys_initcall if it is to
> > be ready ahead of SCSI drivers wanting this and using device_initcall.
> > 
> > Cc: Christoph Hellwig 
> > Cc: Ming Lin 
> > Cc: Sagi Grimberg 
> > Cc: Martin K. Petersen 
> > Signed-off-by: Paul Gortmaker 
> > ---
> >  lib/sg_pool.c | 17 ++---
> >  1 file changed, 2 insertions(+), 15 deletions(-)
> > 
> > diff --git a/lib/sg_pool.c b/lib/sg_pool.c
> > index 6dd30615a201..e2cf548b9610 100644
> > --- a/lib/sg_pool.c
> > +++ b/lib/sg_pool.c
> > @@ -1,4 +1,4 @@
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -156,17 +156,4 @@ cleanup_sdb:
> >  
> > return -ENOMEM;
> >  }
> > -
> > -static __exit void sg_pool_exit(void)
> > -{
> > -   int i;
> > -
> > -   for (i = 0; i < SG_MEMPOOL_NR; i++) {
> > -   struct sg_pool *sgp = sg_pools + i;
> > -   mempool_destroy(sgp->pool);
> > -   kmem_cache_destroy(sgp->slab);
> > -   }
> > -}
> > -
> > -module_init(sg_pool_init);
> > -module_exit(sg_pool_exit);
> > +device_initcall(sg_pool_init);
> 
> For SCSI it's OK because always CONFIG_SCSI=y
> 
> But we may have a kernel .config with !CONFIG_SCSI and other
> non-block-device driver may use this sg_pool.
> 
> So the .config will have CONFIG_SG_POOL=m

That is impossible currently, since as per above, the variable is bool
and not tristate.  Did you mean to make it tristate?

Paul.
--

> 
> 
> 
> 

Re: [PATCH] lib: make sg_pool explicitly non-modular

[Paul Gortmaker]

[Re: [PATCH] lib: make sg_pool explicitly non-modular] On 20/04/2016 (Wed 
13:28) Ming Lin wrote:

> On Wed, 2016-04-20 at 15:13 -0400, Paul Gortmaker wrote:
> > The recently added Kconfig controlling compilation of this code is:
> > 
> > lib/Kconfig:config SG_POOL
> > lib/Kconfig:def_bool n
> > 
> > ...meaning that it currently is not being built as a module by anyone.
> > 
> > Lets remove the modular code that is essentially orphaned, so that
> > when reading the driver there is no doubt it is builtin-only.
> > 
> > Since module_init translates to device_initcall in the non-modular
> > case, the init ordering remains unchanged with this commit.  However
> > one might want to consider moving it to subsys_initcall if it is to
> > be ready ahead of SCSI drivers wanting this and using device_initcall.
> > 
> > Cc: Christoph Hellwig 
> > Cc: Ming Lin 
> > Cc: Sagi Grimberg 
> > Cc: Martin K. Petersen 
> > Signed-off-by: Paul Gortmaker 
> > ---
> >  lib/sg_pool.c | 17 ++---
> >  1 file changed, 2 insertions(+), 15 deletions(-)
> > 
> > diff --git a/lib/sg_pool.c b/lib/sg_pool.c
> > index 6dd30615a201..e2cf548b9610 100644
> > --- a/lib/sg_pool.c
> > +++ b/lib/sg_pool.c
> > @@ -1,4 +1,4 @@
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -156,17 +156,4 @@ cleanup_sdb:
> >  
> > return -ENOMEM;
> >  }
> > -
> > -static __exit void sg_pool_exit(void)
> > -{
> > -   int i;
> > -
> > -   for (i = 0; i < SG_MEMPOOL_NR; i++) {
> > -   struct sg_pool *sgp = sg_pools + i;
> > -   mempool_destroy(sgp->pool);
> > -   kmem_cache_destroy(sgp->slab);
> > -   }
> > -}
> > -
> > -module_init(sg_pool_init);
> > -module_exit(sg_pool_exit);
> > +device_initcall(sg_pool_init);
> 
> For SCSI it's OK because always CONFIG_SCSI=y
> 
> But we may have a kernel .config with !CONFIG_SCSI and other
> non-block-device driver may use this sg_pool.
> 
> So the .config will have CONFIG_SG_POOL=m

That is impossible currently, since as per above, the variable is bool
and not tristate.  Did you mean to make it tristate?

Paul.
--

> 
> 
> 
> 

Re: [RESEND][PATCH 1/3] thermal: mediatek: Add cpu dynamic power cooling model.

[Eduardo Valentin]

On Thu, Apr 21, 2016 at 02:41:24AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 20, 2016 01:58:07 PM Matthias Brugger wrote:
> > Hi Rafael,
> > 
> > On 13/04/16 06:52, Rafael J. Wysocki wrote:
> > > On Tue, Apr 12, 2016 at 7:38 AM, Viresh Kumar  
> > > wrote:
> > >> Hi Rafael,
> > >>
> > >> On 15-03-16, 16:10, Dawei Chien wrote:
> > >>> MT8173 cpufreq driver select of_cpufreq_power_cooling_register 
> > >>> registering
> > >>> cooling devices with dynamic power coefficient.
> > >>>
> > >>> Signed-off-by: Dawei Chien 
> > >>> Acked-by: Viresh Kumar 
> > >>
> > >> Can you please apply this patch from Dawei ?
> > >
> > > I can, but I'm traveling this week, so that's rather going to happen next 
> > > week.
> > >
> > 
> > I don't see the patch in linux-next, did you forget to pick/push it?
> 
> No, I didn't.  I just didn't have the time to get to them before.
> 
> Now, given that they are thermal patches, they really should go in via
> linux-soc-thermal.git.
> 
> Eduardo, any chance to take care of these?

Yes I can add this one, given that they have the proper acked-by. I was
a bit hesitant to just get them because they are touching
drivers/cpufreq. 

Anyways, I am adding this to my branch to the next merge window.


> 
> Thanks,
> Rafael
> 

Re: [RESEND][PATCH 1/3] thermal: mediatek: Add cpu dynamic power cooling model.

[Eduardo Valentin]

On Thu, Apr 21, 2016 at 02:41:24AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 20, 2016 01:58:07 PM Matthias Brugger wrote:
> > Hi Rafael,
> > 
> > On 13/04/16 06:52, Rafael J. Wysocki wrote:
> > > On Tue, Apr 12, 2016 at 7:38 AM, Viresh Kumar  
> > > wrote:
> > >> Hi Rafael,
> > >>
> > >> On 15-03-16, 16:10, Dawei Chien wrote:
> > >>> MT8173 cpufreq driver select of_cpufreq_power_cooling_register 
> > >>> registering
> > >>> cooling devices with dynamic power coefficient.
> > >>>
> > >>> Signed-off-by: Dawei Chien 
> > >>> Acked-by: Viresh Kumar 
> > >>
> > >> Can you please apply this patch from Dawei ?
> > >
> > > I can, but I'm traveling this week, so that's rather going to happen next 
> > > week.
> > >
> > 
> > I don't see the patch in linux-next, did you forget to pick/push it?
> 
> No, I didn't.  I just didn't have the time to get to them before.
> 
> Now, given that they are thermal patches, they really should go in via
> linux-soc-thermal.git.
> 
> Eduardo, any chance to take care of these?

Yes I can add this one, given that they have the proper acked-by. I was
a bit hesitant to just get them because they are touching
drivers/cpufreq. 

Anyways, I am adding this to my branch to the next merge window.


> 
> Thanks,
> Rafael
> 

Re: [PATCH V4 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

[Eduardo Valentin]

On Thu, Apr 21, 2016 at 06:42:16AM +0530, Laxman Dewangan wrote:
> 
> On Thursday 21 April 2016 05:13 AM, Eduardo Valentin wrote:
> >Laxman,
> >
> >On Tue, Apr 19, 2016 at 12:52:01PM +0530, Laxman Dewangan wrote:
> >>In some of platform, thermal sensors like NCT thermistors are
> >>connected to the one of ADC channel. The temperature is read by
> >>reading the voltage across the sensor resistance via ADC. Lookup
> >>table for ADC read value to temperature is referred to get
> >>temperature. ADC is read via IIO framework.
> >>
> >>Add support for thermal sensor driver which read the voltage across
> >>sensor resistance from ADC through IIO framework.
> >>
> >>Signed-off-by: Laxman Dewangan 
> >I really like this driver, as I mentioned  before. Just one comment
> >though.
> >
> >>+
> >>+   gti->tz_dev = thermal_zone_of_sensor_register(>dev, 0,
> >>+ gti, _thermal_ops);
> >Why not using the devm_ version you introduced?
> >
> >Any particular reason?
> >
> 
> Yaah, the reason is just to maintain the proper sequence in releasing of
> resource during driver unbinding.
> 
> Sequence in probe are:
> iio_channel_get()
> thermal_zone_of_sensor_register()
> 
> and on release, sensor should be released first before iio channel.
> As of now, we do not have devm_iio_channel_get() [I already post patch and
> it is accepted by Jonathan in iio sub system] and hence I can not use the
> devm_ for sensor register to avoid race.
> 
> However, once the devm_ for iio channel get available in all subsystem (may
> be in next release), I will post the patch to use devm_.
> 
> Currently, we can go with these APIs.

Ok. We can have it in this way then.

> 
> 

Re: [PATCH V4 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

[Eduardo Valentin]

On Thu, Apr 21, 2016 at 06:42:16AM +0530, Laxman Dewangan wrote:
> 
> On Thursday 21 April 2016 05:13 AM, Eduardo Valentin wrote:
> >Laxman,
> >
> >On Tue, Apr 19, 2016 at 12:52:01PM +0530, Laxman Dewangan wrote:
> >>In some of platform, thermal sensors like NCT thermistors are
> >>connected to the one of ADC channel. The temperature is read by
> >>reading the voltage across the sensor resistance via ADC. Lookup
> >>table for ADC read value to temperature is referred to get
> >>temperature. ADC is read via IIO framework.
> >>
> >>Add support for thermal sensor driver which read the voltage across
> >>sensor resistance from ADC through IIO framework.
> >>
> >>Signed-off-by: Laxman Dewangan 
> >I really like this driver, as I mentioned  before. Just one comment
> >though.
> >
> >>+
> >>+   gti->tz_dev = thermal_zone_of_sensor_register(>dev, 0,
> >>+ gti, _thermal_ops);
> >Why not using the devm_ version you introduced?
> >
> >Any particular reason?
> >
> 
> Yaah, the reason is just to maintain the proper sequence in releasing of
> resource during driver unbinding.
> 
> Sequence in probe are:
> iio_channel_get()
> thermal_zone_of_sensor_register()
> 
> and on release, sensor should be released first before iio channel.
> As of now, we do not have devm_iio_channel_get() [I already post patch and
> it is accepted by Jonathan in iio sub system] and hence I can not use the
> devm_ for sensor register to avoid race.
> 
> However, once the devm_ for iio channel get available in all subsystem (may
> be in next release), I will post the patch to use devm_.
> 
> Currently, we can go with these APIs.

Ok. We can have it in this way then.

> 
> 

Re: [PATCH 2/4] i2c: designware-platdrv: fix unbalanced clk enable and prepare

[Jisheng Zhang]

Dear Jarkko, Andy,

On Wed, 20 Apr 2016 17:16:00 +0300 Andy Shevchenko wrote:

> On Wed, 2016-04-20 at 15:55 +0300, Jarkko Nikula wrote:
> > On 04/14/2016 03:53 PM, Jisheng Zhang wrote:  
> > > 
> > > If i2c_dw_probe() fail, we should call i2c_dw_plat_prepare_clk() to
> > > disable and unprepare the clk, otherwise the clk enable and prepare
> > > is left unbalanced.
> > > 
> > > Signed-off-by: Jisheng Zhang 
> > > ---
> > >   drivers/i2c/busses/i2c-designware-platdrv.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> > > b/drivers/i2c/busses/i2c-designware-platdrv.c
> > > index 00f9e99..1488cea 100644
> > > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > > @@ -268,6 +268,8 @@ rpm_disable:
> > >   pm_runtime_put_noidle(>dev);
> > >   }
> > > 
> > > + i2c_dw_plat_prepare_clk(dev, false);
> > > +
> > >   return r;
> > >   }
> > >   
> > This is a bit unclear to me does devm_clk_get take care of clk
> > disabling 
> > in case of probe error or driver removal?
> > 
> > I see Andy's 1cb715ca4694 ("i2c-designware: move to managed functions 
> > (devm_*)") removed it but at quick look drivers/clk/clk-devres.c: 
> > devm_clk_release() calls only clk_put and I don't see disable is done 
> > down the path.  
> 
> The following is a mistake of the mentioned patch.
> -   clk_disable_unprepare(dev->clk);
> 
> I did at the same mistake in dw_dmac driver which had been fixed later
> in the commit 8be4f523b480 ("dmaengine: dw: fix regression in dw_probe()
> function").
> 

As Andy pointed out, managed devm_clk_get can only automatically put clk
but doesn't unprepare and disable the clk

Thanks,
Jisheng

Re: [PATCH 2/4] i2c: designware-platdrv: fix unbalanced clk enable and prepare

[Jisheng Zhang]

Dear Jarkko, Andy,

On Wed, 20 Apr 2016 17:16:00 +0300 Andy Shevchenko wrote:

> On Wed, 2016-04-20 at 15:55 +0300, Jarkko Nikula wrote:
> > On 04/14/2016 03:53 PM, Jisheng Zhang wrote:  
> > > 
> > > If i2c_dw_probe() fail, we should call i2c_dw_plat_prepare_clk() to
> > > disable and unprepare the clk, otherwise the clk enable and prepare
> > > is left unbalanced.
> > > 
> > > Signed-off-by: Jisheng Zhang 
> > > ---
> > >   drivers/i2c/busses/i2c-designware-platdrv.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> > > b/drivers/i2c/busses/i2c-designware-platdrv.c
> > > index 00f9e99..1488cea 100644
> > > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > > @@ -268,6 +268,8 @@ rpm_disable:
> > >   pm_runtime_put_noidle(>dev);
> > >   }
> > > 
> > > + i2c_dw_plat_prepare_clk(dev, false);
> > > +
> > >   return r;
> > >   }
> > >   
> > This is a bit unclear to me does devm_clk_get take care of clk
> > disabling 
> > in case of probe error or driver removal?
> > 
> > I see Andy's 1cb715ca4694 ("i2c-designware: move to managed functions 
> > (devm_*)") removed it but at quick look drivers/clk/clk-devres.c: 
> > devm_clk_release() calls only clk_put and I don't see disable is done 
> > down the path.  
> 
> The following is a mistake of the mentioned patch.
> -   clk_disable_unprepare(dev->clk);
> 
> I did at the same mistake in dw_dmac driver which had been fixed later
> in the commit 8be4f523b480 ("dmaengine: dw: fix regression in dw_probe()
> function").
> 

As Andy pointed out, managed devm_clk_get can only automatically put clk
but doesn't unprepare and disable the clk

Thanks,
Jisheng

IPv6 patch mysteriously breaks IPv4 VPN

[Valdis Kletnieks]

I'll say up front - no, I do *not* have a clue why this commit causes this
problem - it makes exactly zero fsking sense.

Scenario:  $WORK is blessed with a Juniper VPN system.  I've been
seeing for a while now (since Dec-ish) an issue where at startup,
the tun0 device will get wedged.  ifconfig reports this:

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
inet 172.27.1.165  netmask 255.255.255.255  destination 172.27.1.165
inet6 fe80::6802:d95c:f3f4:2a6f  prefixlen 64  scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  
(UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 1  bytes 48 (48.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

and no more packets cross - not even a ping.

Yes, the tunnel is ipv4 only, and only ipv4 routes get set by the VPN software.

bisect results confirmed - linux-next 20160327 is bad, but 20160420 with this
one conmmit reverted works.

% git bisect bad  
cc9da6cc4f56e05cc9e591459fe0192727ff58b3 is the first bad commit
commit cc9da6cc4f56e05cc9e591459fe0192727ff58b3
Author: Bjørn Mork <bj...@mork.no>
Date:   Wed Dec 16 16:44:38 2015 +0100

ipv6: addrconf: use stable address generator for ARPHRD_NONE

Add a new address generator mode, using the stable address generator
with an automatically generated secret. This is intended as a default
address generator mode for device types with no EUI64 implementation.
The new generator is used for ARPHRD_NONE interfaces initially, adding
default IPv6 autoconf support to e.g. tun interfaces.

If the addrgenmode is set to 'random', either by default or manually,
and no stable secret is available, then a random secret is used as
input for the stable-privacy address generator.  The secret can be
read and modified like manually configured secrets, using the proc
interface.  Modifying the secret will change the addrgen mode to
'stable-privacy' to indicate that it operates on a known secret.

Existing behaviour of the 'stable-privacy' mode is kept unchanged. If
a known secret is available when the device is created, then the mode
will default to 'stable-privacy' as before.  The mode can be manually
set to 'random' but it will behave exactly like 'stable-privacy' in
this case. The secret will not change.

Cc: Hannes Frederic Sowa <han...@stressinduktion.org>
Cc: 吉藤英明 <hideaki.yoshif...@miraclelinux.com>
Signed-off-by: Bjørn Mork <bj...@mork.no>
Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>
Signed-off-by: David S. Miller <da...@davemloft.net>

(Sorry for the delay in reporting this - bisecting this proved to be
a bear and a half, because this problematic commit landed only about 10 commits 
after
this one: 

git bisect start
# good: [1bd4978a88ac2589f3105f599b1d404a312fb7f6] tun: honor IFF_UP in 
tun_get_user()

which fixed a *different* issue that prevented the tun device from getting
created at all (or it was immediately taken back down by the VPN software).
End result was that unless I gave a "known good" start point in that dozen
commit range, there's be a month's worth of 'git commit skip' to wade through.
I got damned lucky and found a record on one of my servers of an ssh over VPN,
and correlated it to the one day that linux-next had the above fix for the
previous issue, and wasn't broken by this current issue)


pgpExEp33iYTU.pgp
Description: PGP signature

IPv6 patch mysteriously breaks IPv4 VPN

[Valdis Kletnieks]

I'll say up front - no, I do *not* have a clue why this commit causes this
problem - it makes exactly zero fsking sense.

Scenario:  $WORK is blessed with a Juniper VPN system.  I've been
seeing for a while now (since Dec-ish) an issue where at startup,
the tun0 device will get wedged.  ifconfig reports this:

tun0: flags=4305  mtu 1400
inet 172.27.1.165  netmask 255.255.255.255  destination 172.27.1.165
inet6 fe80::6802:d95c:f3f4:2a6f  prefixlen 64  scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  
(UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 1  bytes 48 (48.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

and no more packets cross - not even a ping.

Yes, the tunnel is ipv4 only, and only ipv4 routes get set by the VPN software.

bisect results confirmed - linux-next 20160327 is bad, but 20160420 with this
one conmmit reverted works.

% git bisect bad  
cc9da6cc4f56e05cc9e591459fe0192727ff58b3 is the first bad commit
commit cc9da6cc4f56e05cc9e591459fe0192727ff58b3
Author: Bjørn Mork 
Date:   Wed Dec 16 16:44:38 2015 +0100

ipv6: addrconf: use stable address generator for ARPHRD_NONE

Add a new address generator mode, using the stable address generator
with an automatically generated secret. This is intended as a default
address generator mode for device types with no EUI64 implementation.
The new generator is used for ARPHRD_NONE interfaces initially, adding
default IPv6 autoconf support to e.g. tun interfaces.

If the addrgenmode is set to 'random', either by default or manually,
and no stable secret is available, then a random secret is used as
input for the stable-privacy address generator.  The secret can be
read and modified like manually configured secrets, using the proc
interface.  Modifying the secret will change the addrgen mode to
'stable-privacy' to indicate that it operates on a known secret.

Existing behaviour of the 'stable-privacy' mode is kept unchanged. If
a known secret is available when the device is created, then the mode
will default to 'stable-privacy' as before.  The mode can be manually
set to 'random' but it will behave exactly like 'stable-privacy' in
this case. The secret will not change.

Cc: Hannes Frederic Sowa 
Cc: 吉藤英明 
Signed-off-by: Bjørn Mork 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 

(Sorry for the delay in reporting this - bisecting this proved to be
a bear and a half, because this problematic commit landed only about 10 commits 
after
this one: 

git bisect start
# good: [1bd4978a88ac2589f3105f599b1d404a312fb7f6] tun: honor IFF_UP in 
tun_get_user()

which fixed a *different* issue that prevented the tun device from getting
created at all (or it was immediately taken back down by the VPN software).
End result was that unless I gave a "known good" start point in that dozen
commit range, there's be a month's worth of 'git commit skip' to wade through.
I got damned lucky and found a record on one of my servers of an ssh over VPN,
and correlated it to the one day that linux-next had the above fix for the
previous issue, and wasn't broken by this current issue)


pgpExEp33iYTU.pgp
Description: PGP signature

Re: [RFC PATCH 3/4] intel_pstate: support scheduler cpufreq callbacks on remote CPUs

[Steve Muckle]

On Wed, Apr 20, 2016 at 02:37:18PM +0200, Rafael J. Wysocki wrote:
...
> > @@ -1173,20 +1179,88 @@ static inline void 
> > intel_pstate_adjust_busy_pstate(struct cpudata *cpu)
> > get_avg_frequency(cpu));
> >  }
> >  
> > +static void _intel_pstate_update_util(struct cpudata *cpu, u64 time)
> 
> What about calling this intel_pstate_update_cpu()?

Sure will change.

...
> >  static void intel_pstate_update_util(struct update_util_data *data, u64 
> > time,
> >  unsigned long util, unsigned long max)
> >  {
> > struct cpudata *cpu = container_of(data, struct cpudata, update_util);
> > -   u64 delta_ns = time - cpu->sample.time;
> > +   s64 delta_ns = time - cpu->sample.time;
> >  
> > -   if ((s64)delta_ns >= pid_params.sample_rate_ns) {
> > -   bool sample_taken = intel_pstate_sample(cpu, time);
> > +   if (delta_ns < pid_params.sample_rate_ns)
> 
> Why don't you check cpu->ipi_in_progress here too and bail out if it is set?
> 
> That would allow you to avoid checking the time again below, woulnd't it?

Yeah I think that should work. I can't recall why I thought I needed
to check the time first, then ipi_in_progress, then the time. As long
as ipi_in_progress is checked prior to the time, it should be fine.

> 
> > +   return;
> >  
> > -   if (sample_taken && !hwp_active)
> > -   intel_pstate_adjust_busy_pstate(cpu);
> > +   if (cpu->cpu == smp_processor_id()) {
> > +   _intel_pstate_update_util(cpu, time);
> > +   } else {
> > +   /* The target CPU's rq lock is held. */
> > +   if (cpu->ipi_in_progress)
> > +   return;
> > +
> > +   /* Re-check sample_time which may have advanced. */
> > +   smp_rmb();
> > +   delta_ns = time - READ_ONCE(cpu->sample.time);
> > +   if (delta_ns < pid_params.sample_rate_ns)
> > +   return;
> > +
> > +   cpu->ipi_in_progress = true;
> > +   cpu->time = time;
> > +   irq_work_queue_on(>irq_work, cpu->cpu);
> > }
> >  }
> >  
> > +static inline void intel_pstate_irq_work_sync(unsigned int cpu)
> > +{
> > +   irq_work_sync(_cpu_data[cpu]->irq_work);
> > +}
> > +
> > +static inline void intel_pstate_init_irq_work(struct cpudata *cpu)
> > +{
> > +   init_irq_work(>irq_work, intel_pstate_update_util_remote);
> > +}
> > +#else /* !CONFIG_SMP */
> > +static inline void intel_pstate_irq_work_sync(unsigned int cpu) {}
> > +static inline void intel_pstate_init_irq_work(struct cpudata *cpu) {}
> > +
> > +static void intel_pstate_update_util(struct update_util_data *data, u64 
> > time,
> > +unsigned long util, unsigned long max)
> > +{
> > +   struct cpudata *cpu = container_of(data, struct cpudata, update_util);
> > +   s64 delta_ns = time - cpu->sample.time;
> > +
> > +   if (delta_ns < pid_params.sample_rate_ns)
> > +   return;
> > +
> > +   _intel_pstate_update_util(cpu, time);
> > +}
> > +#endif
> > +
> > +
> > +
> 
> The additional two empty lines are not necessary.
> 

Sorry yeah these were unintentional, will remove these and the ones below.

Thanks for the review.

thanks,
Steve

Re: [RFC PATCH 3/4] intel_pstate: support scheduler cpufreq callbacks on remote CPUs

[Steve Muckle]

On Wed, Apr 20, 2016 at 02:37:18PM +0200, Rafael J. Wysocki wrote:
...
> > @@ -1173,20 +1179,88 @@ static inline void 
> > intel_pstate_adjust_busy_pstate(struct cpudata *cpu)
> > get_avg_frequency(cpu));
> >  }
> >  
> > +static void _intel_pstate_update_util(struct cpudata *cpu, u64 time)
> 
> What about calling this intel_pstate_update_cpu()?

Sure will change.

...
> >  static void intel_pstate_update_util(struct update_util_data *data, u64 
> > time,
> >  unsigned long util, unsigned long max)
> >  {
> > struct cpudata *cpu = container_of(data, struct cpudata, update_util);
> > -   u64 delta_ns = time - cpu->sample.time;
> > +   s64 delta_ns = time - cpu->sample.time;
> >  
> > -   if ((s64)delta_ns >= pid_params.sample_rate_ns) {
> > -   bool sample_taken = intel_pstate_sample(cpu, time);
> > +   if (delta_ns < pid_params.sample_rate_ns)
> 
> Why don't you check cpu->ipi_in_progress here too and bail out if it is set?
> 
> That would allow you to avoid checking the time again below, woulnd't it?

Yeah I think that should work. I can't recall why I thought I needed
to check the time first, then ipi_in_progress, then the time. As long
as ipi_in_progress is checked prior to the time, it should be fine.

> 
> > +   return;
> >  
> > -   if (sample_taken && !hwp_active)
> > -   intel_pstate_adjust_busy_pstate(cpu);
> > +   if (cpu->cpu == smp_processor_id()) {
> > +   _intel_pstate_update_util(cpu, time);
> > +   } else {
> > +   /* The target CPU's rq lock is held. */
> > +   if (cpu->ipi_in_progress)
> > +   return;
> > +
> > +   /* Re-check sample_time which may have advanced. */
> > +   smp_rmb();
> > +   delta_ns = time - READ_ONCE(cpu->sample.time);
> > +   if (delta_ns < pid_params.sample_rate_ns)
> > +   return;
> > +
> > +   cpu->ipi_in_progress = true;
> > +   cpu->time = time;
> > +   irq_work_queue_on(>irq_work, cpu->cpu);
> > }
> >  }
> >  
> > +static inline void intel_pstate_irq_work_sync(unsigned int cpu)
> > +{
> > +   irq_work_sync(_cpu_data[cpu]->irq_work);
> > +}
> > +
> > +static inline void intel_pstate_init_irq_work(struct cpudata *cpu)
> > +{
> > +   init_irq_work(>irq_work, intel_pstate_update_util_remote);
> > +}
> > +#else /* !CONFIG_SMP */
> > +static inline void intel_pstate_irq_work_sync(unsigned int cpu) {}
> > +static inline void intel_pstate_init_irq_work(struct cpudata *cpu) {}
> > +
> > +static void intel_pstate_update_util(struct update_util_data *data, u64 
> > time,
> > +unsigned long util, unsigned long max)
> > +{
> > +   struct cpudata *cpu = container_of(data, struct cpudata, update_util);
> > +   s64 delta_ns = time - cpu->sample.time;
> > +
> > +   if (delta_ns < pid_params.sample_rate_ns)
> > +   return;
> > +
> > +   _intel_pstate_update_util(cpu, time);
> > +}
> > +#endif
> > +
> > +
> > +
> 
> The additional two empty lines are not necessary.
> 

Sorry yeah these were unintentional, will remove these and the ones below.

Thanks for the review.

thanks,
Steve

Re: [PATCH v11 0/3] printk: Make printk() completely async

[Joe Perches]

On Thu, 2016-04-21 at 11:14 +0900, Sergey Senozhatsky wrote:
> On (04/15/16 22:44), Joe Perches wrote:
> [..]
> > > Sir, is there anything else you want me to improve in this patch
> > > set?
> > I'm not sir, but my preference would be to move as much of the
> > async/thread functionality as possible into a separate file.
> hm, we are talking about some 50-60 lines of code in total (seems
> that the patch set adds more comments than code), but your point
> is interesting. let's say, if there will be more opinions that it
> better land in async_printk.{c,h} files, then I'll take a look on
> it. how does it sound?

I think printk.c is pretty large, complicated and should
be broken up into several bits.

I did that once, but it's a real development timing issue 
https://lkml.org/lkml/2012/10/17/41

cheers, Joe

Re: [PATCH v11 0/3] printk: Make printk() completely async

[Joe Perches]

On Thu, 2016-04-21 at 11:14 +0900, Sergey Senozhatsky wrote:
> On (04/15/16 22:44), Joe Perches wrote:
> [..]
> > > Sir, is there anything else you want me to improve in this patch
> > > set?
> > I'm not sir, but my preference would be to move as much of the
> > async/thread functionality as possible into a separate file.
> hm, we are talking about some 50-60 lines of code in total (seems
> that the patch set adds more comments than code), but your point
> is interesting. let's say, if there will be more opinions that it
> better land in async_printk.{c,h} files, then I'll take a look on
> it. how does it sound?

I think printk.c is pretty large, complicated and should
be broken up into several bits.

I did that once, but it's a real development timing issue 
https://lkml.org/lkml/2012/10/17/41

cheers, Joe

Re: Sound: BUG: KASAN: use-after-free in kill_fasync

[Baozeng Ding]

On 2016/4/6 19:37, Baozeng Ding wrote:



On 2016/4/5 22:18, Takashi Iwai wrote:

On Tue, 05 Apr 2016 15:51:30 +0200,
Baozeng Ding wrote:

Hi all,
I've got the following report (use-after-free in kill_fasync) while
running syzkaller.
Unfortunately no reproducer.The kernel version is 4.5 (on Mar 16 commit
09fd671ccb2475436bd5f597f751ca4a7d177aea).

==
BUG: KASAN: use-after-free in kill_fasync+0x3fb/0x420 at addr
880067691d88
Read of size 8 by task swapper/2/0
= 


BUG kmalloc-2048 (Not tainted): kasan: bad access detected
- 



Disabling lock debugging due to kernel taint
INFO: Allocated in 0x age=18446678412249576073
cpu=2245704320 pid=-1
[< inline >] kmalloc /kernel/include/linux/slab.h:472
[< inline >] kzalloc /kernel/include/linux/slab.h:616
[<  none  >] snd_pcm_attach_substream+0x3b4/0xb10
/kernel/sound/core/pcm.c:966
[<  none  >] ___slab_alloc+0x4c7/0x500 /kernel/mm/slub.c:2446
[<  none  >] __slab_alloc+0x4c/0x90 /kernel/mm/slub.c:2475
[< inline >] slab_alloc_node /kernel/mm/slub.c:2538
[< inline >] slab_alloc /kernel/mm/slub.c:2580
[<  none  >] kmem_cache_alloc_trace+0x262/0x300
/kernel/mm/slub.c:2597
[< inline >] kmalloc /kernel/include/linux/slab.h:472
[< inline >] kzalloc /kernel/include/linux/slab.h:616
[<  none  >] snd_pcm_attach_substream+0x3b4/0xb10
/kernel/sound/core/pcm.c:966
[<  none  >] snd_pcm_open_substream+0x84/0x450
/kernel/sound/core/pcm_native.c:2262
[< inline >] snd_pcm_oss_open_file
/kernel/sound/core/oss/pcm_oss.c:2346
[<  none  >] snd_pcm_oss_open.part.17+0x5a4/0x1100
/kernel/sound/core/oss/pcm_oss.c:2428
[<  none  >] snd_pcm_oss_open+0x35/0x50
/kernel/sound/core/oss/pcm_oss.c:2392
[<  none  >] soundcore_open+0x30f/0x640
/kernel/sound/sound_core.c:639
[<  none  >] chrdev_open+0x22a/0x4c0 /kernel/fs/char_dev.c:388
[<  none  >] do_dentry_open+0x6a2/0xcb0 /kernel/fs/open.c:736
[<  none  >] vfs_open+0x17b/0x1f0 /kernel/fs/open.c:853
[< inline >] do_last /kernel/fs/namei.c:3258
[<  none  >] path_openat+0x4837/0x5830 /kernel/fs/namei.c:3394
[<  none  >] do_filp_open+0x18e/0x250 /kernel/fs/namei.c:3429
[<  none  >] do_sys_open+0x201/0x420 /kernel/fs/open.c:1022
[< inline >] SYSC_open /kernel/fs/open.c:1040
[<  none  >] SyS_open+0x2d/0x40 /kernel/fs/open.c:1035
INFO: Freed in 0x1b076 age=18446678416544543380 cpu=0 pid=0
[<  none  >] snd_pcm_detach_substream+0x134/0x280
/kernel/sound/core/pcm.c:1017
[<  none  >] __slab_free+0x1e8/0x300 /kernel/mm/slub.c:2657
[< inline >] slab_free /kernel/mm/slub.c:2810
[<  none  >] kfree+0x24e/0x2d0 /kernel/mm/slub.c:3661
[<  none  >] snd_pcm_detach_substream+0x134/0x280
/kernel/sound/core/pcm.c:1017
[<  none  >] snd_pcm_release_substream.part.38+0x219/0x2f0
/kernel/sound/core/pcm_native.c:2250
[<  none  >] snd_pcm_release_substream+0x59/0x70
/kernel/sound/core/pcm_native.c:2251
[<  none  >] snd_pcm_oss_release_file+0x45/0xb0
/kernel/sound/core/oss/pcm_oss.c:2305
[<  none  >] snd_pcm_oss_release+0xfa/0x250
/kernel/sound/core/oss/pcm_oss.c:2485
[<  none  >] __fput+0x236/0x780 /kernel/fs/file_table.c:208
[<  none  >] fput+0x15/0x20 /kernel/fs/file_table.c:244
[<  none  >] task_work_run+0x16b/0x200
/kernel/kernel/task_work.c:115
[< inline >] exit_task_work 
/kernel/include/linux/task_work.h:21

[<  none  >] do_exit+0x87f/0x2c90 /kernel/kernel/exit.c:748
[<  none  >] do_group_exit+0x108/0x330 
/kernel/kernel/exit.c:878

[< inline >] SYSC_exit_group /kernel/kernel/exit.c:889
[<  none  >] SyS_exit_group+0x1d/0x20 /kernel/kernel/exit.c:887
[<  none  >] entry_SYSCALL_64_fastpath+0x23/0xc1
/kernel/arch/x86/entry/entry_64.S:207
INFO: Slab 0xea00019da400 objects=13 used=8 fp=0x880067691be0
flags=0x5fffc004080
INFO: Object 0x880067691bd8 @offset=7128 fp=0x
Call Trace:
 [< inline >] __dump_stack /kernel/lib/dump_stack.c:15
 [] dump_stack+0xb3/0x112
/kernel/lib/dump_stack.c:51
   [] print_trailer+0x10d/0x190 /kernel/mm/slub.c:668
   [] object_err+0x2f/0x40 /kernel/mm/slub.c:675
   [< inline >] print_address_description
/kernel/mm/kasan/report.c:138
   [] kasan_report_error+0x215/0x530
/kernel/mm/kasan/report.c:236
   [< inline >] ? spin_lock 
/kernel/include/linux/spinlock.h:302

   [] ? snd_pcm_stream_lock+0x80/0xd0
/kernel/sound/core/pcm_native.c:104
   [< inline >] kasan_report /kernel/mm/kasan/report.c:259
   [] __asan_report_load8_noabort+0x3e/0x40
/kernel/mm/kasan/report.c:280
   [] ? kill_fasync+0x3fb/0x420 

Re: Sound: BUG: KASAN: use-after-free in kill_fasync

[Baozeng Ding]

On 2016/4/6 19:37, Baozeng Ding wrote:



On 2016/4/5 22:18, Takashi Iwai wrote:

On Tue, 05 Apr 2016 15:51:30 +0200,
Baozeng Ding wrote:

Hi all,
I've got the following report (use-after-free in kill_fasync) while
running syzkaller.
Unfortunately no reproducer.The kernel version is 4.5 (on Mar 16 commit
09fd671ccb2475436bd5f597f751ca4a7d177aea).

==
BUG: KASAN: use-after-free in kill_fasync+0x3fb/0x420 at addr
880067691d88
Read of size 8 by task swapper/2/0
= 


BUG kmalloc-2048 (Not tainted): kasan: bad access detected
- 



Disabling lock debugging due to kernel taint
INFO: Allocated in 0x age=18446678412249576073
cpu=2245704320 pid=-1
[< inline >] kmalloc /kernel/include/linux/slab.h:472
[< inline >] kzalloc /kernel/include/linux/slab.h:616
[<  none  >] snd_pcm_attach_substream+0x3b4/0xb10
/kernel/sound/core/pcm.c:966
[<  none  >] ___slab_alloc+0x4c7/0x500 /kernel/mm/slub.c:2446
[<  none  >] __slab_alloc+0x4c/0x90 /kernel/mm/slub.c:2475
[< inline >] slab_alloc_node /kernel/mm/slub.c:2538
[< inline >] slab_alloc /kernel/mm/slub.c:2580
[<  none  >] kmem_cache_alloc_trace+0x262/0x300
/kernel/mm/slub.c:2597
[< inline >] kmalloc /kernel/include/linux/slab.h:472
[< inline >] kzalloc /kernel/include/linux/slab.h:616
[<  none  >] snd_pcm_attach_substream+0x3b4/0xb10
/kernel/sound/core/pcm.c:966
[<  none  >] snd_pcm_open_substream+0x84/0x450
/kernel/sound/core/pcm_native.c:2262
[< inline >] snd_pcm_oss_open_file
/kernel/sound/core/oss/pcm_oss.c:2346
[<  none  >] snd_pcm_oss_open.part.17+0x5a4/0x1100
/kernel/sound/core/oss/pcm_oss.c:2428
[<  none  >] snd_pcm_oss_open+0x35/0x50
/kernel/sound/core/oss/pcm_oss.c:2392
[<  none  >] soundcore_open+0x30f/0x640
/kernel/sound/sound_core.c:639
[<  none  >] chrdev_open+0x22a/0x4c0 /kernel/fs/char_dev.c:388
[<  none  >] do_dentry_open+0x6a2/0xcb0 /kernel/fs/open.c:736
[<  none  >] vfs_open+0x17b/0x1f0 /kernel/fs/open.c:853
[< inline >] do_last /kernel/fs/namei.c:3258
[<  none  >] path_openat+0x4837/0x5830 /kernel/fs/namei.c:3394
[<  none  >] do_filp_open+0x18e/0x250 /kernel/fs/namei.c:3429
[<  none  >] do_sys_open+0x201/0x420 /kernel/fs/open.c:1022
[< inline >] SYSC_open /kernel/fs/open.c:1040
[<  none  >] SyS_open+0x2d/0x40 /kernel/fs/open.c:1035
INFO: Freed in 0x1b076 age=18446678416544543380 cpu=0 pid=0
[<  none  >] snd_pcm_detach_substream+0x134/0x280
/kernel/sound/core/pcm.c:1017
[<  none  >] __slab_free+0x1e8/0x300 /kernel/mm/slub.c:2657
[< inline >] slab_free /kernel/mm/slub.c:2810
[<  none  >] kfree+0x24e/0x2d0 /kernel/mm/slub.c:3661
[<  none  >] snd_pcm_detach_substream+0x134/0x280
/kernel/sound/core/pcm.c:1017
[<  none  >] snd_pcm_release_substream.part.38+0x219/0x2f0
/kernel/sound/core/pcm_native.c:2250
[<  none  >] snd_pcm_release_substream+0x59/0x70
/kernel/sound/core/pcm_native.c:2251
[<  none  >] snd_pcm_oss_release_file+0x45/0xb0
/kernel/sound/core/oss/pcm_oss.c:2305
[<  none  >] snd_pcm_oss_release+0xfa/0x250
/kernel/sound/core/oss/pcm_oss.c:2485
[<  none  >] __fput+0x236/0x780 /kernel/fs/file_table.c:208
[<  none  >] fput+0x15/0x20 /kernel/fs/file_table.c:244
[<  none  >] task_work_run+0x16b/0x200
/kernel/kernel/task_work.c:115
[< inline >] exit_task_work 
/kernel/include/linux/task_work.h:21

[<  none  >] do_exit+0x87f/0x2c90 /kernel/kernel/exit.c:748
[<  none  >] do_group_exit+0x108/0x330 
/kernel/kernel/exit.c:878

[< inline >] SYSC_exit_group /kernel/kernel/exit.c:889
[<  none  >] SyS_exit_group+0x1d/0x20 /kernel/kernel/exit.c:887
[<  none  >] entry_SYSCALL_64_fastpath+0x23/0xc1
/kernel/arch/x86/entry/entry_64.S:207
INFO: Slab 0xea00019da400 objects=13 used=8 fp=0x880067691be0
flags=0x5fffc004080
INFO: Object 0x880067691bd8 @offset=7128 fp=0x
Call Trace:
 [< inline >] __dump_stack /kernel/lib/dump_stack.c:15
 [] dump_stack+0xb3/0x112
/kernel/lib/dump_stack.c:51
   [] print_trailer+0x10d/0x190 /kernel/mm/slub.c:668
   [] object_err+0x2f/0x40 /kernel/mm/slub.c:675
   [< inline >] print_address_description
/kernel/mm/kasan/report.c:138
   [] kasan_report_error+0x215/0x530
/kernel/mm/kasan/report.c:236
   [< inline >] ? spin_lock 
/kernel/include/linux/spinlock.h:302

   [] ? snd_pcm_stream_lock+0x80/0xd0
/kernel/sound/core/pcm_native.c:104
   [< inline >] kasan_report /kernel/mm/kasan/report.c:259
   [] __asan_report_load8_noabort+0x3e/0x40
/kernel/mm/kasan/report.c:280
   [] ? kill_fasync+0x3fb/0x420 

Re: [PATCH v11 0/3] printk: Make printk() completely async

[Sergey Senozhatsky]

On (04/15/16 22:44), Joe Perches wrote:
[..]
> > Sir, is there anything else you want me to improve in this patch set?
> 
> I'm not sir, but my preference would be to move as much of the
> async/thread functionality as possible into a separate file.

hm, we are talking about some 50-60 lines of code in total (seems
that the patch set adds more comments than code), but your point
is interesting. let's say, if there will be more opinions that it
better land in async_printk.{c,h} files, then I'll take a look on
it. how does it sound?

-ss

Re: [PATCH v11 0/3] printk: Make printk() completely async

[Sergey Senozhatsky]

On (04/15/16 22:44), Joe Perches wrote:
[..]
> > Sir, is there anything else you want me to improve in this patch set?
> 
> I'm not sir, but my preference would be to move as much of the
> async/thread functionality as possible into a separate file.

hm, we are talking about some 50-60 lines of code in total (seems
that the patch set adds more comments than code), but your point
is interesting. let's say, if there will be more opinions that it
better land in async_printk.{c,h} files, then I'll take a look on
it. how does it sound?

-ss

[PATCH v2] ARM: dts: uniphier: add NAND pinmux node

[Masahiro Yamada]

This commit adds pin-mux nodes for the NAND controller.
Some SoCs support 2 chip selects and the others only support
1 chip select.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Add pinctrl_nand2cs node (NAND with 2 chip selects)

 arch/arm/boot/dts/uniphier-pinctrl.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-pinctrl.dtsi 
b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
index 2459279..f2f3fbe 100644
--- a/arch/arm/boot/dts/uniphier-pinctrl.dtsi
+++ b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
@@ -68,6 +68,16 @@
function = "i2c4";
};
 
+   pinctrl_nand: nand_grp {
+   groups = "nand";
+   function = "nand";
+   };
+
+   pinctrl_nand2cs: nand2cs_grp {
+   groups = "nand", "nand_cs1";
+   function = "nand";
+   };
+
pinctrl_uart0: uart0_grp {
groups = "uart0";
function = "uart0";
-- 
1.9.1

[PATCH v2] ARM: dts: uniphier: add NAND pinmux node

[Masahiro Yamada]

This commit adds pin-mux nodes for the NAND controller.
Some SoCs support 2 chip selects and the others only support
1 chip select.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Add pinctrl_nand2cs node (NAND with 2 chip selects)

 arch/arm/boot/dts/uniphier-pinctrl.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-pinctrl.dtsi 
b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
index 2459279..f2f3fbe 100644
--- a/arch/arm/boot/dts/uniphier-pinctrl.dtsi
+++ b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
@@ -68,6 +68,16 @@
function = "i2c4";
};
 
+   pinctrl_nand: nand_grp {
+   groups = "nand";
+   function = "nand";
+   };
+
+   pinctrl_nand2cs: nand2cs_grp {
+   groups = "nand", "nand_cs1";
+   function = "nand";
+   };
+
pinctrl_uart0: uart0_grp {
groups = "uart0";
function = "uart0";
-- 
1.9.1

[PATCH] usb: xhci-mtk: fixup mouse wakeup failure during system suspend

[Chunfeng Yun]

Click mouse after xhci suspend completion but before system suspend
completion, system will not be waken up by mouse if the duration of
them is larger than 20ms which is the device UFP's resume signaling
lasted. Another reason is that the SPM is not enabled before system
suspend compeltion, this causes SPM also not notice the resume signal.
So in order to reduce the duration less than 20ms, make use of
syscore's suspend/resume interface.
In fact it is a work around solution which only reduces the
probability of failure, because we can't ensure that the duration from
syscore's suspend completion to SPM working is always less than 20ms.

Because the syscore runs on irq disabled context, and xhci's
suspend/resume calls some sleeping functions, enable local irq
and then disable it during suspend/resume. This may be not a problem,
since only boot CPU is runing.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..8277f02 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xhci.h"
 #include "xhci-mtk.h"
@@ -490,6 +491,8 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
return xhci_gen_setup(hcd, xhci_mtk_quirks);
 }
 
+static struct device *xhci_mtk_syscore_dev;
+
 static int xhci_mtk_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -512,6 +515,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
if (!mtk)
return -ENOMEM;
 
+   xhci_mtk_syscore_dev = dev;
mtk->dev = dev;
mtk->vbus = devm_regulator_get(dev, "vbus");
if (IS_ERR(mtk->vbus)) {
@@ -740,6 +744,29 @@ static int __maybe_unused xhci_mtk_resume(struct device 
*dev)
return 0;
 }
 
+static int xhci_mtk_syscore_suspend(void)
+{
+   local_irq_enable();
+   xhci_mtk_suspend(xhci_mtk_syscore_dev);
+   local_irq_disable();
+
+   return 0;
+}
+
+static void xhci_mtk_syscore_resume(void)
+{
+   local_irq_enable();
+   xhci_mtk_resume(xhci_mtk_syscore_dev);
+   local_irq_disable();
+
+   return;
+}
+
+static struct syscore_ops xhci_mtk_syscore_ops = {
+   .suspend = xhci_mtk_syscore_suspend,
+   .resume = xhci_mtk_syscore_resume,
+};
+
 static const struct dev_pm_ops xhci_mtk_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
 };
@@ -758,7 +785,7 @@ static struct platform_driver mtk_xhci_driver = {
.remove = xhci_mtk_remove,
.driver = {
.name = "xhci-mtk",
-   .pm = DEV_PM_OPS,
+   /*.pm = DEV_PM_OPS,*/
.of_match_table = of_match_ptr(mtk_xhci_of_match),
},
 };
@@ -766,6 +793,7 @@ MODULE_ALIAS("platform:xhci-mtk");
 
 static int __init xhci_mtk_init(void)
 {
+   register_syscore_ops(_mtk_syscore_ops);
xhci_init_driver(_mtk_hc_driver, _mtk_overrides);
return platform_driver_register(_xhci_driver);
 }
@@ -774,6 +802,7 @@ module_init(xhci_mtk_init);
 static void __exit xhci_mtk_exit(void)
 {
platform_driver_unregister(_xhci_driver);
+   unregister_syscore_ops(_mtk_syscore_ops);
 }
 module_exit(xhci_mtk_exit);
 
-- 
1.7.9.5

[PATCH] usb: xhci-mtk: fixup mouse wakeup failure during system suspend

[Chunfeng Yun]

Click mouse after xhci suspend completion but before system suspend
completion, system will not be waken up by mouse if the duration of
them is larger than 20ms which is the device UFP's resume signaling
lasted. Another reason is that the SPM is not enabled before system
suspend compeltion, this causes SPM also not notice the resume signal.
So in order to reduce the duration less than 20ms, make use of
syscore's suspend/resume interface.
In fact it is a work around solution which only reduces the
probability of failure, because we can't ensure that the duration from
syscore's suspend completion to SPM working is always less than 20ms.

Because the syscore runs on irq disabled context, and xhci's
suspend/resume calls some sleeping functions, enable local irq
and then disable it during suspend/resume. This may be not a problem,
since only boot CPU is runing.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..8277f02 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xhci.h"
 #include "xhci-mtk.h"
@@ -490,6 +491,8 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
return xhci_gen_setup(hcd, xhci_mtk_quirks);
 }
 
+static struct device *xhci_mtk_syscore_dev;
+
 static int xhci_mtk_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -512,6 +515,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
if (!mtk)
return -ENOMEM;
 
+   xhci_mtk_syscore_dev = dev;
mtk->dev = dev;
mtk->vbus = devm_regulator_get(dev, "vbus");
if (IS_ERR(mtk->vbus)) {
@@ -740,6 +744,29 @@ static int __maybe_unused xhci_mtk_resume(struct device 
*dev)
return 0;
 }
 
+static int xhci_mtk_syscore_suspend(void)
+{
+   local_irq_enable();
+   xhci_mtk_suspend(xhci_mtk_syscore_dev);
+   local_irq_disable();
+
+   return 0;
+}
+
+static void xhci_mtk_syscore_resume(void)
+{
+   local_irq_enable();
+   xhci_mtk_resume(xhci_mtk_syscore_dev);
+   local_irq_disable();
+
+   return;
+}
+
+static struct syscore_ops xhci_mtk_syscore_ops = {
+   .suspend = xhci_mtk_syscore_suspend,
+   .resume = xhci_mtk_syscore_resume,
+};
+
 static const struct dev_pm_ops xhci_mtk_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
 };
@@ -758,7 +785,7 @@ static struct platform_driver mtk_xhci_driver = {
.remove = xhci_mtk_remove,
.driver = {
.name = "xhci-mtk",
-   .pm = DEV_PM_OPS,
+   /*.pm = DEV_PM_OPS,*/
.of_match_table = of_match_ptr(mtk_xhci_of_match),
},
 };
@@ -766,6 +793,7 @@ MODULE_ALIAS("platform:xhci-mtk");
 
 static int __init xhci_mtk_init(void)
 {
+   register_syscore_ops(_mtk_syscore_ops);
xhci_init_driver(_mtk_hc_driver, _mtk_overrides);
return platform_driver_register(_xhci_driver);
 }
@@ -774,6 +802,7 @@ module_init(xhci_mtk_init);
 static void __exit xhci_mtk_exit(void)
 {
platform_driver_unregister(_xhci_driver);
+   unregister_syscore_ops(_mtk_syscore_ops);
 }
 module_exit(xhci_mtk_exit);
 
-- 
1.7.9.5

[PATCH] ARM: cache-uniphier: activate ways for secondary CPUs

[Masahiro Yamada]

This outer cache allows to control active ways independently for
each CPU, but currently nothing is done for secondary CPUs.  In
other words, all the ways are locked for secondary CPUs by default.
This commit fixes it to fully bring out the performance of this
outer cache.

There would be two possible ways to achieve this:

[1] Each CPU initializes active ways for itself.  This can be done
via the SSCLPDAWCR register.  This is a banked register, so each
CPU sees a different instance of the register for its own.

[2] The master CPU initializes active ways for all the CPUs.  This
is available via SSCDAWCARMR(N) registers, where all instances
of SSCLPDAWCR are mirrored.  They are mapped at the address
SSCDAWCARMR + 4 * N, where N is the CPU number.

The outer cache frame work does not support a per-CPU init callback.
So this commit adopts [2]; the master CPU iterates over possible CPUs
setting up SSCDAWCARMR(N) registers.

Signed-off-by: Masahiro Yamada 
---

KernelVersion: 4.6-rc4


 arch/arm/mm/cache-uniphier.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/cache-uniphier.c b/arch/arm/mm/cache-uniphier.c
index a6fa7b7..c8e2f49 100644
--- a/arch/arm/mm/cache-uniphier.c
+++ b/arch/arm/mm/cache-uniphier.c
@@ -96,6 +96,7 @@ struct uniphier_cache_data {
void __iomem *ctrl_base;
void __iomem *rev_base;
void __iomem *op_base;
+   void __iomem *way_ctrl_base;
u32 way_present_mask;
u32 way_locked_mask;
u32 nsets;
@@ -256,10 +257,13 @@ static void __init __uniphier_cache_set_locked_ways(
struct uniphier_cache_data *data,
u32 way_mask)
 {
+   unsigned int cpu;
+
data->way_locked_mask = way_mask & data->way_present_mask;
 
-   writel_relaxed(~data->way_locked_mask & data->way_present_mask,
-  data->ctrl_base + UNIPHIER_SSCLPDAWCR);
+   for_each_possible_cpu(cpu)
+   writel_relaxed(~data->way_locked_mask & data->way_present_mask,
+  data->way_ctrl_base + 4 * cpu);
 }
 
 static void uniphier_cache_maint_range(unsigned long start, unsigned long end,
@@ -459,6 +463,8 @@ static int __init __uniphier_cache_init(struct device_node 
*np,
goto err;
}
 
+   data->way_ctrl_base = data->ctrl_base + 0xc00;
+
if (*cache_level == 2) {
u32 revision = readl(data->rev_base + UNIPHIER_SSCID);
/*
@@ -467,6 +473,22 @@ static int __init __uniphier_cache_init(struct device_node 
*np,
 */
if (revision <= 0x16)
data->range_op_max_size = (u32)1 << 22;
+
+   /*
+* Unfortunatly, the offset address of active way control base
+* varies from SoC to SoC.
+*/
+   switch (revision) {
+   case 0x11:  /* sLD3 */
+   data->way_ctrl_base = data->ctrl_base + 0x870;
+   break;
+   case 0x12:  /* LD4 */
+   case 0x16:  /* sld8 */
+   data->way_ctrl_base = data->ctrl_base + 0x840;
+   break;
+   default:
+   break;
+   }
}
 
data->range_op_max_size -= data->line_size;
-- 
1.9.1

[PATCH] ARM: cache-uniphier: activate ways for secondary CPUs

[Masahiro Yamada]

This outer cache allows to control active ways independently for
each CPU, but currently nothing is done for secondary CPUs.  In
other words, all the ways are locked for secondary CPUs by default.
This commit fixes it to fully bring out the performance of this
outer cache.

There would be two possible ways to achieve this:

[1] Each CPU initializes active ways for itself.  This can be done
via the SSCLPDAWCR register.  This is a banked register, so each
CPU sees a different instance of the register for its own.

[2] The master CPU initializes active ways for all the CPUs.  This
is available via SSCDAWCARMR(N) registers, where all instances
of SSCLPDAWCR are mirrored.  They are mapped at the address
SSCDAWCARMR + 4 * N, where N is the CPU number.

The outer cache frame work does not support a per-CPU init callback.
So this commit adopts [2]; the master CPU iterates over possible CPUs
setting up SSCDAWCARMR(N) registers.

Signed-off-by: Masahiro Yamada 
---

KernelVersion: 4.6-rc4


 arch/arm/mm/cache-uniphier.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/cache-uniphier.c b/arch/arm/mm/cache-uniphier.c
index a6fa7b7..c8e2f49 100644
--- a/arch/arm/mm/cache-uniphier.c
+++ b/arch/arm/mm/cache-uniphier.c
@@ -96,6 +96,7 @@ struct uniphier_cache_data {
void __iomem *ctrl_base;
void __iomem *rev_base;
void __iomem *op_base;
+   void __iomem *way_ctrl_base;
u32 way_present_mask;
u32 way_locked_mask;
u32 nsets;
@@ -256,10 +257,13 @@ static void __init __uniphier_cache_set_locked_ways(
struct uniphier_cache_data *data,
u32 way_mask)
 {
+   unsigned int cpu;
+
data->way_locked_mask = way_mask & data->way_present_mask;
 
-   writel_relaxed(~data->way_locked_mask & data->way_present_mask,
-  data->ctrl_base + UNIPHIER_SSCLPDAWCR);
+   for_each_possible_cpu(cpu)
+   writel_relaxed(~data->way_locked_mask & data->way_present_mask,
+  data->way_ctrl_base + 4 * cpu);
 }
 
 static void uniphier_cache_maint_range(unsigned long start, unsigned long end,
@@ -459,6 +463,8 @@ static int __init __uniphier_cache_init(struct device_node 
*np,
goto err;
}
 
+   data->way_ctrl_base = data->ctrl_base + 0xc00;
+
if (*cache_level == 2) {
u32 revision = readl(data->rev_base + UNIPHIER_SSCID);
/*
@@ -467,6 +473,22 @@ static int __init __uniphier_cache_init(struct device_node 
*np,
 */
if (revision <= 0x16)
data->range_op_max_size = (u32)1 << 22;
+
+   /*
+* Unfortunatly, the offset address of active way control base
+* varies from SoC to SoC.
+*/
+   switch (revision) {
+   case 0x11:  /* sLD3 */
+   data->way_ctrl_base = data->ctrl_base + 0x870;
+   break;
+   case 0x12:  /* LD4 */
+   case 0x16:  /* sld8 */
+   data->way_ctrl_base = data->ctrl_base + 0x840;
+   break;
+   default:
+   break;
+   }
}
 
data->range_op_max_size -= data->line_size;
-- 
1.9.1

Re: [PATCH v11 3/3] printk: make printk.synchronous param rw

[Sergey Senozhatsky]

On (04/20/16 17:16), Jan Kara wrote:
[..]
> I finally found time to have a look. The patch looks good to me. You can
> add:
> 
> Reviewed-by: Jan Kara 


thanks.

-ss

[PATCH] ARM: cache-uniphier: activate ways for secondary CPUs

[Masahiro Yamada]

This outer cache allows to control active ways independently for
each CPU, but currently nothing is done for secondary CPUs.  In
other words, all the ways are locked for secondary CPUs by default.
This commit fixes it to fully bring out the performance of this
outer cache.

There would be two possible ways to achieve this:

[1] Each CPU initializes active ways for itself.  This can be done
via the SSCLPDAWCR register.  This is a banked register, so each
CPU sees a different instance of the register.

[2] The master CPU initializes active ways for all the CPUs.  This
is available via SSCDAWCARMR(N) registers.  They are mapped at
the address SSCDAWCARMR + 4 * N, where N is the CPU number.

The outer cache frame work does not support a per-CPU init callback.
So this commit adopts [2]; the master CPU iterates over possible CPUs
setting up SSCDAWCARMR(N) registers.

Unfortunately, the register offsets for SSCDAWCARMR(N) are different
by SoC.  We can live with it by checking the version register.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mm/cache-uniphier.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/cache-uniphier.c b/arch/arm/mm/cache-uniphier.c
index a6fa7b7..c8e2f49 100644
--- a/arch/arm/mm/cache-uniphier.c
+++ b/arch/arm/mm/cache-uniphier.c
@@ -96,6 +96,7 @@ struct uniphier_cache_data {
void __iomem *ctrl_base;
void __iomem *rev_base;
void __iomem *op_base;
+   void __iomem *way_ctrl_base;
u32 way_present_mask;
u32 way_locked_mask;
u32 nsets;
@@ -256,10 +257,13 @@ static void __init __uniphier_cache_set_locked_ways(
struct uniphier_cache_data *data,
u32 way_mask)
 {
+   unsigned int cpu;
+
data->way_locked_mask = way_mask & data->way_present_mask;
 
-   writel_relaxed(~data->way_locked_mask & data->way_present_mask,
-  data->ctrl_base + UNIPHIER_SSCLPDAWCR);
+   for_each_possible_cpu(cpu)
+   writel_relaxed(~data->way_locked_mask & data->way_present_mask,
+  data->way_ctrl_base + 4 * cpu);
 }
 
 static void uniphier_cache_maint_range(unsigned long start, unsigned long end,
@@ -459,6 +463,8 @@ static int __init __uniphier_cache_init(struct device_node 
*np,
goto err;
}
 
+   data->way_ctrl_base = data->ctrl_base + 0xc00;
+
if (*cache_level == 2) {
u32 revision = readl(data->rev_base + UNIPHIER_SSCID);
/*
@@ -467,6 +473,22 @@ static int __init __uniphier_cache_init(struct device_node 
*np,
 */
if (revision <= 0x16)
data->range_op_max_size = (u32)1 << 22;
+
+   /*
+* Unfortunatly, the offset address of active way control base
+* varies from SoC to SoC.
+*/
+   switch (revision) {
+   case 0x11:  /* sLD3 */
+   data->way_ctrl_base = data->ctrl_base + 0x870;
+   break;
+   case 0x12:  /* LD4 */
+   case 0x16:  /* sld8 */
+   data->way_ctrl_base = data->ctrl_base + 0x840;
+   break;
+   default:
+   break;
+   }
}
 
data->range_op_max_size -= data->line_size;
-- 
1.9.1

Re: [PATCH v11 3/3] printk: make printk.synchronous param rw

[Sergey Senozhatsky]

On (04/20/16 17:16), Jan Kara wrote:
[..]
> I finally found time to have a look. The patch looks good to me. You can
> add:
> 
> Reviewed-by: Jan Kara 


thanks.

-ss

[PATCH] ARM: cache-uniphier: activate ways for secondary CPUs

[Masahiro Yamada]

This outer cache allows to control active ways independently for
each CPU, but currently nothing is done for secondary CPUs.  In
other words, all the ways are locked for secondary CPUs by default.
This commit fixes it to fully bring out the performance of this
outer cache.

There would be two possible ways to achieve this:

[1] Each CPU initializes active ways for itself.  This can be done
via the SSCLPDAWCR register.  This is a banked register, so each
CPU sees a different instance of the register.

[2] The master CPU initializes active ways for all the CPUs.  This
is available via SSCDAWCARMR(N) registers.  They are mapped at
the address SSCDAWCARMR + 4 * N, where N is the CPU number.

The outer cache frame work does not support a per-CPU init callback.
So this commit adopts [2]; the master CPU iterates over possible CPUs
setting up SSCDAWCARMR(N) registers.

Unfortunately, the register offsets for SSCDAWCARMR(N) are different
by SoC.  We can live with it by checking the version register.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mm/cache-uniphier.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/cache-uniphier.c b/arch/arm/mm/cache-uniphier.c
index a6fa7b7..c8e2f49 100644
--- a/arch/arm/mm/cache-uniphier.c
+++ b/arch/arm/mm/cache-uniphier.c
@@ -96,6 +96,7 @@ struct uniphier_cache_data {
void __iomem *ctrl_base;
void __iomem *rev_base;
void __iomem *op_base;
+   void __iomem *way_ctrl_base;
u32 way_present_mask;
u32 way_locked_mask;
u32 nsets;
@@ -256,10 +257,13 @@ static void __init __uniphier_cache_set_locked_ways(
struct uniphier_cache_data *data,
u32 way_mask)
 {
+   unsigned int cpu;
+
data->way_locked_mask = way_mask & data->way_present_mask;
 
-   writel_relaxed(~data->way_locked_mask & data->way_present_mask,
-  data->ctrl_base + UNIPHIER_SSCLPDAWCR);
+   for_each_possible_cpu(cpu)
+   writel_relaxed(~data->way_locked_mask & data->way_present_mask,
+  data->way_ctrl_base + 4 * cpu);
 }
 
 static void uniphier_cache_maint_range(unsigned long start, unsigned long end,
@@ -459,6 +463,8 @@ static int __init __uniphier_cache_init(struct device_node 
*np,
goto err;
}
 
+   data->way_ctrl_base = data->ctrl_base + 0xc00;
+
if (*cache_level == 2) {
u32 revision = readl(data->rev_base + UNIPHIER_SSCID);
/*
@@ -467,6 +473,22 @@ static int __init __uniphier_cache_init(struct device_node 
*np,
 */
if (revision <= 0x16)
data->range_op_max_size = (u32)1 << 22;
+
+   /*
+* Unfortunatly, the offset address of active way control base
+* varies from SoC to SoC.
+*/
+   switch (revision) {
+   case 0x11:  /* sLD3 */
+   data->way_ctrl_base = data->ctrl_base + 0x870;
+   break;
+   case 0x12:  /* LD4 */
+   case 0x16:  /* sld8 */
+   data->way_ctrl_base = data->ctrl_base + 0x840;
+   break;
+   default:
+   break;
+   }
}
 
data->range_op_max_size -= data->line_size;
-- 
1.9.1

Re: [PATCH 2/3] kernel.h: add u64_to_user_ptr()

[Joe Perches]

On Wed, 2016-04-20 at 16:18 -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This function had copies in 3 different files. Unify them in kernel.h.
[]
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
[]
> @@ -53,6 +53,12 @@
> 
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>  
> +static inline void __user *u64_to_user_ptr(u64 address)
> +{
> + typecheck(u64, address);
> + return (void __user *)(uintptr_t)address;
> +}
> +

This won't work because by the time address is checked
address is already u64

This would need to be something like

#define u64_to_user_ptr(x)  \
({  \
typecheck(u64, x);  \
u64_to_user_ptr(x); \
})

Re: [PATCH 2/3] kernel.h: add u64_to_user_ptr()

[Joe Perches]

On Wed, 2016-04-20 at 16:18 -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This function had copies in 3 different files. Unify them in kernel.h.
[]
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
[]
> @@ -53,6 +53,12 @@
> 
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>  
> +static inline void __user *u64_to_user_ptr(u64 address)
> +{
> + typecheck(u64, address);
> + return (void __user *)(uintptr_t)address;
> +}
> +

This won't work because by the time address is checked
address is already u64

This would need to be something like

#define u64_to_user_ptr(x)  \
({  \
typecheck(u64, x);  \
u64_to_user_ptr(x); \
})

Re: [PATCH V2] audit: add tty field to LOGIN event

[Paul Moore]

On Wed, Apr 20, 2016 at 7:31 PM, Richard Guy Briggs  wrote:
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index b40ed5d..b00beef 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #define AUDIT_INO_UNSET ((unsigned long)-1)
>  #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -343,6 +344,18 @@ static inline unsigned int audit_get_sessionid(struct 
> task_struct *tsk)
> return tsk->sessionid;
>  }
>
> +static inline struct tty_struct *audit_get_tty(struct task_struct *tsk)
> +{
> +   struct tty_struct *tty = NULL;
> +   unsigned long flags;
> +
> +   spin_lock_irqsave(>sighand->siglock, flags);
> +   if (tsk->signal)
> +   tty = tty_kref_get(tsk->signal->tty);
> +   spin_unlock_irqrestore(>sighand->siglock, flags);
> +   return tty;
> +}

I'll look at this patch closer tomorrow, but one thing jumped out at
me just now: we should probably have a audit_put_tty(...) to match the
audit_get_tty(...).  It seems more obvious than trying to match
audit_get_tty() and tty_kref_put() in a function.

-- 
paul moore
www.paul-moore.com

Re: [PATCH V2] audit: add tty field to LOGIN event

[Paul Moore]

On Wed, Apr 20, 2016 at 7:31 PM, Richard Guy Briggs  wrote:
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index b40ed5d..b00beef 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #define AUDIT_INO_UNSET ((unsigned long)-1)
>  #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -343,6 +344,18 @@ static inline unsigned int audit_get_sessionid(struct 
> task_struct *tsk)
> return tsk->sessionid;
>  }
>
> +static inline struct tty_struct *audit_get_tty(struct task_struct *tsk)
> +{
> +   struct tty_struct *tty = NULL;
> +   unsigned long flags;
> +
> +   spin_lock_irqsave(>sighand->siglock, flags);
> +   if (tsk->signal)
> +   tty = tty_kref_get(tsk->signal->tty);
> +   spin_unlock_irqrestore(>sighand->siglock, flags);
> +   return tty;
> +}

I'll look at this patch closer tomorrow, but one thing jumped out at
me just now: we should probably have a audit_put_tty(...) to match the
audit_get_tty(...).  It seems more obvious than trying to match
audit_get_tty() and tty_kref_put() in a function.

-- 
paul moore
www.paul-moore.com

Re: [alsa-devel] [RFC PATCH v2 2/5] ASoC: mediatek: add documents for mt2701

[Garlic Tseng]

On Wed, 2016-04-20 at 12:36 +0200, Matthias Brugger wrote:
> 
> On 14/04/16 14:14, Garlic Tseng wrote:
> [...]
> 
> > diff --git a/Documentation/devicetree/bindings/sound/mtk2701-afe-pcm.txt 
> > b/Documentation/devicetree/bindings/sound/mtk2701-afe-pcm.txt
> > new file mode 100644
> 
> Nit:
> I would prefer to name it mt2701-afe-pcm.txt as all the other SoC 
> specific files.

OK, I'll change it in the next version.
Thanks for you comment.

> 
> Regards,
> Matthias

Re: [alsa-devel] [RFC PATCH v2 2/5] ASoC: mediatek: add documents for mt2701

[Garlic Tseng]

On Wed, 2016-04-20 at 12:36 +0200, Matthias Brugger wrote:
> 
> On 14/04/16 14:14, Garlic Tseng wrote:
> [...]
> 
> > diff --git a/Documentation/devicetree/bindings/sound/mtk2701-afe-pcm.txt 
> > b/Documentation/devicetree/bindings/sound/mtk2701-afe-pcm.txt
> > new file mode 100644
> 
> Nit:
> I would prefer to name it mt2701-afe-pcm.txt as all the other SoC 
> specific files.

OK, I'll change it in the next version.
Thanks for you comment.

> 
> Regards,
> Matthias