Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

[Huang Rui]

On Thu, Jun 16, 2016 at 01:38:13PM +0800, Huang Rui wrote:
> On Wed, Jun 15, 2016 at 09:13:59PM -0400, Vince Weaver wrote:
> > 
> > 2.  Unless I'm misunderstanding things, the code seems to be accumulating 
> > Power. (see chunk below) Power is an instantaneous measurement, it 
> > makes no sense to add values.  If you use 5W for 1ms and 10W for
> > 1ms, the average power across the 2ms interval is not 15W.
> > 
> > You can add energy, but not power.
> > 
> > > + delta *= cpu_pwr_sample_ratio * 1000;
> > > + tdelta = new_ptsc - prev_ptsc;
> > > +
> > > + do_div(delta, tdelta);
> > > + local64_add(delta, >count);
> > 
> 
> You're right. Nice catch! The average power is per compute unit. We
> cannot add the power simplely for each processor/package.
> 
> So here, the average power per package should be (delta1 + delta2 + ... + 
> deltaN)/(tdelta_avg).
> I will work out a fix. Thanks to point out.
> 

After considering carefully, the original method should be OK. 

  AMD nomenclature for CMT systems:

[node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
 -> [Compute Unit Core 1] -> Linux CPU 1
 -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
 -> [Compute Unit Core 1] -> Linux CPU 3

The deltaN is power per compute unit. Current one package has two CUs.
In the *same* interval, CU0's power is 10W, CU1's power is 15W. The
package (CU0 + CU1) power should be 15W, right? Because the interval
is the same.

Q = Q1 + Q2.  P = Q/t = (Q1 + Q2)/t = Q1/t + Q2/t = P1 + P2.

Is that clear?

Thanks,
Rui

Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

[Huang Rui]

On Thu, Jun 16, 2016 at 01:38:13PM +0800, Huang Rui wrote:
> On Wed, Jun 15, 2016 at 09:13:59PM -0400, Vince Weaver wrote:
> > 
> > 2.  Unless I'm misunderstanding things, the code seems to be accumulating 
> > Power. (see chunk below) Power is an instantaneous measurement, it 
> > makes no sense to add values.  If you use 5W for 1ms and 10W for
> > 1ms, the average power across the 2ms interval is not 15W.
> > 
> > You can add energy, but not power.
> > 
> > > + delta *= cpu_pwr_sample_ratio * 1000;
> > > + tdelta = new_ptsc - prev_ptsc;
> > > +
> > > + do_div(delta, tdelta);
> > > + local64_add(delta, >count);
> > 
> 
> You're right. Nice catch! The average power is per compute unit. We
> cannot add the power simplely for each processor/package.
> 
> So here, the average power per package should be (delta1 + delta2 + ... + 
> deltaN)/(tdelta_avg).
> I will work out a fix. Thanks to point out.
> 

After considering carefully, the original method should be OK. 

  AMD nomenclature for CMT systems:

[node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
 -> [Compute Unit Core 1] -> Linux CPU 1
 -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
 -> [Compute Unit Core 1] -> Linux CPU 3

The deltaN is power per compute unit. Current one package has two CUs.
In the *same* interval, CU0's power is 10W, CU1's power is 15W. The
package (CU0 + CU1) power should be 15W, right? Because the interval
is the same.

Q = Q1 + Q2.  P = Q/t = (Q1 + Q2)/t = Q1/t + Q2/t = P1 + P2.

Is that clear?

Thanks,
Rui

linux-next: Tree for Jun 16

[Stephen Rothwell]

Hi all,

Changes since 20160615:

New tree: mali-dp

The vhost tree gained a conflict against the net-next tree.

The akpm-current tree regained a build failure for which I applied the
previous fix patch.

Non-merge commits (relative to Linus' tree): 3589
 3588 files changed, 165565 insertions(+), 56640 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (db06d759d6cf Merge branch 'for-4.7-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu)
Merging fixes/master (5edb56491d48 Linux 4.7-rc3)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (5edb56491d48 Linux 4.7-rc3)
Merging arm-current/fixes (56530f5d2ddc ARM: 8579/1: mm: Fix definition of 
pmd_mknotpresent)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (8550e2fa34f0 powerpc/mm/hash: Use the correct PPP 
mask when updating HPTE)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (e4587ea1d748 Merge branch 'macsec-fixes')
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (50219538ffc0 vmxnet3: segCnt can be 1 for LRO packets)
Merging wireless-drivers/master (bba42c7877d3 Merge tag 
'iwlwifi-for-kalle-2016-06-10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (3d5fdff46c4b wext: Fix 32 bit iwpriv compatibility 
issue with 64 bit Kernel)
Merging sound-current/for-linus (35639a0e9839 ALSA: hda - Add PCI ID for 
Kabylake)
Merging pci-current/for-linus (96381c04ef9b PCI: hv: Handle all pending 
messages in hv_pci_onchannelcallback())
Merging driver-core.current/driver-core-linus (75f0b68b75da debugfs: 
open_proxy_open(): avoid double fops release)
Merging tty.current/tty-linus (5edb56491d48 Linux 4.7-rc3)
Merging usb.current/usb-linus (1c4bf5ac6a16 usb: musb: sunxi: Remove bogus 
"Frees glue" comment)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (af8c34ce6ae3 Linux 4.7-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (a9cc4006155a staging: lustre: lnet: 
Don't access NULL NI on failure path)
Merging char-misc.current/char-misc-linus (4d2ec8575357 mcb: Acquire reference 
to carrier module in core)
Merging input-current/for-linus (540c26087bfb Input: xpad - fix rumble on Xbox 
One controllers with 2015 firmware)
Merging crypto-current/master (19ced623db2f crypto: ux500 - memmove the right 
size)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read)
Merging kselftest-fixes/fixes (f80eb4289491 selftests/exec: Makefile is a 
run-time dependency, add it to the install

linux-next: Tree for Jun 16

[Stephen Rothwell]

Hi all,

Changes since 20160615:

New tree: mali-dp

The vhost tree gained a conflict against the net-next tree.

The akpm-current tree regained a build failure for which I applied the
previous fix patch.

Non-merge commits (relative to Linus' tree): 3589
 3588 files changed, 165565 insertions(+), 56640 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (db06d759d6cf Merge branch 'for-4.7-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu)
Merging fixes/master (5edb56491d48 Linux 4.7-rc3)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (5edb56491d48 Linux 4.7-rc3)
Merging arm-current/fixes (56530f5d2ddc ARM: 8579/1: mm: Fix definition of 
pmd_mknotpresent)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (8550e2fa34f0 powerpc/mm/hash: Use the correct PPP 
mask when updating HPTE)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (e4587ea1d748 Merge branch 'macsec-fixes')
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (50219538ffc0 vmxnet3: segCnt can be 1 for LRO packets)
Merging wireless-drivers/master (bba42c7877d3 Merge tag 
'iwlwifi-for-kalle-2016-06-10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (3d5fdff46c4b wext: Fix 32 bit iwpriv compatibility 
issue with 64 bit Kernel)
Merging sound-current/for-linus (35639a0e9839 ALSA: hda - Add PCI ID for 
Kabylake)
Merging pci-current/for-linus (96381c04ef9b PCI: hv: Handle all pending 
messages in hv_pci_onchannelcallback())
Merging driver-core.current/driver-core-linus (75f0b68b75da debugfs: 
open_proxy_open(): avoid double fops release)
Merging tty.current/tty-linus (5edb56491d48 Linux 4.7-rc3)
Merging usb.current/usb-linus (1c4bf5ac6a16 usb: musb: sunxi: Remove bogus 
"Frees glue" comment)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (af8c34ce6ae3 Linux 4.7-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (a9cc4006155a staging: lustre: lnet: 
Don't access NULL NI on failure path)
Merging char-misc.current/char-misc-linus (4d2ec8575357 mcb: Acquire reference 
to carrier module in core)
Merging input-current/for-linus (540c26087bfb Input: xpad - fix rumble on Xbox 
One controllers with 2015 firmware)
Merging crypto-current/master (19ced623db2f crypto: ux500 - memmove the right 
size)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read)
Merging kselftest-fixes/fixes (f80eb4289491 selftests/exec: Makefile is a 
run-time dependency, add it to the install

Re: [PATCH v2 0/9] kexec_file_load implementation for PowerPC

[Michael Ellerman]

On Tue, 2016-06-14 at 11:59 -0300, Thiago Jung Bauermann wrote:

> Hello,
> 
> This patch series implements the kexec_file_load system call on PowerPC.

Can you tell me what this syscall does and why I would want it?

cheers

Re: [PATCH v2 0/9] kexec_file_load implementation for PowerPC

[Michael Ellerman]

On Tue, 2016-06-14 at 11:59 -0300, Thiago Jung Bauermann wrote:

> Hello,
> 
> This patch series implements the kexec_file_load system call on PowerPC.

Can you tell me what this syscall does and why I would want it?

cheers

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from include/linux/mm.h:400:0,
 from mm/huge_memory.c:10:
include/linux/huge_mm.h:53:22: error: initializer element is not constant
 #define HPAGE_PMD_NR (1<
Date: Mon, 2 May 2016 18:25:42 +1000
Subject: [PATCH] mm: make optimistic check for swapin readahead fix

Signed-off-by: Stephen Rothwell 
---
 mm/huge_memory.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f0cd9dbc1157..6aabfa166b6d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -101,7 +101,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
  * fault.
  */
 static unsigned int khugepaged_max_ptes_none __read_mostly;
-static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
+static unsigned int khugepaged_max_ptes_swap __read_mostly;
 static unsigned long allocstall;
 
 static int khugepaged(void *none);
@@ -703,6 +703,7 @@ static int __init hugepage_init(void)
 
khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
+   khugepaged_max_ptes_swap = HPAGE_PMD_NR / 8;
/*
 * hugepages can't be allocated by the buddy allocator
 */
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from include/linux/mm.h:400:0,
 from mm/huge_memory.c:10:
include/linux/huge_mm.h:53:22: error: initializer element is not constant
 #define HPAGE_PMD_NR (1<
Date: Mon, 2 May 2016 18:25:42 +1000
Subject: [PATCH] mm: make optimistic check for swapin readahead fix

Signed-off-by: Stephen Rothwell 
---
 mm/huge_memory.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f0cd9dbc1157..6aabfa166b6d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -101,7 +101,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
  * fault.
  */
 static unsigned int khugepaged_max_ptes_none __read_mostly;
-static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
+static unsigned int khugepaged_max_ptes_swap __read_mostly;
 static unsigned long allocstall;
 
 static int khugepaged(void *none);
@@ -703,6 +703,7 @@ static int __init hugepage_init(void)
 
khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
+   khugepaged_max_ptes_swap = HPAGE_PMD_NR / 8;
/*
 * hugepages can't be allocated by the buddy allocator
 */
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 3/3] ARM: dts: imx7: add Toradex Colibri iMX7S/iMX7D support

[Stefan Agner]

On 2016-06-11 19:31, Shawn Guo wrote:
> On Tue, Jun 07, 2016 at 07:37:09PM -0700, Stefan Agner wrote:
>> + {
>> +status = "okay";
>> +display = <>;
> 
> Please put 'status' at the bottom of property list.
> 
>> +
>> +display0: lcd-display {
>> +bits-per-pixel = <16>;
>> +bus-width = <18>;
>> +
>> +display-timings {
>> +native-mode = <_vga>;
>> +
>> +/* Standard VGA timing */
>> +timing_vga: 640x480 {
>> +clock-frequency = <25175000>;
>> +hactive = <640>;
>> +vactive = <480>;
>> +hback-porch = <40>;
>> +hfront-porch = <24>;
>> +vback-porch = <32>;
>> +vfront-porch = <11>;
>> +hsync-len = <96>;
>> +vsync-len = <2>;
>> +de-active = <1>;
>> +hsync-active = <0>;
>> +vsync-active = <0>;
>> +pixelclk-active = <0>;
>> +};
>> +};
>> +};
>> +};
> 
> 
> 
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_usdhc1 _cd_usdhc1>;
>> +no-1-8-v;
>> +cd-gpios = < 0 0>;
> 
> Use the macro in include/dt-bindings/gpio/gpio.h.
> 
>> +enable-sdio-wakeup;
> 
> This is deprecated.  Please use wakeup-source instead.
> 
>> +fsl,tuning-step = <2>;
>> +keep-power-in-suspend;
>> +status = "okay";
>> +};
> 
> 
> 
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_enet1>;
>> +clocks = < IMX7D_ENET_AXI_ROOT_CLK>,
>> +< IMX7D_ENET_AXI_ROOT_CLK>,
>> +< IMX7D_ENET1_TIME_ROOT_CLK>,
>> +< IMX7D_PLL_ENET_MAIN_50M_CLK>;
>> +clock-names = "ipg", "ahb", "ptp", "enet_clk_ref";
>> +
> 
> Drop this newline.
> 
>> +assigned-clocks = < IMX7D_ENET1_TIME_ROOT_SRC>,
>> +  < IMX7D_ENET1_TIME_ROOT_CLK>;
>> +assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
>> +assigned-clock-rates = <0>, <1>;
>> +phy-mode = "rmii";
>> +phy-supply = <_LDO1>;
>> +fsl,magic-packet;
>> +};
> 
> 
> 
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_uart1 _uart1_ctrl1 _uart1_ctrl2>;
>> +assigned-clocks = < IMX7D_UART1_ROOT_SRC>;
>> +assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
>> +fsl,uart-has-rtscts;
> 
> Please use generic 'uart-has-rtscts' instead.
> 
>> +fsl,dte-mode;
>> +};
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_uart2>;
>> +assigned-clocks = < IMX7D_UART2_ROOT_SRC>;
>> +assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
>> +fsl,uart-has-rtscts;
> 
> Ditto
> 
>> +fsl,dte-mode;
>> +};

Agreed on all the stuff above.

> 
> 
> 
>> +/ {
>> +model = "Toradex Colibri iMX7D on Colibri Evaluation Board V3";
>> +compatible = "toradex,colibri_imx7d-eval", "toradex,colibri_imx7d", \
> 
> We always use hyphen than underscore in compatible string.

We always used underscores, this goes back to the first Colibri specific
device tree: tegra20-iris-512.dts.

I would rather prefer to not change this for the sake of consistency...
What do you think?

> 
>> + "fsl,imx7d";
>> +
>> +reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
>> +compatible = "regulator-fixed";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_usbotg2_reg>;
>> +regulator-name = "VCC_USB[1-4]";
>> +regulator-min-microvolt = <500>;
>> +regulator-max-microvolt = <500>;
>> +gpio = < 7 GPIO_ACTIVE_LOW>;
>> +};
>> +};
>> +/ {
>> +model = "Toradex Colibri iMX7S on Colibri Evaluation Board V3";
>> +compatible = "toradex,colibri_imx7s-eval", "toradex,colibri_imx7s", \
>> + "fsl,imx7s", "fsl,imx7d";
> 
> You may not want to have "fsl,imx7d" here.  Otherwise, the detection
> between  imx7s and imx7d colibri-eval-v3 board will be difficult.

Yeah my idea behind this is that "imx7d" is still kind of the base name
of that SoC. But I agree for the bindings it does not make that much
sense.

I have to add imx7s to arch/arm/mach-imx/mach-imx7d.c though.

--
Stefan

Re: [PATCH 3/3] ARM: dts: imx7: add Toradex Colibri iMX7S/iMX7D support

[Stefan Agner]

On 2016-06-11 19:31, Shawn Guo wrote:
> On Tue, Jun 07, 2016 at 07:37:09PM -0700, Stefan Agner wrote:
>> + {
>> +status = "okay";
>> +display = <>;
> 
> Please put 'status' at the bottom of property list.
> 
>> +
>> +display0: lcd-display {
>> +bits-per-pixel = <16>;
>> +bus-width = <18>;
>> +
>> +display-timings {
>> +native-mode = <_vga>;
>> +
>> +/* Standard VGA timing */
>> +timing_vga: 640x480 {
>> +clock-frequency = <25175000>;
>> +hactive = <640>;
>> +vactive = <480>;
>> +hback-porch = <40>;
>> +hfront-porch = <24>;
>> +vback-porch = <32>;
>> +vfront-porch = <11>;
>> +hsync-len = <96>;
>> +vsync-len = <2>;
>> +de-active = <1>;
>> +hsync-active = <0>;
>> +vsync-active = <0>;
>> +pixelclk-active = <0>;
>> +};
>> +};
>> +};
>> +};
> 
> 
> 
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_usdhc1 _cd_usdhc1>;
>> +no-1-8-v;
>> +cd-gpios = < 0 0>;
> 
> Use the macro in include/dt-bindings/gpio/gpio.h.
> 
>> +enable-sdio-wakeup;
> 
> This is deprecated.  Please use wakeup-source instead.
> 
>> +fsl,tuning-step = <2>;
>> +keep-power-in-suspend;
>> +status = "okay";
>> +};
> 
> 
> 
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_enet1>;
>> +clocks = < IMX7D_ENET_AXI_ROOT_CLK>,
>> +< IMX7D_ENET_AXI_ROOT_CLK>,
>> +< IMX7D_ENET1_TIME_ROOT_CLK>,
>> +< IMX7D_PLL_ENET_MAIN_50M_CLK>;
>> +clock-names = "ipg", "ahb", "ptp", "enet_clk_ref";
>> +
> 
> Drop this newline.
> 
>> +assigned-clocks = < IMX7D_ENET1_TIME_ROOT_SRC>,
>> +  < IMX7D_ENET1_TIME_ROOT_CLK>;
>> +assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
>> +assigned-clock-rates = <0>, <1>;
>> +phy-mode = "rmii";
>> +phy-supply = <_LDO1>;
>> +fsl,magic-packet;
>> +};
> 
> 
> 
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_uart1 _uart1_ctrl1 _uart1_ctrl2>;
>> +assigned-clocks = < IMX7D_UART1_ROOT_SRC>;
>> +assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
>> +fsl,uart-has-rtscts;
> 
> Please use generic 'uart-has-rtscts' instead.
> 
>> +fsl,dte-mode;
>> +};
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_uart2>;
>> +assigned-clocks = < IMX7D_UART2_ROOT_SRC>;
>> +assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
>> +fsl,uart-has-rtscts;
> 
> Ditto
> 
>> +fsl,dte-mode;
>> +};

Agreed on all the stuff above.

> 
> 
> 
>> +/ {
>> +model = "Toradex Colibri iMX7D on Colibri Evaluation Board V3";
>> +compatible = "toradex,colibri_imx7d-eval", "toradex,colibri_imx7d", \
> 
> We always use hyphen than underscore in compatible string.

We always used underscores, this goes back to the first Colibri specific
device tree: tegra20-iris-512.dts.

I would rather prefer to not change this for the sake of consistency...
What do you think?

> 
>> + "fsl,imx7d";
>> +
>> +reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
>> +compatible = "regulator-fixed";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_usbotg2_reg>;
>> +regulator-name = "VCC_USB[1-4]";
>> +regulator-min-microvolt = <500>;
>> +regulator-max-microvolt = <500>;
>> +gpio = < 7 GPIO_ACTIVE_LOW>;
>> +};
>> +};
>> +/ {
>> +model = "Toradex Colibri iMX7S on Colibri Evaluation Board V3";
>> +compatible = "toradex,colibri_imx7s-eval", "toradex,colibri_imx7s", \
>> + "fsl,imx7s", "fsl,imx7d";
> 
> You may not want to have "fsl,imx7d" here.  Otherwise, the detection
> between  imx7s and imx7d colibri-eval-v3 board will be difficult.

Yeah my idea behind this is that "imx7d" is still kind of the base name
of that SoC. But I agree for the bindings it does not make that much
sense.

I have to add imx7s to arch/arm/mach-imx/mach-imx7d.c though.

--
Stefan

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote:
> On 06/16/2016 05:56 AM, Minchan Kim wrote:
> > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
> >> On 06/15/2016 08:02 AM, Minchan Kim wrote:
> >>> Hi,
> >>>
> >>> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
> > On 05/31/2016 05:31 AM, Minchan Kim wrote:
> >>> @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, 
> >>> struct page *newpage,
> >>>   int rc = -EAGAIN;
> >>>   int page_was_mapped = 0;
> >>>   struct anon_vma *anon_vma = NULL;
> >>> + bool is_lru = !__PageMovable(page);
> >>>  
> >>>   if (!trylock_page(page)) {
> >>>   if (!force || mode == MIGRATE_ASYNC)
> >>> @@ -871,6 +1002,11 @@ static int __unmap_and_move(struct page *page, 
> >>> struct page *newpage,
> >>>   goto out_unlock_both;
> >>>   }
> >>>  
> >>> + if (unlikely(!is_lru)) {
> >>> + rc = move_to_new_page(newpage, page, mode);
> >>> + goto out_unlock_both;
> >>> + }
> >>> +
> >
> > Hello Minchan,
> >
> > I might be missing something here but does this implementation support 
> > the
> > scenario where these non LRU pages owned by the driver mapped as PTE 
> > into
> > process page table ? Because the "goto out_unlock_both" statement above
> > skips all the PTE unmap, putting a migration PTE and removing the 
> > migration
> > PTE steps.
> >>> You're right. Unfortunately, it doesn't support right now but surely,
> >>> it's my TODO after landing this work.
> >>>
> >>> Could you share your usecase?
> >>
> >> Sure.
> > 
> > Thanks a lot!
> > 
> >>
> >> My driver has privately managed non LRU pages which gets mapped into user 
> >> space
> >> process page table through f_ops->mmap() and vmops->fault() which then 
> >> updates
> >> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). 
> >> One thing
> > 
> > Hmm, page_add_file_rmap is not exported function. How does your driver can 
> > use it?
> 
> Its not using the function directly, I just re-iterated the sequence of 
> functions
> above. (do_set_pte -> page_add_file_rmap) gets called after we grab the page 
> from
> driver through (__do_fault->vma->vm_ops->fault()).
> 
> > Do you use vm_insert_pfn?
> > What type your vma is? VM_PFNMMAP or VM_MIXEDMAP?
> 
> I dont use vm_insert_pfn(). Here is the sequence of events how the user space
> VMA gets the non LRU pages from the driver.
> 
> - Driver registers a character device with 'struct file_operations' binding
> - Then the 'fops->mmap()' just binds the incoming 'struct vma' with a 'struct
>   vm_operations_struct' which provides the 'vmops->fault()' routine which
>   basically traps all page faults on the VMA and provides one page at a time
>   through a driver specific allocation routine which hands over non LRU pages
> 
> The VMA is not anything special as such. Its what we get when we try to do a
> simple mmap() on a file descriptor pointing to a character device. I can
> figure out all the VM_* flags it holds after creation.
> 
> > 
> > I want to make dummy driver to simulate your case.
> 
> Sure. I hope the above mentioned steps will help you but in case you need more
> information, please do let me know.

I got understood now. :)
I will test it with dummy driver and will Cc'ed when I send a patch.

Thanks.

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote:
> On 06/16/2016 05:56 AM, Minchan Kim wrote:
> > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
> >> On 06/15/2016 08:02 AM, Minchan Kim wrote:
> >>> Hi,
> >>>
> >>> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
> > On 05/31/2016 05:31 AM, Minchan Kim wrote:
> >>> @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, 
> >>> struct page *newpage,
> >>>   int rc = -EAGAIN;
> >>>   int page_was_mapped = 0;
> >>>   struct anon_vma *anon_vma = NULL;
> >>> + bool is_lru = !__PageMovable(page);
> >>>  
> >>>   if (!trylock_page(page)) {
> >>>   if (!force || mode == MIGRATE_ASYNC)
> >>> @@ -871,6 +1002,11 @@ static int __unmap_and_move(struct page *page, 
> >>> struct page *newpage,
> >>>   goto out_unlock_both;
> >>>   }
> >>>  
> >>> + if (unlikely(!is_lru)) {
> >>> + rc = move_to_new_page(newpage, page, mode);
> >>> + goto out_unlock_both;
> >>> + }
> >>> +
> >
> > Hello Minchan,
> >
> > I might be missing something here but does this implementation support 
> > the
> > scenario where these non LRU pages owned by the driver mapped as PTE 
> > into
> > process page table ? Because the "goto out_unlock_both" statement above
> > skips all the PTE unmap, putting a migration PTE and removing the 
> > migration
> > PTE steps.
> >>> You're right. Unfortunately, it doesn't support right now but surely,
> >>> it's my TODO after landing this work.
> >>>
> >>> Could you share your usecase?
> >>
> >> Sure.
> > 
> > Thanks a lot!
> > 
> >>
> >> My driver has privately managed non LRU pages which gets mapped into user 
> >> space
> >> process page table through f_ops->mmap() and vmops->fault() which then 
> >> updates
> >> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). 
> >> One thing
> > 
> > Hmm, page_add_file_rmap is not exported function. How does your driver can 
> > use it?
> 
> Its not using the function directly, I just re-iterated the sequence of 
> functions
> above. (do_set_pte -> page_add_file_rmap) gets called after we grab the page 
> from
> driver through (__do_fault->vma->vm_ops->fault()).
> 
> > Do you use vm_insert_pfn?
> > What type your vma is? VM_PFNMMAP or VM_MIXEDMAP?
> 
> I dont use vm_insert_pfn(). Here is the sequence of events how the user space
> VMA gets the non LRU pages from the driver.
> 
> - Driver registers a character device with 'struct file_operations' binding
> - Then the 'fops->mmap()' just binds the incoming 'struct vma' with a 'struct
>   vm_operations_struct' which provides the 'vmops->fault()' routine which
>   basically traps all page faults on the VMA and provides one page at a time
>   through a driver specific allocation routine which hands over non LRU pages
> 
> The VMA is not anything special as such. Its what we get when we try to do a
> simple mmap() on a file descriptor pointing to a character device. I can
> figure out all the VM_* flags it holds after creation.
> 
> > 
> > I want to make dummy driver to simulate your case.
> 
> Sure. I hope the above mentioned steps will help you but in case you need more
> information, please do let me know.

I got understood now. :)
I will test it with dummy driver and will Cc'ed when I send a patch.

Thanks.

[PATCH RFC] Revert "cpufreq: dt: Identify cpu-sharing for platforms without operating-points-v2"

[Alexandre Courbot]

This is not an actual request for revert, but rather for comments about
the observed behavior since I am not really familiar with cpufreq.

I am observing a serious performance regression on Jetson TK1 since 4.7-rc1:
namely, moving windows under X would become unsufferably slow, and graphical
performance under X in general is seriously degraded. After bisecting, I
found the regression to be visible since commit 1530b9963eeb ("cpufreq: dt: 
Identify cpu-sharing for platforms without operating-points-v2")

If I revert this commit, I noticed that the CPU frequency immediately jumps to
a higher frequency once I start moving windows (resulting in a smooth and
responsive action), whereas enabling this commit causes the CPU frequency to
remain low (typically 204 Mhz) in that case, resulting in CPU-bound slowness.

What happens is that with 1530b9963eeb applied, dev_pm_opp_get_sharing_cpus()
returns zero causing the fallback variable to remain false, whereas without it
opp_v1 is set to true.

It is not clear to me whether this is a cpufreq issue or a Tegra issue, so I am
posting this in the hope to get clarifications from either side.

Thanks!

---
 drivers/cpufreq/cpufreq-dt.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 3957de801ae8..eef245cd4b7f 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -146,7 +146,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
struct clk *cpu_clk;
struct dev_pm_opp *suspend_opp;
unsigned int transition_latency;
-   bool fallback = false;
+   bool opp_v1 = false;
const char *name;
int ret;
 
@@ -166,16 +166,14 @@ static int cpufreq_init(struct cpufreq_policy *policy)
/* Get OPP-sharing information from "operating-points-v2" bindings */
ret = dev_pm_opp_of_get_sharing_cpus(cpu_dev, policy->cpus);
if (ret) {
-   if (ret != -ENOENT)
-   goto out_put_clk;
-
/*
 * operating-points-v2 not supported, fallback to old method of
-* finding shared-OPPs for backward compatibility if the
-* platform hasn't set sharing CPUs.
+* finding shared-OPPs for backward compatibility.
 */
-   if (dev_pm_opp_get_sharing_cpus(cpu_dev, policy->cpus))
-   fallback = true;
+   if (ret == -ENOENT)
+   opp_v1 = true;
+   else
+   goto out_put_clk;
}
 
/*
@@ -215,7 +213,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
goto out_free_opp;
}
 
-   if (fallback) {
+   if (opp_v1) {
cpumask_setall(policy->cpus);
 
/*
-- 
2.8.3

[PATCH RFC] Revert "cpufreq: dt: Identify cpu-sharing for platforms without operating-points-v2"

[Alexandre Courbot]

This is not an actual request for revert, but rather for comments about
the observed behavior since I am not really familiar with cpufreq.

I am observing a serious performance regression on Jetson TK1 since 4.7-rc1:
namely, moving windows under X would become unsufferably slow, and graphical
performance under X in general is seriously degraded. After bisecting, I
found the regression to be visible since commit 1530b9963eeb ("cpufreq: dt: 
Identify cpu-sharing for platforms without operating-points-v2")

If I revert this commit, I noticed that the CPU frequency immediately jumps to
a higher frequency once I start moving windows (resulting in a smooth and
responsive action), whereas enabling this commit causes the CPU frequency to
remain low (typically 204 Mhz) in that case, resulting in CPU-bound slowness.

What happens is that with 1530b9963eeb applied, dev_pm_opp_get_sharing_cpus()
returns zero causing the fallback variable to remain false, whereas without it
opp_v1 is set to true.

It is not clear to me whether this is a cpufreq issue or a Tegra issue, so I am
posting this in the hope to get clarifications from either side.

Thanks!

---
 drivers/cpufreq/cpufreq-dt.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 3957de801ae8..eef245cd4b7f 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -146,7 +146,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
struct clk *cpu_clk;
struct dev_pm_opp *suspend_opp;
unsigned int transition_latency;
-   bool fallback = false;
+   bool opp_v1 = false;
const char *name;
int ret;
 
@@ -166,16 +166,14 @@ static int cpufreq_init(struct cpufreq_policy *policy)
/* Get OPP-sharing information from "operating-points-v2" bindings */
ret = dev_pm_opp_of_get_sharing_cpus(cpu_dev, policy->cpus);
if (ret) {
-   if (ret != -ENOENT)
-   goto out_put_clk;
-
/*
 * operating-points-v2 not supported, fallback to old method of
-* finding shared-OPPs for backward compatibility if the
-* platform hasn't set sharing CPUs.
+* finding shared-OPPs for backward compatibility.
 */
-   if (dev_pm_opp_get_sharing_cpus(cpu_dev, policy->cpus))
-   fallback = true;
+   if (ret == -ENOENT)
+   opp_v1 = true;
+   else
+   goto out_put_clk;
}
 
/*
@@ -215,7 +213,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
goto out_free_opp;
}
 
-   if (fallback) {
+   if (opp_v1) {
cpumask_setall(policy->cpus);
 
/*
-- 
2.8.3

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

[Andy Lutomirski]

On Jun 15, 2016 9:32 PM, "Mika Penttilä"  wrote:
>
> Hi,
>

> > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> > index 5643fd0b1a7d..fbf036ae72ac 100644
> > --- a/arch/x86/mm/tlb.c
> > +++ b/arch/x86/mm/tlb.c
> > @@ -77,10 +77,25 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
> > mm_struct *next,
> >   unsigned cpu = smp_processor_id();
> >
> >   if (likely(prev != next)) {
> > + if (IS_ENABLED(CONFIG_VMAP_STACK)) {
> > + /*
> > +  * If our current stack is in vmalloc space and isn't
> > +  * mapped in the new pgd, we'll double-fault.  
> > Forcibly
> > +  * map it.
> > +  */
> > + unsigned int stack_pgd_index =
> > + pgd_index(current_stack_pointer());
>
>
> stack pointer is still the previous task's, current_stack_pointer() returns 
> that, not
> next task's which was intention I guess. Things may happen to work if on same 
> pgd, but at least the
> boot cpu init_task_struct is special.

This is intentional.  When switching processes, we first switch the mm
and then switch the task.  We need to make sure that the prev stack is
mapped in the new mm or we'll double-fault and die after switching the
mm which still trying to execute on the old stack.

The change to switch_to makes sure that the new stack is mapped.

--Andy

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

[Andy Lutomirski]

On Jun 15, 2016 9:32 PM, "Mika Penttilä"  wrote:
>
> Hi,
>

> > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> > index 5643fd0b1a7d..fbf036ae72ac 100644
> > --- a/arch/x86/mm/tlb.c
> > +++ b/arch/x86/mm/tlb.c
> > @@ -77,10 +77,25 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
> > mm_struct *next,
> >   unsigned cpu = smp_processor_id();
> >
> >   if (likely(prev != next)) {
> > + if (IS_ENABLED(CONFIG_VMAP_STACK)) {
> > + /*
> > +  * If our current stack is in vmalloc space and isn't
> > +  * mapped in the new pgd, we'll double-fault.  
> > Forcibly
> > +  * map it.
> > +  */
> > + unsigned int stack_pgd_index =
> > + pgd_index(current_stack_pointer());
>
>
> stack pointer is still the previous task's, current_stack_pointer() returns 
> that, not
> next task's which was intention I guess. Things may happen to work if on same 
> pgd, but at least the
> boot cpu init_task_struct is special.

This is intentional.  When switching processes, we first switch the mm
and then switch the task.  We need to make sure that the prev stack is
mapped in the new mm or we'll double-fault and die after switching the
mm which still trying to execute on the old stack.

The change to switch_to makes sure that the new stack is mapped.

--Andy

Re: [PATCH net-next 0/8] rxrpc: Rework endpoint record handling

[David Miller]

From: David Howells <dhowe...@redhat.com>
Date: Wed, 15 Jun 2016 17:41:38 +0100

> Here's the next part of the AF_RXRPC rewrite.  In this set I rework
> endpoint record handling.  There are two types of endpoint record, local
> and peer.  The local endpoint record is used as an anchor for the transport
> socket that AF_RXRPC uses (at the moment a UDP socket).  Local endpoints
> can be shared between AF_RXRPC sockets under certain restricted
> circumstances.
> 
> The peer endpoint is a record of the remote end.  It is (or will be) used
> to keep track MTU and RTT values and, with these changes, is used to find
> the call(s) to abort when a network error occurs.
> 
> The following significant changes are made:
 ...
> The patches can be found here also:
> 
>   
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite
> 
> Tagged thusly:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-rewrite-20160615

Pulled, thanks David.

Re: [PATCH net-next 0/8] rxrpc: Rework endpoint record handling

[David Miller]

From: David Howells 
Date: Wed, 15 Jun 2016 17:41:38 +0100

> Here's the next part of the AF_RXRPC rewrite.  In this set I rework
> endpoint record handling.  There are two types of endpoint record, local
> and peer.  The local endpoint record is used as an anchor for the transport
> socket that AF_RXRPC uses (at the moment a UDP socket).  Local endpoints
> can be shared between AF_RXRPC sockets under certain restricted
> circumstances.
> 
> The peer endpoint is a record of the remote end.  It is (or will be) used
> to keep track MTU and RTT values and, with these changes, is used to find
> the call(s) to abort when a network error occurs.
> 
> The following significant changes are made:
 ...
> The patches can be found here also:
> 
>   
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite
> 
> Tagged thusly:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-rewrite-20160615

Pulled, thanks David.

Re: [PATCH v7 00/12] Support non-lru page migration

[Sergey Senozhatsky]

On (06/16/16 13:47), Minchan Kim wrote:
[..]
> > this is what I'm getting with the [zsmalloc: keep first object offset in 
> > struct page]
> > applied:  "count:0 mapcount:-127". which may be not related to zsmalloc at 
> > this point.
> > 
> > kernel: BUG: Bad page state in process khugepaged  pfn:101db8
> > kernel: page:ea0004076e00 count:0 mapcount:-127 mapping:  
> > (null) index:0x1
> 
> Hm, it seems double free.
> 
> It doen't happen if you disable zram? IOW, it seems to be related
> zsmalloc migration?

need to test more, can't confidently answer now.

> How easy can you reprodcue it? Could you bisect it?

it takes some (um.. random) time to trigger the bug.
I'll try to come up with more details.

-ss

> > kernel: flags: 0x8000()
> > kernel: page dumped because: nonzero mapcount
> > kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon 
> > crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii 
> > snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd 
> > soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod hid_generic usb
> > kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted 
> > 4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491
> > kernel:   8801124c73f8 814d69b0 ea0004076e00
> > kernel:  81e658a0 8801124c7420 811e9b63 
> > kernel:  ea0004076e00 81e658a0 8801124c7440 811e9ca9
> > kernel: Call Trace:
> > kernel:  [] dump_stack+0x68/0x92
> > kernel:  [] bad_page+0x158/0x1a2
> > kernel:  [] free_pages_check_bad+0xfc/0x101
> > kernel:  [] free_hot_cold_page+0x135/0x5de
> > kernel:  [] __free_pages+0x67/0x72
> > kernel:  [] release_freepages+0x13a/0x191
> > kernel:  [] compact_zone+0x845/0x1155
> > kernel:  [] ? compaction_suitable+0x76/0x76
> > kernel:  [] compact_zone_order+0xe0/0x167
> > kernel:  [] ? compact_zone+0x1155/0x1155
> > kernel:  [] try_to_compact_pages+0x2f1/0x648
> > kernel:  [] ? try_to_compact_pages+0x2f1/0x648
> > kernel:  [] ? compaction_zonelist_suitable+0x3a6/0x3a6
> > kernel:  [] ? get_page_from_freelist+0x2c0/0x133c
> > kernel:  [] __alloc_pages_direct_compact+0xea/0x30d
> > kernel:  [] ? get_page_from_freelist+0x133c/0x133c
> > kernel:  [] ? drain_all_pages+0x1d6/0x205
> > kernel:  [] __alloc_pages_nodemask+0x143d/0x16b6
> > kernel:  [] ? debug_show_all_locks+0x226/0x226
> > kernel:  [] ? warn_alloc_failed+0x24c/0x24c
> > kernel:  [] ? finish_wait+0x1a4/0x1b0
> > kernel:  [] ? lock_acquire+0xec/0x147
> > kernel:  [] ? _raw_spin_unlock_irqrestore+0x3b/0x5c
> > kernel:  [] ? _raw_spin_unlock_irqrestore+0x47/0x5c
> > kernel:  [] ? finish_wait+0x1a4/0x1b0
> > kernel:  [] khugepaged+0x1d4/0x484f
> > kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> > kernel:  [] ? finish_task_switch+0x3de/0x484
> > kernel:  [] ? _raw_spin_unlock_irq+0x27/0x45
> > kernel:  [] ? trace_hardirqs_on_caller+0x3d2/0x492
> > kernel:  [] ? prepare_to_wait_event+0x3f7/0x3f7
> > kernel:  [] ? __schedule+0xa4d/0xd16
> > kernel:  [] kthread+0x252/0x261
> > kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> > kernel:  [] ? kthread_create_on_node+0x377/0x377
> > kernel:  [] ret_from_fork+0x1f/0x40
> > kernel:  [] ? kthread_create_on_node+0x377/0x377
> > -- Reboot --

Re: [PATCH v7 00/12] Support non-lru page migration

[Sergey Senozhatsky]

On (06/16/16 13:47), Minchan Kim wrote:
[..]
> > this is what I'm getting with the [zsmalloc: keep first object offset in 
> > struct page]
> > applied:  "count:0 mapcount:-127". which may be not related to zsmalloc at 
> > this point.
> > 
> > kernel: BUG: Bad page state in process khugepaged  pfn:101db8
> > kernel: page:ea0004076e00 count:0 mapcount:-127 mapping:  
> > (null) index:0x1
> 
> Hm, it seems double free.
> 
> It doen't happen if you disable zram? IOW, it seems to be related
> zsmalloc migration?

need to test more, can't confidently answer now.

> How easy can you reprodcue it? Could you bisect it?

it takes some (um.. random) time to trigger the bug.
I'll try to come up with more details.

-ss

> > kernel: flags: 0x8000()
> > kernel: page dumped because: nonzero mapcount
> > kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon 
> > crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii 
> > snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd 
> > soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod hid_generic usb
> > kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted 
> > 4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491
> > kernel:   8801124c73f8 814d69b0 ea0004076e00
> > kernel:  81e658a0 8801124c7420 811e9b63 
> > kernel:  ea0004076e00 81e658a0 8801124c7440 811e9ca9
> > kernel: Call Trace:
> > kernel:  [] dump_stack+0x68/0x92
> > kernel:  [] bad_page+0x158/0x1a2
> > kernel:  [] free_pages_check_bad+0xfc/0x101
> > kernel:  [] free_hot_cold_page+0x135/0x5de
> > kernel:  [] __free_pages+0x67/0x72
> > kernel:  [] release_freepages+0x13a/0x191
> > kernel:  [] compact_zone+0x845/0x1155
> > kernel:  [] ? compaction_suitable+0x76/0x76
> > kernel:  [] compact_zone_order+0xe0/0x167
> > kernel:  [] ? compact_zone+0x1155/0x1155
> > kernel:  [] try_to_compact_pages+0x2f1/0x648
> > kernel:  [] ? try_to_compact_pages+0x2f1/0x648
> > kernel:  [] ? compaction_zonelist_suitable+0x3a6/0x3a6
> > kernel:  [] ? get_page_from_freelist+0x2c0/0x133c
> > kernel:  [] __alloc_pages_direct_compact+0xea/0x30d
> > kernel:  [] ? get_page_from_freelist+0x133c/0x133c
> > kernel:  [] ? drain_all_pages+0x1d6/0x205
> > kernel:  [] __alloc_pages_nodemask+0x143d/0x16b6
> > kernel:  [] ? debug_show_all_locks+0x226/0x226
> > kernel:  [] ? warn_alloc_failed+0x24c/0x24c
> > kernel:  [] ? finish_wait+0x1a4/0x1b0
> > kernel:  [] ? lock_acquire+0xec/0x147
> > kernel:  [] ? _raw_spin_unlock_irqrestore+0x3b/0x5c
> > kernel:  [] ? _raw_spin_unlock_irqrestore+0x47/0x5c
> > kernel:  [] ? finish_wait+0x1a4/0x1b0
> > kernel:  [] khugepaged+0x1d4/0x484f
> > kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> > kernel:  [] ? finish_task_switch+0x3de/0x484
> > kernel:  [] ? _raw_spin_unlock_irq+0x27/0x45
> > kernel:  [] ? trace_hardirqs_on_caller+0x3d2/0x492
> > kernel:  [] ? prepare_to_wait_event+0x3f7/0x3f7
> > kernel:  [] ? __schedule+0xa4d/0xd16
> > kernel:  [] kthread+0x252/0x261
> > kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> > kernel:  [] ? kthread_create_on_node+0x377/0x377
> > kernel:  [] ret_from_fork+0x1f/0x40
> > kernel:  [] ? kthread_create_on_node+0x377/0x377
> > -- Reboot --

Re: [PATCH 0/4] net-next: mediatek: IRQ cleanups, fixes and grouping

[David Miller]

From: John Crispin 
Date: Wed, 15 Jun 2016 16:58:46 +0200

> This series contains 2 small code cleanups that are leftovers from the
> MIPS support. There is also a small fix that adds proper locking to the
> code accessing the IRQ registers. Without this fix we saw deadlocks caused
> by the last patch of the series, which adds IRQ grouping. The grouping
> feature allows us to use different IRQs for TX and RX. By doing so we can
> use affinity to let the SoC handle the IRQs on different cores.

This patch series doesn't apply cleanly to the net-next tree, I get rejects
on patch #4.

Re: [PATCH 0/4] net-next: mediatek: IRQ cleanups, fixes and grouping

[David Miller]

From: John Crispin 
Date: Wed, 15 Jun 2016 16:58:46 +0200

> This series contains 2 small code cleanups that are leftovers from the
> MIPS support. There is also a small fix that adds proper locking to the
> code accessing the IRQ registers. Without this fix we saw deadlocks caused
> by the last patch of the series, which adds IRQ grouping. The grouping
> feature allows us to use different IRQs for TX and RX. By doing so we can
> use affinity to let the SoC handle the IRQs on different cores.

This patch series doesn't apply cleanly to the net-next tree, I get rejects
on patch #4.

Re: [PATCH] net: Don't forget pr_fmt on net_dbg_ratelimited for CONFIG_DYNAMIC_DEBUG

[David Miller]

From: "Jason A. Donenfeld" 
Date: Wed, 15 Jun 2016 11:14:53 +0200

> The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG
> case was added with 2c94b5373 ("net: Implement net_dbg_ratelimited() for
> CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to take the
> usual definition of the dynamic_pr_debug macro, but alter it by adding a
> call to "net_ratelimit()" in the if statement. This is, in fact, the
> correct approach.
> 
> However, while doing this, the author of the commit forgot to surround
> fmt by pr_fmt, resulting in unprefixed log messages appearing in the
> console. So, this commit adds back the pr_fmt(fmt) invocation, making
> net_dbg_ratelimited properly consistent across DEBUG, no DEBUG, and
> DYNAMIC_DEBUG cases, and bringing parity with the behavior of
> dynamic_pr_debug as well.
> 
> Fixes: 2c94b5373 ("net: Implement net_dbg_ratelimited() for 
> CONFIG_DYNAMIC_DEBUG case")
> Signed-off-by: Jason A. Donenfeld 
> Cc: Tim Bingham 

Looks good, applied, thanks.

Re: [PATCH] net: Don't forget pr_fmt on net_dbg_ratelimited for CONFIG_DYNAMIC_DEBUG

[David Miller]

From: "Jason A. Donenfeld" 
Date: Wed, 15 Jun 2016 11:14:53 +0200

> The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG
> case was added with 2c94b5373 ("net: Implement net_dbg_ratelimited() for
> CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to take the
> usual definition of the dynamic_pr_debug macro, but alter it by adding a
> call to "net_ratelimit()" in the if statement. This is, in fact, the
> correct approach.
> 
> However, while doing this, the author of the commit forgot to surround
> fmt by pr_fmt, resulting in unprefixed log messages appearing in the
> console. So, this commit adds back the pr_fmt(fmt) invocation, making
> net_dbg_ratelimited properly consistent across DEBUG, no DEBUG, and
> DYNAMIC_DEBUG cases, and bringing parity with the behavior of
> dynamic_pr_debug as well.
> 
> Fixes: 2c94b5373 ("net: Implement net_dbg_ratelimited() for 
> CONFIG_DYNAMIC_DEBUG case")
> Signed-off-by: Jason A. Donenfeld 
> Cc: Tim Bingham 

Looks good, applied, thanks.

Re: [PATCH v2 09/11] net: skfb: remove obsolete -I cflag

[David Miller]

From: Arnd Bergmann 
Date: Wed, 15 Jun 2016 17:45:51 +0200

> The skfp driver has been moved to drivers/net/fddi/skfp a long time
> ago, but we still attempt to include headers from the old location,
> which causes a warning when building with W=1:
> 
> cc1: error: /git/arm-soc/drivers/net/skfp: No such file or directory 
> [-Werror=missing-include-dirs]
> cc1: error: drivers/net/skfp: No such file or directory 
> [-Werror=missing-include-dirs]
> 
> Clearly this include directive is not needed any more, so we can
> just remove it now.
> 
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH v2 09/11] net: skfb: remove obsolete -I cflag

[David Miller]

From: Arnd Bergmann 
Date: Wed, 15 Jun 2016 17:45:51 +0200

> The skfp driver has been moved to drivers/net/fddi/skfp a long time
> ago, but we still attempt to include headers from the old location,
> which causes a warning when building with W=1:
> 
> cc1: error: /git/arm-soc/drivers/net/skfp: No such file or directory 
> [-Werror=missing-include-dirs]
> cc1: error: drivers/net/skfp: No such file or directory 
> [-Werror=missing-include-dirs]
> 
> Clearly this include directive is not needed any more, so we can
> just remove it now.
> 
> Signed-off-by: Arnd Bergmann 

Applied.

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

[Len Brown]

Applied, thanks!


Len Brown, Intel Open Source Technology Center

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

[Len Brown]

Applied, thanks!


Len Brown, Intel Open Source Technology Center

[GIT PULL] extcon fixes for 4.7-rc4

[Chanwoo Choi]

Dear Greg,

This is extcon-fixes pull request for v4.7-rc4 I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:

  Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-fixes-for-4.7-rc4

for you to fetch changes up to 62e6d1e59c77316768a663d1328390b4cd33801f:

  extcon: palmas: Fix boot up state of VBUS when using GPIO detection 
(2016-06-15 17:17:22 +0900)


Update extcon for v4.7-rc4

This patch fixes the following issue:
- In the extcon-palmas.c, fix the state of VBUS when using GPIO detection.
If probe funticon don't check the state during probe, the extcon client
driver cannot get the state of VBUS gpio until the user detach the connector
and attach the connector again.


Roger Quadros (1):
  extcon: palmas: Fix boot up state of VBUS when using GPIO detection

 drivers/extcon/extcon-palmas.c | 2 ++
 1 file changed, 2 insertions(+)

[GIT PULL] extcon fixes for 4.7-rc4

[Chanwoo Choi]

Dear Greg,

This is extcon-fixes pull request for v4.7-rc4 I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:

  Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-fixes-for-4.7-rc4

for you to fetch changes up to 62e6d1e59c77316768a663d1328390b4cd33801f:

  extcon: palmas: Fix boot up state of VBUS when using GPIO detection 
(2016-06-15 17:17:22 +0900)


Update extcon for v4.7-rc4

This patch fixes the following issue:
- In the extcon-palmas.c, fix the state of VBUS when using GPIO detection.
If probe funticon don't check the state during probe, the extcon client
driver cannot get the state of VBUS gpio until the user detach the connector
and attach the connector again.


Roger Quadros (1):
  extcon: palmas: Fix boot up state of VBUS when using GPIO detection

 drivers/extcon/extcon-palmas.c | 2 ++
 1 file changed, 2 insertions(+)

Re: [PATCH v7 00/12] Support non-lru page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 01:23:43PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 11:58), Minchan Kim wrote:
> [..]
> > RAX: 2065676162726166 so rax is totally garbage, I think.
> > It means obj_to_head returns garbage because get_first_obj_offset is
> > utter crab because (page_idx / class->pages_per_zspage) was totally
> > wrong.
> > 
> > >   ^^
> > > 6408:   f0 0f ba 28 00  lock btsl $0x0,(%rax)
> >  
> > 
> > 
> > > > Could you test with [zsmalloc: keep first object offset in struct page]
> > > > in mmotm?
> > > 
> > > sure, I can.  will it help, tho? we have a race condition here I think.
> > 
> > I guess root cause is caused by get_first_obj_offset.
> 
> sounds reasonable.
> 
> > Please test with it.
> 
> 
> this is what I'm getting with the [zsmalloc: keep first object offset in 
> struct page]
> applied:  "count:0 mapcount:-127". which may be not related to zsmalloc at 
> this point.
> 
> kernel: BUG: Bad page state in process khugepaged  pfn:101db8
> kernel: page:ea0004076e00 count:0 mapcount:-127 mapping:  (null) 
> index:0x1

Hm, it seems double free.

It doen't happen if you disable zram? IOW, it seems to be related
zsmalloc migration?

How easy can you reprodcue it? Could you bisect it?

> kernel: flags: 0x8000()
> kernel: page dumped because: nonzero mapcount
> kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon 
> crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii 
> snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd 
> soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod hid_generic usb
> kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted 
> 4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491
> kernel:   8801124c73f8 814d69b0 ea0004076e00
> kernel:  81e658a0 8801124c7420 811e9b63 
> kernel:  ea0004076e00 81e658a0 8801124c7440 811e9ca9
> kernel: Call Trace:
> kernel:  [] dump_stack+0x68/0x92
> kernel:  [] bad_page+0x158/0x1a2
> kernel:  [] free_pages_check_bad+0xfc/0x101
> kernel:  [] free_hot_cold_page+0x135/0x5de
> kernel:  [] __free_pages+0x67/0x72
> kernel:  [] release_freepages+0x13a/0x191
> kernel:  [] compact_zone+0x845/0x1155
> kernel:  [] ? compaction_suitable+0x76/0x76
> kernel:  [] compact_zone_order+0xe0/0x167
> kernel:  [] ? compact_zone+0x1155/0x1155
> kernel:  [] try_to_compact_pages+0x2f1/0x648
> kernel:  [] ? try_to_compact_pages+0x2f1/0x648
> kernel:  [] ? compaction_zonelist_suitable+0x3a6/0x3a6
> kernel:  [] ? get_page_from_freelist+0x2c0/0x133c
> kernel:  [] __alloc_pages_direct_compact+0xea/0x30d
> kernel:  [] ? get_page_from_freelist+0x133c/0x133c
> kernel:  [] ? drain_all_pages+0x1d6/0x205
> kernel:  [] __alloc_pages_nodemask+0x143d/0x16b6
> kernel:  [] ? debug_show_all_locks+0x226/0x226
> kernel:  [] ? warn_alloc_failed+0x24c/0x24c
> kernel:  [] ? finish_wait+0x1a4/0x1b0
> kernel:  [] ? lock_acquire+0xec/0x147
> kernel:  [] ? _raw_spin_unlock_irqrestore+0x3b/0x5c
> kernel:  [] ? _raw_spin_unlock_irqrestore+0x47/0x5c
> kernel:  [] ? finish_wait+0x1a4/0x1b0
> kernel:  [] khugepaged+0x1d4/0x484f
> kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> kernel:  [] ? finish_task_switch+0x3de/0x484
> kernel:  [] ? _raw_spin_unlock_irq+0x27/0x45
> kernel:  [] ? trace_hardirqs_on_caller+0x3d2/0x492
> kernel:  [] ? prepare_to_wait_event+0x3f7/0x3f7
> kernel:  [] ? __schedule+0xa4d/0xd16
> kernel:  [] kthread+0x252/0x261
> kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> kernel:  [] ? kthread_create_on_node+0x377/0x377
> kernel:  [] ret_from_fork+0x1f/0x40
> kernel:  [] ? kthread_create_on_node+0x377/0x377
> -- Reboot --
> 
>   -ss

Re: [PATCH v7 00/12] Support non-lru page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 01:23:43PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 11:58), Minchan Kim wrote:
> [..]
> > RAX: 2065676162726166 so rax is totally garbage, I think.
> > It means obj_to_head returns garbage because get_first_obj_offset is
> > utter crab because (page_idx / class->pages_per_zspage) was totally
> > wrong.
> > 
> > >   ^^
> > > 6408:   f0 0f ba 28 00  lock btsl $0x0,(%rax)
> >  
> > 
> > 
> > > > Could you test with [zsmalloc: keep first object offset in struct page]
> > > > in mmotm?
> > > 
> > > sure, I can.  will it help, tho? we have a race condition here I think.
> > 
> > I guess root cause is caused by get_first_obj_offset.
> 
> sounds reasonable.
> 
> > Please test with it.
> 
> 
> this is what I'm getting with the [zsmalloc: keep first object offset in 
> struct page]
> applied:  "count:0 mapcount:-127". which may be not related to zsmalloc at 
> this point.
> 
> kernel: BUG: Bad page state in process khugepaged  pfn:101db8
> kernel: page:ea0004076e00 count:0 mapcount:-127 mapping:  (null) 
> index:0x1

Hm, it seems double free.

It doen't happen if you disable zram? IOW, it seems to be related
zsmalloc migration?

How easy can you reprodcue it? Could you bisect it?

> kernel: flags: 0x8000()
> kernel: page dumped because: nonzero mapcount
> kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon 
> crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii 
> snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd 
> soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod hid_generic usb
> kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted 
> 4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491
> kernel:   8801124c73f8 814d69b0 ea0004076e00
> kernel:  81e658a0 8801124c7420 811e9b63 
> kernel:  ea0004076e00 81e658a0 8801124c7440 811e9ca9
> kernel: Call Trace:
> kernel:  [] dump_stack+0x68/0x92
> kernel:  [] bad_page+0x158/0x1a2
> kernel:  [] free_pages_check_bad+0xfc/0x101
> kernel:  [] free_hot_cold_page+0x135/0x5de
> kernel:  [] __free_pages+0x67/0x72
> kernel:  [] release_freepages+0x13a/0x191
> kernel:  [] compact_zone+0x845/0x1155
> kernel:  [] ? compaction_suitable+0x76/0x76
> kernel:  [] compact_zone_order+0xe0/0x167
> kernel:  [] ? compact_zone+0x1155/0x1155
> kernel:  [] try_to_compact_pages+0x2f1/0x648
> kernel:  [] ? try_to_compact_pages+0x2f1/0x648
> kernel:  [] ? compaction_zonelist_suitable+0x3a6/0x3a6
> kernel:  [] ? get_page_from_freelist+0x2c0/0x133c
> kernel:  [] __alloc_pages_direct_compact+0xea/0x30d
> kernel:  [] ? get_page_from_freelist+0x133c/0x133c
> kernel:  [] ? drain_all_pages+0x1d6/0x205
> kernel:  [] __alloc_pages_nodemask+0x143d/0x16b6
> kernel:  [] ? debug_show_all_locks+0x226/0x226
> kernel:  [] ? warn_alloc_failed+0x24c/0x24c
> kernel:  [] ? finish_wait+0x1a4/0x1b0
> kernel:  [] ? lock_acquire+0xec/0x147
> kernel:  [] ? _raw_spin_unlock_irqrestore+0x3b/0x5c
> kernel:  [] ? _raw_spin_unlock_irqrestore+0x47/0x5c
> kernel:  [] ? finish_wait+0x1a4/0x1b0
> kernel:  [] khugepaged+0x1d4/0x484f
> kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> kernel:  [] ? finish_task_switch+0x3de/0x484
> kernel:  [] ? _raw_spin_unlock_irq+0x27/0x45
> kernel:  [] ? trace_hardirqs_on_caller+0x3d2/0x492
> kernel:  [] ? prepare_to_wait_event+0x3f7/0x3f7
> kernel:  [] ? __schedule+0xa4d/0xd16
> kernel:  [] kthread+0x252/0x261
> kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> kernel:  [] ? kthread_create_on_node+0x377/0x377
> kernel:  [] ret_from_fork+0x1f/0x40
> kernel:  [] ? kthread_create_on_node+0x377/0x377
> -- Reboot --
> 
>   -ss

Re: [PATCH] Revert "ARM: cns3xxx: pci: avoid potential stack overflow"

[Krzysztof Hałasa]

Arnd Bergmann  writes:

> I'd start by copying the relevant nodes from
> arch/arm/boot/dts/arm-realview-pb11mp.dts, which is the closest
> I can think of. I've put together something completely untested
> below.

Thanks. I will try to handle that. 3+ weeks, unfortunately.

Now, what do we do with the PCIe MRRS?
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH] Revert "ARM: cns3xxx: pci: avoid potential stack overflow"

[Krzysztof Hałasa]

Arnd Bergmann  writes:

> I'd start by copying the relevant nodes from
> arch/arm/boot/dts/arm-realview-pb11mp.dts, which is the closest
> I can think of. I've put together something completely untested
> below.

Thanks. I will try to handle that. 3+ weeks, unfortunately.

Now, what do we do with the PCIe MRRS?
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH V2 resend] libata:fix kernel panic when hotplug

[DingXiang]

In normal condition,if we use sas protocol and hotplug a
sata disk on a port,the sas driver will send event
"PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new
sata disk,this operation may cause a kernel panic like this:

[ 2366.923208] Unable to handle kernel NULL pointer dereference
at virtual address 07b8
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110

This because "dev_to_shost" in "sas_find_dev_by_rphy" return
a NULL point,and SHOST_TO_SAS_HA used it,so kernel panic happened.

why did dev_to_shost return a NULL point?
Because in "__scsi_add_device" ,
struct device *parent = >shost_gendev,
and in "scsi_alloc_target", "*parent" is assigned to
"starget->dev.parent",then "sas_target_alloc" will get
"struct sas_rphy" according "starget->dev.parent", and in
"sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost"
according "rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent
is "ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at this moment,the libata hotplug task
will run and panic will happen.

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Signed-off-by: Ding Xiang 
---
 drivers/ata/libata-eh.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..4428a7c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,7 +816,8 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
+   else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
+!(ap->pflags & ATA_FLAG_SAS_HOST))
schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
-- 
2.5.0

[PATCH V2 resend] libata:fix kernel panic when hotplug

[DingXiang]

In normal condition,if we use sas protocol and hotplug a
sata disk on a port,the sas driver will send event
"PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new
sata disk,this operation may cause a kernel panic like this:

[ 2366.923208] Unable to handle kernel NULL pointer dereference
at virtual address 07b8
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110

This because "dev_to_shost" in "sas_find_dev_by_rphy" return
a NULL point,and SHOST_TO_SAS_HA used it,so kernel panic happened.

why did dev_to_shost return a NULL point?
Because in "__scsi_add_device" ,
struct device *parent = >shost_gendev,
and in "scsi_alloc_target", "*parent" is assigned to
"starget->dev.parent",then "sas_target_alloc" will get
"struct sas_rphy" according "starget->dev.parent", and in
"sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost"
according "rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent
is "ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at this moment,the libata hotplug task
will run and panic will happen.

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Signed-off-by: Ding Xiang 
---
 drivers/ata/libata-eh.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..4428a7c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,7 +816,8 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
+   else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
+!(ap->pflags & ATA_FLAG_SAS_HOST))
schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
-- 
2.5.0

[PATCH v2] iommu/amd: Add proper error check in two functions

[Wan Zongshun]

From: Wan Zongshun 

This patch is to do the following:

1. Add error check for caller of iommu_device_create.

2. Add error check for caller of iommu_device_link and
move 'iommu = amd_iommu_rlookup_table[dev_data->devid]' out of
iommuv2 capability condition that make iommu_device_link also
use the 'iommu' to make code more clear and no more than 80
characters.

Signed-off-by: Wan Zongshun 
---
Changes from v1:

Don't fail the iommu_init_device() function when the iommu_device_link returned
an error,just print a warning message.
---
 drivers/iommu/amd_iommu.c  | 11 +--
 drivers/iommu/amd_iommu_init.c |  2 ++
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 634f636..dbdcaeb 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -476,6 +476,7 @@ out:
 static int iommu_init_device(struct device *dev)
 {
struct iommu_dev_data *dev_data;
+   struct amd_iommu *iommu;
int devid;
 
if (dev->archdata.iommu)
@@ -491,17 +492,15 @@ static int iommu_init_device(struct device *dev)
 
dev_data->alias = get_alias(dev);
 
-   if (dev_is_pci(dev) && pci_iommuv2_capable(to_pci_dev(dev))) {
-   struct amd_iommu *iommu;
+   iommu = amd_iommu_rlookup_table[dev_data->devid];
 
-   iommu = amd_iommu_rlookup_table[dev_data->devid];
+   if (dev_is_pci(dev) && pci_iommuv2_capable(to_pci_dev(dev)))
dev_data->iommu_v2 = iommu->is_iommu_v2;
-   }
 
dev->archdata.iommu = dev_data;
 
-   iommu_device_link(amd_iommu_rlookup_table[dev_data->devid]->iommu_dev,
- dev);
+   if (iommu_device_link(iommu->iommu_dev, dev))
+   dev_warn(dev, "Creating iommu device link failed in sysfs.\n");
 
return 0;
 }
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 9e00341..73fa986 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -1526,6 +1526,8 @@ static int iommu_init_pci(struct amd_iommu *iommu)
iommu->iommu_dev = iommu_device_create(>dev->dev, iommu,
   amd_iommu_groups, "ivhd%d",
   iommu->index);
+   if (IS_ERR(iommu->iommu_dev))
+   return PTR_ERR(iommu->iommu_dev);
 
return pci_enable_device(iommu->dev);
 }
-- 
1.9.1

[PATCH v2] iommu/amd: Add proper error check in two functions

[Wan Zongshun]

From: Wan Zongshun 

This patch is to do the following:

1. Add error check for caller of iommu_device_create.

2. Add error check for caller of iommu_device_link and
move 'iommu = amd_iommu_rlookup_table[dev_data->devid]' out of
iommuv2 capability condition that make iommu_device_link also
use the 'iommu' to make code more clear and no more than 80
characters.

Signed-off-by: Wan Zongshun 
---
Changes from v1:

Don't fail the iommu_init_device() function when the iommu_device_link returned
an error,just print a warning message.
---
 drivers/iommu/amd_iommu.c  | 11 +--
 drivers/iommu/amd_iommu_init.c |  2 ++
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 634f636..dbdcaeb 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -476,6 +476,7 @@ out:
 static int iommu_init_device(struct device *dev)
 {
struct iommu_dev_data *dev_data;
+   struct amd_iommu *iommu;
int devid;
 
if (dev->archdata.iommu)
@@ -491,17 +492,15 @@ static int iommu_init_device(struct device *dev)
 
dev_data->alias = get_alias(dev);
 
-   if (dev_is_pci(dev) && pci_iommuv2_capable(to_pci_dev(dev))) {
-   struct amd_iommu *iommu;
+   iommu = amd_iommu_rlookup_table[dev_data->devid];
 
-   iommu = amd_iommu_rlookup_table[dev_data->devid];
+   if (dev_is_pci(dev) && pci_iommuv2_capable(to_pci_dev(dev)))
dev_data->iommu_v2 = iommu->is_iommu_v2;
-   }
 
dev->archdata.iommu = dev_data;
 
-   iommu_device_link(amd_iommu_rlookup_table[dev_data->devid]->iommu_dev,
- dev);
+   if (iommu_device_link(iommu->iommu_dev, dev))
+   dev_warn(dev, "Creating iommu device link failed in sysfs.\n");
 
return 0;
 }
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 9e00341..73fa986 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -1526,6 +1526,8 @@ static int iommu_init_pci(struct amd_iommu *iommu)
iommu->iommu_dev = iommu_device_create(>dev->dev, iommu,
   amd_iommu_groups, "ivhd%d",
   iommu->index);
+   if (IS_ERR(iommu->iommu_dev))
+   return PTR_ERR(iommu->iommu_dev);
 
return pci_enable_device(iommu->dev);
 }
-- 
1.9.1

linux-next: build warning after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from drivers/gpio/gpiolib.c:25:0:
drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread':
include/linux/kfifo.h:403:39: warning: 'ge.id' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
)[__kfifo->in & __tmp->kfifo.mask] = \
   ^
drivers/gpio/gpiolib.c:657:24: note: 'ge.id' was declared here
  struct gpioevent_data ge;
^

Introduced by commit

  61f922db7221 ("gpio: userspace ABI for reading GPIO line events")

This is in the kfifo_put() call.

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from drivers/gpio/gpiolib.c:25:0:
drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread':
include/linux/kfifo.h:403:39: warning: 'ge.id' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
)[__kfifo->in & __tmp->kfifo.mask] = \
   ^
drivers/gpio/gpiolib.c:657:24: note: 'ge.id' was declared here
  struct gpioevent_data ge;
^

Introduced by commit

  61f922db7221 ("gpio: userspace ABI for reading GPIO line events")

This is in the kfifo_put() call.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v7 00/12] Support non-lru page migration

[Sergey Senozhatsky]

On (06/16/16 11:58), Minchan Kim wrote:
[..]
> RAX: 2065676162726166 so rax is totally garbage, I think.
> It means obj_to_head returns garbage because get_first_obj_offset is
> utter crab because (page_idx / class->pages_per_zspage) was totally
> wrong.
> 
> > ^^
> > 6408:   f0 0f ba 28 00  lock btsl $0x0,(%rax)
>  
> 
> 
> > > Could you test with [zsmalloc: keep first object offset in struct page]
> > > in mmotm?
> > 
> > sure, I can.  will it help, tho? we have a race condition here I think.
> 
> I guess root cause is caused by get_first_obj_offset.

sounds reasonable.

> Please test with it.


this is what I'm getting with the [zsmalloc: keep first object offset in struct 
page]
applied:  "count:0 mapcount:-127". which may be not related to zsmalloc at this 
point.

kernel: BUG: Bad page state in process khugepaged  pfn:101db8
kernel: page:ea0004076e00 count:0 mapcount:-127 mapping:  (null) 
index:0x1
kernel: flags: 0x8000()
kernel: page dumped because: nonzero mapcount
kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon 
crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii 
snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd 
soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod hid_generic usb
kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted 
4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491
kernel:   8801124c73f8 814d69b0 ea0004076e00
kernel:  81e658a0 8801124c7420 811e9b63 
kernel:  ea0004076e00 81e658a0 8801124c7440 811e9ca9
kernel: Call Trace:
kernel:  [] dump_stack+0x68/0x92
kernel:  [] bad_page+0x158/0x1a2
kernel:  [] free_pages_check_bad+0xfc/0x101
kernel:  [] free_hot_cold_page+0x135/0x5de
kernel:  [] __free_pages+0x67/0x72
kernel:  [] release_freepages+0x13a/0x191
kernel:  [] compact_zone+0x845/0x1155
kernel:  [] ? compaction_suitable+0x76/0x76
kernel:  [] compact_zone_order+0xe0/0x167
kernel:  [] ? compact_zone+0x1155/0x1155
kernel:  [] try_to_compact_pages+0x2f1/0x648
kernel:  [] ? try_to_compact_pages+0x2f1/0x648
kernel:  [] ? compaction_zonelist_suitable+0x3a6/0x3a6
kernel:  [] ? get_page_from_freelist+0x2c0/0x133c
kernel:  [] __alloc_pages_direct_compact+0xea/0x30d
kernel:  [] ? get_page_from_freelist+0x133c/0x133c
kernel:  [] ? drain_all_pages+0x1d6/0x205
kernel:  [] __alloc_pages_nodemask+0x143d/0x16b6
kernel:  [] ? debug_show_all_locks+0x226/0x226
kernel:  [] ? warn_alloc_failed+0x24c/0x24c
kernel:  [] ? finish_wait+0x1a4/0x1b0
kernel:  [] ? lock_acquire+0xec/0x147
kernel:  [] ? _raw_spin_unlock_irqrestore+0x3b/0x5c
kernel:  [] ? _raw_spin_unlock_irqrestore+0x47/0x5c
kernel:  [] ? finish_wait+0x1a4/0x1b0
kernel:  [] khugepaged+0x1d4/0x484f
kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
kernel:  [] ? finish_task_switch+0x3de/0x484
kernel:  [] ? _raw_spin_unlock_irq+0x27/0x45
kernel:  [] ? trace_hardirqs_on_caller+0x3d2/0x492
kernel:  [] ? prepare_to_wait_event+0x3f7/0x3f7
kernel:  [] ? __schedule+0xa4d/0xd16
kernel:  [] kthread+0x252/0x261
kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
kernel:  [] ? kthread_create_on_node+0x377/0x377
kernel:  [] ret_from_fork+0x1f/0x40
kernel:  [] ? kthread_create_on_node+0x377/0x377
-- Reboot --

-ss

Re: [PATCH v7 00/12] Support non-lru page migration

[Sergey Senozhatsky]

On (06/16/16 11:58), Minchan Kim wrote:
[..]
> RAX: 2065676162726166 so rax is totally garbage, I think.
> It means obj_to_head returns garbage because get_first_obj_offset is
> utter crab because (page_idx / class->pages_per_zspage) was totally
> wrong.
> 
> > ^^
> > 6408:   f0 0f ba 28 00  lock btsl $0x0,(%rax)
>  
> 
> 
> > > Could you test with [zsmalloc: keep first object offset in struct page]
> > > in mmotm?
> > 
> > sure, I can.  will it help, tho? we have a race condition here I think.
> 
> I guess root cause is caused by get_first_obj_offset.

sounds reasonable.

> Please test with it.


this is what I'm getting with the [zsmalloc: keep first object offset in struct 
page]
applied:  "count:0 mapcount:-127". which may be not related to zsmalloc at this 
point.

kernel: BUG: Bad page state in process khugepaged  pfn:101db8
kernel: page:ea0004076e00 count:0 mapcount:-127 mapping:  (null) 
index:0x1
kernel: flags: 0x8000()
kernel: page dumped because: nonzero mapcount
kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon 
crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii 
snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd 
soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod hid_generic usb
kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted 
4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491
kernel:   8801124c73f8 814d69b0 ea0004076e00
kernel:  81e658a0 8801124c7420 811e9b63 
kernel:  ea0004076e00 81e658a0 8801124c7440 811e9ca9
kernel: Call Trace:
kernel:  [] dump_stack+0x68/0x92
kernel:  [] bad_page+0x158/0x1a2
kernel:  [] free_pages_check_bad+0xfc/0x101
kernel:  [] free_hot_cold_page+0x135/0x5de
kernel:  [] __free_pages+0x67/0x72
kernel:  [] release_freepages+0x13a/0x191
kernel:  [] compact_zone+0x845/0x1155
kernel:  [] ? compaction_suitable+0x76/0x76
kernel:  [] compact_zone_order+0xe0/0x167
kernel:  [] ? compact_zone+0x1155/0x1155
kernel:  [] try_to_compact_pages+0x2f1/0x648
kernel:  [] ? try_to_compact_pages+0x2f1/0x648
kernel:  [] ? compaction_zonelist_suitable+0x3a6/0x3a6
kernel:  [] ? get_page_from_freelist+0x2c0/0x133c
kernel:  [] __alloc_pages_direct_compact+0xea/0x30d
kernel:  [] ? get_page_from_freelist+0x133c/0x133c
kernel:  [] ? drain_all_pages+0x1d6/0x205
kernel:  [] __alloc_pages_nodemask+0x143d/0x16b6
kernel:  [] ? debug_show_all_locks+0x226/0x226
kernel:  [] ? warn_alloc_failed+0x24c/0x24c
kernel:  [] ? finish_wait+0x1a4/0x1b0
kernel:  [] ? lock_acquire+0xec/0x147
kernel:  [] ? _raw_spin_unlock_irqrestore+0x3b/0x5c
kernel:  [] ? _raw_spin_unlock_irqrestore+0x47/0x5c
kernel:  [] ? finish_wait+0x1a4/0x1b0
kernel:  [] khugepaged+0x1d4/0x484f
kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
kernel:  [] ? finish_task_switch+0x3de/0x484
kernel:  [] ? _raw_spin_unlock_irq+0x27/0x45
kernel:  [] ? trace_hardirqs_on_caller+0x3d2/0x492
kernel:  [] ? prepare_to_wait_event+0x3f7/0x3f7
kernel:  [] ? __schedule+0xa4d/0xd16
kernel:  [] kthread+0x252/0x261
kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
kernel:  [] ? kthread_create_on_node+0x377/0x377
kernel:  [] ret_from_fork+0x1f/0x40
kernel:  [] ? kthread_create_on_node+0x377/0x377
-- Reboot --

-ss

Re: [PATCH v1 0/3] per-process reclaim

[Vinayak Menon]

On 6/15/2016 6:27 AM, Minchan Kim wrote:
>
> Yeb, I read Johannes's thread which suggests one-cgroup-per-app model.
> It does make sense to me. It is worth to try although I guess it's not
> easy to control memory usage on demand, not proactively.
> If we can do, maybe we don't need per-process reclaim policy which
> is rather coarse-grained model of reclaim POV.
> However, a concern with one-cgroup-per-app model is LRU list size
> of a cgroup is much smaller so how LRU aging works well and
> LRU churing(e.g., compaction) effect would be severe than old.
And I was thinking what would vmpressure mean and how to use it when cgroup is 
per task.
>
> I guess codeaurora tried memcg model for android.
> Could you share if you know something?
>
We tried, but had issues with charge migration and then Johannes suggested per 
task cgroup.
But that's not tried yet.

Thanks

Re: [PATCH v1 0/3] per-process reclaim

[Vinayak Menon]

On 6/15/2016 6:27 AM, Minchan Kim wrote:
>
> Yeb, I read Johannes's thread which suggests one-cgroup-per-app model.
> It does make sense to me. It is worth to try although I guess it's not
> easy to control memory usage on demand, not proactively.
> If we can do, maybe we don't need per-process reclaim policy which
> is rather coarse-grained model of reclaim POV.
> However, a concern with one-cgroup-per-app model is LRU list size
> of a cgroup is much smaller so how LRU aging works well and
> LRU churing(e.g., compaction) effect would be severe than old.
And I was thinking what would vmpressure mean and how to use it when cgroup is 
per task.
>
> I guess codeaurora tried memcg model for android.
> Could you share if you know something?
>
We tried, but had issues with charge migration and then Johannes suggested per 
task cgroup.
But that's not tried yet.

Thanks

linux-next: manual merge of the vhost tree with the net-next tree

[Stephen Rothwell]

Hi Michael,

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

  tools/virtio/ringtest/Makefile

between commit:

  9fb6bc5b4a78 ("ptr_ring: ring test")

from the net-next tree and commit:

  139ab4d4e68b ("tools/virtio: add noring tool")

from the vhost tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc tools/virtio/ringtest/Makefile
index 50e086c6a7b6,6173adae9f08..
--- a/tools/virtio/ringtest/Makefile
+++ b/tools/virtio/ringtest/Makefile
@@@ -1,6 -1,6 +1,6 @@@
  all:
  
- all: ring virtio_ring_0_9 virtio_ring_poll virtio_ring_inorder ptr_ring
 -all: ring virtio_ring_0_9 virtio_ring_poll virtio_ring_inorder noring
++all: ring virtio_ring_0_9 virtio_ring_poll virtio_ring_inorder ptr_ring noring
  
  CFLAGS += -Wall
  CFLAGS += -pthread -O2 -ggdb
@@@ -16,13 -15,13 +16,15 @@@ ring: ring.o main.
  virtio_ring_0_9: virtio_ring_0_9.o main.o
  virtio_ring_poll: virtio_ring_poll.o main.o
  virtio_ring_inorder: virtio_ring_inorder.o main.o
 +ptr_ring: ptr_ring.o main.o
+ noring: noring.o main.o
  clean:
-rm main.o
-rm ring.o ring
-rm virtio_ring_0_9.o virtio_ring_0_9
-rm virtio_ring_poll.o virtio_ring_poll
-rm virtio_ring_inorder.o virtio_ring_inorder
 +  -rm ptr_ring.o ptr_ring
+   -rm noring.o noring
  
  .PHONY: all clean

linux-next: manual merge of the vhost tree with the net-next tree

[Stephen Rothwell]

Hi Michael,

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

  tools/virtio/ringtest/Makefile

between commit:

  9fb6bc5b4a78 ("ptr_ring: ring test")

from the net-next tree and commit:

  139ab4d4e68b ("tools/virtio: add noring tool")

from the vhost tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc tools/virtio/ringtest/Makefile
index 50e086c6a7b6,6173adae9f08..
--- a/tools/virtio/ringtest/Makefile
+++ b/tools/virtio/ringtest/Makefile
@@@ -1,6 -1,6 +1,6 @@@
  all:
  
- all: ring virtio_ring_0_9 virtio_ring_poll virtio_ring_inorder ptr_ring
 -all: ring virtio_ring_0_9 virtio_ring_poll virtio_ring_inorder noring
++all: ring virtio_ring_0_9 virtio_ring_poll virtio_ring_inorder ptr_ring noring
  
  CFLAGS += -Wall
  CFLAGS += -pthread -O2 -ggdb
@@@ -16,13 -15,13 +16,15 @@@ ring: ring.o main.
  virtio_ring_0_9: virtio_ring_0_9.o main.o
  virtio_ring_poll: virtio_ring_poll.o main.o
  virtio_ring_inorder: virtio_ring_inorder.o main.o
 +ptr_ring: ptr_ring.o main.o
+ noring: noring.o main.o
  clean:
-rm main.o
-rm ring.o ring
-rm virtio_ring_0_9.o virtio_ring_0_9
-rm virtio_ring_poll.o virtio_ring_poll
-rm virtio_ring_inorder.o virtio_ring_inorder
 +  -rm ptr_ring.o ptr_ring
+   -rm noring.o noring
  
  .PHONY: all clean

[PATCH] mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Prasun Maiti]

The two members min_scan_time and max_scan_time of structure
"mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
are assigned directtly from firmware without endian conversion handling.
So, wrong datas will get saved in big-endian systems.

This patch converts the values into cpu's byte order before assigning them
into the local members.

Signed-off-by: Prasun Maiti 
---
 drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c 
b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index 0104108..7dff452 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -474,8 +474,8 @@ void mwifiex_bt_coex_wlan_param_update_event(struct 
mwifiex_private *priv,
scantlv =
(struct mwifiex_ie_types_btcoex_scan_time *)tlv;
adapter->coex_scan = scantlv->coex_scan;
-   adapter->coex_min_scan_time = scantlv->min_scan_time;
-   adapter->coex_max_scan_time = scantlv->max_scan_time;
+   adapter->coex_min_scan_time = 
le16_to_cpu(scantlv->min_scan_time);
+   adapter->coex_max_scan_time = 
le16_to_cpu(scantlv->max_scan_time);
break;
 
default:
-- 
1.9.1

[PATCH] mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Prasun Maiti]

The two members min_scan_time and max_scan_time of structure
"mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
are assigned directtly from firmware without endian conversion handling.
So, wrong datas will get saved in big-endian systems.

This patch converts the values into cpu's byte order before assigning them
into the local members.

Signed-off-by: Prasun Maiti 
---
 drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c 
b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index 0104108..7dff452 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -474,8 +474,8 @@ void mwifiex_bt_coex_wlan_param_update_event(struct 
mwifiex_private *priv,
scantlv =
(struct mwifiex_ie_types_btcoex_scan_time *)tlv;
adapter->coex_scan = scantlv->coex_scan;
-   adapter->coex_min_scan_time = scantlv->min_scan_time;
-   adapter->coex_max_scan_time = scantlv->max_scan_time;
+   adapter->coex_min_scan_time = 
le16_to_cpu(scantlv->min_scan_time);
+   adapter->coex_max_scan_time = 
le16_to_cpu(scantlv->max_scan_time);
break;
 
default:
-- 
1.9.1

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

[Mika Penttilä]

Hi,

On 06/16/2016 03:28 AM, Andy Lutomirski wrote:
> This allows x86_64 kernels to enable vmapped stacks.  There are a
> couple of interesting bits.
> 
> First, x86 lazily faults in top-level paging entries for the vmalloc
> area.  This won't work if we get a page fault while trying to access
> the stack: the CPU will promote it to a double-fault and we'll die.
> To avoid this problem, probe the new stack when switching stacks and
> forcibly populate the pgd entry for the stack when switching mms.
> 
> Second, once we have guard pages around the stack, we'll want to
> detect and handle stack overflow.
> 
> I didn't enable it on x86_32.  We'd need to rework the double-fault
> code a bit and I'm concerned about running out of vmalloc virtual
> addresses under some workloads.
> 
> This patch, by itself, will behave somewhat erratically when the
> stack overflows while RSP is still more than a few tens of bytes
> above the bottom of the stack.  Specifically, we'll get #PF and make
> it to no_context and an oops without triggering a double-fault, and
> no_context doesn't know about stack overflows.  The next patch will
> improve that case.
> 
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/Kconfig |  1 +
>  arch/x86/include/asm/switch_to.h | 28 +++-
>  arch/x86/kernel/traps.c  | 32 
>  arch/x86/mm/tlb.c| 15 +++
>  4 files changed, 75 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 0a7b885964ba..b624b24d1dc1 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -92,6 +92,7 @@ config X86
>   select HAVE_ARCH_TRACEHOOK
>   select HAVE_ARCH_TRANSPARENT_HUGEPAGE
>   select HAVE_EBPF_JITif X86_64
> + select HAVE_ARCH_VMAP_STACK if X86_64
>   select HAVE_CC_STACKPROTECTOR
>   select HAVE_CMPXCHG_DOUBLE
>   select HAVE_CMPXCHG_LOCAL
> diff --git a/arch/x86/include/asm/switch_to.h 
> b/arch/x86/include/asm/switch_to.h
> index 8f321a1b03a1..14e4b20f0aaf 100644
> --- a/arch/x86/include/asm/switch_to.h
> +++ b/arch/x86/include/asm/switch_to.h
> @@ -8,6 +8,28 @@ struct tss_struct;
>  void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
> struct tss_struct *tss);
>  
> +/* This runs runs on the previous thread's stack. */
> +static inline void prepare_switch_to(struct task_struct *prev,
> +  struct task_struct *next)
> +{
> +#ifdef CONFIG_VMAP_STACK
> + /*
> +  * If we switch to a stack that has a top-level paging entry
> +  * that is not present in the current mm, the resulting #PF will
> +  * will be promoted to a double-fault and we'll panic.  Probe
> +  * the new stack now so that vmalloc_fault can fix up the page
> +  * tables if needed.  This can only happen if we use a stack
> +  * in vmap space.
> +  *
> +  * We assume that the stack is aligned so that it never spans
> +  * more than one top-level paging entry.
> +  *
> +  * To minimize cache pollution, just follow the stack pointer.
> +  */
> + READ_ONCE(*(unsigned char *)next->thread.sp);
> +#endif
> +}
> +
>  #ifdef CONFIG_X86_32
>  
>  #ifdef CONFIG_CC_STACKPROTECTOR
> @@ -39,6 +61,8 @@ do {
> \
>*/ \
>   unsigned long ebx, ecx, edx, esi, edi;  \
>   \
> + prepare_switch_to(prev, next);  \
> + \
>   asm volatile("pushl %%ebp\n\t"  /* saveEBP   */ \
>"movl %%esp,%[prev_sp]\n\t"/* saveESP   */ \
>"movl %[next_sp],%%esp\n\t"/* restore ESP   */ \
> @@ -103,7 +127,9 @@ do {  
> \
>   * clean in kernel mode, with the possible exception of IOPL.  Kernel IOPL
>   * has no effect.
>   */
> -#define switch_to(prev, next, last) \
> +#define switch_to(prev, next, last)\
> + prepare_switch_to(prev, next);\
> +   \
>   asm volatile(SAVE_CONTEXT \
>"movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP */   \
>"movq %P[threadrsp](%[next]),%%rsp\n\t" /* restore RSP */\
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 00f03d82e69a..9cb7ea781176 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -292,12 +292,30 @@ DO_ERROR(X86_TRAP_NP, SIGBUS,  "segment not 
> present", 

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

[Mika Penttilä]

Hi,

On 06/16/2016 03:28 AM, Andy Lutomirski wrote:
> This allows x86_64 kernels to enable vmapped stacks.  There are a
> couple of interesting bits.
> 
> First, x86 lazily faults in top-level paging entries for the vmalloc
> area.  This won't work if we get a page fault while trying to access
> the stack: the CPU will promote it to a double-fault and we'll die.
> To avoid this problem, probe the new stack when switching stacks and
> forcibly populate the pgd entry for the stack when switching mms.
> 
> Second, once we have guard pages around the stack, we'll want to
> detect and handle stack overflow.
> 
> I didn't enable it on x86_32.  We'd need to rework the double-fault
> code a bit and I'm concerned about running out of vmalloc virtual
> addresses under some workloads.
> 
> This patch, by itself, will behave somewhat erratically when the
> stack overflows while RSP is still more than a few tens of bytes
> above the bottom of the stack.  Specifically, we'll get #PF and make
> it to no_context and an oops without triggering a double-fault, and
> no_context doesn't know about stack overflows.  The next patch will
> improve that case.
> 
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/Kconfig |  1 +
>  arch/x86/include/asm/switch_to.h | 28 +++-
>  arch/x86/kernel/traps.c  | 32 
>  arch/x86/mm/tlb.c| 15 +++
>  4 files changed, 75 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 0a7b885964ba..b624b24d1dc1 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -92,6 +92,7 @@ config X86
>   select HAVE_ARCH_TRACEHOOK
>   select HAVE_ARCH_TRANSPARENT_HUGEPAGE
>   select HAVE_EBPF_JITif X86_64
> + select HAVE_ARCH_VMAP_STACK if X86_64
>   select HAVE_CC_STACKPROTECTOR
>   select HAVE_CMPXCHG_DOUBLE
>   select HAVE_CMPXCHG_LOCAL
> diff --git a/arch/x86/include/asm/switch_to.h 
> b/arch/x86/include/asm/switch_to.h
> index 8f321a1b03a1..14e4b20f0aaf 100644
> --- a/arch/x86/include/asm/switch_to.h
> +++ b/arch/x86/include/asm/switch_to.h
> @@ -8,6 +8,28 @@ struct tss_struct;
>  void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
> struct tss_struct *tss);
>  
> +/* This runs runs on the previous thread's stack. */
> +static inline void prepare_switch_to(struct task_struct *prev,
> +  struct task_struct *next)
> +{
> +#ifdef CONFIG_VMAP_STACK
> + /*
> +  * If we switch to a stack that has a top-level paging entry
> +  * that is not present in the current mm, the resulting #PF will
> +  * will be promoted to a double-fault and we'll panic.  Probe
> +  * the new stack now so that vmalloc_fault can fix up the page
> +  * tables if needed.  This can only happen if we use a stack
> +  * in vmap space.
> +  *
> +  * We assume that the stack is aligned so that it never spans
> +  * more than one top-level paging entry.
> +  *
> +  * To minimize cache pollution, just follow the stack pointer.
> +  */
> + READ_ONCE(*(unsigned char *)next->thread.sp);
> +#endif
> +}
> +
>  #ifdef CONFIG_X86_32
>  
>  #ifdef CONFIG_CC_STACKPROTECTOR
> @@ -39,6 +61,8 @@ do {
> \
>*/ \
>   unsigned long ebx, ecx, edx, esi, edi;  \
>   \
> + prepare_switch_to(prev, next);  \
> + \
>   asm volatile("pushl %%ebp\n\t"  /* saveEBP   */ \
>"movl %%esp,%[prev_sp]\n\t"/* saveESP   */ \
>"movl %[next_sp],%%esp\n\t"/* restore ESP   */ \
> @@ -103,7 +127,9 @@ do {  
> \
>   * clean in kernel mode, with the possible exception of IOPL.  Kernel IOPL
>   * has no effect.
>   */
> -#define switch_to(prev, next, last) \
> +#define switch_to(prev, next, last)\
> + prepare_switch_to(prev, next);\
> +   \
>   asm volatile(SAVE_CONTEXT \
>"movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP */   \
>"movq %P[threadrsp](%[next]),%%rsp\n\t" /* restore RSP */\
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 00f03d82e69a..9cb7ea781176 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -292,12 +292,30 @@ DO_ERROR(X86_TRAP_NP, SIGBUS,  "segment not 
> present",   

Re: [PATCHv4 07/48] thermal: core: move passive attr to tz->device.groups

[Zhang Rui]

On 四, 2016-06-16 at 11:27 +0800, Zhang Rui wrote:
> On 一, 2016-05-30 at 23:18 -0700, Eduardo Valentin wrote:
> > 
> > This patch moves the passive attribute to tz->device.groups. Moving
> > the
> > passive attribute also requires a .is_visible() callback
> > implementation
> > for its attribute group.
> > 
> > The logic behind the visibility of passive attribute is kept the
> > same.
> > We only expose the passive attribute if the thermal driver has
> > exposed
> > at least one passive trip point.
> > 
> No, the passive attribute is only present for zones in which the
> passive cooling policy is not supported by native thermal driver.
> 
> > 
> > Cc: Zhang Rui 
> > Cc: linux...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Eduardo Valentin 
> > ---
> >  drivers/thermal/thermal_core.c | 42
> > +-
> >  1 file changed, 33 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/thermal/thermal_core.c
> > b/drivers/thermal/thermal_core.c
> > index 19fea9e..efc190c 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -1056,9 +1056,42 @@ static struct attribute_group
> > thermal_zone_mode_attribute_group = {
> >     .is_visible = thermal_zone_mode_is_visible,
> >  };
> >  
> > +/* We expose passive only if passive trips are present */
> > +static struct attribute *thermal_zone_passive_attrs[] = {
> > +   _attr_passive.attr,
> > +   NULL,
> > +};
> > +
> > +static umode_t thermal_zone_passive_is_visible(struct kobject
> > *kobj,
> > +      struct attribute
> > *attr,
> > +      int attrno)
> > +{
> > +   struct device *dev = container_of(kobj, struct device,
> > kobj);
> > +   struct thermal_zone_device *tz;
> > +   enum thermal_trip_type trip_type;
> > +   int count;
> > +
> > +   tz = container_of(dev, struct thermal_zone_device,
> > device);
> > +
> > +   for (count = 0; count < tz->trips; count++) {
> > +   tz->ops->get_trip_type(tz, count, _type);
> > +
> > +   if (trip_type == THERMAL_TRIP_PASSIVE)
> > +   return attr->mode;
> we should
>   return 0;
> > 
> > +   }
> > +
> > +   return 0;
> and
>   return attr->mode;
> 
refreshed patch attached, please review.
>From 98415315a7ce1027d2e788476980b7815d9e9627 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin 
Date: Mon, 30 May 2016 23:18:14 -0700
Subject: [PATCH] thermal: core: move passive attr to tz->device.groups

This patch moves the passive attribute to tz->device.groups. Moving the
passive attribute also requires a .is_visible() callback implementation
for its attribute group.

The logic behind the visibility of passive attribute is kept the same.
We only expose the passive attribute if the thermal driver has exposed
at least one passive trip point.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
Signed-off-by: Zhang Rui 
---
 drivers/thermal/thermal_core.c | 42 +-
 1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 19fea9e..40299a0 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1056,9 +1056,42 @@ static struct attribute_group 
thermal_zone_mode_attribute_group = {
    .is_visible = thermal_zone_mode_is_visible,
 };
 
+/* We expose passive only if passive trips are present */
+static struct attribute *thermal_zone_passive_attrs[] = {
+   _attr_passive.attr,
+   NULL,
+};
+
+static umode_t thermal_zone_passive_is_visible(struct kobject *kobj,
+      struct attribute *attr,
+      int attrno)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct thermal_zone_device *tz;
+   enum thermal_trip_type trip_type;
+   int count;
+
+   tz = container_of(dev, struct thermal_zone_device, device);
+
+   for (count = 0; count < tz->trips; count++) {
+   tz->ops->get_trip_type(tz, count, _type);
+
+   if (trip_type == THERMAL_TRIP_PASSIVE)
+   return 0;
+   }
+
+   return attr->mode;
+}
+
+static struct attribute_group thermal_zone_passive_attribute_group = {
+   .attrs = thermal_zone_passive_attrs,
+   .is_visible = thermal_zone_passive_is_visible,
+};
+
 static const struct attribute_group *thermal_zone_attribute_groups[] = {
    _zone_attribute_group,
    _zone_mode_attribute_group,
+   _zone_passive_attribute_group,
    NULL
 };
 
@@ -1843,7 +1876,6 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
    int trip_temp;
    int result;
  

Re: [PATCHv4 07/48] thermal: core: move passive attr to tz->device.groups

[Zhang Rui]

On 四, 2016-06-16 at 11:27 +0800, Zhang Rui wrote:
> On 一, 2016-05-30 at 23:18 -0700, Eduardo Valentin wrote:
> > 
> > This patch moves the passive attribute to tz->device.groups. Moving
> > the
> > passive attribute also requires a .is_visible() callback
> > implementation
> > for its attribute group.
> > 
> > The logic behind the visibility of passive attribute is kept the
> > same.
> > We only expose the passive attribute if the thermal driver has
> > exposed
> > at least one passive trip point.
> > 
> No, the passive attribute is only present for zones in which the
> passive cooling policy is not supported by native thermal driver.
> 
> > 
> > Cc: Zhang Rui 
> > Cc: linux...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Eduardo Valentin 
> > ---
> >  drivers/thermal/thermal_core.c | 42
> > +-
> >  1 file changed, 33 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/thermal/thermal_core.c
> > b/drivers/thermal/thermal_core.c
> > index 19fea9e..efc190c 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -1056,9 +1056,42 @@ static struct attribute_group
> > thermal_zone_mode_attribute_group = {
> >     .is_visible = thermal_zone_mode_is_visible,
> >  };
> >  
> > +/* We expose passive only if passive trips are present */
> > +static struct attribute *thermal_zone_passive_attrs[] = {
> > +   _attr_passive.attr,
> > +   NULL,
> > +};
> > +
> > +static umode_t thermal_zone_passive_is_visible(struct kobject
> > *kobj,
> > +      struct attribute
> > *attr,
> > +      int attrno)
> > +{
> > +   struct device *dev = container_of(kobj, struct device,
> > kobj);
> > +   struct thermal_zone_device *tz;
> > +   enum thermal_trip_type trip_type;
> > +   int count;
> > +
> > +   tz = container_of(dev, struct thermal_zone_device,
> > device);
> > +
> > +   for (count = 0; count < tz->trips; count++) {
> > +   tz->ops->get_trip_type(tz, count, _type);
> > +
> > +   if (trip_type == THERMAL_TRIP_PASSIVE)
> > +   return attr->mode;
> we should
>   return 0;
> > 
> > +   }
> > +
> > +   return 0;
> and
>   return attr->mode;
> 
refreshed patch attached, please review.
>From 98415315a7ce1027d2e788476980b7815d9e9627 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin 
Date: Mon, 30 May 2016 23:18:14 -0700
Subject: [PATCH] thermal: core: move passive attr to tz->device.groups

This patch moves the passive attribute to tz->device.groups. Moving the
passive attribute also requires a .is_visible() callback implementation
for its attribute group.

The logic behind the visibility of passive attribute is kept the same.
We only expose the passive attribute if the thermal driver has exposed
at least one passive trip point.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
Signed-off-by: Zhang Rui 
---
 drivers/thermal/thermal_core.c | 42 +-
 1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 19fea9e..40299a0 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1056,9 +1056,42 @@ static struct attribute_group 
thermal_zone_mode_attribute_group = {
    .is_visible = thermal_zone_mode_is_visible,
 };
 
+/* We expose passive only if passive trips are present */
+static struct attribute *thermal_zone_passive_attrs[] = {
+   _attr_passive.attr,
+   NULL,
+};
+
+static umode_t thermal_zone_passive_is_visible(struct kobject *kobj,
+      struct attribute *attr,
+      int attrno)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct thermal_zone_device *tz;
+   enum thermal_trip_type trip_type;
+   int count;
+
+   tz = container_of(dev, struct thermal_zone_device, device);
+
+   for (count = 0; count < tz->trips; count++) {
+   tz->ops->get_trip_type(tz, count, _type);
+
+   if (trip_type == THERMAL_TRIP_PASSIVE)
+   return 0;
+   }
+
+   return attr->mode;
+}
+
+static struct attribute_group thermal_zone_passive_attribute_group = {
+   .attrs = thermal_zone_passive_attrs,
+   .is_visible = thermal_zone_passive_is_visible,
+};
+
 static const struct attribute_group *thermal_zone_attribute_groups[] = {
    _zone_attribute_group,
    _zone_mode_attribute_group,
+   _zone_passive_attribute_group,
    NULL
 };
 
@@ -1843,7 +1876,6 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
    int trip_temp;
    int result;
    int count;
-   int passive = 0;
    struct thermal_governor *governor;
 
    if (!type || strlen(type) == 0)
@@ 

Re: [PATCH] mdio: mux: avoid 'maybe-uninitialized' warning

[David Miller]

From: Arnd Bergmann 
Date: Tue, 14 Jun 2016 12:03:17 +0200

> The latest changes to the MDIO code introduced a false-positive
> warning with gcc-6 (possibly others):
> 
> drivers/net/phy/mdio-mux.c: In function 'mdio_mux_init':
> drivers/net/phy/mdio-mux.c:188:3: error: 'parent_bus_node' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> It's easy to avoid the warning by making sure the parent_bus_node
> is initialized in both cases at the start of the function, since
> the later 'of_node_put()' call is also valid for a NULL pointer
> argument.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: f20e6657a875 ("mdio: mux: Enhanced MDIO mux framework for integrated 
> multiplexers")

Applied.

Re: [PATCH] mdio: mux: avoid 'maybe-uninitialized' warning

[David Miller]

From: Arnd Bergmann 
Date: Tue, 14 Jun 2016 12:03:17 +0200

> The latest changes to the MDIO code introduced a false-positive
> warning with gcc-6 (possibly others):
> 
> drivers/net/phy/mdio-mux.c: In function 'mdio_mux_init':
> drivers/net/phy/mdio-mux.c:188:3: error: 'parent_bus_node' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> It's easy to avoid the warning by making sure the parent_bus_node
> is initialized in both cases at the start of the function, since
> the later 'of_node_put()' call is also valid for a NULL pointer
> argument.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: f20e6657a875 ("mdio: mux: Enhanced MDIO mux framework for integrated 
> multiplexers")

Applied.

[git pull] drm fixes for rc4

[Dave Airlie]

Hi Linus,

Main drm fixes pull for rc4, one regression fix in the connector
refcounting, and an MST fix.

There rest is nouveau, amdkfd, i915, etnaviv, and radeon/amdgpu fixes,
mostly regression or black screen fixes.

Dave.

The following changes since commit 7ff6977be8e3c7e6f5ae1ee56bc1535c5ca653b1:

  Merge branch 'fixes-for-v4.7-rc3' of 
http://git.agner.ch/git/linux-drm-fsl-dcu into drm-fixes (2016-06-10 12:17:46 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.7-rc4

for you to fetch changes up to 0ab15bdeb2943bd6491a35ec4eeb53a9a4436525:

  Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-06-16 10:24:13 +1000)


Alex Deucher (3):
  drm/radeon: fix asic initialization for virtualized environments
  drm/amdgpu/gfx7: fix broken condition check
  Revert "drm/amdgpu: add pipeline sync while vmid switch in same ctx"

Ander Conselvan de Oliveira (1):
  drm/i915: Fix NULL pointer deference when out of PLLs in IVB

Andres Rodriguez (1):
  amdgpu: fix asic initialization for virtualized environments (v2)

Andrey Grodzovsky (1):
  drm/dp/mst: Always clear proposed vcpi table for port.

Ben Skeggs (1):
  drm/nouveau/iccsense: fix memory leak

Chris Wilson (2):
  drm/i915: Silence "unexpected child device config size" for VBT on 845g
  drm/i915: Only ignore eDP ports that are connected

Christian König (1):
  drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled

Dave Airlie (5):
  Merge tag 'drm-amdkfd-fixes-2016-06-03' of 
git://people.freedesktop.org/~gabbayo/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2016-06-14' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge branch 'linux-4.7' of git://github.com/skeggsb/linux into drm-fixes
  Merge branch 'drm-etnaviv-fixes' of 
git://git.pengutronix.de/git/lst/linux into drm-fixes
  Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Jérôme Glisse (1):
  drm/radeon: do not hard reset GPU while freezing on r600/r700 family

Lucas Stach (1):
  drm/etnaviv: initialize iommu domain page size

Lyude (1):
  drm/i915/ilk: Don't disable SSC source if it's in use

Oded Gabbay (3):
  drm/amdkfd: unbind only existing processes
  drm/amdkfd: destroy dbgmgr in notifier release
  drm/amdkfd: print once about mem_banks truncation

Philipp Zabel (2):
  drm/crtc: fix connector reference counting mismatch in 
drm_crtc_helper_set_config
  drm/crtc: only store the necessary data for set_config rollback

Rex Zhu (2):
  drm/amd/powerplay: update powerplay table parsing
  drm/amd/powerplay: select samu dpm 0 as boot level on polaris.

Robin Murphy (1):
  drm/nouveau/Revert "drm/nouveau/device/pci: set as non-CPU-coherent on 
ARM64"

Ville Syrjälä (2):
  drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV
  drm/i915: Extract physical display dimensions from VBT

 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 11 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |  9 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  6 +-
 drivers/gpu/drm/amd/amdgpu/cik.c   |  7 ++
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/vi.c| 15 
 drivers/gpu/drm/amd/amdkfd/kfd_process.c   | 70 ++---
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c  |  2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr_ppt.h|  1 +
 .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 28 ---
 .../gpu/drm/amd/powerplay/hwmgr/tonga_pptable.h| 16 
 .../amd/powerplay/hwmgr/tonga_processpptables.c| 91 +++---
 drivers/gpu/drm/drm_crtc_helper.c  | 54 ++---
 drivers/gpu/drm/drm_dp_mst_topology.c  |  8 +-
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c|  1 +
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/intel_bios.c  | 46 ++-
 drivers/gpu/drm/i915/intel_display.c   | 88 ++---
 drivers/gpu/drm/i915/intel_dp.c| 18 +++--
 drivers/gpu/drm/i915/intel_dpll_mgr.c  |  3 +
 drivers/gpu/drm/i915/intel_drv.h   |  2 +-
 drivers/gpu/drm/i915/intel_dsi.c   |  3 +
 drivers/gpu/drm/i915/intel_hdmi.c  |  3 +
 drivers/gpu/drm/i915/intel_lvds.c  |  2 +
 drivers/gpu/drm/i915/intel_vbt_defs.h  |  7 +-
 drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c   |  2 +-
 .../gpu/drm/nouveau/nvkm/subdev/iccsense/base.c| 16 ++--
 drivers/gpu/drm/radeon/atombios_crtc.c |  5 +-
 drivers/gpu/drm/radeon/radeon_device.c | 

[git pull] drm fixes for rc4

[Dave Airlie]

Hi Linus,

Main drm fixes pull for rc4, one regression fix in the connector
refcounting, and an MST fix.

There rest is nouveau, amdkfd, i915, etnaviv, and radeon/amdgpu fixes,
mostly regression or black screen fixes.

Dave.

The following changes since commit 7ff6977be8e3c7e6f5ae1ee56bc1535c5ca653b1:

  Merge branch 'fixes-for-v4.7-rc3' of 
http://git.agner.ch/git/linux-drm-fsl-dcu into drm-fixes (2016-06-10 12:17:46 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.7-rc4

for you to fetch changes up to 0ab15bdeb2943bd6491a35ec4eeb53a9a4436525:

  Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-06-16 10:24:13 +1000)


Alex Deucher (3):
  drm/radeon: fix asic initialization for virtualized environments
  drm/amdgpu/gfx7: fix broken condition check
  Revert "drm/amdgpu: add pipeline sync while vmid switch in same ctx"

Ander Conselvan de Oliveira (1):
  drm/i915: Fix NULL pointer deference when out of PLLs in IVB

Andres Rodriguez (1):
  amdgpu: fix asic initialization for virtualized environments (v2)

Andrey Grodzovsky (1):
  drm/dp/mst: Always clear proposed vcpi table for port.

Ben Skeggs (1):
  drm/nouveau/iccsense: fix memory leak

Chris Wilson (2):
  drm/i915: Silence "unexpected child device config size" for VBT on 845g
  drm/i915: Only ignore eDP ports that are connected

Christian König (1):
  drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled

Dave Airlie (5):
  Merge tag 'drm-amdkfd-fixes-2016-06-03' of 
git://people.freedesktop.org/~gabbayo/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2016-06-14' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge branch 'linux-4.7' of git://github.com/skeggsb/linux into drm-fixes
  Merge branch 'drm-etnaviv-fixes' of 
git://git.pengutronix.de/git/lst/linux into drm-fixes
  Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Jérôme Glisse (1):
  drm/radeon: do not hard reset GPU while freezing on r600/r700 family

Lucas Stach (1):
  drm/etnaviv: initialize iommu domain page size

Lyude (1):
  drm/i915/ilk: Don't disable SSC source if it's in use

Oded Gabbay (3):
  drm/amdkfd: unbind only existing processes
  drm/amdkfd: destroy dbgmgr in notifier release
  drm/amdkfd: print once about mem_banks truncation

Philipp Zabel (2):
  drm/crtc: fix connector reference counting mismatch in 
drm_crtc_helper_set_config
  drm/crtc: only store the necessary data for set_config rollback

Rex Zhu (2):
  drm/amd/powerplay: update powerplay table parsing
  drm/amd/powerplay: select samu dpm 0 as boot level on polaris.

Robin Murphy (1):
  drm/nouveau/Revert "drm/nouveau/device/pci: set as non-CPU-coherent on 
ARM64"

Ville Syrjälä (2):
  drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV
  drm/i915: Extract physical display dimensions from VBT

 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 11 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |  9 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  6 +-
 drivers/gpu/drm/amd/amdgpu/cik.c   |  7 ++
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/vi.c| 15 
 drivers/gpu/drm/amd/amdkfd/kfd_process.c   | 70 ++---
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c  |  2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr_ppt.h|  1 +
 .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 28 ---
 .../gpu/drm/amd/powerplay/hwmgr/tonga_pptable.h| 16 
 .../amd/powerplay/hwmgr/tonga_processpptables.c| 91 +++---
 drivers/gpu/drm/drm_crtc_helper.c  | 54 ++---
 drivers/gpu/drm/drm_dp_mst_topology.c  |  8 +-
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c|  1 +
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/intel_bios.c  | 46 ++-
 drivers/gpu/drm/i915/intel_display.c   | 88 ++---
 drivers/gpu/drm/i915/intel_dp.c| 18 +++--
 drivers/gpu/drm/i915/intel_dpll_mgr.c  |  3 +
 drivers/gpu/drm/i915/intel_drv.h   |  2 +-
 drivers/gpu/drm/i915/intel_dsi.c   |  3 +
 drivers/gpu/drm/i915/intel_hdmi.c  |  3 +
 drivers/gpu/drm/i915/intel_lvds.c  |  2 +
 drivers/gpu/drm/i915/intel_vbt_defs.h  |  7 +-
 drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c   |  2 +-
 .../gpu/drm/nouveau/nvkm/subdev/iccsense/base.c| 16 ++--
 drivers/gpu/drm/radeon/atombios_crtc.c |  5 +-
 drivers/gpu/drm/radeon/radeon_device.c | 

[PATCH] mm: memcontrol: fix cgroup creation failure after many small jobs

[Johannes Weiner]

The memory controller has quite a bit of state that usually outlives
the cgroup and pins its CSS until said state disappears. At the same
time it imposes a 16-bit limit on the CSS ID space to economically
store IDs in the wild. Consequently, when we use cgroups to contain
frequent but small and short-lived jobs that leave behind some page
cache, we quickly run into the 64k limitations of outstanding CSSs.
Creating a new cgroup fails with -ENOSPC while there are only a few,
or even no user-visible cgroups in existence.

Although pinning CSSs past cgroup removal is common, there are only
two instances that actually need a CSS ID after a cgroup is deleted:
cache shadow entries and swapout records.

Cache shadow entries reference the ID weakly and can deal with the CSS
having disappeared when it's looked up later. They pose no hurdle.

Swap-out records do need to pin the css to hierarchically attribute
swapins after the cgroup has been deleted; though the only pages that
remain swapped out after a process exits are tmpfs/shmem pages. Those
references are under the user's control and thus manageable.

This patch introduces a private 16bit memcg ID and switches swap and
cache shadow entries over to using that. It then decouples the CSS
lifetime from the CSS ID lifetime, such that a CSS ID can be recycled
when the CSS is only pinned by common objects that don't need an ID.

This script demonstrates the problem by faulting one cache page in a
new cgroup and deleting it again:

set -e
mkdir -p pages
for x in `seq 128000`; do
  [ $((x % 1000)) -eq 0 ] && echo $x
  mkdir /cgroup/foo
  echo $$ >/cgroup/foo/cgroup.procs
  echo trex >pages/$x
  echo $$ >/cgroup/cgroup.procs
  rmdir /cgroup/foo
done

When run on an unpatched kernel, we eventually run out of possible CSS
IDs even though there is no visible cgroup existing anymore:

[root@ham ~]# ./cssidstress.sh
[...]
65000
mkdir: cannot create directory '/cgroup/foo': No space left on device

After this patch, the CSS IDs get released upon cgroup destruction and
the cache and css objects get released once memory reclaim kicks in.

Signed-off-by: Johannes Weiner 
---
 include/linux/cgroup.h |  3 ++-
 include/linux/memcontrol.h | 25 +
 kernel/cgroup.c| 22 --
 mm/memcontrol.c| 56 --
 mm/slab_common.c   |  4 ++--
 5 files changed, 83 insertions(+), 27 deletions(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index a20320c666fd..6510bf291d36 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -85,9 +85,10 @@ struct cgroup_subsys_state *cgroup_get_e_css(struct cgroup 
*cgroup,
 struct cgroup_subsys *ss);
 struct cgroup_subsys_state *css_tryget_online_from_dir(struct dentry *dentry,
   struct cgroup_subsys 
*ss);
-
 struct cgroup *cgroup_get_from_path(const char *path);
 
+void css_id_free(struct cgroup_subsys_state *css);
+
 int cgroup_attach_task_all(struct task_struct *from, struct task_struct *);
 int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from);
 
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index a805474df4ab..56e6069d2452 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -97,6 +97,11 @@ enum mem_cgroup_events_target {
 #define MEM_CGROUP_ID_SHIFT16
 #define MEM_CGROUP_ID_MAX  USHRT_MAX
 
+struct mem_cgroup_id {
+   int id;
+   atomic_t ref;
+};
+
 struct mem_cgroup_stat_cpu {
long count[MEMCG_NR_STAT];
unsigned long events[MEMCG_NR_EVENTS];
@@ -172,6 +177,9 @@ enum memcg_kmem_state {
 struct mem_cgroup {
struct cgroup_subsys_state css;
 
+   /* Private memcg ID. Used to ID objects that outlive the cgroup */
+   struct mem_cgroup_id id;
+
/* Accounted resources */
struct page_counter memory;
struct page_counter swap;
@@ -330,22 +338,9 @@ static inline unsigned short mem_cgroup_id(struct 
mem_cgroup *memcg)
if (mem_cgroup_disabled())
return 0;
 
-   return memcg->css.id;
-}
-
-/**
- * mem_cgroup_from_id - look up a memcg from an id
- * @id: the id to look up
- *
- * Caller must hold rcu_read_lock() and use css_tryget() as necessary.
- */
-static inline struct mem_cgroup *mem_cgroup_from_id(unsigned short id)
-{
-   struct cgroup_subsys_state *css;
-
-   css = css_from_id(id, _cgrp_subsys);
-   return mem_cgroup_from_css(css);
+   return memcg->id.id;
 }
+struct mem_cgroup *mem_cgroup_from_id(unsigned short id);
 
 /**
  * parent_mem_cgroup - find the accounting parent of a memcg
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 86cb5c6e8932..2e4aff6fd6ec 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4961,10 +4961,10 @@ static void css_free_work_fn(struct work_struct *work)
if (ss) {
/* css free 

[PATCH] mm: memcontrol: fix cgroup creation failure after many small jobs

[Johannes Weiner]

The memory controller has quite a bit of state that usually outlives
the cgroup and pins its CSS until said state disappears. At the same
time it imposes a 16-bit limit on the CSS ID space to economically
store IDs in the wild. Consequently, when we use cgroups to contain
frequent but small and short-lived jobs that leave behind some page
cache, we quickly run into the 64k limitations of outstanding CSSs.
Creating a new cgroup fails with -ENOSPC while there are only a few,
or even no user-visible cgroups in existence.

Although pinning CSSs past cgroup removal is common, there are only
two instances that actually need a CSS ID after a cgroup is deleted:
cache shadow entries and swapout records.

Cache shadow entries reference the ID weakly and can deal with the CSS
having disappeared when it's looked up later. They pose no hurdle.

Swap-out records do need to pin the css to hierarchically attribute
swapins after the cgroup has been deleted; though the only pages that
remain swapped out after a process exits are tmpfs/shmem pages. Those
references are under the user's control and thus manageable.

This patch introduces a private 16bit memcg ID and switches swap and
cache shadow entries over to using that. It then decouples the CSS
lifetime from the CSS ID lifetime, such that a CSS ID can be recycled
when the CSS is only pinned by common objects that don't need an ID.

This script demonstrates the problem by faulting one cache page in a
new cgroup and deleting it again:

set -e
mkdir -p pages
for x in `seq 128000`; do
  [ $((x % 1000)) -eq 0 ] && echo $x
  mkdir /cgroup/foo
  echo $$ >/cgroup/foo/cgroup.procs
  echo trex >pages/$x
  echo $$ >/cgroup/cgroup.procs
  rmdir /cgroup/foo
done

When run on an unpatched kernel, we eventually run out of possible CSS
IDs even though there is no visible cgroup existing anymore:

[root@ham ~]# ./cssidstress.sh
[...]
65000
mkdir: cannot create directory '/cgroup/foo': No space left on device

After this patch, the CSS IDs get released upon cgroup destruction and
the cache and css objects get released once memory reclaim kicks in.

Signed-off-by: Johannes Weiner 
---
 include/linux/cgroup.h |  3 ++-
 include/linux/memcontrol.h | 25 +
 kernel/cgroup.c| 22 --
 mm/memcontrol.c| 56 --
 mm/slab_common.c   |  4 ++--
 5 files changed, 83 insertions(+), 27 deletions(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index a20320c666fd..6510bf291d36 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -85,9 +85,10 @@ struct cgroup_subsys_state *cgroup_get_e_css(struct cgroup 
*cgroup,
 struct cgroup_subsys *ss);
 struct cgroup_subsys_state *css_tryget_online_from_dir(struct dentry *dentry,
   struct cgroup_subsys 
*ss);
-
 struct cgroup *cgroup_get_from_path(const char *path);
 
+void css_id_free(struct cgroup_subsys_state *css);
+
 int cgroup_attach_task_all(struct task_struct *from, struct task_struct *);
 int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from);
 
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index a805474df4ab..56e6069d2452 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -97,6 +97,11 @@ enum mem_cgroup_events_target {
 #define MEM_CGROUP_ID_SHIFT16
 #define MEM_CGROUP_ID_MAX  USHRT_MAX
 
+struct mem_cgroup_id {
+   int id;
+   atomic_t ref;
+};
+
 struct mem_cgroup_stat_cpu {
long count[MEMCG_NR_STAT];
unsigned long events[MEMCG_NR_EVENTS];
@@ -172,6 +177,9 @@ enum memcg_kmem_state {
 struct mem_cgroup {
struct cgroup_subsys_state css;
 
+   /* Private memcg ID. Used to ID objects that outlive the cgroup */
+   struct mem_cgroup_id id;
+
/* Accounted resources */
struct page_counter memory;
struct page_counter swap;
@@ -330,22 +338,9 @@ static inline unsigned short mem_cgroup_id(struct 
mem_cgroup *memcg)
if (mem_cgroup_disabled())
return 0;
 
-   return memcg->css.id;
-}
-
-/**
- * mem_cgroup_from_id - look up a memcg from an id
- * @id: the id to look up
- *
- * Caller must hold rcu_read_lock() and use css_tryget() as necessary.
- */
-static inline struct mem_cgroup *mem_cgroup_from_id(unsigned short id)
-{
-   struct cgroup_subsys_state *css;
-
-   css = css_from_id(id, _cgrp_subsys);
-   return mem_cgroup_from_css(css);
+   return memcg->id.id;
 }
+struct mem_cgroup *mem_cgroup_from_id(unsigned short id);
 
 /**
  * parent_mem_cgroup - find the accounting parent of a memcg
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 86cb5c6e8932..2e4aff6fd6ec 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4961,10 +4961,10 @@ static void css_free_work_fn(struct work_struct *work)
if (ss) {
/* css free path */
   

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

[Anshuman Khandual]

On 06/16/2016 05:56 AM, Minchan Kim wrote:
> On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
>> On 06/15/2016 08:02 AM, Minchan Kim wrote:
>>> Hi,
>>>
>>> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
> On 05/31/2016 05:31 AM, Minchan Kim wrote:
>>> @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, 
>>> struct page *newpage,
>>> int rc = -EAGAIN;
>>> int page_was_mapped = 0;
>>> struct anon_vma *anon_vma = NULL;
>>> +   bool is_lru = !__PageMovable(page);
>>>  
>>> if (!trylock_page(page)) {
>>> if (!force || mode == MIGRATE_ASYNC)
>>> @@ -871,6 +1002,11 @@ static int __unmap_and_move(struct page *page, 
>>> struct page *newpage,
>>> goto out_unlock_both;
>>> }
>>>  
>>> +   if (unlikely(!is_lru)) {
>>> +   rc = move_to_new_page(newpage, page, mode);
>>> +   goto out_unlock_both;
>>> +   }
>>> +
>
> Hello Minchan,
>
> I might be missing something here but does this implementation support the
> scenario where these non LRU pages owned by the driver mapped as PTE into
> process page table ? Because the "goto out_unlock_both" statement above
> skips all the PTE unmap, putting a migration PTE and removing the 
> migration
> PTE steps.
>>> You're right. Unfortunately, it doesn't support right now but surely,
>>> it's my TODO after landing this work.
>>>
>>> Could you share your usecase?
>>
>> Sure.
> 
> Thanks a lot!
> 
>>
>> My driver has privately managed non LRU pages which gets mapped into user 
>> space
>> process page table through f_ops->mmap() and vmops->fault() which then 
>> updates
>> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One 
>> thing
> 
> Hmm, page_add_file_rmap is not exported function. How does your driver can 
> use it?

Its not using the function directly, I just re-iterated the sequence of 
functions
above. (do_set_pte -> page_add_file_rmap) gets called after we grab the page 
from
driver through (__do_fault->vma->vm_ops->fault()).

> Do you use vm_insert_pfn?
> What type your vma is? VM_PFNMMAP or VM_MIXEDMAP?

I dont use vm_insert_pfn(). Here is the sequence of events how the user space
VMA gets the non LRU pages from the driver.

- Driver registers a character device with 'struct file_operations' binding
- Then the 'fops->mmap()' just binds the incoming 'struct vma' with a 'struct
  vm_operations_struct' which provides the 'vmops->fault()' routine which
  basically traps all page faults on the VMA and provides one page at a time
  through a driver specific allocation routine which hands over non LRU pages

The VMA is not anything special as such. Its what we get when we try to do a
simple mmap() on a file descriptor pointing to a character device. I can
figure out all the VM_* flags it holds after creation.

> 
> I want to make dummy driver to simulate your case.

Sure. I hope the above mentioned steps will help you but in case you need more
information, please do let me know.

> It would be very helpful to implement/test pte-mapped non-lru page
> migration feature. That's why I ask now.
> 
>> to note here is that the page->mapping eventually points to struct 
>> address_space
>> (file->f_mapping) which belongs to the character device file (created using 
>> mknod)
>> which we are using for establishing the mmap() regions in the user space.
>>
>> Now as per this new framework, all the page's are to be made 
>> __SetPageMovable before
>> passing the list down to migrate_pages(). Now __SetPageMovable() takes *new* 
>> struct
>> address_space as an argument and replaces the existing page->mapping. Now 
>> thats the
>> problem, we have lost all our connection to the existing file RMAP 
>> information. This
> 
> We could change __SetPageMovable doesn't need mapping argument.
> Instead, it just marks PAGE_MAPPING_MOVABLE into page->mapping.
> For that, user should take care of setting page->mapping earlier than
> marking the flag.

Sounds like a good idea, that way we dont loose the reverse mapping information.

> 
>> stands as a problem when we try to migrate these non LRU pages which are PTE 
>> mapped.
>> The rmap_walk_file() never finds them in the VMA, skips all the migrate PTE 
>> steps and
>> then the migration eventually fails.
>>
>> Seems like assigning a new struct address_space to the page through 
>> __SetPageMovable()
>> is the source of the problem. Can it take the existing (file->f_mapping) as 
>> an argument

> We can set existing file->f_mapping under the page_lock.

Thats another option along with what you mentioned above.

> 
>> in there ? Sure, but then can we override file system generic ->isolate(), 
>> ->putback(),
> 
> I don't get it. Why does it override file system generic functions?

Sure it does not, it was just an wild idea to over come the problem.

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

[Anshuman Khandual]

On 06/16/2016 05:56 AM, Minchan Kim wrote:
> On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
>> On 06/15/2016 08:02 AM, Minchan Kim wrote:
>>> Hi,
>>>
>>> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
> On 05/31/2016 05:31 AM, Minchan Kim wrote:
>>> @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, 
>>> struct page *newpage,
>>> int rc = -EAGAIN;
>>> int page_was_mapped = 0;
>>> struct anon_vma *anon_vma = NULL;
>>> +   bool is_lru = !__PageMovable(page);
>>>  
>>> if (!trylock_page(page)) {
>>> if (!force || mode == MIGRATE_ASYNC)
>>> @@ -871,6 +1002,11 @@ static int __unmap_and_move(struct page *page, 
>>> struct page *newpage,
>>> goto out_unlock_both;
>>> }
>>>  
>>> +   if (unlikely(!is_lru)) {
>>> +   rc = move_to_new_page(newpage, page, mode);
>>> +   goto out_unlock_both;
>>> +   }
>>> +
>
> Hello Minchan,
>
> I might be missing something here but does this implementation support the
> scenario where these non LRU pages owned by the driver mapped as PTE into
> process page table ? Because the "goto out_unlock_both" statement above
> skips all the PTE unmap, putting a migration PTE and removing the 
> migration
> PTE steps.
>>> You're right. Unfortunately, it doesn't support right now but surely,
>>> it's my TODO after landing this work.
>>>
>>> Could you share your usecase?
>>
>> Sure.
> 
> Thanks a lot!
> 
>>
>> My driver has privately managed non LRU pages which gets mapped into user 
>> space
>> process page table through f_ops->mmap() and vmops->fault() which then 
>> updates
>> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One 
>> thing
> 
> Hmm, page_add_file_rmap is not exported function. How does your driver can 
> use it?

Its not using the function directly, I just re-iterated the sequence of 
functions
above. (do_set_pte -> page_add_file_rmap) gets called after we grab the page 
from
driver through (__do_fault->vma->vm_ops->fault()).

> Do you use vm_insert_pfn?
> What type your vma is? VM_PFNMMAP or VM_MIXEDMAP?

I dont use vm_insert_pfn(). Here is the sequence of events how the user space
VMA gets the non LRU pages from the driver.

- Driver registers a character device with 'struct file_operations' binding
- Then the 'fops->mmap()' just binds the incoming 'struct vma' with a 'struct
  vm_operations_struct' which provides the 'vmops->fault()' routine which
  basically traps all page faults on the VMA and provides one page at a time
  through a driver specific allocation routine which hands over non LRU pages

The VMA is not anything special as such. Its what we get when we try to do a
simple mmap() on a file descriptor pointing to a character device. I can
figure out all the VM_* flags it holds after creation.

> 
> I want to make dummy driver to simulate your case.

Sure. I hope the above mentioned steps will help you but in case you need more
information, please do let me know.

> It would be very helpful to implement/test pte-mapped non-lru page
> migration feature. That's why I ask now.
> 
>> to note here is that the page->mapping eventually points to struct 
>> address_space
>> (file->f_mapping) which belongs to the character device file (created using 
>> mknod)
>> which we are using for establishing the mmap() regions in the user space.
>>
>> Now as per this new framework, all the page's are to be made 
>> __SetPageMovable before
>> passing the list down to migrate_pages(). Now __SetPageMovable() takes *new* 
>> struct
>> address_space as an argument and replaces the existing page->mapping. Now 
>> thats the
>> problem, we have lost all our connection to the existing file RMAP 
>> information. This
> 
> We could change __SetPageMovable doesn't need mapping argument.
> Instead, it just marks PAGE_MAPPING_MOVABLE into page->mapping.
> For that, user should take care of setting page->mapping earlier than
> marking the flag.

Sounds like a good idea, that way we dont loose the reverse mapping information.

> 
>> stands as a problem when we try to migrate these non LRU pages which are PTE 
>> mapped.
>> The rmap_walk_file() never finds them in the VMA, skips all the migrate PTE 
>> steps and
>> then the migration eventually fails.
>>
>> Seems like assigning a new struct address_space to the page through 
>> __SetPageMovable()
>> is the source of the problem. Can it take the existing (file->f_mapping) as 
>> an argument

> We can set existing file->f_mapping under the page_lock.

Thats another option along with what you mentioned above.

> 
>> in there ? Sure, but then can we override file system generic ->isolate(), 
>> ->putback(),
> 
> I don't get it. Why does it override file system generic functions?

Sure it does not, it was just an wild idea to over come the problem.

Re: [rfc patch] sched/fair: Use instantaneous load for fork/exec balancing

[Mike Galbraith]

On Wed, 2016-06-15 at 20:03 +0100, Dietmar Eggemann wrote:

> Isn't there a theoretical problem with the scale_load() on CONFIG_64BIT
> machines on tip/sched/core? load.weight has a higher resolution than
> runnable_load_avg (and so the values in the rq->cpu_load[] array).
> Theoretically because [forkexec|wake]_idx is 0 so [target|source]_load()
> is nothing else than weighted_cpuload().

I see a not so theoretical problem with my rfc in that I forgot to
scale_load_down() if that's what you mean.

(changes nothing, reality was just extra special unadulterated;)

-Mike  

Re: [rfc patch] sched/fair: Use instantaneous load for fork/exec balancing

[Mike Galbraith]

On Wed, 2016-06-15 at 20:03 +0100, Dietmar Eggemann wrote:

> Isn't there a theoretical problem with the scale_load() on CONFIG_64BIT
> machines on tip/sched/core? load.weight has a higher resolution than
> runnable_load_avg (and so the values in the rq->cpu_load[] array).
> Theoretically because [forkexec|wake]_idx is 0 so [target|source]_load()
> is nothing else than weighted_cpuload().

I see a not so theoretical problem with my rfc in that I forgot to
scale_load_down() if that's what you mean.

(changes nothing, reality was just extra special unadulterated;)

-Mike  

Re: [PATCH V2] libata:fix kernel panic when hotplug

[kbuild test robot]

Hi,

[auto build test ERROR on tj-libata/for-next]
[also build test ERROR on v4.7-rc3 next-20160615]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/DingXiang/libata-fix-kernel-panic-when-hotplug/20160616-105155
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tj/libata for-next
config: x86_64-randconfig-s5-06161042 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/ata/libata-eh.c: In function 'ata_scsi_port_error_handler':
>> drivers/ata/libata-eh.c:820:19: error: 'ATA_PFLAG_SAS_HOST' undeclared 
>> (first use in this function)
   !(ap->pflags & ATA_PFLAG_SAS_HOST))
  ^~
   drivers/ata/libata-eh.c:820:19: note: each undeclared identifier is reported 
only once for each function it appears in

vim +/ATA_PFLAG_SAS_HOST +820 drivers/ata/libata-eh.c

   814  /* clean up */
   815  spin_lock_irqsave(ap->lock, flags);
   816  
   817  if (ap->pflags & ATA_PFLAG_LOADING)
   818  ap->pflags &= ~ATA_PFLAG_LOADING;
   819  else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
 > 820   !(ap->pflags & ATA_PFLAG_SAS_HOST))
   821  schedule_delayed_work(>hotplug_task, 0);
   822  
   823  if (ap->pflags & ATA_PFLAG_RECOVERED)

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


.config.gz
Description: Binary data

Re: [PATCH V2] libata:fix kernel panic when hotplug

[kbuild test robot]

Hi,

[auto build test ERROR on tj-libata/for-next]
[also build test ERROR on v4.7-rc3 next-20160615]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/DingXiang/libata-fix-kernel-panic-when-hotplug/20160616-105155
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tj/libata for-next
config: x86_64-randconfig-s5-06161042 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/ata/libata-eh.c: In function 'ata_scsi_port_error_handler':
>> drivers/ata/libata-eh.c:820:19: error: 'ATA_PFLAG_SAS_HOST' undeclared 
>> (first use in this function)
   !(ap->pflags & ATA_PFLAG_SAS_HOST))
  ^~
   drivers/ata/libata-eh.c:820:19: note: each undeclared identifier is reported 
only once for each function it appears in

vim +/ATA_PFLAG_SAS_HOST +820 drivers/ata/libata-eh.c

   814  /* clean up */
   815  spin_lock_irqsave(ap->lock, flags);
   816  
   817  if (ap->pflags & ATA_PFLAG_LOADING)
   818  ap->pflags &= ~ATA_PFLAG_LOADING;
   819  else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
 > 820   !(ap->pflags & ATA_PFLAG_SAS_HOST))
   821  schedule_delayed_work(>hotplug_task, 0);
   822  
   823  if (ap->pflags & ATA_PFLAG_RECOVERED)

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


.config.gz
Description: Binary data

Re: [PATCHv4 07/48] thermal: core: move passive attr to tz->device.groups

[Zhang Rui]

On 一, 2016-05-30 at 23:18 -0700, Eduardo Valentin wrote:
> This patch moves the passive attribute to tz->device.groups. Moving
> the
> passive attribute also requires a .is_visible() callback
> implementation
> for its attribute group.
> 
> The logic behind the visibility of passive attribute is kept the
> same.
> We only expose the passive attribute if the thermal driver has
> exposed
> at least one passive trip point.
> 
No, the passive attribute is only present for zones in which the
passive cooling policy is not supported by native thermal driver.

> Cc: Zhang Rui 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/thermal_core.c | 42
> +-
>  1 file changed, 33 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> index 19fea9e..efc190c 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1056,9 +1056,42 @@ static struct attribute_group
> thermal_zone_mode_attribute_group = {
>   .is_visible = thermal_zone_mode_is_visible,
>  };
>  
> +/* We expose passive only if passive trips are present */
> +static struct attribute *thermal_zone_passive_attrs[] = {
> + _attr_passive.attr,
> + NULL,
> +};
> +
> +static umode_t thermal_zone_passive_is_visible(struct kobject *kobj,
> +    struct attribute
> *attr,
> +    int attrno)
> +{
> + struct device *dev = container_of(kobj, struct device,
> kobj);
> + struct thermal_zone_device *tz;
> + enum thermal_trip_type trip_type;
> + int count;
> +
> + tz = container_of(dev, struct thermal_zone_device, device);
> +
> + for (count = 0; count < tz->trips; count++) {
> + tz->ops->get_trip_type(tz, count, _type);
> +
> + if (trip_type == THERMAL_TRIP_PASSIVE)
> + return attr->mode;
we should
return 0;
> + }
> +
> + return 0;
and
return attr->mode;

thanks,
rui
> +}
> +
> +static struct attribute_group thermal_zone_passive_attribute_group =
> {
> + .attrs = thermal_zone_passive_attrs,
> + .is_visible = thermal_zone_passive_is_visible,
> +};
> +
>  static const struct attribute_group *thermal_zone_attribute_groups[]
> = {
>   _zone_attribute_group,
>   _zone_mode_attribute_group,
> + _zone_passive_attribute_group,
>   NULL
>  };
>  
> @@ -1843,7 +1876,6 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
>   int trip_temp;
>   int result;
>   int count;
> - int passive = 0;
>   struct thermal_governor *governor;
>  
>   if (!type || strlen(type) == 0)
> @@ -1904,8 +1936,6 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
>   for (count = 0; count < trips; count++) {
>   if (tz->ops->get_trip_type(tz, count, _type))
>   set_bit(count, >trips_disabled);
> - if (trip_type == THERMAL_TRIP_PASSIVE)
> - passive = 1;
>   if (tz->ops->get_trip_temp(tz, count, _temp))
>   set_bit(count, >trips_disabled);
>   /* Check for bogus trip points */
> @@ -1913,12 +1943,6 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
>   set_bit(count, >trips_disabled);
>   }
>  
> - if (!passive) {
> - result = device_create_file(>device,
> _attr_passive);
> - if (result)
> - goto unregister;
> - }
> -
>   /* Update 'this' zone's governor information */
>   mutex_lock(_governor_lock);
>  

Re: [PATCHv4 07/48] thermal: core: move passive attr to tz->device.groups

[Zhang Rui]

On 一, 2016-05-30 at 23:18 -0700, Eduardo Valentin wrote:
> This patch moves the passive attribute to tz->device.groups. Moving
> the
> passive attribute also requires a .is_visible() callback
> implementation
> for its attribute group.
> 
> The logic behind the visibility of passive attribute is kept the
> same.
> We only expose the passive attribute if the thermal driver has
> exposed
> at least one passive trip point.
> 
No, the passive attribute is only present for zones in which the
passive cooling policy is not supported by native thermal driver.

> Cc: Zhang Rui 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/thermal_core.c | 42
> +-
>  1 file changed, 33 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> index 19fea9e..efc190c 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1056,9 +1056,42 @@ static struct attribute_group
> thermal_zone_mode_attribute_group = {
>   .is_visible = thermal_zone_mode_is_visible,
>  };
>  
> +/* We expose passive only if passive trips are present */
> +static struct attribute *thermal_zone_passive_attrs[] = {
> + _attr_passive.attr,
> + NULL,
> +};
> +
> +static umode_t thermal_zone_passive_is_visible(struct kobject *kobj,
> +    struct attribute
> *attr,
> +    int attrno)
> +{
> + struct device *dev = container_of(kobj, struct device,
> kobj);
> + struct thermal_zone_device *tz;
> + enum thermal_trip_type trip_type;
> + int count;
> +
> + tz = container_of(dev, struct thermal_zone_device, device);
> +
> + for (count = 0; count < tz->trips; count++) {
> + tz->ops->get_trip_type(tz, count, _type);
> +
> + if (trip_type == THERMAL_TRIP_PASSIVE)
> + return attr->mode;
we should
return 0;
> + }
> +
> + return 0;
and
return attr->mode;

thanks,
rui
> +}
> +
> +static struct attribute_group thermal_zone_passive_attribute_group =
> {
> + .attrs = thermal_zone_passive_attrs,
> + .is_visible = thermal_zone_passive_is_visible,
> +};
> +
>  static const struct attribute_group *thermal_zone_attribute_groups[]
> = {
>   _zone_attribute_group,
>   _zone_mode_attribute_group,
> + _zone_passive_attribute_group,
>   NULL
>  };
>  
> @@ -1843,7 +1876,6 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
>   int trip_temp;
>   int result;
>   int count;
> - int passive = 0;
>   struct thermal_governor *governor;
>  
>   if (!type || strlen(type) == 0)
> @@ -1904,8 +1936,6 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
>   for (count = 0; count < trips; count++) {
>   if (tz->ops->get_trip_type(tz, count, _type))
>   set_bit(count, >trips_disabled);
> - if (trip_type == THERMAL_TRIP_PASSIVE)
> - passive = 1;
>   if (tz->ops->get_trip_temp(tz, count, _temp))
>   set_bit(count, >trips_disabled);
>   /* Check for bogus trip points */
> @@ -1913,12 +1943,6 @@ struct thermal_zone_device
> *thermal_zone_device_register(const char *type,
>   set_bit(count, >trips_disabled);
>   }
>  
> - if (!passive) {
> - result = device_create_file(>device,
> _attr_passive);
> - if (result)
> - goto unregister;
> - }
> -
>   /* Update 'this' zone's governor information */
>   mutex_lock(_governor_lock);
>  

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

[Darren Hart]

On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali Rohár wrote:
> First patch describe problem about 0xe045 code. Second and third are just
> cosmetic and last rework code which processing WMI events. It should be
> properly tested on more Dell machines, to check that everything is still
> working correctly.

Is this "should be properly tested on more Dell machines" still the case? Are
you ready for this to go into linux-next?

> 
> Changes since v2:
> * Updated description for 2/4 and 4/4
> * Fixed comments over 80 characters in 2/4 and 4/4
> * Use switch fall-through in 4/4
> * Added Michał's Reviewed-by line
> 
> Changes since v1:
> * Fixed comments
> * Fixed memory leak
> * Added Tested-By lines
> * Added event 0xe06e
> 
> Pali Rohár (4):
>   dell-wmi: Ignore WMI event code 0xe045
>   dell-wmi: Sort WMI event codes and update comments
>   dell-wmi: Add information about other WMI event codes
>   dell-wmi: Generate one sparse keymap for all machines
> 
>  drivers/platform/x86/dell-wmi.c |  290 
> ++-
>  1 file changed, 166 insertions(+), 124 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

[Darren Hart]

On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali Rohár wrote:
> First patch describe problem about 0xe045 code. Second and third are just
> cosmetic and last rework code which processing WMI events. It should be
> properly tested on more Dell machines, to check that everything is still
> working correctly.

Is this "should be properly tested on more Dell machines" still the case? Are
you ready for this to go into linux-next?

> 
> Changes since v2:
> * Updated description for 2/4 and 4/4
> * Fixed comments over 80 characters in 2/4 and 4/4
> * Use switch fall-through in 4/4
> * Added Michał's Reviewed-by line
> 
> Changes since v1:
> * Fixed comments
> * Fixed memory leak
> * Added Tested-By lines
> * Added event 0xe06e
> 
> Pali Rohár (4):
>   dell-wmi: Ignore WMI event code 0xe045
>   dell-wmi: Sort WMI event codes and update comments
>   dell-wmi: Add information about other WMI event codes
>   dell-wmi: Generate one sparse keymap for all machines
> 
>  drivers/platform/x86/dell-wmi.c |  290 
> ++-
>  1 file changed, 166 insertions(+), 124 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v3] sched: fix first task of a task group is attached twice

[Yuyang Du]

On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote:
> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
> that the 1st sched_entity that will be attached, will keep its
> last_update_time set to 0 and will attached once again during the
> enqueue.
> Initialize cfs_rq->avg.last_update_time to 1 instead.
> 
> Signed-off-by: Vincent Guittot 
> ---
> 
> v3:
> - add initialization of load_last_update_time_copy for not 64bits system
> - move init into init_cfs_rq
> 
> v2:
> - rq_clock_task(rq_of(cfs_rq)) can't be used because lock is not held
> 
>  kernel/sched/fair.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 218f8e8..86be9c1 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8459,6 +8459,16 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
>   cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime;
>  #endif
>  #ifdef CONFIG_SMP
> + /*
> +  * Set last_update_time to something different from 0 to make
> +  * sure the 1st sched_entity will not be attached twice: once
> +  * when attaching the task to the group and one more time when
> +  * enqueueing the task.
> +  */
> + cfs_rq->avg.last_update_time = 1;
> +#ifndef CONFIG_64BIT
> + cfs_rq->load_last_update_time_copy = 1;
> +#endif
>   atomic_long_set(_rq->removed_load_avg, 0);
>   atomic_long_set(_rq->removed_util_avg, 0);
>  #endif

Then, when enqueued, both cfs_rq and task will be decayed to 0, due to
a large gap between 1 and now, no?

Re: [PATCH v3] sched: fix first task of a task group is attached twice

[Yuyang Du]

On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote:
> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
> that the 1st sched_entity that will be attached, will keep its
> last_update_time set to 0 and will attached once again during the
> enqueue.
> Initialize cfs_rq->avg.last_update_time to 1 instead.
> 
> Signed-off-by: Vincent Guittot 
> ---
> 
> v3:
> - add initialization of load_last_update_time_copy for not 64bits system
> - move init into init_cfs_rq
> 
> v2:
> - rq_clock_task(rq_of(cfs_rq)) can't be used because lock is not held
> 
>  kernel/sched/fair.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 218f8e8..86be9c1 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8459,6 +8459,16 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
>   cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime;
>  #endif
>  #ifdef CONFIG_SMP
> + /*
> +  * Set last_update_time to something different from 0 to make
> +  * sure the 1st sched_entity will not be attached twice: once
> +  * when attaching the task to the group and one more time when
> +  * enqueueing the task.
> +  */
> + cfs_rq->avg.last_update_time = 1;
> +#ifndef CONFIG_64BIT
> + cfs_rq->load_last_update_time_copy = 1;
> +#endif
>   atomic_long_set(_rq->removed_load_avg, 0);
>   atomic_long_set(_rq->removed_util_avg, 0);
>  #endif

Then, when enqueued, both cfs_rq and task will be decayed to 0, due to
a large gap between 1 and now, no?

Re: [linux-sunxi] [PATCH] [V2] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

[Chen-Yu Tsai]

On Thu, Jun 16, 2016 at 4:52 AM, Maxime Ripard
 wrote:
> Hi Chen-Yu,
>
> On Mon, Jun 13, 2016 at 11:01:53AM +0800, Chen-Yu Tsai wrote:
>> On Fri, Jun 10, 2016 at 5:38 PM, Maxime Ripard
>>  wrote:
>> > On Thu, Jun 02, 2016 at 11:15:55AM +0200, Bernhard Nortmann wrote:
>> >> Am 02.06.2016 um 10:16 schrieb Maxime Ripard:
>> >> >[...]
>> >> >Yes, everything that is shared with the banana-pro (which, judging
>> >> >from Bernhard, is pretty much everything but a GPIO) should be merged
>> >> >in the banapro DT.
>> >> >
>> >> >Maxime
>> >> >
>> >>
>> >> Don't take my word for granted, as I do not own this hardware or know it
>> >> particularly well. There is no doubt that "BPi-M1+" and "Banana Pro" are
>> >> very similar, but if in doubt the information form the wiki should be
>> >> verified.
>> >
>> > H, ok. Chen-Yu, any input on this? You know the banana-pis much
>> > more than I do.
>>
>> I did a comparison of the "Banana Pro" vs the "BPi-M1+".
>>
>> The differences are similar to what we have with any other development
>> board, say the Cubietruck:
>>
>>   - A different WiFi chip is used, and the BT part is not hooked up.
>>   - Different GPIOs for external power regulator/switches
>>   - Different GPIOs for LEDs
>>   - Different peripherals exposed on the headers.
>>
>> IMO There's no need to merge or have a common .dtsi for the two boards.
>
> Ok.
>
>> They (and all the other development boards) look similar because
>> everyone is following the basic set by Allwinner's reference design,
>> like which MMC controller and pins are used for SD/MMC, which ones
>> are used for SDIO-based WiFi, and so on.
>>
>> I did a version completely from scratch using just the schematics:
>>
>>   https://github.com/wens/linux/commits/bpi-m1-plus
>
> So, what do you mean by that? Do you have some comments on that patch,
> or should I merge it, and you'll post your additions on top of it?

I'd like Luo to send a new version, based on what was his updated v1.

I'll reply to that one with some comments.


ChenYu

Re: [linux-sunxi] [PATCH] [V2] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

[Chen-Yu Tsai]

On Thu, Jun 16, 2016 at 4:52 AM, Maxime Ripard
 wrote:
> Hi Chen-Yu,
>
> On Mon, Jun 13, 2016 at 11:01:53AM +0800, Chen-Yu Tsai wrote:
>> On Fri, Jun 10, 2016 at 5:38 PM, Maxime Ripard
>>  wrote:
>> > On Thu, Jun 02, 2016 at 11:15:55AM +0200, Bernhard Nortmann wrote:
>> >> Am 02.06.2016 um 10:16 schrieb Maxime Ripard:
>> >> >[...]
>> >> >Yes, everything that is shared with the banana-pro (which, judging
>> >> >from Bernhard, is pretty much everything but a GPIO) should be merged
>> >> >in the banapro DT.
>> >> >
>> >> >Maxime
>> >> >
>> >>
>> >> Don't take my word for granted, as I do not own this hardware or know it
>> >> particularly well. There is no doubt that "BPi-M1+" and "Banana Pro" are
>> >> very similar, but if in doubt the information form the wiki should be
>> >> verified.
>> >
>> > H, ok. Chen-Yu, any input on this? You know the banana-pis much
>> > more than I do.
>>
>> I did a comparison of the "Banana Pro" vs the "BPi-M1+".
>>
>> The differences are similar to what we have with any other development
>> board, say the Cubietruck:
>>
>>   - A different WiFi chip is used, and the BT part is not hooked up.
>>   - Different GPIOs for external power regulator/switches
>>   - Different GPIOs for LEDs
>>   - Different peripherals exposed on the headers.
>>
>> IMO There's no need to merge or have a common .dtsi for the two boards.
>
> Ok.
>
>> They (and all the other development boards) look similar because
>> everyone is following the basic set by Allwinner's reference design,
>> like which MMC controller and pins are used for SD/MMC, which ones
>> are used for SDIO-based WiFi, and so on.
>>
>> I did a version completely from scratch using just the schematics:
>>
>>   https://github.com/wens/linux/commits/bpi-m1-plus
>
> So, what do you mean by that? Do you have some comments on that patch,
> or should I merge it, and you'll post your additions on top of it?

I'd like Luo to send a new version, based on what was his updated v1.

I'll reply to that one with some comments.


ChenYu

Re: [PATCH 1/2] drm/mediatek: Add gamma correction

[Bibby Hsieh]

Hi, Daniel, 

Thank you for your suggestion, I will modify that to use the atomic
color management.

Bibby

On Tue, 2016-06-14 at 07:43 +0200, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 10:55:52AM +0800, Bibby Hsieh wrote:
> > Apply gamma function to correct brightness values.
> > It applies arbitrary mapping curve to compensate the
> > incorrect transfer function of the panel.
> > 
> > Signed-off-by: Bibby Hsieh 
> 
> I think it would be much better to use the new atomic color management
> support, which includes gamma. See drm_crtc_enable_color_mgmt.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   12 ++
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   56 
> > ++-
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |9 +
> >  4 files changed, 77 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 24aa3ba..1b38406 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -127,6 +127,16 @@ static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
> > state->base.crtc = crtc;
> >  }
> >  
> > +static void mtk_crtc_gamma_set(struct drm_crtc *crtc, u16 *r,
> > +  u16 *g, u16 *b, uint32_t start, uint32_t size)
> > +{
> > +   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > +   mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], r, g, b, start, size);
> > +}
> > +
> >  static struct drm_crtc_state *mtk_drm_crtc_duplicate_state(struct drm_crtc 
> > *crtc)
> >  {
> > struct mtk_crtc_state *state;
> > @@ -418,6 +428,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > .reset  = mtk_drm_crtc_reset,
> > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
> > +   .gamma_set  = mtk_crtc_gamma_set,
> >  };
> >  
> >  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > @@ -569,6 +580,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > if (ret < 0)
> > goto unprepare;
> >  
> > +   drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> > priv->crtc[pipe] = _crtc->base;
> > priv->num_pipes++;
> >  
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > index 81e5566..d332564 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > @@ -19,6 +19,7 @@
> >  #include "mtk_drm_plane.h"
> >  
> >  #define OVL_LAYER_NR   4
> > +#define MTK_LUT_SIZE   512
> >  
> >  int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
> >  void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int 
> > pipe);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 3970fcf..3fd5141 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -24,6 +24,7 @@
> >  #include "mtk_drm_drv.h"
> >  #include "mtk_drm_plane.h"
> >  #include "mtk_drm_ddp_comp.h"
> > +#include "mtk_drm_crtc.h"
> >  
> >  #define DISP_OD_EN 0x
> >  #define DISP_OD_INTEN  0x0008
> > @@ -38,6 +39,18 @@
> >  #define DISP_COLOR_WIDTH   0x0c50
> >  #define DISP_COLOR_HEIGHT  0x0c54
> >  
> > +#define DISP_AAL_EN0x000
> > +#define DISP_AAL_SIZE  0x030
> > +
> > +#define DISP_GAMMA_CFG 0x020
> > +#define DISP_GAMMA_LUT 0x700
> > +
> > +#define LUT_10BIT_MASK 0x3ff
> > +
> > +#define AAL_EN BIT(0)
> > +
> > +#define GAMMA_LUT_EN   BIT(1)
> > +
> >  #defineOD_RELAY_MODE   BIT(0)
> >  
> >  #defineUFO_BYPASS  BIT(2)
> > @@ -76,6 +89,40 @@ static void mtk_ufoe_start(struct mtk_ddp_comp *comp)
> > writel(UFO_BYPASS, comp->regs + DISP_REG_UFO_START);
> >  }
> >  
> > +static void mtk_aal_config(struct mtk_ddp_comp *comp, unsigned int w,
> > +  unsigned int h, unsigned int vrefresh)
> > +{
> > +   writel(h << 16 | w, comp->regs + DISP_AAL_SIZE);
> > +}
> > +
> > +static void mtk_aal_start(struct mtk_ddp_comp *comp)
> > +{
> > +   writel(AAL_EN, comp->regs  + DISP_AAL_EN);
> > +}
> > +
> > +static void mtk_aal_stop(struct mtk_ddp_comp *comp)
> > +{
> > +   writel_relaxed(0x0, comp->regs  + DISP_AAL_EN);
> > +}
> > +
> > +static void mtk_gamma_set(struct mtk_ddp_comp *comp, u16 *r, u16 *g,
> > + u16 *b, uint32_t start, 

Re: [PATCH 1/2] drm/mediatek: Add gamma correction

[Bibby Hsieh]

Hi, Daniel, 

Thank you for your suggestion, I will modify that to use the atomic
color management.

Bibby

On Tue, 2016-06-14 at 07:43 +0200, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 10:55:52AM +0800, Bibby Hsieh wrote:
> > Apply gamma function to correct brightness values.
> > It applies arbitrary mapping curve to compensate the
> > incorrect transfer function of the panel.
> > 
> > Signed-off-by: Bibby Hsieh 
> 
> I think it would be much better to use the new atomic color management
> support, which includes gamma. See drm_crtc_enable_color_mgmt.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   12 ++
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   56 
> > ++-
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |9 +
> >  4 files changed, 77 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 24aa3ba..1b38406 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -127,6 +127,16 @@ static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
> > state->base.crtc = crtc;
> >  }
> >  
> > +static void mtk_crtc_gamma_set(struct drm_crtc *crtc, u16 *r,
> > +  u16 *g, u16 *b, uint32_t start, uint32_t size)
> > +{
> > +   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > +   mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], r, g, b, start, size);
> > +}
> > +
> >  static struct drm_crtc_state *mtk_drm_crtc_duplicate_state(struct drm_crtc 
> > *crtc)
> >  {
> > struct mtk_crtc_state *state;
> > @@ -418,6 +428,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > .reset  = mtk_drm_crtc_reset,
> > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
> > +   .gamma_set  = mtk_crtc_gamma_set,
> >  };
> >  
> >  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > @@ -569,6 +580,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > if (ret < 0)
> > goto unprepare;
> >  
> > +   drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> > priv->crtc[pipe] = _crtc->base;
> > priv->num_pipes++;
> >  
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > index 81e5566..d332564 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > @@ -19,6 +19,7 @@
> >  #include "mtk_drm_plane.h"
> >  
> >  #define OVL_LAYER_NR   4
> > +#define MTK_LUT_SIZE   512
> >  
> >  int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
> >  void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int 
> > pipe);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 3970fcf..3fd5141 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -24,6 +24,7 @@
> >  #include "mtk_drm_drv.h"
> >  #include "mtk_drm_plane.h"
> >  #include "mtk_drm_ddp_comp.h"
> > +#include "mtk_drm_crtc.h"
> >  
> >  #define DISP_OD_EN 0x
> >  #define DISP_OD_INTEN  0x0008
> > @@ -38,6 +39,18 @@
> >  #define DISP_COLOR_WIDTH   0x0c50
> >  #define DISP_COLOR_HEIGHT  0x0c54
> >  
> > +#define DISP_AAL_EN0x000
> > +#define DISP_AAL_SIZE  0x030
> > +
> > +#define DISP_GAMMA_CFG 0x020
> > +#define DISP_GAMMA_LUT 0x700
> > +
> > +#define LUT_10BIT_MASK 0x3ff
> > +
> > +#define AAL_EN BIT(0)
> > +
> > +#define GAMMA_LUT_EN   BIT(1)
> > +
> >  #defineOD_RELAY_MODE   BIT(0)
> >  
> >  #defineUFO_BYPASS  BIT(2)
> > @@ -76,6 +89,40 @@ static void mtk_ufoe_start(struct mtk_ddp_comp *comp)
> > writel(UFO_BYPASS, comp->regs + DISP_REG_UFO_START);
> >  }
> >  
> > +static void mtk_aal_config(struct mtk_ddp_comp *comp, unsigned int w,
> > +  unsigned int h, unsigned int vrefresh)
> > +{
> > +   writel(h << 16 | w, comp->regs + DISP_AAL_SIZE);
> > +}
> > +
> > +static void mtk_aal_start(struct mtk_ddp_comp *comp)
> > +{
> > +   writel(AAL_EN, comp->regs  + DISP_AAL_EN);
> > +}
> > +
> > +static void mtk_aal_stop(struct mtk_ddp_comp *comp)
> > +{
> > +   writel_relaxed(0x0, comp->regs  + DISP_AAL_EN);
> > +}
> > +
> > +static void mtk_gamma_set(struct mtk_ddp_comp *comp, u16 *r, u16 *g,
> > + u16 *b, uint32_t start, uint32_t size)
> > +{
> > +  

[PATCH v5 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

[Vinay Simha BN]

Add support for the JDI LT070ME05000 WUXGA DSI panel used in
Nexus 7 2013 devices.

Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git

And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
file in:
git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27

Cc: Archit Taneja 
[sumit.semwal: Ported to the drm/panel framework]
Signed-off-by: Sumit Semwal 
[jstultz: Cherry-picked to mainline, folded down other fixes
 from Vinay and Archit]
Signed-off-by: John Stultz 
[vinay simha bn: removed interface setting cmd mode, video
mode panel setting selection]
Cc: Rob Clark 
Signed-off-by: Vinay Simha BN 

---
v2:
 * incorporated code reviews from theiry, archit
   code style, alphabetical soring in Makefile, Kconfig, regulator_bulk,
   arrays of u8, generic helper function, documentation bindings,

v3:
 * dcs backlight support added
 * tested this panel driver in nexus7 2013 device

v4:
 * backlight interface added in the panel driver
 * incorporated width_mm and height_mm suggested by rob herring

v5:
 * theirry review comments incorporated
   panel model naming consistent, alphabetical soring in Kconfig
   Makefile, MAX_BRIGHTNESS dropped, regulator_names, parameterize
   panel width and height, descprition for control display, cabc
   and interface setting, temporary variable removed, consistent
   error reporting and commit message
 * removed tear on/off, scanline, since these are required only
   for command mode panels
---
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 515 +
 3 files changed, 527 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 1500ab9..62aba97 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_JDI_LT070ME05000
+   tristate "JDI LT070ME05000 WUXGA DSI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for JDI DSI video mode
+ panel as found in Google Nexus 7 (2013) devices.
+ The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
+ 24 bit per pixel.
+
 config DRM_PANEL_SAMSUNG_LD9040
tristate "Samsung LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f277eed..a5c7ec0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
new file mode 100644
index 000..e935a63
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -0,0 +1,515 @@
+/*
+ * Copyright (C) 2016 InforceComputing
+ * Author: Vinay Simha BN 
+ *
+ * Copyright (C) 2016 Linaro Ltd
+ * Author: Sumit Semwal 
+ *
+ * From internet archives, the panel for Nexus 7 2nd Gen, 2013 model is a
+ * JDI model LT070ME05000, and its data sheet is at:
+ * http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define PANEL_NUM_REGULATORS   3
+
+static const char * const regulator_names[] = {
+   "vddp",
+   "dcdc_en",
+   "vcc"
+};
+
+struct jdi_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct regulator_bulk_data 

[PATCH v5 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

[Vinay Simha BN]

Add support for the JDI LT070ME05000 WUXGA DSI panel used in
Nexus 7 2013 devices.

Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git

And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
file in:
git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27

Cc: Archit Taneja 
[sumit.semwal: Ported to the drm/panel framework]
Signed-off-by: Sumit Semwal 
[jstultz: Cherry-picked to mainline, folded down other fixes
 from Vinay and Archit]
Signed-off-by: John Stultz 
[vinay simha bn: removed interface setting cmd mode, video
mode panel setting selection]
Cc: Rob Clark 
Signed-off-by: Vinay Simha BN 

---
v2:
 * incorporated code reviews from theiry, archit
   code style, alphabetical soring in Makefile, Kconfig, regulator_bulk,
   arrays of u8, generic helper function, documentation bindings,

v3:
 * dcs backlight support added
 * tested this panel driver in nexus7 2013 device

v4:
 * backlight interface added in the panel driver
 * incorporated width_mm and height_mm suggested by rob herring

v5:
 * theirry review comments incorporated
   panel model naming consistent, alphabetical soring in Kconfig
   Makefile, MAX_BRIGHTNESS dropped, regulator_names, parameterize
   panel width and height, descprition for control display, cabc
   and interface setting, temporary variable removed, consistent
   error reporting and commit message
 * removed tear on/off, scanline, since these are required only
   for command mode panels
---
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 515 +
 3 files changed, 527 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 1500ab9..62aba97 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_JDI_LT070ME05000
+   tristate "JDI LT070ME05000 WUXGA DSI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for JDI DSI video mode
+ panel as found in Google Nexus 7 (2013) devices.
+ The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
+ 24 bit per pixel.
+
 config DRM_PANEL_SAMSUNG_LD9040
tristate "Samsung LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f277eed..a5c7ec0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
new file mode 100644
index 000..e935a63
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -0,0 +1,515 @@
+/*
+ * Copyright (C) 2016 InforceComputing
+ * Author: Vinay Simha BN 
+ *
+ * Copyright (C) 2016 Linaro Ltd
+ * Author: Sumit Semwal 
+ *
+ * From internet archives, the panel for Nexus 7 2nd Gen, 2013 model is a
+ * JDI model LT070ME05000, and its data sheet is at:
+ * http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define PANEL_NUM_REGULATORS   3
+
+static const char * const regulator_names[] = {
+   "vddp",
+   "dcdc_en",
+   "vcc"
+};
+
+struct jdi_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct regulator_bulk_data supplies[PANEL_NUM_REGULATORS];
+
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *enable_gpio;
+   struct backlight_device *backlight;
+
+   bool 

[PATCH v2 1/2] drm/dsi: Implement dcs set/get display brightness

[Vinay Simha BN]

Provide a small convenience wrapper that set/get the
display brightness value

Cc: John Stultz 
Cc: Sumit Semwal 
Cc: Archit Taneja 
Cc: Rob Clark 
Cc: Jani Nikula 
Cc: Thierry Reding 
Signed-off-by: Vinay Simha BN 

---
v1:
 *tested in nexus7 2nd gen.

v2:
 * implemented jani review comments
   -functions name mapped accordingly
   -bl value increased from 0xff to 0x
   -backlight interface will be handled in panel driver,
so it is moved from the mipi_dsi helper function
---
 drivers/gpu/drm/drm_mipi_dsi.c | 49 ++
 include/drm/drm_mipi_dsi.h |  4 
 2 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 49311fc..2c03784 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -1041,6 +1041,55 @@ int mipi_dsi_dcs_set_pixel_format(struct mipi_dsi_device 
*dsi, u8 format)
 }
 EXPORT_SYMBOL(mipi_dsi_dcs_set_pixel_format);
 
+/**
+ * mipi_dsi_dcs_get_display_brightness() - gets the current brightness value
+ * of the display
+ * @dsi: DSI peripheral device
+ * @brightness: brightness value
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_get_display_brightness(struct mipi_dsi_device *dsi,
+   u16 *brightness)
+{
+   ssize_t err;
+
+   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DISPLAY_BRIGHTNESS,
+   brightness, sizeof(*brightness));
+   if (err < 0) {
+   if (err == 0)
+   err = -ENODATA;
+
+   return err;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_get_display_brightness);
+
+/**
+ * mipi_dsi_dcs_set_display_brightness() - sets the brightness value of
+ * the display
+ * @dsi: DSI peripheral device
+ * @brightness: brightness value
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_set_display_brightness(struct mipi_dsi_device *dsi,
+   u16 brightness)
+{
+   ssize_t err;
+   u8 bl_value[2] = { brightness & 0xff, brightness >> 8 };
+
+   err = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
+bl_value, sizeof(bl_value));
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_set_display_brightness);
+
 static int mipi_dsi_drv_probe(struct device *dev)
 {
struct mipi_dsi_driver *drv = to_mipi_dsi_driver(dev->driver);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 72f5b15..4d77bb0 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -270,6 +270,10 @@ 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);
 int mipi_dsi_dcs_set_pixel_format(struct mipi_dsi_device *dsi, u8 format);
+int mipi_dsi_dcs_get_display_brightness(struct mipi_dsi_device *dsi,
+   u16 *brightness);
+int mipi_dsi_dcs_set_display_brightness(struct mipi_dsi_device *dsi,
+   u16 brightness);
 
 /**
  * struct mipi_dsi_driver - DSI driver
-- 
1.9.1

[PATCH v2 1/2] drm/dsi: Implement dcs set/get display brightness

[Vinay Simha BN]

Provide a small convenience wrapper that set/get the
display brightness value

Cc: John Stultz 
Cc: Sumit Semwal 
Cc: Archit Taneja 
Cc: Rob Clark 
Cc: Jani Nikula 
Cc: Thierry Reding 
Signed-off-by: Vinay Simha BN 

---
v1:
 *tested in nexus7 2nd gen.

v2:
 * implemented jani review comments
   -functions name mapped accordingly
   -bl value increased from 0xff to 0x
   -backlight interface will be handled in panel driver,
so it is moved from the mipi_dsi helper function
---
 drivers/gpu/drm/drm_mipi_dsi.c | 49 ++
 include/drm/drm_mipi_dsi.h |  4 
 2 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 49311fc..2c03784 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -1041,6 +1041,55 @@ int mipi_dsi_dcs_set_pixel_format(struct mipi_dsi_device 
*dsi, u8 format)
 }
 EXPORT_SYMBOL(mipi_dsi_dcs_set_pixel_format);
 
+/**
+ * mipi_dsi_dcs_get_display_brightness() - gets the current brightness value
+ * of the display
+ * @dsi: DSI peripheral device
+ * @brightness: brightness value
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_get_display_brightness(struct mipi_dsi_device *dsi,
+   u16 *brightness)
+{
+   ssize_t err;
+
+   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DISPLAY_BRIGHTNESS,
+   brightness, sizeof(*brightness));
+   if (err < 0) {
+   if (err == 0)
+   err = -ENODATA;
+
+   return err;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_get_display_brightness);
+
+/**
+ * mipi_dsi_dcs_set_display_brightness() - sets the brightness value of
+ * the display
+ * @dsi: DSI peripheral device
+ * @brightness: brightness value
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_set_display_brightness(struct mipi_dsi_device *dsi,
+   u16 brightness)
+{
+   ssize_t err;
+   u8 bl_value[2] = { brightness & 0xff, brightness >> 8 };
+
+   err = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
+bl_value, sizeof(bl_value));
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_set_display_brightness);
+
 static int mipi_dsi_drv_probe(struct device *dev)
 {
struct mipi_dsi_driver *drv = to_mipi_dsi_driver(dev->driver);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 72f5b15..4d77bb0 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -270,6 +270,10 @@ 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);
 int mipi_dsi_dcs_set_pixel_format(struct mipi_dsi_device *dsi, u8 format);
+int mipi_dsi_dcs_get_display_brightness(struct mipi_dsi_device *dsi,
+   u16 *brightness);
+int mipi_dsi_dcs_set_display_brightness(struct mipi_dsi_device *dsi,
+   u16 brightness);
 
 /**
  * struct mipi_dsi_driver - DSI driver
-- 
1.9.1

[PATCH net 3/3] r8152: correct the rx early size

[Hayes Wang]

The rx early size should be

(agg_buf_sz - packet size) / 8

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f5bc351..4e257b8 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -31,7 +31,7 @@
 #define NETNEXT_VERSION"08"
 
 /* Information for net */
-#define NET_VERSION"3"
+#define NET_VERSION"4"
 
 #define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -2174,7 +2174,7 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
 static void r8153_set_rx_early_size(struct r8152 *tp)
 {
u32 mtu = tp->netdev->mtu;
-   u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
+   u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 8;
 
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data);
 }
-- 
2.4.11

[PATCH net 2/3] r8152: reset the bmu

[Hayes Wang]

Reset the BMU to clear the rx/tx fifo. This avoids that the unexpected
data remains in the hw.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 89dc752..f5bc351 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -116,6 +116,7 @@
 #define USB_TX_DMA 0xd434
 #define USB_TOLERANCE  0xd490
 #define USB_LPM_CTRL   0xd41a
+#define USB_BMU_RESET  0xd4b0
 #define USB_UPS_CTRL   0xd800
 #define USB_MISC_0 0xd81a
 #define USB_POWER_CUT  0xd80a
@@ -338,6 +339,10 @@
 #define TEST_MODE_DISABLE  0x0001
 #define TX_SIZE_ADJUST10x0100
 
+/* USB_BMU_RESET */
+#define BMU_RESET_EP_IN0x01
+#define BMU_RESET_EP_OUT   0x02
+
 /* USB_UPS_CTRL */
 #define POWER_CUT  0x0100
 
@@ -2456,6 +2461,17 @@ static void r8153_teredo_off(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TEREDO_TIMER, 0);
 }
 
+static void rtl_reset_bmu(struct r8152 *tp)
+{
+   u32 ocp_data;
+
+   ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_BMU_RESET);
+   ocp_data &= ~(BMU_RESET_EP_IN | BMU_RESET_EP_OUT);
+   ocp_write_byte(tp, MCU_TYPE_USB, USB_BMU_RESET, ocp_data);
+   ocp_data |= BMU_RESET_EP_IN | BMU_RESET_EP_OUT;
+   ocp_write_byte(tp, MCU_TYPE_USB, USB_BMU_RESET, ocp_data);
+}
+
 static void r8152_aldps_en(struct r8152 *tp, bool enable)
 {
if (enable) {
@@ -2681,6 +2697,7 @@ static void r8153_first_init(struct r8152 *tp)
r8153_hw_phy_cfg(tp);
 
rtl8152_nic_reset(tp);
+   rtl_reset_bmu(tp);
 
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
ocp_data &= ~NOW_IS_OOB;
@@ -2742,6 +2759,7 @@ static void r8153_enter_oob(struct r8152 *tp)
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL, ocp_data);
 
rtl_disable(tp);
+   rtl_reset_bmu(tp);
 
for (i = 0; i < 1000; i++) {
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
@@ -2803,6 +2821,7 @@ static void rtl8153_disable(struct r8152 *tp)
 {
r8153_aldps_en(tp, false);
rtl_disable(tp);
+   rtl_reset_bmu(tp);
r8153_aldps_en(tp, true);
usb_enable_lpm(tp->udev);
 }
-- 
2.4.11

[GIT PULL] platform-drivers-x86 for 4.7-2

[Darren Hart]

Hi Linus,

The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:

  Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)

are available in the git repository at:

  git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
tags/platform-drivers-x86-v4.7-2

for you to fetch changes up to 25789f95a8834d154e5c1f0c9df9a7faedeae98e:

  platform/x86: Drop duplicate dependencies on X86 (2016-06-08 13:21:37 -0700)


platform-drivers-x86 for 4.7-2

Minor kconfig dependency cleanup, trivial mic mute hotkey for ideapad, and a
needed improvement in adaptive keyboard detection for thinkpad.

platform/x86:
 - Drop duplicate dependencies on X86

thinkpad_acpi:
 - Add support for HKEY version 0x200

ideapad_laptop:
 - Add an event for mic mute hotkey


Alex Hung (1):
  ideapad_laptop: Add an event for mic mute hotkey

Dennis Wassenberg (1):
  thinkpad_acpi: Add support for HKEY version 0x200

Jean Delvare (1):
  platform/x86: Drop duplicate dependencies on X86

 drivers/platform/x86/Kconfig  | 10 ++--
 drivers/platform/x86/ideapad-laptop.c |  2 +
 drivers/platform/x86/thinkpad_acpi.c  | 87 +--
 3 files changed, 69 insertions(+), 30 deletions(-)

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH net 3/3] r8152: correct the rx early size

[Hayes Wang]

The rx early size should be

(agg_buf_sz - packet size) / 8

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f5bc351..4e257b8 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -31,7 +31,7 @@
 #define NETNEXT_VERSION"08"
 
 /* Information for net */
-#define NET_VERSION"3"
+#define NET_VERSION"4"
 
 #define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -2174,7 +2174,7 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
 static void r8153_set_rx_early_size(struct r8152 *tp)
 {
u32 mtu = tp->netdev->mtu;
-   u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
+   u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 8;
 
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data);
 }
-- 
2.4.11

[PATCH net 2/3] r8152: reset the bmu

[Hayes Wang]

Reset the BMU to clear the rx/tx fifo. This avoids that the unexpected
data remains in the hw.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 89dc752..f5bc351 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -116,6 +116,7 @@
 #define USB_TX_DMA 0xd434
 #define USB_TOLERANCE  0xd490
 #define USB_LPM_CTRL   0xd41a
+#define USB_BMU_RESET  0xd4b0
 #define USB_UPS_CTRL   0xd800
 #define USB_MISC_0 0xd81a
 #define USB_POWER_CUT  0xd80a
@@ -338,6 +339,10 @@
 #define TEST_MODE_DISABLE  0x0001
 #define TX_SIZE_ADJUST10x0100
 
+/* USB_BMU_RESET */
+#define BMU_RESET_EP_IN0x01
+#define BMU_RESET_EP_OUT   0x02
+
 /* USB_UPS_CTRL */
 #define POWER_CUT  0x0100
 
@@ -2456,6 +2461,17 @@ static void r8153_teredo_off(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TEREDO_TIMER, 0);
 }
 
+static void rtl_reset_bmu(struct r8152 *tp)
+{
+   u32 ocp_data;
+
+   ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_BMU_RESET);
+   ocp_data &= ~(BMU_RESET_EP_IN | BMU_RESET_EP_OUT);
+   ocp_write_byte(tp, MCU_TYPE_USB, USB_BMU_RESET, ocp_data);
+   ocp_data |= BMU_RESET_EP_IN | BMU_RESET_EP_OUT;
+   ocp_write_byte(tp, MCU_TYPE_USB, USB_BMU_RESET, ocp_data);
+}
+
 static void r8152_aldps_en(struct r8152 *tp, bool enable)
 {
if (enable) {
@@ -2681,6 +2697,7 @@ static void r8153_first_init(struct r8152 *tp)
r8153_hw_phy_cfg(tp);
 
rtl8152_nic_reset(tp);
+   rtl_reset_bmu(tp);
 
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
ocp_data &= ~NOW_IS_OOB;
@@ -2742,6 +2759,7 @@ static void r8153_enter_oob(struct r8152 *tp)
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL, ocp_data);
 
rtl_disable(tp);
+   rtl_reset_bmu(tp);
 
for (i = 0; i < 1000; i++) {
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
@@ -2803,6 +2821,7 @@ static void rtl8153_disable(struct r8152 *tp)
 {
r8153_aldps_en(tp, false);
rtl_disable(tp);
+   rtl_reset_bmu(tp);
r8153_aldps_en(tp, true);
usb_enable_lpm(tp->udev);
 }
-- 
2.4.11

[GIT PULL] platform-drivers-x86 for 4.7-2

[Darren Hart]

Hi Linus,

The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:

  Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)

are available in the git repository at:

  git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
tags/platform-drivers-x86-v4.7-2

for you to fetch changes up to 25789f95a8834d154e5c1f0c9df9a7faedeae98e:

  platform/x86: Drop duplicate dependencies on X86 (2016-06-08 13:21:37 -0700)


platform-drivers-x86 for 4.7-2

Minor kconfig dependency cleanup, trivial mic mute hotkey for ideapad, and a
needed improvement in adaptive keyboard detection for thinkpad.

platform/x86:
 - Drop duplicate dependencies on X86

thinkpad_acpi:
 - Add support for HKEY version 0x200

ideapad_laptop:
 - Add an event for mic mute hotkey


Alex Hung (1):
  ideapad_laptop: Add an event for mic mute hotkey

Dennis Wassenberg (1):
  thinkpad_acpi: Add support for HKEY version 0x200

Jean Delvare (1):
  platform/x86: Drop duplicate dependencies on X86

 drivers/platform/x86/Kconfig  | 10 ++--
 drivers/platform/x86/ideapad-laptop.c |  2 +
 drivers/platform/x86/thinkpad_acpi.c  | 87 +--
 3 files changed, 69 insertions(+), 30 deletions(-)

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v7 00/12] Support non-lru page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote:
> Hi,
> 
> On (06/16/16 08:12), Minchan Kim wrote:
> > > [  315.146533] kasan: CONFIG_KASAN_INLINE enabled
> > > [  315.146538] kasan: GPF could be caused by NULL-ptr deref or user 
> > > memory access
> > > [  315.146546] general protection fault:  [#1] PREEMPT SMP KASAN
> > > [  315.146576] Modules linked in: lzo zram zsmalloc mousedev coretemp 
> > > hwmon crc32c_intel r8169 i2c_i801 mii snd_hda_codec_realtek 
> > > snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core 
> > > acpi_cpufreq snd_pcm snd_timer snd soundcore lpc_ich mfd_core processor 
> > > sch_fq_codel sd_mod hid_generic usbhid hid ahci libahci libata ehci_pci 
> > > ehci_hcd scsi_mod usbcore usb_common
> > > [  315.146785] CPU: 3 PID: 38 Comm: khugepaged Not tainted 
> > > 4.7.0-rc3-next-20160614-dbg-4-ga1c2cbc-dirty #488
> > > [  315.146841] task: 8800bfaf2900 ti: 880112468000 task.ti: 
> > > 880112468000
> > > [  315.146859] RIP: 0010:[]  [] 
> > > zs_page_migrate+0x355/0xaa0 [zsmalloc]
> > 
> > Thanks for the report!
> > 
> > zs_page_migrate+0x355? Could you tell me what line is it?
> > 
> > It seems to be related to obj_to_head.
> 
> reproduced. a bit different call stack this time. but the problem is
> still the same.
> 
> zs_compact()
> ...
> 6371:   e8 00 00 00 00  callq  6376 
> 6376:   0f 0b   ud2
> 6378:   48 8b 95 a8 fe ff ffmov-0x158(%rbp),%rdx
> 637f:   4d 8d 74 24 78  lea0x78(%r12),%r14
> 6384:   4c 89 eemov%r13,%rsi
> 6387:   4c 89 e7mov%r12,%rdi
> 638a:   e8 86 c7 ff ff  callq  2b15 
> 638f:   41 89 c5mov%eax,%r13d
> 6392:   4c 89 f0mov%r14,%rax
> 6395:   48 c1 e8 03 shr$0x3,%rax
> 6399:   8a 04 18mov(%rax,%rbx,1),%al
> 639c:   84 c0   test   %al,%al
> 639e:   0f 85 f2 02 00 00   jne6696 
> 63a4:   41 8b 44 24 78  mov0x78(%r12),%eax
> 63a9:   41 0f af c7 imul   %r15d,%eax
> 63ad:   41 01 c5add%eax,%r13d
> 63b0:   4c 89 f0mov%r14,%rax
> 63b3:   48 c1 e8 03 shr$0x3,%rax
> 63b7:   48 01 d8add%rbx,%rax
> 63ba:   48 89 85 88 fe ff ffmov%rax,-0x178(%rbp)
> 63c1:   41 81 fd ff 0f 00 00cmp$0xfff,%r13d
> 63c8:   0f 87 1a 03 00 00   ja 66e8 
> 63ce:   49 63 f5movslq %r13d,%rsi
> 63d1:   48 03 b5 98 fe ff ffadd-0x168(%rbp),%rsi
> 63d8:   48 8b bd a8 fe ff ffmov-0x158(%rbp),%rdi
> 63df:   e8 67 d9 ff ff  callq  3d4b 
> 63e4:   a8 01   test   $0x1,%al
> 63e6:   0f 84 d9 02 00 00   je 66c5 
> 63ec:   48 83 e0 fe and$0xfffe,%rax
> 63f0:   bf 01 00 00 00  mov$0x1,%edi
> 63f5:   48 89 85 b0 fe ff ffmov%rax,-0x150(%rbp)
> 63fc:   e8 00 00 00 00  callq  6401 
> 6401:   48 8b 85 b0 fe ff ffmov-0x150(%rbp),%rax

RAX: 2065676162726166 so rax is totally garbage, I think.
It means obj_to_head returns garbage because get_first_obj_offset is
utter crab because (page_idx / class->pages_per_zspage) was totally
wrong.

>   ^^
> 6408:   f0 0f ba 28 00  lock btsl $0x0,(%rax)
 


> > Could you test with [zsmalloc: keep first object offset in struct page]
> > in mmotm?
> 
> sure, I can.  will it help, tho? we have a race condition here I think.

I guess root cause is caused by get_first_obj_offset.
Please test with it.

Thanks!

Re: [PATCH v7 00/12] Support non-lru page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote:
> Hi,
> 
> On (06/16/16 08:12), Minchan Kim wrote:
> > > [  315.146533] kasan: CONFIG_KASAN_INLINE enabled
> > > [  315.146538] kasan: GPF could be caused by NULL-ptr deref or user 
> > > memory access
> > > [  315.146546] general protection fault:  [#1] PREEMPT SMP KASAN
> > > [  315.146576] Modules linked in: lzo zram zsmalloc mousedev coretemp 
> > > hwmon crc32c_intel r8169 i2c_i801 mii snd_hda_codec_realtek 
> > > snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core 
> > > acpi_cpufreq snd_pcm snd_timer snd soundcore lpc_ich mfd_core processor 
> > > sch_fq_codel sd_mod hid_generic usbhid hid ahci libahci libata ehci_pci 
> > > ehci_hcd scsi_mod usbcore usb_common
> > > [  315.146785] CPU: 3 PID: 38 Comm: khugepaged Not tainted 
> > > 4.7.0-rc3-next-20160614-dbg-4-ga1c2cbc-dirty #488
> > > [  315.146841] task: 8800bfaf2900 ti: 880112468000 task.ti: 
> > > 880112468000
> > > [  315.146859] RIP: 0010:[]  [] 
> > > zs_page_migrate+0x355/0xaa0 [zsmalloc]
> > 
> > Thanks for the report!
> > 
> > zs_page_migrate+0x355? Could you tell me what line is it?
> > 
> > It seems to be related to obj_to_head.
> 
> reproduced. a bit different call stack this time. but the problem is
> still the same.
> 
> zs_compact()
> ...
> 6371:   e8 00 00 00 00  callq  6376 
> 6376:   0f 0b   ud2
> 6378:   48 8b 95 a8 fe ff ffmov-0x158(%rbp),%rdx
> 637f:   4d 8d 74 24 78  lea0x78(%r12),%r14
> 6384:   4c 89 eemov%r13,%rsi
> 6387:   4c 89 e7mov%r12,%rdi
> 638a:   e8 86 c7 ff ff  callq  2b15 
> 638f:   41 89 c5mov%eax,%r13d
> 6392:   4c 89 f0mov%r14,%rax
> 6395:   48 c1 e8 03 shr$0x3,%rax
> 6399:   8a 04 18mov(%rax,%rbx,1),%al
> 639c:   84 c0   test   %al,%al
> 639e:   0f 85 f2 02 00 00   jne6696 
> 63a4:   41 8b 44 24 78  mov0x78(%r12),%eax
> 63a9:   41 0f af c7 imul   %r15d,%eax
> 63ad:   41 01 c5add%eax,%r13d
> 63b0:   4c 89 f0mov%r14,%rax
> 63b3:   48 c1 e8 03 shr$0x3,%rax
> 63b7:   48 01 d8add%rbx,%rax
> 63ba:   48 89 85 88 fe ff ffmov%rax,-0x178(%rbp)
> 63c1:   41 81 fd ff 0f 00 00cmp$0xfff,%r13d
> 63c8:   0f 87 1a 03 00 00   ja 66e8 
> 63ce:   49 63 f5movslq %r13d,%rsi
> 63d1:   48 03 b5 98 fe ff ffadd-0x168(%rbp),%rsi
> 63d8:   48 8b bd a8 fe ff ffmov-0x158(%rbp),%rdi
> 63df:   e8 67 d9 ff ff  callq  3d4b 
> 63e4:   a8 01   test   $0x1,%al
> 63e6:   0f 84 d9 02 00 00   je 66c5 
> 63ec:   48 83 e0 fe and$0xfffe,%rax
> 63f0:   bf 01 00 00 00  mov$0x1,%edi
> 63f5:   48 89 85 b0 fe ff ffmov%rax,-0x150(%rbp)
> 63fc:   e8 00 00 00 00  callq  6401 
> 6401:   48 8b 85 b0 fe ff ffmov-0x150(%rbp),%rax

RAX: 2065676162726166 so rax is totally garbage, I think.
It means obj_to_head returns garbage because get_first_obj_offset is
utter crab because (page_idx / class->pages_per_zspage) was totally
wrong.

>   ^^
> 6408:   f0 0f ba 28 00  lock btsl $0x0,(%rax)
 


> > Could you test with [zsmalloc: keep first object offset in struct page]
> > in mmotm?
> 
> sure, I can.  will it help, tho? we have a race condition here I think.

I guess root cause is caused by get_first_obj_offset.
Please test with it.

Thanks!

[PATCH net 1/3] r8152: disable MAC clock speed down

[Hayes Wang]

Disable MAC clock speed down. It may casue the first control
transfer to contain the wrong data, when the power state change
from U1 to U0.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3f9f6ed..89dc752 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3382,15 +3382,11 @@ static void r8153_init(struct r8152 *tp)
r8153_power_cut_en(tp, false);
r8153_u1u2en(tp, true);
 
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, ALDPS_SPDWN_RATIO);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2, EEE_SPDWN_RATIO);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
-  PKT_AVAIL_SPDWN_EN | SUSPEND_SPDWN_EN |
-  U1U2_SPDWN_EN | L1_SPDWN_EN);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4,
-  PWRSAVE_SPDWN_EN | RXDV_SPDWN_EN | TX10MIDLE_EN |
-  TP100_SPDWN_EN | TP500_SPDWN_EN | TP1000_SPDWN_EN |
-  EEE_SPDWN_EN);
+   /* MAC clock speed down */
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, 0);
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2, 0);
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, 0);
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4, 0);
 
r8153_enable_eee(tp);
r8153_aldps_en(tp, true);
-- 
2.4.11

[PATCH net 1/3] r8152: disable MAC clock speed down

[Hayes Wang]

Disable MAC clock speed down. It may casue the first control
transfer to contain the wrong data, when the power state change
from U1 to U0.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3f9f6ed..89dc752 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3382,15 +3382,11 @@ static void r8153_init(struct r8152 *tp)
r8153_power_cut_en(tp, false);
r8153_u1u2en(tp, true);
 
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, ALDPS_SPDWN_RATIO);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2, EEE_SPDWN_RATIO);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
-  PKT_AVAIL_SPDWN_EN | SUSPEND_SPDWN_EN |
-  U1U2_SPDWN_EN | L1_SPDWN_EN);
-   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4,
-  PWRSAVE_SPDWN_EN | RXDV_SPDWN_EN | TX10MIDLE_EN |
-  TP100_SPDWN_EN | TP500_SPDWN_EN | TP1000_SPDWN_EN |
-  EEE_SPDWN_EN);
+   /* MAC clock speed down */
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, 0);
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2, 0);
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, 0);
+   ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4, 0);
 
r8153_enable_eee(tp);
r8153_aldps_en(tp, true);
-- 
2.4.11

[PATCH net 0/3] r8152: fix known issues

[Hayes Wang]

These patches fix some known issues.

Hayes Wang (3):
  r8152: disable MAC clock speed down
  r8152: reset the bmu
  r8152: correct the rx early size

 drivers/net/usb/r8152.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

-- 
2.4.11

[PATCH net 0/3] r8152: fix known issues

[Hayes Wang]

These patches fix some known issues.

Hayes Wang (3):
  r8152: disable MAC clock speed down
  r8152: reset the bmu
  r8152: correct the rx early size

 drivers/net/usb/r8152.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

-- 
2.4.11

[PATCH V2] libata:fix kernel panic when hotplug

[DingXiang]

From: Ding Xiang 

In normal condition,if we use sas protocol and hotplug a
sata disk on a port,the sas driver will send event
"PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new
sata disk,this operation may cause a kernel panic like this:

[ 2366.923208] Unable to handle kernel NULL pointer dereference
at virtual address 07b8
[ 2366.949253] pgd = ffc00121d000
[ 2366.971164] [07b8] *pgd=0027df893003, *pud=0027df893003,
*pmd=0027df894003, *pte=00606d000707
[ 2367.022822] Internal error: Oops: 9605 [#1] SMP
[ 2367.048490] Modules linked in: dm_mirror(E) dm_region_hash(E) dm_log(E)
dm_mod(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E) cry ptd(E)
aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E) ses(E) enclosure(E)
shpchp(E) marvell(E)
[ 2367.144808] CPU: 16 PID: 710 Comm: kworker/16:1 Tainted: GE
4.1.23-next.aarch64 #1
[ 2367.180161] Hardware name: Huawei Taishan 2280 /BC11SPCC,
BIOS 1.28 05/14/2016
[ 2367.213305] Workqueue: events ata_scsi_hotplug
[ 2367.244296] task: ffe7db9b5e00 ti: ffe7db1a
task.ti: ffe7db1a
[ 2367.279949] PC is at sas_find_dev_by_rphy+0x48/0x118
[ 2367.312045] LR is at sas_find_dev_by_rphy+0x40/0x118
[ 2367.341970] pc : [] lr : []
pstate: 0145
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110
[ 2368.940923] Code: aa1303e0 97ff5deb 3480 d1082273 (f943de76)

This because "dev_to_shost" in "sas_find_dev_by_rphy" return
a NULL point,and SHOST_TO_SAS_HA used it,so kernel panic happed.

why dev_to_shost return a NULL point?
Because in "__scsi_add_device" ,
struct device *parent = >shost_gendev,
and in "scsi_alloc_target", "*parent" is assigned to
"starget->dev.parent",then "sas_target_alloc" will get
"struct sas_rphy" according "starget->dev.parent", and in
"sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost"
according "rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent
is "ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at this moment,the libata hotplug task
will run and panic will happen.

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Signed-off-by: Ding Xiang 
---
 drivers/ata/libata-eh.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..4428a7c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,7 +816,8 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
+   else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
+!(ap->pflags & ATA_PFLAG_SAS_HOST))
schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
-- 
2.5.0

[PATCH V2] libata:fix kernel panic when hotplug

[DingXiang]

From: Ding Xiang 

In normal condition,if we use sas protocol and hotplug a
sata disk on a port,the sas driver will send event
"PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new
sata disk,this operation may cause a kernel panic like this:

[ 2366.923208] Unable to handle kernel NULL pointer dereference
at virtual address 07b8
[ 2366.949253] pgd = ffc00121d000
[ 2366.971164] [07b8] *pgd=0027df893003, *pud=0027df893003,
*pmd=0027df894003, *pte=00606d000707
[ 2367.022822] Internal error: Oops: 9605 [#1] SMP
[ 2367.048490] Modules linked in: dm_mirror(E) dm_region_hash(E) dm_log(E)
dm_mod(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E) cry ptd(E)
aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E) ses(E) enclosure(E)
shpchp(E) marvell(E)
[ 2367.144808] CPU: 16 PID: 710 Comm: kworker/16:1 Tainted: GE
4.1.23-next.aarch64 #1
[ 2367.180161] Hardware name: Huawei Taishan 2280 /BC11SPCC,
BIOS 1.28 05/14/2016
[ 2367.213305] Workqueue: events ata_scsi_hotplug
[ 2367.244296] task: ffe7db9b5e00 ti: ffe7db1a
task.ti: ffe7db1a
[ 2367.279949] PC is at sas_find_dev_by_rphy+0x48/0x118
[ 2367.312045] LR is at sas_find_dev_by_rphy+0x40/0x118
[ 2367.341970] pc : [] lr : []
pstate: 0145
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110
[ 2368.940923] Code: aa1303e0 97ff5deb 3480 d1082273 (f943de76)

This because "dev_to_shost" in "sas_find_dev_by_rphy" return
a NULL point,and SHOST_TO_SAS_HA used it,so kernel panic happed.

why dev_to_shost return a NULL point?
Because in "__scsi_add_device" ,
struct device *parent = >shost_gendev,
and in "scsi_alloc_target", "*parent" is assigned to
"starget->dev.parent",then "sas_target_alloc" will get
"struct sas_rphy" according "starget->dev.parent", and in
"sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost"
according "rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent
is "ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at this moment,the libata hotplug task
will run and panic will happen.

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Signed-off-by: Ding Xiang 
---
 drivers/ata/libata-eh.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..4428a7c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,7 +816,8 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
+   else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
+!(ap->pflags & ATA_PFLAG_SAS_HOST))
schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
-- 
2.5.0

Re: [PATCH v7 00/12] Support non-lru page migration

[Sergey Senozhatsky]

INLINE enabled
[  319.363650] kasan: GPF could be caused by NULL-ptr deref or user memory 
access
[  319.363658] general protection fault:  [#1] PREEMPT SMP KASAN
[  319.363688] Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon 
crc32c_intel snd_hda_codec_realtek snd_hda_codec_generic r8169 mii i2c_i801 
snd_hda_intel snd_hda_codec snd_hda_core snd_pcm snd_timer acpi_cpufreq snd 
lpc_ich soundcore mfd_core processor sch_fq_codel sd_mod hid_generic usbhid hid 
ahci libahci ehci_pci libata ehci_hcd usbcore scsi_mod usb_common
[  319.363895] CPU: 0 PID: 45 Comm: kswapd0 Not tainted 
4.7.0-rc3-next-20160615-dbg-4-g550dc8a-dirty #490
[  319.363950] task: 8800bfb93d80 ti: 88011220 task.ti: 
88011220
[  319.363968] RIP: 0010:[]  [] 
zs_compact+0x2bd/0xf22 [zsmalloc]
[  319.364000] RSP: 0018:8801122077f8  EFLAGS: 00010293
[  319.364014] RAX: 2065676162726166 RBX: dc00 RCX: 
[  319.364032] RDX: 1064c504 RSI: 88003217c770 RDI: 83262ae0
[  319.364049] RBP: 880112207a18 R08: 0001 R09: 
[  319.364067] R10: 880112207768 R11: a19f2c26 R12: 8800a7caab00
[  319.364085] R13: 0770 R14: 8800a7caab78 R15: 
[  319.364103] FS:  () GS:88011360() 
knlGS:
[  319.364123] CS:  0010 DS:  ES:  CR0: 80050033
[  319.364138] CR2: 7fa154633d70 CR3: b183d000 CR4: 06f0
[  319.364154] Stack:
[  319.364160]  ed00163d6a81 110017f729b9 8800bfb944a0 
ed0017f729b9
[  319.364191]  8800bfb93d80 8800b1eb5408 8800bfb93d80 
8800bfb94dc8
[  319.364222]  8800bfb944f8 8801 110022440f1a 
41b58ab3
[  319.364252] Call Trace:
[  319.364264]  [] ? debug_show_all_locks+0x226/0x226
[  319.364284]  [] ? zs_free+0x27a/0x27a [zsmalloc]
[  319.364303]  [] ? list_lru_count_one+0x65/0x6d
[  319.364320]  [] ? lock_acquire+0xec/0x147
[  319.364336]  [] ? list_lru_count_one+0x39/0x6d
[  319.364353]  [] ? _raw_spin_unlock+0x2c/0x3f
[  319.364371]  [] zs_shrinker_scan+0x3b/0x4e [zsmalloc]
[  319.364391]  [] shrink_slab.part.5.constprop.17+0x2e4/0x432
[  319.364411]  [] ? cpu_callback+0xb0/0xb0
[  319.364426]  [] shrink_zone+0x19b/0x416
[  319.364442]  [] ? shrink_zone_memcg.isra.14+0xd08/0xd08
[  319.364461]  [] ? zone_watermark_ok_safe+0x1e9/0x1f8
[  319.364478]  [] ? zone_reclaimable+0x14b/0x170
[  319.364495]  [] kswapd+0xaad/0xcee
[  319.364510]  [] ? try_to_free_pages+0x617/0x617
[  319.364527]  [] ? trace_hardirqs_on_caller+0x3d2/0x492
[  319.364545]  [] ? prepare_to_wait_event+0x3f7/0x3f7
[  319.364564]  [] kthread+0x252/0x261
[  319.364578]  [] ? try_to_free_pages+0x617/0x617
[  319.364595]  [] ? kthread_create_on_node+0x377/0x377
[  319.364614]  [] ret_from_fork+0x1f/0x40
[  319.364629]  [] ? kthread_create_on_node+0x377/0x377
[  319.364645] Code: ff ff e8 67 d9 ff ff a8 01 0f 84 d9 02 00 00 48 83 e0 fe 
bf 01 00 00 00 48 89 85 b0 fe ff ff e8 71 78 d0 e0 48 8b 85 b0 fe ff ff  0f 
ba 28 00 0f 82 98 02 00 00 48 8b 85 10 fe ff ff 48 8d b8 
[  319.364913] RIP  [] zs_compact+0x2bd/0xf22 [zsmalloc]
[  319.364937]  RSP 
[  319.372870] ---[ end trace bcefd5a456f6b462 ]---



[  319.372875] BUG: sleeping function called from invalid context at 
include/linux/sched.h:2960
[  319.372877] in_atomic(): 1, irqs_disabled(): 0, pid: 45, name: kswapd0
[  319.372879] INFO: lockdep is turned off.
[  319.372880] Preemption disabled at:[] 
zs_compact+0x178/0xf22 [zsmalloc]

[  319.372891] CPU: 0 PID: 45 Comm: kswapd0 Tainted: G  D 
4.7.0-rc3-next-20160615-dbg-4-g550dc8a-dirty #490
[  319.372895]   880112207418 814d69b0 
8800bfb93d80
[  319.372901]  0003 880112207458 810d6165 

[  319.372906]  8800bfb93d80 81e39860 0b90 

[  319.372911] Call Trace:
[  319.372915]  [] dump_stack+0x68/0x92
[  319.372919]  [] ___might_sleep+0x3bd/0x3c9
[  319.372922]  [] __might_sleep+0x15b/0x167
[  319.372927]  [] exit_signals+0x7a/0x34f
[  319.372931]  [] ? get_signal+0xd9b/0xd9b
[  319.372934]  [] ? irq_work_queue+0x101/0x11c
[  319.372938]  [] ? debug_show_all_locks+0x226/0x226
[  319.372943]  [] do_exit+0x34d/0x1b4e
[  319.372947]  [] ? vprintk_emit+0x4b1/0x4d3
[  319.372951]  [] ? is_current_pgrp_orphaned+0x8c/0x8c
[  319.372954]  [] ? lock_acquire+0xec/0x147
[  319.372957]  [] ? kmsg_dump+0x12/0x27a
[  319.372961]  [] ? kmsg_dump+0x26b/0x27a
[  319.372965]  [] oops_end+0x9d/0xa4
[  319.372968]  [] die+0x55/0x5e
[  319.372971]  [] do_general_protection+0x16c/0x337
[  319.372975]  [] general_protection+0x1f/0x30
[  319.372981]  [] ? zs_compact+0x2bd/0xf22 [zsmalloc]
[  319.372986]  [] ? zs_compact+0x2b6/0xf22 [zsmalloc]
[  319.372989]  [] ? debug_show_all_locks+0x226/0x226
[  319.372995]  [] ? zs_free+0x27a/0x27a [zsmalloc]
[  319.372999]  [] ? list_lru_count_

Re: [PATCH v7 00/12] Support non-lru page migration

[Sergey Senozhatsky]

nked in: lzo zram zsmalloc mousedev coretemp hwmon 
crc32c_intel snd_hda_codec_realtek snd_hda_codec_generic r8169 mii i2c_i801 
snd_hda_intel snd_hda_codec snd_hda_core snd_pcm snd_timer acpi_cpufreq snd 
lpc_ich soundcore mfd_core processor sch_fq_codel sd_mod hid_generic usbhid hid 
ahci libahci ehci_pci libata ehci_hcd usbcore scsi_mod usb_common
[  319.363895] CPU: 0 PID: 45 Comm: kswapd0 Not tainted 
4.7.0-rc3-next-20160615-dbg-4-g550dc8a-dirty #490
[  319.363950] task: 8800bfb93d80 ti: 88011220 task.ti: 
88011220
[  319.363968] RIP: 0010:[]  [] 
zs_compact+0x2bd/0xf22 [zsmalloc]
[  319.364000] RSP: 0018:8801122077f8  EFLAGS: 00010293
[  319.364014] RAX: 2065676162726166 RBX: dc00 RCX: 
[  319.364032] RDX: 1064c504 RSI: 88003217c770 RDI: 83262ae0
[  319.364049] RBP: 880112207a18 R08: 0001 R09: 
[  319.364067] R10: 880112207768 R11: a19f2c26 R12: 8800a7caab00
[  319.364085] R13: 0770 R14: 8800a7caab78 R15: 
[  319.364103] FS:  () GS:88011360() 
knlGS:
[  319.364123] CS:  0010 DS:  ES:  CR0: 80050033
[  319.364138] CR2: 7fa154633d70 CR3: b183d000 CR4: 06f0
[  319.364154] Stack:
[  319.364160]  ed00163d6a81 110017f729b9 8800bfb944a0 
ed0017f729b9
[  319.364191]  8800bfb93d80 8800b1eb5408 8800bfb93d80 
8800bfb94dc8
[  319.364222]  8800bfb944f8 8801 110022440f1a 
41b58ab3
[  319.364252] Call Trace:
[  319.364264]  [] ? debug_show_all_locks+0x226/0x226
[  319.364284]  [] ? zs_free+0x27a/0x27a [zsmalloc]
[  319.364303]  [] ? list_lru_count_one+0x65/0x6d
[  319.364320]  [] ? lock_acquire+0xec/0x147
[  319.364336]  [] ? list_lru_count_one+0x39/0x6d
[  319.364353]  [] ? _raw_spin_unlock+0x2c/0x3f
[  319.364371]  [] zs_shrinker_scan+0x3b/0x4e [zsmalloc]
[  319.364391]  [] shrink_slab.part.5.constprop.17+0x2e4/0x432
[  319.364411]  [] ? cpu_callback+0xb0/0xb0
[  319.364426]  [] shrink_zone+0x19b/0x416
[  319.364442]  [] ? shrink_zone_memcg.isra.14+0xd08/0xd08
[  319.364461]  [] ? zone_watermark_ok_safe+0x1e9/0x1f8
[  319.364478]  [] ? zone_reclaimable+0x14b/0x170
[  319.364495]  [] kswapd+0xaad/0xcee
[  319.364510]  [] ? try_to_free_pages+0x617/0x617
[  319.364527]  [] ? trace_hardirqs_on_caller+0x3d2/0x492
[  319.364545]  [] ? prepare_to_wait_event+0x3f7/0x3f7
[  319.364564]  [] kthread+0x252/0x261
[  319.364578]  [] ? try_to_free_pages+0x617/0x617
[  319.364595]  [] ? kthread_create_on_node+0x377/0x377
[  319.364614]  [] ret_from_fork+0x1f/0x40
[  319.364629]  [] ? kthread_create_on_node+0x377/0x377
[  319.364645] Code: ff ff e8 67 d9 ff ff a8 01 0f 84 d9 02 00 00 48 83 e0 fe 
bf 01 00 00 00 48 89 85 b0 fe ff ff e8 71 78 d0 e0 48 8b 85 b0 fe ff ff  0f 
ba 28 00 0f 82 98 02 00 00 48 8b 85 10 fe ff ff 48 8d b8 
[  319.364913] RIP  [] zs_compact+0x2bd/0xf22 [zsmalloc]
[  319.364937]  RSP 
[  319.372870] ---[ end trace bcefd5a456f6b462 ]---



[  319.372875] BUG: sleeping function called from invalid context at 
include/linux/sched.h:2960
[  319.372877] in_atomic(): 1, irqs_disabled(): 0, pid: 45, name: kswapd0
[  319.372879] INFO: lockdep is turned off.
[  319.372880] Preemption disabled at:[] 
zs_compact+0x178/0xf22 [zsmalloc]

[  319.372891] CPU: 0 PID: 45 Comm: kswapd0 Tainted: G  D 
4.7.0-rc3-next-20160615-dbg-4-g550dc8a-dirty #490
[  319.372895]   880112207418 814d69b0 
8800bfb93d80
[  319.372901]  0003 880112207458 810d6165 

[  319.372906]  8800bfb93d80 81e39860 0b90 

[  319.372911] Call Trace:
[  319.372915]  [] dump_stack+0x68/0x92
[  319.372919]  [] ___might_sleep+0x3bd/0x3c9
[  319.372922]  [] __might_sleep+0x15b/0x167
[  319.372927]  [] exit_signals+0x7a/0x34f
[  319.372931]  [] ? get_signal+0xd9b/0xd9b
[  319.372934]  [] ? irq_work_queue+0x101/0x11c
[  319.372938]  [] ? debug_show_all_locks+0x226/0x226
[  319.372943]  [] do_exit+0x34d/0x1b4e
[  319.372947]  [] ? vprintk_emit+0x4b1/0x4d3
[  319.372951]  [] ? is_current_pgrp_orphaned+0x8c/0x8c
[  319.372954]  [] ? lock_acquire+0xec/0x147
[  319.372957]  [] ? kmsg_dump+0x12/0x27a
[  319.372961]  [] ? kmsg_dump+0x26b/0x27a
[  319.372965]  [] oops_end+0x9d/0xa4
[  319.372968]  [] die+0x55/0x5e
[  319.372971]  [] do_general_protection+0x16c/0x337
[  319.372975]  [] general_protection+0x1f/0x30
[  319.372981]  [] ? zs_compact+0x2bd/0xf22 [zsmalloc]
[  319.372986]  [] ? zs_compact+0x2b6/0xf22 [zsmalloc]
[  319.372989]  [] ? debug_show_all_locks+0x226/0x226
[  319.372995]  [] ? zs_free+0x27a/0x27a [zsmalloc]
[  319.372999]  [] ? list_lru_count_one+0x65/0x6d
[  319.373002]  [] ? lock_acquire+0xec/0x147
[  319.373005]  [] ? list_lru_count_one+0x39/0x6d
[  319.373009]  [] ? _raw_spin_unlock+0x2c/0x3f
[  319.373014]  [] zs_shr

[PATCH v3] mm/compaction: remove unnecessary order check in direct compact path

[Ganesh Mahendran]

In direct compact path, both __alloc_pages_direct_compact and
try_to_compact_pages check (order == 0).

This patch removes the check in __alloc_pages_direct_compact() and
move the modifying of current->flags to the entry point of direct
page compaction where we really do the compaction.

Signed-off-by: Ganesh Mahendran 
---
v2:
  remove the check in __alloc_pages_direct_compact - Anshuman Khandual
v3:
  remove check in __alloc_pages_direct_compact and move current->flags
  modifying to try_to_compact_pages
---
 mm/compaction.c | 7 ++-
 mm/page_alloc.c | 5 -
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index fbb7b38..dcfaf57 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1686,12 +1686,16 @@ enum compact_result try_to_compact_pages(gfp_t 
gfp_mask, unsigned int order,
 
*contended = COMPACT_CONTENDED_NONE;
 
-   /* Check if the GFP flags allow compaction */
+   /*
+* Check if this is an order-0 request and
+* if the GFP flags allow compaction.
+*/
if (!order || !may_enter_fs || !may_perform_io)
return COMPACT_SKIPPED;
 
trace_mm_compaction_try_to_compact_pages(order, gfp_mask, mode);
 
+   current->flags |= PF_MEMALLOC;
/* Compact each zone in the list */
for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx,
ac->nodemask) {
@@ -1768,6 +1772,7 @@ break_loop:
all_zones_contended = 0;
break;
}
+   current->flags &= ~PF_MEMALLOC;
 
/*
 * If at least one zone wasn't deferred or skipped, we report if all
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b9ea618..dd3a2b6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3173,13 +3173,8 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned 
int order,
struct page *page;
int contended_compaction;
 
-   if (!order)
-   return NULL;
-
-   current->flags |= PF_MEMALLOC;
*compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
mode, _compaction);
-   current->flags &= ~PF_MEMALLOC;
 
if (*compact_result <= COMPACT_INACTIVE)
return NULL;
-- 
1.9.1

[PATCH v3] mm/compaction: remove unnecessary order check in direct compact path

[Ganesh Mahendran]

In direct compact path, both __alloc_pages_direct_compact and
try_to_compact_pages check (order == 0).

This patch removes the check in __alloc_pages_direct_compact() and
move the modifying of current->flags to the entry point of direct
page compaction where we really do the compaction.

Signed-off-by: Ganesh Mahendran 
---
v2:
  remove the check in __alloc_pages_direct_compact - Anshuman Khandual
v3:
  remove check in __alloc_pages_direct_compact and move current->flags
  modifying to try_to_compact_pages
---
 mm/compaction.c | 7 ++-
 mm/page_alloc.c | 5 -
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index fbb7b38..dcfaf57 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1686,12 +1686,16 @@ enum compact_result try_to_compact_pages(gfp_t 
gfp_mask, unsigned int order,
 
*contended = COMPACT_CONTENDED_NONE;
 
-   /* Check if the GFP flags allow compaction */
+   /*
+* Check if this is an order-0 request and
+* if the GFP flags allow compaction.
+*/
if (!order || !may_enter_fs || !may_perform_io)
return COMPACT_SKIPPED;
 
trace_mm_compaction_try_to_compact_pages(order, gfp_mask, mode);
 
+   current->flags |= PF_MEMALLOC;
/* Compact each zone in the list */
for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx,
ac->nodemask) {
@@ -1768,6 +1772,7 @@ break_loop:
all_zones_contended = 0;
break;
}
+   current->flags &= ~PF_MEMALLOC;
 
/*
 * If at least one zone wasn't deferred or skipped, we report if all
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b9ea618..dd3a2b6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3173,13 +3173,8 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned 
int order,
struct page *page;
int contended_compaction;
 
-   if (!order)
-   return NULL;
-
-   current->flags |= PF_MEMALLOC;
*compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
mode, _compaction);
-   current->flags &= ~PF_MEMALLOC;
 
if (*compact_result <= COMPACT_INACTIVE)
return NULL;
-- 
1.9.1

Re: [alsa-devel] [PATCH v5] ASoC: rockchip: Add machine driver for RK3399 GRU Boards

[Ben Zhang]

On Wed, Jun 15, 2016 at 5:44 AM, Rob Herring  wrote:
> On Wed, Jun 15, 2016 at 4:53 AM, Mark Brown  wrote:
>> On Tue, Jun 14, 2016 at 05:38:10PM -0500, Rob Herring wrote:
>>> On Mon, Jun 13, 2016 at 04:42:18PM +0800, Xing Zheng wrote:
>>
>>> > +sound {
>>> > +   compatible = "rockchip,rk3399-gru-sound";
>>> > +   rockchip,cpu = <>;
>>> > +   rockchip,codec = <  >;
>>
>>> These seem fairly standard though a variety of versions in the bindings.
>>> Can we use audio-codec and audio-cpu (or cpu or audio-dai) here? Mark?
>>
>> Well, the roles aren't actually that standard (the fact that there's
>> multiple CODECs and one CPU DAI here is really odd and definitely needs
>> a very system specific interpretation).  If they were standard we
>> already have the simple-card binding that things should be using.
>> There's no point in standard property names if the interpretation has to
>> be non-standard.
>
> Okay, I agree with the system specific interpretation part. However, I
> don't think using simple-card or not determines using common
> properties.
>

Hi Mark, I have a question for the one CPU DAI + multiple CODECs
setup. The machine driver defines 3 DAI links, connecting the same CPU
DAI to 3 different CODEC DAIs. Does ASoC/DAPM support
enabling/disabling an individual DAI link based on the status of the
endpoint widget (e.g. DAPM_SPK) connected to the corresponding CODEC?

The goal is to let user select either headphone(da7219) or
speaker(max98357a) as output. max98357a driver does not expose a
kcontrol for mute. It sets a shutdown GPIO on PCM_TRIGGER_START/STOP.
And it seems soc_pcm_trigger calls the trigger op of all 3 CODEC DAIs,
even when the DAPM_SPK widget is disabled by its pin switch.

>> The vendor specific prefixes are there because all bindings are supposed
>> to add prefixes to property names.
>
> ...unless they are common.
>
> Rob
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Thanks,
Ben

Re: [alsa-devel] [PATCH v5] ASoC: rockchip: Add machine driver for RK3399 GRU Boards

[Ben Zhang]

On Wed, Jun 15, 2016 at 5:44 AM, Rob Herring  wrote:
> On Wed, Jun 15, 2016 at 4:53 AM, Mark Brown  wrote:
>> On Tue, Jun 14, 2016 at 05:38:10PM -0500, Rob Herring wrote:
>>> On Mon, Jun 13, 2016 at 04:42:18PM +0800, Xing Zheng wrote:
>>
>>> > +sound {
>>> > +   compatible = "rockchip,rk3399-gru-sound";
>>> > +   rockchip,cpu = <>;
>>> > +   rockchip,codec = <  >;
>>
>>> These seem fairly standard though a variety of versions in the bindings.
>>> Can we use audio-codec and audio-cpu (or cpu or audio-dai) here? Mark?
>>
>> Well, the roles aren't actually that standard (the fact that there's
>> multiple CODECs and one CPU DAI here is really odd and definitely needs
>> a very system specific interpretation).  If they were standard we
>> already have the simple-card binding that things should be using.
>> There's no point in standard property names if the interpretation has to
>> be non-standard.
>
> Okay, I agree with the system specific interpretation part. However, I
> don't think using simple-card or not determines using common
> properties.
>

Hi Mark, I have a question for the one CPU DAI + multiple CODECs
setup. The machine driver defines 3 DAI links, connecting the same CPU
DAI to 3 different CODEC DAIs. Does ASoC/DAPM support
enabling/disabling an individual DAI link based on the status of the
endpoint widget (e.g. DAPM_SPK) connected to the corresponding CODEC?

The goal is to let user select either headphone(da7219) or
speaker(max98357a) as output. max98357a driver does not expose a
kcontrol for mute. It sets a shutdown GPIO on PCM_TRIGGER_START/STOP.
And it seems soc_pcm_trigger calls the trigger op of all 3 CODEC DAIs,
even when the DAPM_SPK widget is disabled by its pin switch.

>> The vendor specific prefixes are there because all bindings are supposed
>> to add prefixes to property names.
>
> ...unless they are common.
>
> Rob
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Thanks,
Ben

Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

[Boqun Feng]

On Wed, Jun 15, 2016 at 03:01:19PM -0400, Waiman Long wrote:
> On 06/15/2016 04:04 AM, Boqun Feng wrote:
> > Hi Waiman,
> > 
> > On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
> > > The osq_lock() and osq_unlock() function may not provide the necessary
> > > acquire and release barrier in some cases. This patch makes sure
> > > that the proper barriers are provided when osq_lock() is successful
> > > or when osq_unlock() is called.
> > > 
> > > Signed-off-by: Waiman Long
> > > ---
> > >   kernel/locking/osq_lock.c |4 ++--
> > >   1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
> > > index 05a3785..7dd4ee5 100644
> > > --- a/kernel/locking/osq_lock.c
> > > +++ b/kernel/locking/osq_lock.c
> > > @@ -115,7 +115,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
> > >* cmpxchg in an attempt to undo our queueing.
> > >*/
> > > 
> > > - while (!READ_ONCE(node->locked)) {
> > > + while (!smp_load_acquire(>locked)) {
> > >   /*
> > >* If we need to reschedule bail... so we can block.
> > >*/
> > > @@ -198,7 +198,7 @@ void osq_unlock(struct optimistic_spin_queue *lock)
> > >* Second most likely case.
> > >*/
> > >   node = this_cpu_ptr(_node);
> > > - next = xchg(>next, NULL);
> > > + next = xchg_release(>next, NULL);
> > >   if (next) {
> > >   WRITE_ONCE(next->locked, 1);
> > So we still use WRITE_ONCE() rather than smp_store_release() here?
> > 
> > Though, IIUC, This is fine for all the archs but ARM64, because there
> > will always be a xchg_release()/xchg() before the WRITE_ONCE(), which
> > carries a necessary barrier to upgrade WRITE_ONCE() to a RELEASE.
> > 
> > Not sure whether it's a problem on ARM64, but I think we certainly need
> > to add some comments here, if we count on this trick.
> > 
> > Am I missing something or misunderstanding you here?
> > 
> > Regards,
> > Boqun
> 
> The change on the unlock side is more for documentation purpose than is
> actually needed. As you had said, the xchg() call has provided the necessary
> memory barrier. Using the _release variant, however, may have some

But I'm afraid the barrier doesn't remain if we replace xchg() with
xchg_release() on ARM64v8, IIUC, xchg_release() is just a ldxr+stlxr
loop with no barrier on ARM64v8. This means the following code:

CPU 0   CPU 1 (next)
==
WRITE_ONCE(x, 1);   r1 = 
smp_load_acquire(next->locked, 1);
xchg_release(>next, NULL);r2 = READ_ONCE(x);
WRITE_ONCE(next->locked, 1);

could result in (r1 == 1 && r2 == 0) on ARM64v8, IIUC.

I translated it into a litmus test:

AArch64 stlxr+str
""
{
0:X4=x; 0:X5=node; node=next;
1:X4=x; 1:X5=next;
}
 P0  | P1  ;
 MOV W0,#1   | LDAR W1,[X5];
 STR W0,[X4] | LDR W2,[X4] ;
 MOV X0,#0   | ;
 LDXR X2,[X5]| ;
 STLXR W1,X0,[X5]| ;
 CBNZ W1, fail   | ;
 MOV W0, #1  | ;
 STR W0,[X2] | ;
 fail:   | ;

exists
(0:X0 = 1 /\ 1:X1 = 1 /\ 1:X2 = 0)

and herd said "Sometimes".

But I may miss something here or make a mistake in the translation. So
add Will in Cc list ;-)

> performance benefit in some architectures.
> 
> BTW, osq_lock/osq_unlock aren't general purpose locking primitives. So there
> is some leeways on how fancy we want on the lock and unlock sides.
> 

Understood, I think it's fine if we rely on something subtle here, but
I just want to make we won't be bitten by some corner cases.

Regards,
Boqun

> Cheers,
> Longman


signature.asc
Description: PGP signature

Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

[Boqun Feng]

On Wed, Jun 15, 2016 at 03:01:19PM -0400, Waiman Long wrote:
> On 06/15/2016 04:04 AM, Boqun Feng wrote:
> > Hi Waiman,
> > 
> > On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
> > > The osq_lock() and osq_unlock() function may not provide the necessary
> > > acquire and release barrier in some cases. This patch makes sure
> > > that the proper barriers are provided when osq_lock() is successful
> > > or when osq_unlock() is called.
> > > 
> > > Signed-off-by: Waiman Long
> > > ---
> > >   kernel/locking/osq_lock.c |4 ++--
> > >   1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
> > > index 05a3785..7dd4ee5 100644
> > > --- a/kernel/locking/osq_lock.c
> > > +++ b/kernel/locking/osq_lock.c
> > > @@ -115,7 +115,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
> > >* cmpxchg in an attempt to undo our queueing.
> > >*/
> > > 
> > > - while (!READ_ONCE(node->locked)) {
> > > + while (!smp_load_acquire(>locked)) {
> > >   /*
> > >* If we need to reschedule bail... so we can block.
> > >*/
> > > @@ -198,7 +198,7 @@ void osq_unlock(struct optimistic_spin_queue *lock)
> > >* Second most likely case.
> > >*/
> > >   node = this_cpu_ptr(_node);
> > > - next = xchg(>next, NULL);
> > > + next = xchg_release(>next, NULL);
> > >   if (next) {
> > >   WRITE_ONCE(next->locked, 1);
> > So we still use WRITE_ONCE() rather than smp_store_release() here?
> > 
> > Though, IIUC, This is fine for all the archs but ARM64, because there
> > will always be a xchg_release()/xchg() before the WRITE_ONCE(), which
> > carries a necessary barrier to upgrade WRITE_ONCE() to a RELEASE.
> > 
> > Not sure whether it's a problem on ARM64, but I think we certainly need
> > to add some comments here, if we count on this trick.
> > 
> > Am I missing something or misunderstanding you here?
> > 
> > Regards,
> > Boqun
> 
> The change on the unlock side is more for documentation purpose than is
> actually needed. As you had said, the xchg() call has provided the necessary
> memory barrier. Using the _release variant, however, may have some

But I'm afraid the barrier doesn't remain if we replace xchg() with
xchg_release() on ARM64v8, IIUC, xchg_release() is just a ldxr+stlxr
loop with no barrier on ARM64v8. This means the following code:

CPU 0   CPU 1 (next)
==
WRITE_ONCE(x, 1);   r1 = 
smp_load_acquire(next->locked, 1);
xchg_release(>next, NULL);r2 = READ_ONCE(x);
WRITE_ONCE(next->locked, 1);

could result in (r1 == 1 && r2 == 0) on ARM64v8, IIUC.

I translated it into a litmus test:

AArch64 stlxr+str
""
{
0:X4=x; 0:X5=node; node=next;
1:X4=x; 1:X5=next;
}
 P0  | P1  ;
 MOV W0,#1   | LDAR W1,[X5];
 STR W0,[X4] | LDR W2,[X4] ;
 MOV X0,#0   | ;
 LDXR X2,[X5]| ;
 STLXR W1,X0,[X5]| ;
 CBNZ W1, fail   | ;
 MOV W0, #1  | ;
 STR W0,[X2] | ;
 fail:   | ;

exists
(0:X0 = 1 /\ 1:X1 = 1 /\ 1:X2 = 0)

and herd said "Sometimes".

But I may miss something here or make a mistake in the translation. So
add Will in Cc list ;-)

> performance benefit in some architectures.
> 
> BTW, osq_lock/osq_unlock aren't general purpose locking primitives. So there
> is some leeways on how fancy we want on the lock and unlock sides.
> 

Understood, I think it's fine if we rely on something subtle here, but
I just want to make we won't be bitten by some corner cases.

Regards,
Boqun

> Cheers,
> Longman


signature.asc
Description: PGP signature