[PATCH v2 2/3] ARM: dts: sun8i: Use the common file in NanoPi NEO SBC

2016-10-28 Thread Milo Kim
NanoPi common dtsi supports all components of NEO SBC, so just include it.

Cc: James Pettigrew 
Signed-off-by: Milo Kim 
---
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 79 +--
 1 file changed, 1 insertion(+), 78 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
index 3d64caf..8d2cc6e 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
@@ -40,86 +40,9 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
-/dts-v1/;
-#include "sun8i-h3.dtsi"
-#include "sunxi-common-regulators.dtsi"
-
-#include 
-#include 
+#include "sun8i-h3-nanopi.dtsi"
 
 / {
model = "FriendlyARM NanoPi NEO";
compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
-
-   aliases {
-   serial0 = &uart0;
-   };
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
-   leds {
-   compatible = "gpio-leds";
-   pinctrl-names = "default";
-   pinctrl-0 = <&leds_opc>, <&leds_r_opc>;
-
-   pwr {
-   label = "nanopi:green:pwr";
-   gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
-   default-state = "on";
-   };
-
-   status {
-   label = "nanopi:blue:status";
-   gpios = <&pio 0 10 GPIO_ACTIVE_HIGH>; /* PA10 */
-   };
-   };
-};
-
-&ehci3 {
-   status = "okay";
-};
-
-&mmc0 {
-   pinctrl-names = "default";
-   pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
-   vmmc-supply = <®_vcc3v3>;
-   bus-width = <4>;
-   cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-   cd-inverted;
-   status = "okay";
-};
-
-&ohci3 {
-   status = "okay";
-};
-
-&pio {
-   leds_opc: led-pins {
-   allwinner,pins = "PA10";
-   allwinner,function = "gpio_out";
-   allwinner,drive = ;
-   allwinner,pull = ;
-   };
-};
-
-&r_pio {
-   leds_r_opc: led-pins {
-   allwinner,pins = "PL10";
-   allwinner,function = "gpio_out";
-   allwinner,drive = ;
-   allwinner,pull = ;
-   };
-};
-
-&uart0 {
-   pinctrl-names = "default";
-   pinctrl-0 = <&uart0_pins_a>;
-   status = "okay";
-};
-
-&usbphy {
-   /* USB VBUS is always on */
-   status = "okay";
 };
-- 
2.9.3



[PATCH v2 1/3] ARM: dts: sun8i: Add common dtsi file for NanoPi SBCs

2016-10-28 Thread Milo Kim
This patch provides a common file for NanoPi M1 and Neo SBC.

Those have common features below.
  * UART0
  * 2 LEDs
  * USB host (EHCI3, OHCI3) and PHY
  * MicroSD
  * GPIO key switch

Cc: James Pettigrew 
Signed-off-by: Milo Kim 
---
 arch/arm/boot/dts/sun8i-h3-nanopi.dtsi | 144 +
 1 file changed, 144 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi.dtsi

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi 
b/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi
new file mode 100644
index 000..8038aa2
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2016 James Pettigrew 
+ * Copyright (C) 2016 Milo Kim 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&leds_npi>, <&leds_r_npi>;
+
+   status {
+   label = "nanopi:blue:status";
+   gpios = <&pio 0 10 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+
+   pwr {
+   label = "nanopi:green:pwr";
+   gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+
+   r_gpio_keys {
+   compatible = "gpio-keys";
+   input-name = "k1";
+   pinctrl-names = "default";
+   pinctrl-0 = <&sw_r_npi>;
+
+   k1@0 {
+   label = "k1";
+   linux,code = ;
+   gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+&ehci3 {
+   status = "okay";
+};
+
+&mmc0 {
+   bus-width = <4>;
+   cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+   cd-inverted;
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+   status = "okay";
+   vmmc-supply = <®_vcc3v3>;
+};
+
+&ohci3 {
+   status = "okay";
+};
+
+&pio {
+   leds_npi: led_pins@0 {
+   allwinner,pins = "PA10";
+   allwinner,function = "gpio_out";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+};
+
+&r_pio {
+   leds_r_npi: led_pins@0 {
+   allwinner,pins = "PL10";
+   allwinner,function = "gpio_out";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   sw_r_npi: key_pins@0 {
+   allwinner,pins = "PL3";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+};
+
+&uart0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart0_pins_a>;
+   status = 

[PATCH v2 3/3] ARM: dts: sun8i: Add dts file for NanoPi M1 SBC

2016-10-28 Thread Milo Kim
NanoPi M1 is the Allwinner H3 based board.
This patch enables UART for debug console, LEDs, GPIO key switch, 3 USB
host ports, a micro SD slot and related power and pin controls by using
NanoPi common dtsi file.

Cc: James Pettigrew 
Signed-off-by: Milo Kim 
---
 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 64 
 1 file changed, 64 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
new file mode 100644
index 000..ec63d10
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2016 Milo Kim 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun8i-h3-nanopi.dtsi"
+
+/ {
+   model = "FriendlyArm NanoPi M1";
+   compatible = "friendlyarm,nanopi-m1", "allwinner,sun8i-h3";
+};
+
+&ehci1 {
+   status = "okay";
+};
+
+&ehci2 {
+   status = "okay";
+};
+
+&ohci1 {
+   status = "okay";
+};
+
+&ohci2 {
+   status = "okay";
+};
-- 
2.9.3



[PATCH v2 0/3] ARM: dts: sun8i: Support NanoPi SBCs

2016-10-28 Thread Milo Kim
NanoPi M1 and NEO have common features, so duplicate properties can be 
moved into new dtsi file.

v2:
  Add James's copyrights in NanoPi common dtsi file 

Milo Kim (3):
  ARM: dts: sun8i: Add common dtsi file for NanoPi SBCs
  ARM: dts: sun8i: Use the common file in NanoPi NEO SBC
  ARM: dts: sun8i: Add dts file for NanoPi M1 SBC

 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts  |  64 +
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts |  79 +---
 arch/arm/boot/dts/sun8i-h3-nanopi.dtsi| 144 ++
 3 files changed, 209 insertions(+), 78 deletions(-)
 create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
 create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi.dtsi

-- 
2.9.3



RE: [patch v1 1/2] drivers/platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

2016-10-28 Thread Vadim Pasternak


> -Original Message-
> From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
> Sent: Thursday, October 27, 2016 4:59 PM
> To: Vadim Pasternak ; dvh...@infradead.org;
> fengguang...@intel.com
> Cc: da...@davemloft.net; ge...@linux-m68k.org; akpm@linux-
> foundation.org; kv...@codeaurora.org; gre...@linuxfoundation.org;
> mche...@kernel.org; li...@roeck-us.net; linux-kernel@vger.kernel.org;
> platform-driver-...@vger.kernel.org; j...@resnulli.us
> Subject: Re: [patch v1 1/2] drivers/platform/x86: move module mlx-platform
> from arch/x86 to drivers/platform/x86
> 
> On Thu, 2016-10-27 at 13:59 +, vad...@mellanox.com wrote:
> > From: Vadim Pasternak 
> >
> > Move module mlx-platform.c from arch/x86/platform/mellanox/ to
> > drivers/platform/x86/.
> > Remove folder arch/x86/platform/mellanox/ and update relevant Makefile
> > and Kconfig.
> 
> No way, please use -M -C.
> 


Hi Andy,

I am afraid I didn't understand your comment.
Could you, please, add some more details?

Thanks,
Vadim.

> >
> > Signed-off-by: Vadim Pasternak 
> > ---
> >  MAINTAINERS   |   2 +-
> >  arch/x86/Kconfig  |  12 --
> >  arch/x86/platform/Makefile|   1 -
> >  arch/x86/platform/mellanox/Makefile   |   1 -
> >  arch/x86/platform/mellanox/mlx-platform.c | 266 ---
> > ---
> >  drivers/platform/x86/Kconfig  |  14 +-
> >  drivers/platform/x86/Makefile |   1 +
> >  drivers/platform/x86/mlx-platform.c   | 266
> > ++
> >  8 files changed, 281 insertions(+), 282 deletions(-)
> >  delete mode 100644 arch/x86/platform/mellanox/Makefile
> >  delete mode 100644 arch/x86/platform/mellanox/mlx-platform.c
> >  create mode 100644 drivers/platform/x86/mlx-platform.c
> 
> 
> --
> Andy Shevchenko 
> Intel Finland Oy


[v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl

2016-10-28 Thread Yangbo Lu
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
header file.  This SVR numberspace is used on some ARM chips as well as
PPC, and even to check for a PPC SVR multi-arch drivers would otherwise
need to ifdef the header inclusion and all references to the SVR symbols.

Signed-off-by: Yangbo Lu 
Acked-by: Wolfram Sang 
Acked-by: Stephen Boyd 
Acked-by: Joerg Roedel 
[scottwood: update description]
Signed-off-by: Scott Wood 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include ' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- Updated description by Scott
Changes for v12:
- None
Changes for v13:
- None
Changes for v14:
- None
Changes for v15:
- None
---
 arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
 arch/powerpc/sysdev/fsl_pci.c | 2 +-
 drivers/clk/clk-qoriq.c   | 3 +--
 drivers/i2c/busses/i2c-mpc.c  | 2 +-
 drivers/iommu/fsl_pamu.c  | 3 +--
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
 7 files changed, 8 insertions(+), 10 deletions(-)
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 _GLOBAL(__e500_icache_setup)
mfspr   r0, SPRN_L1CSR1
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index d3a5974..cb0efea 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 20b1055..dc778e8 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1153,8 +1154,6 @@ static struct clk *clockgen_clk_get(struct 
of_phandle_args *clkspec, void *data)
 }
 
 #ifdef CONFIG_PPC
-#include 
-
 static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10,/* P2040 1.0 */
(SVR_P2040 << 8) | 0x11,/* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 565a49a..e791c51 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 
 #define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
 #include "fsl_pamu.h"
 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 /* define indexes for each operation mapping scenario */
 #define OMI_QMAN0x00
 #define OMI_FMAN0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index 4b4f5bc..55be5ce 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #ifdef CONFIG_PPC
 #include 
-#include 
 #endif
 #include 
 #include 
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
  * (at your option) any later version.
  */
 
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
 
 #define SVR_REV(svr)   ((svr) & 0xFF)  /* SOC design resision */
 #define SVR_MAJ(svr)   (((svr) >>  4) & 0xF)   /* Major revision field*/
-- 
2.1.0.27.g96db324



[v15, 1/7] ARM64: dts: ls2080a: add device configuration node

2016-10-28 Thread Yangbo Lu
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.

Signed-off-by: Yangbo Lu 
Acked-by: Scott Wood 
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- None
Changes for v12:
- None
Changes for v13:
- None
Changes for v14:
- None
Changes for v15:
- None
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 337da90..c03b099 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -215,6 +215,12 @@
clocks = <&sysclk>;
};
 
+   dcfg: dcfg@1e0 {
+   compatible = "fsl,ls2080a-dcfg", "syscon";
+   reg = <0x0 0x1e0 0x0 0x1>;
+   little-endian;
+   };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
-- 
2.1.0.27.g96db324



[v15, 0/7] Fix eSDHC host version register bug

2016-10-28 Thread Yangbo Lu
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To match the SoC version and revision, 10 previous version
patchsets had tried many methods but all of them were rejected by reviewers.
Such as
- dts compatible method
- syscon method
- ifdef PPC method
- GUTS driver getting SVR method
Anrd suggested a soc_device_match method in v10, and this is the only available
method left now. This v11 patchset introduces the soc_device_match interface in
soc driver.

The first five patches of Yangbo are to add the GUTS driver. This is used to
register a soc device which contain soc version and revision information.
The other two patches introduce the soc_device_match method in soc driver
and apply it on esdhc driver to fix this bug.

---
Changes for v15:
- Dropped patch 'dt: bindings: update Freescale DCFG compatible'
  since the work had been done by below patch on ShawnGuo's linux tree.
  'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG
   and DCFG'
- Fixed error code issue in guts driver
---

Arnd Bergmann (1):
  base: soc: introduce soc_device_match() interface

Yangbo Lu (6):
  ARM64: dts: ls2080a: add device configuration node
  dt: bindings: move guts devicetree doc out of powerpc directory
  powerpc/fsl: move mpc85xx.h to include/linux/fsl
  soc: fsl: add GUTS driver for QorIQ platforms
  MAINTAINERS: add entry for Freescale SoC drivers
  mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

 .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
 MAINTAINERS|  11 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
 arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
 arch/powerpc/sysdev/fsl_pci.c  |   2 +-
 drivers/base/Kconfig   |   1 +
 drivers/base/soc.c |  66 ++
 drivers/clk/clk-qoriq.c|   3 +-
 drivers/i2c/busses/i2c-mpc.c   |   2 +-
 drivers/iommu/fsl_pamu.c   |   3 +-
 drivers/mmc/host/Kconfig   |   1 +
 drivers/mmc/host/sdhci-of-esdhc.c  |  20 ++
 drivers/net/ethernet/freescale/gianfar.c   |   2 +-
 drivers/soc/Kconfig|   3 +-
 drivers/soc/fsl/Kconfig|  18 ++
 drivers/soc/fsl/Makefile   |   1 +
 drivers/soc/fsl/guts.c | 237 +
 include/linux/fsl/guts.h   | 125 ++-
 .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
 include/linux/sys_soc.h|   3 +
 20 files changed, 452 insertions(+), 61 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/guts.c
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

-- 
2.1.0.27.g96db324



Re: [REVIEW][PATCH v2] mm: Add a user_ns owner to mm_struct and fix ptrace permission checks

2016-10-28 Thread Cyrill Gorcunov
On Thu, Oct 27, 2016 at 11:45:37PM -0500, Eric W. Biederman wrote:
> 
> Mind if I add your tested-by?
> 
> To see Linus's tree fail with my patch you can apply the patch below.
> That is the essence of what I changed to fix things.  Just ignoring
> dumpable when an mm exists.

Tested-by: Cyrill Gorcunov 

Thanks a huge!


[v15, 2/7] dt: bindings: move guts devicetree doc out of powerpc directory

2016-10-28 Thread Yangbo Lu
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.

Signed-off-by: Yangbo Lu 
Acked-by: Rob Herring 
Acked-by: Scott Wood 
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- None
Changes for v12:
- None
Changes for v13:
- None
Changes for v14:
- None
Changes for v15:
- None
---
 Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
 1 file changed, 3 insertions(+)
 rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt 
b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
  - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
 
+ - little-endian : Indicates that the global utilities block is little
+   endian. The default is big endian.
+
 Examples:
global-utilities@e {/* global utilities block */
compatible = "fsl,mpc8548-guts";
-- 
2.1.0.27.g96db324



[v15, 5/7] MAINTAINERS: add entry for Freescale SoC drivers

2016-10-28 Thread Yangbo Lu
Add maintainer entry for Freescale SoC drivers including
the QE library and the GUTS driver now. Also add maintainer
for QE library.

Signed-off-by: Yangbo Lu 
Acked-by: Scott Wood 
Acked-by: Qiang Zhao 
---
Changes for v8:
- Added this patch
Changes for v9:
- Added linux-arm mail list
- Removed GUTS driver entry
Changes for v10:
- Changed 'DRIVER' to 'DRIVERS'
- Added 'Acked-by' of Scott and Qiang
Changes for v11:
- None
Changes for v12:
- None
Changes for v13:
- None
Changes for v14:
- None
Changes for v15:
- None
---
 MAINTAINERS | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c72fa18..cf3aaee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5037,9 +5037,18 @@ S:   Maintained
 F: drivers/net/ethernet/freescale/fman
 F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt
 
+FREESCALE SOC DRIVERS
+M: Scott Wood 
+L: linuxppc-...@lists.ozlabs.org
+L: linux-arm-ker...@lists.infradead.org
+S: Maintained
+F: drivers/soc/fsl/
+F: include/linux/fsl/
+
 FREESCALE QUICC ENGINE LIBRARY
+M: Qiang Zhao 
 L: linuxppc-...@lists.ozlabs.org
-S: Orphan
+S: Maintained
 F: drivers/soc/fsl/qe/
 F: include/soc/fsl/*qe*.h
 F: include/soc/fsl/*ucc*.h
-- 
2.1.0.27.g96db324



[v15, 4/7] soc: fsl: add GUTS driver for QorIQ platforms

2016-10-28 Thread Yangbo Lu
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.

This patch adds a driver to manage and access global utilities block.
Initially only reading SVR and registering soc device are supported.
Other guts accesses, such as reading RCW, should eventually be moved
into this driver as well.

Signed-off-by: Yangbo Lu 
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
Changes for v8:
- Fixes lines longer than 80 characters checkpatch issue
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- Changed to platform driver
Changes for v12:
- Removed "signed-off-by: Scott"
- Defined fsl_soc_die_attr struct array instead of
  soc_device_attribute
- Re-designed soc_device_attribute for QorIQ SoC
- Other minor fixes
Changes for v13:
- Rebased
- Removed text after 'bool' in Kconfig
- Removed ARCH ifdefs
- Added more bits for ls1021a mask
- Used devm
Changes for v14:
- Used devm_ioremap_resource
Changes for v15:
- Fixed error code for devm_ioremap_resource
---
 drivers/soc/Kconfig  |   3 +-
 drivers/soc/fsl/Kconfig  |  18 
 drivers/soc/fsl/Makefile |   1 +
 drivers/soc/fsl/guts.c   | 237 +++
 include/linux/fsl/guts.h | 125 +++--
 5 files changed, 334 insertions(+), 50 deletions(-)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/guts.c

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index e6e90e8..f31bceb 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,8 +1,7 @@
 menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/bcm/Kconfig"
-source "drivers/soc/fsl/qbman/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000..7a9fb9b
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,18 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qbman/Kconfig"
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+   bool
+   select SOC_BUS
+   help
+ The global utilities block controls power management, I/O device
+ enabling, power-onreset(POR) configuration monitoring, alternate
+ function selection for multiplexed signals,and clock control.
+ This driver is to manage and access global utilities block.
+ Initially only reading SVR and registering soc device are supported.
+ Other guts accesses, such as reading RCW, should eventually be moved
+ into this driver as well.
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 75e1f53..44b3beb 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_FSL_DPAA) += qbman/
 obj-$(CONFIG_QUICC_ENGINE) += qe/
 obj-$(CONFIG_CPM)  += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 000..e564d1a
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,237 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct guts {
+   struct ccsr_guts __iomem *regs;
+   bool little_endian;
+};
+
+struct fsl_soc_die_attr {
+   char*die;
+   u32 svr;
+   u32 mask;
+};
+
+static struct guts *guts;
+static struct soc_device_attribute soc_dev_attr;
+static struct soc_device *soc_dev;
+
+
+/* SoC die attribute definition for QorIQ platform */
+static const struct fsl_soc_die_attr fsl_soc_

[v15, 6/7] base: soc: introduce soc_device_match() interface

2016-10-28 Thread Yangbo Lu
From: Arnd Bergmann 

We keep running into cases where device drivers want to know the exact
version of the a SoC they are currently running on. In the past, this has
usually been done through a vendor specific API that can be called by a
driver, or by directly accessing some kind of version register that is
not part of the device itself but that belongs to a global register area
of the chip.

Common reasons for doing this include:

- A machine is not using devicetree or similar for passing data about
  on-chip devices, but just announces their presence using boot-time
  platform devices, and the machine code itself does not care about the
  revision.

- There is existing firmware or boot loaders with existing DT binaries
  with generic compatible strings that do not identify the particular
  revision of each device, but the driver knows which SoC revisions
  include which part.

- A prerelease version of a chip has some quirks and we are using the same
  version of the bootloader and the DT blob on both the prerelease and the
  final version. An update of the DT binding seems inappropriate because
  that would involve maintaining multiple copies of the dts and/or
  bootloader.

This patch introduces the soc_device_match() interface that is meant to
work like of_match_node() but instead of identifying the version of a
device, it identifies the SoC itself using a vendor-agnostic interface.

Unlike of_match_node(), we do not do an exact string compare but instead
use glob_match() to allow wildcards in strings.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Yangbo Lu 
Acked-by: Greg Kroah-Hartman 
---
Changes for v11:
- Added this patch for soc match
Changes for v12:
- Corrected the author
- Rewrited soc_device_match with while loop
Changes for v13:
- Added ack from Greg
Changes for v14:
- None
Changes for v15:
- None
---
 drivers/base/Kconfig|  1 +
 drivers/base/soc.c  | 66 +
 include/linux/sys_soc.h |  3 +++
 3 files changed, 70 insertions(+)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index fdf44ca..991b21e 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -235,6 +235,7 @@ config GENERIC_CPU_AUTOPROBE
 
 config SOC_BUS
bool
+   select GLOB
 
 source "drivers/base/regmap/Kconfig"
 
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index b63f23e..0c5cf87 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static DEFINE_IDA(soc_ida);
 
@@ -159,3 +160,68 @@ static int __init soc_bus_register(void)
return bus_register(&soc_bus_type);
 }
 core_initcall(soc_bus_register);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+   struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+   const struct soc_device_attribute *match = arg;
+
+   if (match->machine &&
+   !glob_match(match->machine, soc_dev->attr->machine))
+   return 0;
+
+   if (match->family &&
+   !glob_match(match->family, soc_dev->attr->family))
+   return 0;
+
+   if (match->revision &&
+   !glob_match(match->revision, soc_dev->attr->revision))
+   return 0;
+
+   if (match->soc_id &&
+   !glob_match(match->soc_id, soc_dev->attr->soc_id))
+   return 0;
+
+   return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+const struct soc_device_attribute *soc_device_match(
+   const struct soc_device_attribute *matches)
+{
+   int ret = 0;
+
+   if (!matches)
+   return NULL;
+
+   while (!ret) {
+   if (!(matches->machine || matches->family ||
+ matches->revision || matches->soc_id))
+   break;
+   ret = bus_for_each_dev(&soc_bus_type, NULL, (void *)matches,
+  soc_device_match_one);
+   if (!ret)
+   matches++;
+   else
+   return matches;
+   }
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb..9f5eb06 10

[v15, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

2016-10-28 Thread Yangbo Lu
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to match SoC.
And fix host version to avoid that incorrect version numbers break down
the ADMA data transfer.

Signed-off-by: Yangbo Lu 
Acked-by: Ulf Hansson 
Acked-by: Scott Wood 
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- Changed to use soc_device_match
Changes for v12:
- Matched soc through .family field instead of .soc_id
Changes for v13:
- None
Changes for v14:
- None
Changes for v15:
- None
---
 drivers/mmc/host/Kconfig  |  1 +
 drivers/mmc/host/sdhci-of-esdhc.c | 20 
 2 files changed, 21 insertions(+)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 5274f50..a1135a9 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -144,6 +144,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+   select FSL_GUTS
help
  This selects the Freescale eSDHC controller support.
 
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
b/drivers/mmc/host/sdhci-of-esdhc.c
index fb71c86..57bdb9e 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "sdhci-pltfm.h"
 #include "sdhci-esdhc.h"
@@ -28,6 +29,7 @@
 struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+   bool quirk_incorrect_hostver;
 };
 
 /**
@@ -73,6 +75,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
 static u16 esdhc_readw_fixup(struct sdhci_host *host,
 int spec_reg, u32 value)
 {
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
 
@@ -80,6 +84,12 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0x;
else
ret = (value >> shift) & 0x;
+   /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+* vendor version and spec version information.
+*/
+   if ((spec_reg == SDHCI_HOST_VERSION) &&
+   (esdhc->quirk_incorrect_hostver))
+   ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
 }
 
@@ -558,6 +568,12 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata 
= {
.ops = &sdhci_esdhc_le_ops,
 };
 
+static struct soc_device_attribute soc_incorrect_hostver[] = {
+   { .family = "QorIQ T4240", .revision = "1.0", },
+   { .family = "QorIQ T4240", .revision = "2.0", },
+   { },
+};
+
 static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
 {
struct sdhci_pltfm_host *pltfm_host;
@@ -571,6 +587,10 @@ static void esdhc_init(struct platform_device *pdev, 
struct sdhci_host *host)
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
 SDHCI_VENDOR_VER_SHIFT;
esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;
+   if (soc_device_match(soc_incorrect_hostver))
+   esdhc->quirk_incorrect_hostver = true;
+   else
+   esdhc->quirk_incorrect_hostver = false;
 }
 
 static int sdhci_esdhc_probe(struct platform_device *pdev)
-- 
2.1.0.27.g96db324



Re: rowhammer protection [was Re: Getting interrupt every million cache misses]

2016-10-28 Thread Ingo Molnar

* Pavel Machek  wrote:

> +static void rh_overflow(struct perf_event *event, struct perf_sample_data 
> *data, struct pt_regs *regs)
> +{
> + u64 *ts = this_cpu_ptr(&rh_timestamp); /* this is NMI context */
> + u64 now = ktime_get_mono_fast_ns();
> + s64 delta = now - *ts;
> +
> + *ts = now;
> +
> + /* FIXME msec per usec, reverse logic? */
> + if (delta < 64 * NSEC_PER_MSEC)
> + mdelay(56);
> +}

I'd suggest making the absolute delay sysctl tunable, because 'wait 56 msecs' 
is 
very magic, and do we know it 100% that 56 msecs is what is needed everywhere?

Plus I'd also suggest exposing an 'NMI rowhammer delay count' in 
/proc/interrupts, 
to make it easier to debug this. (Perhaps only show the line if the count is 
nonzero.)

Finally, could we please also add a sysctl and Kconfig that allows this feature 
to 
be turned on/off, with the default bootup value determined by the Kconfig value 
(i.e. by the distribution)? Similar to CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE.

Thanks,

Ingo


[RFC PATCH 0/3] sched: Introduce Window Assisted Load Tracking

2016-10-28 Thread Vikram Mulukutla

We propose Window-Assisted Load Tracking (WALT) as an alternative or additional
load tracking scheme in lieu of or along with PELT, one that in our estimation
better tracks task demand and CPU utilization especially for use cases on
mobile devices. WALT was conceived by Srivatsa Vaddagiri to provide better
perf-per-watt numbers on asymmetric CPU (frequency and/or IPC) implementations,
(specifically on Qualcomm Snapgdragon chipsets running Android) and its metrics
have been used to guide task placement and p-state selection (load balancing
in CFS still uses PELT statistics). WALT is now present in the android-common
kernel as well. This RFC is not an attempt to supplant PELT statistics; this is
more about starting a discussion; perhaps one that may result in changes to
PELT to address the requirements listed below.

Background
__

1) Classifying a task as "heavy" faster helps in mobile world use-cases such as
scrolling a UI or browsing a web page where tasks exhibit sporadically heavy
load, allowing for instance, faster migration to a more capable CPU (assuming
the scheduler uses task util and CPU capacity as inputs during task placement
decision making, e.g EAS). Reclassification of a light task as heavy is also
important - for example, a rendering thread may change its demand depending on
what is being shown on-screen. We believe that quickly associating a task with
its necessary resources requires a more dynamic demand or utilization signal
than provided by PELT, which is subject to the geometric series and does not
differentiate between task ramp-up and ramp-down. E.g, with a 32ms halflife,
PELT takes ~74ms to reach 80% nice-0-load_avg/util_avg for a continuously
executing 100% task, and ~139ms to reach 95%.

2) Historical task demand (even if a task sleeps for say 300ms due to network
delay) is required to restore both CPU and frequency resources to meet
performance throughput as well. PELT with a 32ms 'half-life' takes just ~213ms
to decay utilization/load (effectively) zero, forgetting that task's history,
requiring the task to re-execute its workload to gain that load_avg/util_avg
again.

3) There is a need to quickly ramp up CPU frequency as a result of heavy CPU
utilization, and to reduce frequency whenever possible to save power.
Consider as an example a single 100% thread running continuously on a single
core using schedutil with a 10ms transition latency. On an i7 8-core SMP
machine with SMT, PELT takes 60-70ms to ramp to FMAX from FMIN.

4) PELT's blocked util decay implies that the underlying cpufreq governor would
have to delay dropping frequency for longer than necessary (especially for
mobile world usecases). PELT with a 32ms 'half-life' takes ~108ms to reduce
the runqueue utilization/nice-0-load from max to 10%. Blocked load/util tracking
is of course a conservative approach recognizing that load might return to
the runqueue, but one that we feel is inflexible when it comes to certain real
world use cases.

WALT vs PELT


WALT retains the per-entity properties of PELT; demand and utilization are
accounted for at the task level, and a CPU rq's utilization contribution is
the sum of its children's contributions. Wallclock time, however, is divided
into a series of windows - to be clear about what WALT tracks exactly, we
introduce the terms task demand and CPU busy-time here and show the benefits
versus PELT that apply to the four points mentioned above:

1) Task Demand - The contribution of a task's running and runnable time to a
window, averaged over N sliding windows. Note that a window has to be
*completed* before its contribution is considered. A task's demand is the
maximum of its contribution to the most recently completed window and its
average demand over the past N windows. This metric can be roughly thought of as
an unweighted load_avg without blocked load.
WALT can take as little as one window of execution to report max task demand,
although with freq and capacity invariance, this tends to be about 3 windows
with a good frequency governor (so that's about 30ms with a 10ms window). This
allows faster and more accurate task placement decisions.

2) WALT "forgets" blocked time entirely, i.e. the sliding windows exist only
when the task is on the runqueue or running. This allows rapid reclassification
of the same task as heavy after a short sleep. Thus a task does not need to
re-execute to gain its demand once more and can be migrated up to a big CPU
immediately.

3) CPU busy time - The sum of execution times of all tasks in the most recently
completed window. For the same machine described above and with schedutil, WALT
with a 10ms window takes around 30-50ms to ramp to FMAX, and with a 20ms window
takes between 60-100ms (note that it is assumed that schedutil has a transition
latency equal to or greater than the window size).

4) WALT "forgets" cpu utilization as soon as tasks are taken off of the
runqueue, and thus the cpufreq governor can choose to drop frequ

[RFC PATCH 3/3] sched: Introduce WALT hooks into core and scheduling classes

2016-10-28 Thread Vikram Mulukutla
From: Srivatsa Vaddagiri 

Add the necessary hooks to core and the various scheduling
classes that will allow WALT to track CPU utilization and
handle task migration between CPUs as well.

With CONFIG_SCHED_WALT enabled, schedutil will use WALT's cpu
utilization metric by default. This can be switched to PELT's
util_avg at runtime by the following command:

echo 0 > /proc/sys/kernel/sched_use_walt_metrics

Signed-off-by: Srivatsa Vaddagiri 
Signed-off-by: Vikram Mulukutla 
---
 kernel/sched/core.c | 29 -
 kernel/sched/deadline.c |  7 +++
 kernel/sched/debug.c|  9 +
 kernel/sched/fair.c |  9 +++--
 kernel/sched/rt.c   |  6 ++
 5 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 44817c6..3b7f67d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -91,6 +91,8 @@
 #define CREATE_TRACE_POINTS
 #include 
 
+#include "walt.h"
+
 DEFINE_MUTEX(sched_domains_mutex);
 DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
 
@@ -991,6 +993,7 @@ static struct rq *move_queued_task(struct rq *rq, struct 
task_struct *p, int new
 
p->on_rq = TASK_ON_RQ_MIGRATING;
dequeue_task(rq, p, 0);
+   walt_prepare_migrate(p, rq, true);
set_task_cpu(p, new_cpu);
raw_spin_unlock(&rq->lock);
 
@@ -998,6 +1001,7 @@ static struct rq *move_queued_task(struct rq *rq, struct 
task_struct *p, int new
 
raw_spin_lock(&rq->lock);
BUG_ON(task_cpu(p) != new_cpu);
+   walt_finish_migrate(p, rq, true);
enqueue_task(rq, p, 0);
p->on_rq = TASK_ON_RQ_QUEUED;
check_preempt_curr(rq, p, 0);
@@ -1257,7 +1261,9 @@ static void __migrate_swap_task(struct task_struct *p, 
int cpu)
 
p->on_rq = TASK_ON_RQ_MIGRATING;
deactivate_task(src_rq, p, 0);
+   walt_prepare_migrate(p, src_rq, true);
set_task_cpu(p, cpu);
+   walt_finish_migrate(p, dst_rq, true);
activate_task(dst_rq, p, 0);
p->on_rq = TASK_ON_RQ_QUEUED;
check_preempt_curr(dst_rq, p, 0);
@@ -2072,13 +2078,19 @@ try_to_wake_up(struct task_struct *p, unsigned int 
state, int wake_flags)
 */
smp_cond_load_acquire(&p->on_cpu, !VAL);
 
+   raw_spin_lock(&task_rq(p)->lock);
+   walt_update_task_ravg(p, task_rq(p), TASK_WAKE, walt_ktime_clock(), 0);
+   raw_spin_unlock(&task_rq(p)->lock);
+
p->sched_contributes_to_load = !!task_contributes_to_load(p);
p->state = TASK_WAKING;
 
cpu = select_task_rq(p, p->wake_cpu, SD_BALANCE_WAKE, wake_flags);
if (task_cpu(p) != cpu) {
wake_flags |= WF_MIGRATED;
+   walt_prepare_migrate(p, task_rq(p), false);
set_task_cpu(p, cpu);
+   walt_finish_migrate(p, cpu_rq(cpu), false);
}
 #endif /* CONFIG_SMP */
 
@@ -2129,8 +2141,10 @@ static void try_to_wake_up_local(struct task_struct *p, 
struct pin_cookie cookie
 
trace_sched_waking(p);
 
-   if (!task_on_rq_queued(p))
+   if (!task_on_rq_queued(p)) {
+   walt_update_task_ravg(p, rq, TASK_WAKE, walt_ktime_clock(), 0);
ttwu_activate(rq, p, ENQUEUE_WAKEUP);
+   }
 
ttwu_do_wakeup(rq, p, 0, cookie);
if (schedstat_enabled())
@@ -2196,6 +2210,7 @@ static void __sched_fork(unsigned long clone_flags, 
struct task_struct *p)
p->se.nr_migrations = 0;
p->se.vruntime  = 0;
INIT_LIST_HEAD(&p->se.group_node);
+   walt_init_new_task_load(p);
 
 #ifdef CONFIG_FAIR_GROUP_SCHED
p->se.cfs_rq= NULL;
@@ -2570,6 +2585,8 @@ void wake_up_new_task(struct task_struct *p)
rq = __task_rq_lock(p, &rf);
post_init_entity_util_avg(&p->se);
 
+   walt_mark_task_starting(p);
+
activate_task(rq, p, 0);
p->on_rq = TASK_ON_RQ_QUEUED;
trace_sched_wakeup_new(p);
@@ -3071,6 +3088,7 @@ void scheduler_tick(void)
update_rq_clock(rq);
curr->sched_class->task_tick(rq, curr, 0);
cpu_load_update_active(rq);
+   walt_update_task_ravg(rq->curr, rq, TASK_UPDATE, walt_ktime_clock(), 0);
calc_global_load_tick(rq);
raw_spin_unlock(&rq->lock);
 
@@ -3322,6 +3340,7 @@ static void __sched notrace __schedule(bool preempt)
struct pin_cookie cookie;
struct rq *rq;
int cpu;
+   u64 wallclock;
 
cpu = smp_processor_id();
rq = cpu_rq(cpu);
@@ -3385,6 +3404,9 @@ static void __sched notrace __schedule(bool preempt)
update_rq_clock(rq);
 
next = pick_next_task(rq, prev, cookie);
+   wallclock = walt_ktime_clock();
+   walt_update_task_ravg(prev, rq, PUT_PREV_TASK, wallclock, 0);
+   walt_update_task_ravg(next, rq, PICK_NEXT_TASK, wallclock, 0);
clear_tsk_need_resched(prev);
clear_preempt_need_resched();
rq->clock_

[RFC PATCH 1/3] sched: Introduce structures necessary for WALT

2016-10-28 Thread Vikram Mulukutla
From: Srivatsa Vaddagiri 

Add the per-task and per-runqueue data structures that
will later be used by Window Assisted Load Tracking (WALT)
to estimate task demand and CPU utilization.

Move cap_scale into sched.h as that will be needed by WALT
as well to implement frequency and capacity invariance.

Signed-off-by: Srivatsa Vaddagiri 
Signed-off-by: Vikram Mulukutla 
---
 include/linux/sched.h | 39 +++
 kernel/sched/fair.c   |  2 --
 kernel/sched/sched.h  |  8 
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 62c68e5..64f8bec 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -315,6 +315,21 @@ extern char ___assert_task_state[1 - 2*!!(
 /* Task command name length */
 #define TASK_COMM_LEN 16
 
+/*
+ * These events may be replaced with a combination of existing scheduler flags
+ * provided that that doesn't make the implementation too fragile.
+ */
+enum task_event {
+   PUT_PREV_TASK   = 0,
+   PICK_NEXT_TASK  = 1,
+   TASK_WAKE   = 2,
+   TASK_MIGRATE= 3,
+   TASK_UPDATE = 4,
+   IRQ_UPDATE  = 5,
+};
+
+extern char *task_event_names[];
+
 #include 
 
 /*
@@ -1320,6 +1335,25 @@ struct sched_statistics {
 };
 #endif
 
+#ifdef CONFIG_SCHED_WALT
+
+/* ravg represents capacity scaled cpu-usage of tasks */
+struct ravg {
+   /*
+* 'mark_start' marks the most recent event for a task
+*
+* 'curr_window' represents task's cpu usage in its most recent
+* window
+*
+* 'prev_window' represents task's cpu usage in the window prior
+* to the one represented by 'curr_window'
+   */
+   u64 mark_start;
+   u32 curr_window, prev_window;
+};
+#endif
+
+
 struct sched_entity {
struct load_weight  load;   /* for load-balancing */
struct rb_node  run_node;
@@ -1480,6 +1514,11 @@ struct task_struct {
const struct sched_class *sched_class;
struct sched_entity se;
struct sched_rt_entity rt;
+
+#ifdef CONFIG_SCHED_WALT
+   struct ravg ravg;
+#endif
+
 #ifdef CONFIG_CGROUP_SCHED
struct task_group *sched_task_group;
 #endif
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ce8b244..39c826d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2674,8 +2674,6 @@ static u32 __compute_runnable_contrib(u64 n)
return contrib + runnable_avg_yN_sum[n];
 }
 
-#define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
-
 /*
  * We can represent the historical contribution to runnable average as the
  * coefficients of a geometric series.  To do this we sub-divide our runnable
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index c64fc51..9bf6925 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -65,6 +65,8 @@ static inline void cpu_load_update_active(struct rq *this_rq) 
{ }
 # define scale_load_down(w)(w)
 #endif
 
+#define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
+
 /*
  * Task weight (visible to users) and its load (invisible to users) have
  * independent resolution, but they should be well calibrated. We use
@@ -664,6 +666,12 @@ struct rq {
u64 max_idle_balance_cost;
 #endif
 
+#ifdef CONFIG_SCHED_WALT
+   u64 window_start;
+   u64 curr_runnable_sum;
+   u64 prev_runnable_sum;
+#endif /* CONFIG_SCHED_WALT */
+
 #ifdef CONFIG_IRQ_TIME_ACCOUNTING
u64 prev_irq_time;
 #endif
-- 
TheMan



[RFC PATCH 2/3] sched: Introduce Window-Assisted CPU utilization Tracking

2016-10-28 Thread Vikram Mulukutla
From: Srivatsa Vaddagiri 

This patch implements an alternative window-based CPU utilization
tracking mechanism in the scheduler. Per task and per CPU counters are
updated with utilization statistics using a synchronized (across CPUs)
time source and a single statistic (prev_runnable_sum) is fed to schedutil
in an upcoming patch. A windowed view of time (window size determined by
walt_ravg_window) is used to determine CPU utilization.

There are two per-CPU-rq quantities maintained by Window Assisted Load Tracking
(WALT), both normalized to the max possible frequency and the max efficiency
(IPC) of that CPU (provided the arch supports the invariance APIs):

curr_runnable_sum: aggregate utilization of all tasks that executed
during the current (not yet completed) window

prev_runnable_sum: aggregate utilization of all tasks that executed
during the most recent completed window

prev_runnable_sum is the primary statistic used to guide CPU frequency in
lieu of PELT's cfs_rq->avg.util_avg. No additional policy is imposed on this
statistic, the assumption being that the consumer (e.g., schedutil) will
perform appropriate policy decisions (e.g., headroom) before deciding the
next P-state.

Corresponding to the aggregate statistics, WALT also mantains the
following stats per task:

curr_window - represents the cpu utilization of the task in its most
recently tracked window

prev_window - represents cpu utilization of task in the window prior
to the one being tracked by curr_window

WALT statistic updates are event driven, with updates occurring in
scheduler_tick, pick_next_task and put_prev_task (i.e, in context_switch),
task wakeup and during task migration. Migration simply involves removing a
tasks's curr_window and prev_window from the source CPU's curr_runnable sum
and prev_runnable_sum, and adding the per-task counters to the destination
CPU's aggregate CPU counters. Execution time in an IRQ handler is accounted
in a CPU's curr_runnable_sum statistic, provided that the CPU was also
executing the idle task for the duration of the interrupt handler.

Idle task handling is modified by walt_io_is_busy; when set to 1, if a CPU
rq has tasks blocked on IO, idle-task execution is accounted in per-task
and per-CPU counters. Setting walt_io_is_busy will also cause interrupt
handlers in the idle task to update counters as if the idle task was
executing (instead of just the interrupt handler execution time).

The major tunable provided by WALT is walt_ravg_window, which represents
window size (in nanoseconds) and is set to 20ms by default. walt_io_is_busy
(described above) is set to 0 by default.

Potential upcoming changes/improvements include: the use of sched_clock
instead of ktime_get as a time source and support for an unsynchronized
(across CPUs) time source. The event codes (PUT_PREV_TASK etc.) may also
potentially be replaced by combinations of existing flags, provided that
doesn't make the implementation too fragile.

Signed-off-by: Srivatsa Vaddagiri 
Signed-off-by: Vikram Mulukutla 
---
 include/linux/sched/sysctl.h |   1 +
 init/Kconfig |   9 +
 kernel/sched/Makefile|   1 +
 kernel/sched/cputime.c   |  10 +-
 kernel/sched/walt.c  | 428 +++
 kernel/sched/walt.h  |  69 +++
 kernel/sysctl.c  |  11 ++
 7 files changed, 528 insertions(+), 1 deletion(-)
 create mode 100644 kernel/sched/walt.c
 create mode 100644 kernel/sched/walt.h

diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index 22db1e6..7007815 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -31,6 +31,7 @@ extern unsigned int sysctl_numa_balancing_scan_delay;
 extern unsigned int sysctl_numa_balancing_scan_period_min;
 extern unsigned int sysctl_numa_balancing_scan_period_max;
 extern unsigned int sysctl_numa_balancing_scan_size;
+extern unsigned int sysctl_sched_use_walt_metrics;
 
 #ifdef CONFIG_SCHED_DEBUG
 extern unsigned int sysctl_sched_migration_cost;
diff --git a/init/Kconfig b/init/Kconfig
index cac3f09..1e629ac 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -390,6 +390,15 @@ config IRQ_TIME_ACCOUNTING
 
  If in doubt, say N here.
 
+config SCHED_WALT
+   bool "Support window based load tracking"
+   depends on SMP
+   help
+   This feature will allow the scheduler to maintain a tunable window
+   based set of metrics for tasks and runqueues. These metrics can be
+   used to guide task placement as well as task frequency requirements
+   for cpufreq governors.
+
 config BSD_PROCESS_ACCT
bool "BSD Process Accounting"
depends on MULTIUSER
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index 5e59b83..41ada04 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -19,6 +19,7 @@ obj-y += core.o loadavg.o clock.o cputime.o
 obj-y += idle_task.o fair.o rt.o deadline.o stop_task.o
 obj-y += wai

Implement complete_all() with swait

2016-10-28 Thread Daniel Wagner

Hi,

I went through all the users of complete_all() in order to figure out if 
we can change the completion code using swait instead of wait. The 
motivation for this is to remove another source of non preemptable 
unbounded work for -rt.


The complete_all() code uses __wake_up_locked(..., 0) which wakes all 
waiters. Naturally, complete_all() would use swake_up_all() when using 
the swait API.


One of the main differences is how swake_up_all() is implemented 
compared to wake API. swake_up_all() toggles with irq enable/disable to 
introduce additional preemption points.



/*
 * Does not allow usage from IRQ disabled, since we must be able to
 * release IRQs to guarantee bounded hold time.
 */
void swake_up_all(struct swait_queue_head *q)
{
struct swait_queue *curr;
LIST_HEAD(tmp);

if (!swait_active(q))
return;

raw_spin_lock_irq(&q->lock);
list_splice_init(&q->task_list, &tmp);
while (!list_empty(&tmp)) {
curr = list_first_entry(&tmp, typeof(*curr), task_list);

wake_up_state(curr->task, TASK_NORMAL);
list_del_init(&curr->task_list);

if (list_empty(&tmp))
break;

raw_spin_unlock_irq(&q->lock);
raw_spin_lock_irq(&q->lock);
}
raw_spin_unlock_irq(&q->lock);
}

In the end that means we would weaken the garantees complete_all() 
current gives you. Currently you can use it in any context (mainline). 
After the swait switch, you can only use it in non IRQ context anymore.



So I went through the list of users and tried to identify which of them 
is going to make troubles. I found 4 users which are using 
complete_all() while IRQs are disabled. The rest looks like it just 
would work nice. I already fixed up a bunch of drivers which use 
complete_all() just to make really sure the single waiter is woken up. 
This list does only contain proper complete_all() users.


Just posting my notes so we have something to discuss next week.

cheers,
daniel


* complete_all() under spin_lock


** drivers/block/drbd/drbd_main.c:

The spinlock serializes the access to thi->t_state and complete_all()
is called while irq are disabled.

This seems to be a state machine.

_drbd_thread_stop()
  spin_lock_irqsave()
  if (thi->t_state == ...) { }
  thi->t_state = ...
  smp_mb()
  init_completion()
  thi->t_state = ...
  spin_unlock_irqrestore()
  wait_for_completion()

drbd_thread_setup()
  spin_lock_irqsave(
  if (thi->t_state == ...) { }
  thi->t_state = ...
  smp_mb()
  complete_all()
  spin_unlock_irqrestore()

992d6e91d365 ("drbd: fix thread stop deadlock")


** drivers/memstick/core/mspro_block.c:

msb->mrq_handler = h_mspro_block_default
memstick_init_req()
memstick_new_req()

jmb38x_ms_isr() # shared irq isr -> thread irq context
  spin_lock()
  jmb38x_ms_complete_cmd()
memstick_next_req()
  host->card->next_request() # h_mspro_block_default()
h_mspro_block_default()
  mspro_block_complete_req()
  spin_lock_irqsave()
complete_all()
  spin_unlock_irqrestore()

r592.c:
kthread(..., "r592_io")
  memstick_next_req()
...

rtsx_pci_ms.c:
workqueue
  rtsx_pci_ms_handle_req()
memstick_next_req()
  ...

rtsx_usb_ms.c:
workqueue
  rtsc_usb_ms_handle_req()
memstick_next_req()
  ...

tifm_ms.c:
tifm_ms_req_tasklet
  spin_lock_irqsave()
  memstick_next_req()
  spin_unlock_irqrestore()


f1d82698029b ("memstick: use fully asynchronous request processing")


**  drivers/misc/tifm_7xx1.c:

tifm_7xx1_isr() # shared_irq -> thread context
  spin_lock()
  complete_all()
  spin_unlock()

3540af8ffddc ("tifm: replace per-adapter kthread with freezeable workqueue")


** drivers/mmc/core/core.c:

request_threaded_irq(sdhci_irq)

sdhci_irq()
  spin_lock()
  sdhci_cmd_irq()
sdhci_finish_command()
  mmc_command_done()
mmc_complete_cmd()
  complete_all()
  spin_unlock()

5163af5a5e2e ("mmc: core: Add support for sending commands during data 
transfer")



** fs/autofs4/expire.c:

autofs4_root_ioctl_unlock()
  autofs4_expire_run()
complete_all()

autofs4_root_ioctl_unlock()
  autofs4_expire_mutli()
autofs4_do_expire_multi()
  spin_lock()
  complete_all()
  spin_unlock()

6e60a9ab5f5d ("autofs4: fix direct mount pending expire race")


* misc


** drivers/block/amiflop.c:

timer
  motor_on_callback()
complete_all()

6d0be946e150 ("m68k: amiflop - Get rid of sleep_on calls")


** drivers/block/cciss.c:

remove_from_scan_list()
  mutex_lock()
  complete_all()
  mutex_unlock()

b368c9dd6598 ("cciss: Use one scan thread per controller and fix hang 
during rmmod")



** drivers/block/rbd.c:

net/ceph/osd_client.c:
mutex_lock()
  complete_request()
__complete_request() -> rbd_od_req_callback
mutext_unlock()


rbd_osd_req_callback()
  rbd_obj_request_complete()
complete_all()

788e2df3b92e ("rbd: implement sync object read with new c

[PATCH 0/2] More FCSR handling fixes

2016-10-28 Thread Maciej W. Rozycki
Hi,

 Here are some further fixes to our FCSR handling.  Just 2 changes at this 
time.

 The first, very small one, closes an issue where a write made with 
ptrace(PTRACE_POKEUSR, ...) to FCSR does not mark the FP context as used.  
This is the legacy interface, seldom used these days, having been largely 
replaced with ptrace(PTRACE_SETFPREGS, ...), so the problem may have 
escaped easily.  Fixed now.

 The second, larger one, addresses the handling of the Cause bits, by 
letting them remain set in some cases, making their semantics more 
consistent with what hardware does when undisturbed; a SIGFPE signal is 
sent if appropriate where previously it was missed.

 This change is not final as in some cases, specifically in the FP context 
of SIGFPE's signal frame, active Cause bits that match Enable bits will 
still be recorded as clear even though they were originally set, being the 
reason for the signal.  Consequently the signal will not retrigger if the 
handler returns with the FP context unchanged in the signal frame.  This 
is unlike with other signals triggered by a hardware exception which do 
require a corrective action if a return is intended rather than an escape 
via `longjmp' or suchlike and which is what one would expect here as well.

 I plan to address this final issue with a further change in the future, 
however I have not started this effort yet and I don't have a schedule 
set.  Meanwhile this change is I believe a step in the right direction.

 Details of both changes have been provided with individual patch 
descriptions.

 While making these changes I have noticed a bunch of bitrot issues we 
have with the handling of the FP context in signal frames with MIPS I-II 
processors.  I will submit corrections as a separate patch series.

 Questions or comments are welcome, as usually, and otherwise please queue
for the next merge cycle.

  Maciej


[PATCH 1/2] MIPS: ptrace: Also initialize the FP context on individual FCSR writes

2016-10-28 Thread Maciej W. Rozycki
Complement commit ac9ad83bc318 ("MIPS: prevent FP context set via ptrace 
being discarded") and also initialize the FP context whenever FCSR alone 
is written with a PTRACE_POKEUSR request addressing FPC_CSR, rather than
along with the full FPU register set in the case of the PTRACE_SETFPREGS
request.

Signed-off-by: Maciej W. Rozycki 
---
Hi,

 This is tricky to verify with modern user software as these days it all 
uses PTRACE_SETFPREGS.  I suppose I could tweak and rebuild `gdbserver' to 
disable modern code and let it use fallback legacy support still present 
there, but frankly I think the change is obviously correct.

 Please apply.

  Maciej

linux-mips-ptrace-fcsr-init-fp-ctx.diff
Index: linux-sfr-test/arch/mips/kernel/ptrace.c
===
--- linux-sfr-test.orig/arch/mips/kernel/ptrace.c   2016-10-22 
01:29:44.0 +0100
+++ linux-sfr-test/arch/mips/kernel/ptrace.c2016-10-22 01:44:38.740202000 
+0100
@@ -817,6 +818,7 @@ long arch_ptrace(struct task_struct *chi
break;
 #endif
case FPC_CSR:
+   init_fp_ctx(child);
ptrace_setfcr31(child, data);
break;
case DSP_BASE ... DSP_BASE + 5: {


[PATCH 2/2] MIPS: Fix FCSR Cause bit handling for correct SIGFPE issue

2016-10-28 Thread Maciej W. Rozycki
Sanitize FCSR Cause bit handling, following a trail of past attempts:

* commit 4249548454f7 ("MIPS: ptrace: Fix FP context restoration FCSR 
regression"),

* commit 443c44032a54 ("MIPS: Always clear FCSR cause bits after 
emulation"),

* commit 64bedffe4968 ("MIPS: Clear [MSA]FPE CSR.Cause after 
notify_die()"),

* commit b1442d39fac2 ("MIPS: Prevent user from setting FCSR cause 
bits"),

* commit b54d2901517d ("Properly handle branch delay slots in connection 
with signals.").

Specifically do not mask these bits out in ptrace(2) processing and send 
a SIGFPE signal instead whenever a matching pair of an FCSR Cause and 
Enable bit is seen as execution of an affected context is about to 
resume.  Only then clear Cause bits, and even then do not clear any bits 
that are set but masked with the respective Enable bits.  Adjust Cause 
bit clearing throughout code likewise, except within the FPU emulator 
proper where they are set according to IEEE 754 exceptions raised as the 
operation emulated executed.  Do so so that any IEEE 754 exceptions 
subject to their default handling are recorded like with operations 
executed by FPU hardware.

Signed-off-by: Maciej W. Rozycki 
---
Hi,

 This for a change I actually verified, by poking at FCSR with GDB, via 
`gdbserver'.  With this change you can now set any Cause bits and at the 
resumption of the debuggee it will receive a SIGFPE with the right code, 
according to the priority set in `force_fcr31_sig'.  Any transient FCSR 
state does not matter of course.  The R6 emulation bits have only been 
verified by building an R6 configuration though.  They are consistent 
with the rest of the changes so they should be good.  Please apply.

  Maciej

linux-mips-ptrace-fcsr-set-cause.diff
Index: linux-sfr-test/arch/mips/include/asm/fpu_emulator.h
===
--- linux-sfr-test.orig/arch/mips/include/asm/fpu_emulator.h2016-10-22 
07:10:07.27129 +0100
+++ linux-sfr-test/arch/mips/include/asm/fpu_emulator.h 2016-10-22 
07:10:47.019621000 +0100
@@ -63,6 +63,8 @@ do {  
\
 extern int fpu_emulator_cop1Handler(struct pt_regs *xcp,
struct mips_fpu_struct *ctx, int has_fpu,
void *__user *fault_addr);
+void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
+struct task_struct *tsk);
 int process_fpemu_return(int sig, void __user *fault_addr,
 unsigned long fcr31);
 int isBranchInstr(struct pt_regs *regs, struct mm_decoded_insn dec_insn,
@@ -81,4 +83,15 @@ static inline void fpu_emulator_init_fpu
set_fpr64(&t->thread.fpu.fpr[i], 0, SIGNALLING_NAN);
 }
 
+/*
+ * Mask the FCSR Cause bits according to the Enable bits, observing
+ * that Unimplemented is always enabled.
+ */
+static inline unsigned long mask_fcr31_x(unsigned long fcr31)
+{
+   return fcr31 & (FPU_CSR_UNI_X |
+   ((fcr31 & FPU_CSR_ALL_E) <<
+(ffs(FPU_CSR_ALL_X) - ffs(FPU_CSR_ALL_E;
+}
+
 #endif /* _ASM_FPU_EMULATOR_H */
Index: linux-sfr-test/arch/mips/include/asm/switch_to.h
===
--- linux-sfr-test.orig/arch/mips/include/asm/switch_to.h   2016-10-22 
07:10:07.275287000 +0100
+++ linux-sfr-test/arch/mips/include/asm/switch_to.h2016-10-22 
07:10:47.037633000 +0100
@@ -76,6 +76,22 @@ do { if (cpu_has_rw_llb) {   
\
 } while (0)
 
 /*
+ * Check FCSR for any unmasked exceptions pending set with `ptrace',
+ * clear them and send a signal.
+ */
+#define __sanitize_fcr31(next) \
+do {   \
+   unsigned long fcr31 = mask_fcr31_x(next->thread.fpu.fcr31); \
+   void __user *pc;\
+   \
+   if (unlikely(fcr31)) {  \
+   pc = (void __user *)task_pt_regs(next)->cp0_epc;\
+   next->thread.fpu.fcr31 &= ~fcr31;   \
+   force_fcr31_sig(fcr31, pc, next);   \
+   }   \
+} while (0)
+
+/*
  * For newly created kernel threads switch_to() will return to
  * ret_from_kernel_thread, newly created user threads to ret_from_fork.
  * That is, everything following resume() will be skipped for new threads.
@@ -85,6 +101,8 @@ do { if (cpu_has_rw_llb) {   
\
 do {   \
__mips_mt_fpaff_switch_to(prev);\
lose_fpu_inatomic(1, prev); 

Re: [PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes

2016-10-28 Thread Leo Yan
On Fri, Oct 28, 2016 at 08:43:51AM +0200, Vincent Guittot wrote:

[...]

> > running with? Also do you have any details about the card in case its
> > card specific?
> 
> The sdcard is quite common: sandisk ultra 16GB
> and my rootfs is on the sdcard

I'm using rootfs in emmc also have same failure.

> > Guodong: Is there any bootloader dependency on that change?
> 
> FYI, I use firmwares available in AOSP

I tried latest firmware [1], still cannot boot up until revert the
patch "arm64: dts: hi6220: add resets property into dwmmc nodes".

[1] 
http://builds.96boards.org/snapshots/hikey/linaro/uefi-openplatformpkg/latest/

Thanks,
Leo Yan


Re: common android definition bug in 3.18 kernel

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 11:00:21AM +0530, Rajesh P8 wrote:
> Hi all,
>   I am currently working on porting eas features using 3.18 common
> android kernel. In file  kernel/sched/fair.c there is no definition
> for the function "trace_sched_boost_task(task, util, margin);" which
> is present in line 5142. Is it a bug or am I missing something? can I
> file this as a bug?
> 

This symbol has never existed in the mainline scheduler. You'll have to
go bug android people.


Re: [RFC PATCH 0/3] sched: Introduce Window Assisted Load Tracking

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 12:10:39AM -0700, Vikram Mulukutla wrote:
> 
> We propose Window-Assisted Load Tracking (WALT) as an alternative or 
> additional
> load tracking scheme in lieu of or along with PELT, one that in our estimation
> better tracks task demand and CPU utilization especially for use cases on
> mobile devices. WALT was conceived by Srivatsa Vaddagiri to provide better
> perf-per-watt numbers on asymmetric CPU (frequency and/or IPC) 
> implementations,
> (specifically on Qualcomm Snapgdragon chipsets running Android) and its 
> metrics
> have been used to guide task placement and p-state selection (load balancing
> in CFS still uses PELT statistics). WALT is now present in the android-common
> kernel as well. 

And how come we only learn of it after its already shipping? Isn't that
arse backwards?


Re: [PATCH v6 1/6] drm/atomic: add drm_atomic_set_fence_for_plane()

2016-10-28 Thread Daniel Vetter
On Thu, Oct 27, 2016 at 05:37:06PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This new function should be used by drivers when setting a implicit
> fence for the plane. It abstracts the fact that the user might have
> chosen explicit fencing instead.
> 
> Signed-off-by: Gustavo Padovan 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_atomic.c | 30 ++
>  include/drm/drm_atomic.h |  2 ++
>  include/drm/drm_plane.h  |  2 +-
>  3 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c32fb3c..5e73954 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1147,6 +1147,36 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state 
> *plane_state,
>  EXPORT_SYMBOL(drm_atomic_set_fb_for_plane);
>  
>  /**
> + * drm_atomic_set_fence_for_plane - set fence for plane
> + * @plane_state: atomic state object for the plane
> + * @fence: dma_fence to use for the plane
> + *
> + * Helper to setup the plane_state fence in case it is not set yet.
> + * By using this drivers doesn't need to worry if the user choose
> + * implicit or explicit fencing.
> + *
> + * This function will not set the fence to the state if it was set
> + * via explicit fencing interfaces on the atomic ioctl. It will
> + * all drope the reference to the fence as we not storing it
> + * anywhere.
> + *
> + * Otherwise, if plane_state->fence is not set this function we
> + * just set it with the received implict fence.
> + */
> +void
> +drm_atomic_set_fence_for_plane(struct drm_plane_state *plane_state,
> +struct dma_fence *fence)
> +{
> + if (plane_state->fence) {
> + dma_fence_put(fence);
> + return;
> + }
> +
> + plane_state->fence = fence;
> +}
> +EXPORT_SYMBOL(drm_atomic_set_fence_for_plane);
> +
> +/**
>   * drm_atomic_set_crtc_for_connector - set crtc for connector
>   * @conn_state: atomic state object for the connector
>   * @crtc: crtc to use for the connector
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index fc8af53..2d1e9c9 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -345,6 +345,8 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state 
> *plane_state,
> struct drm_crtc *crtc);
>  void drm_atomic_set_fb_for_plane(struct drm_plane_state *plane_state,
>struct drm_framebuffer *fb);
> +void drm_atomic_set_fence_for_plane(struct drm_plane_state *plane_state,
> + struct dma_fence *fence);
>  int __must_check
>  drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state,
> struct drm_crtc *crtc);
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index c5e8a0d..68f6d22 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -59,7 +59,7 @@ struct drm_plane_state {
>  
>   struct drm_crtc *crtc;   /* do not write directly, use 
> drm_atomic_set_crtc_for_plane() */
>   struct drm_framebuffer *fb;  /* do not write directly, use 
> drm_atomic_set_fb_for_plane() */
> - struct dma_fence *fence;
> + struct dma_fence *fence; /* do not write directly, use 
> drm_atomic_set_fence_for_plane() */
>  
>   /* Signed dest location allows it to be partially off screen */
>   int32_t crtc_x, crtc_y;
> -- 
> 2.5.5
> 

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


Re: [PATCH v6 1/6] drm/atomic: add drm_atomic_set_fence_for_plane()

2016-10-28 Thread Daniel Vetter
On Fri, Oct 28, 2016 at 09:30:26AM +0200, Daniel Vetter wrote:
> On Thu, Oct 27, 2016 at 05:37:06PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > This new function should be used by drivers when setting a implicit
> > fence for the plane. It abstracts the fact that the user might have
> > chosen explicit fencing instead.
> > 
> > Signed-off-by: Gustavo Padovan 
> 
> Reviewed-by: Daniel Vetter 
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 30 ++
> >  include/drm/drm_atomic.h |  2 ++
> >  include/drm/drm_plane.h  |  2 +-
> >  3 files changed, 33 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index c32fb3c..5e73954 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1147,6 +1147,36 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state 
> > *plane_state,
> >  EXPORT_SYMBOL(drm_atomic_set_fb_for_plane);
> >  
> >  /**
> > + * drm_atomic_set_fence_for_plane - set fence for plane
> > + * @plane_state: atomic state object for the plane
> > + * @fence: dma_fence to use for the plane
> > + *
> > + * Helper to setup the plane_state fence in case it is not set yet.
> > + * By using this drivers doesn't need to worry if the user choose
> > + * implicit or explicit fencing.
> > + *
> > + * This function will not set the fence to the state if it was set
> > + * via explicit fencing interfaces on the atomic ioctl. It will
> > + * all drope the reference to the fence as we not storing it
> > + * anywhere.
> > + *
> > + * Otherwise, if plane_state->fence is not set this function we
> > + * just set it with the received implict fence.
> > + */
> > +void
> > +drm_atomic_set_fence_for_plane(struct drm_plane_state *plane_state,
> > +  struct dma_fence *fence)
> > +{
> > +   if (plane_state->fence) {
> > +   dma_fence_put(fence);
> > +   return;
> > +   }
> > +
> > +   plane_state->fence = fence;
> > +}
> > +EXPORT_SYMBOL(drm_atomic_set_fence_for_plane);
> > +
> > +/**
> >   * drm_atomic_set_crtc_for_connector - set crtc for connector
> >   * @conn_state: atomic state object for the connector
> >   * @crtc: crtc to use for the connector
> > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > index fc8af53..2d1e9c9 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -345,6 +345,8 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state 
> > *plane_state,
> >   struct drm_crtc *crtc);
> >  void drm_atomic_set_fb_for_plane(struct drm_plane_state *plane_state,
> >  struct drm_framebuffer *fb);
> > +void drm_atomic_set_fence_for_plane(struct drm_plane_state *plane_state,
> > +   struct dma_fence *fence);
> >  int __must_check
> >  drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state,
> >   struct drm_crtc *crtc);
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > index c5e8a0d..68f6d22 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -59,7 +59,7 @@ struct drm_plane_state {
> >  
> > struct drm_crtc *crtc;   /* do not write directly, use 
> > drm_atomic_set_crtc_for_plane() */
> > struct drm_framebuffer *fb;  /* do not write directly, use 
> > drm_atomic_set_fb_for_plane() */
> > -   struct dma_fence *fence;
> > +   struct dma_fence *fence; /* do not write directly, use 
> > drm_atomic_set_fence_for_plane() */

Ok, small bikeshed maybe: When you feel the need to add more comments
in-line in a struct, then please switch to the in-line kernel-doc member
documentation style, and merge the existing kerneldoc together with these
additional comments. Would be great to do that with all the others here
too. Follow-up patch to address this would be great.
-Daniel

> >  
> > /* Signed dest location allows it to be partially off screen */
> > int32_t crtc_x, crtc_y;
> > -- 
> > 2.5.5
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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


Re: [PATCH v6 3/6] drm/msm: use drm_atomic_set_fence_for_plane() to set the fence

2016-10-28 Thread Daniel Vetter
On Thu, Oct 27, 2016 at 05:37:08PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> drm_atomic_set_fence_for_plane() is smart and won't overwrite
> plane_state->fence if the user already set an explicit fence there.
> 
> Signed-off-by: Gustavo Padovan 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/msm/msm_atomic.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c 
> b/drivers/gpu/drm/msm/msm_atomic.c
> index db193f8..4e21e1d 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -217,8 +217,9 @@ int msm_atomic_commit(struct drm_device *dev,
>   if ((plane->state->fb != plane_state->fb) && plane_state->fb) {
>   struct drm_gem_object *obj = 
> msm_framebuffer_bo(plane_state->fb, 0);
>   struct msm_gem_object *msm_obj = to_msm_bo(obj);
> + struct dma_fence *fence = 
> reservation_object_get_excl_rcu(msm_obj->resv);
>  
> - plane_state->fence = 
> reservation_object_get_excl_rcu(msm_obj->resv);
> + drm_atomic_set_fence_for_plane(plane_state, fence);
>   }
>   }
>  
> -- 
> 2.5.5
> 

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


Re: [PATCH v6 2/6] drm/imx: use drm_atomic_set_fence_for_plane() to set the fence

2016-10-28 Thread Daniel Vetter
On Thu, Oct 27, 2016 at 05:37:07PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> drm_atomic_set_fence_for_plane() is smart and won't overwrite
> plane_state->fence if the user already set an explicit fence there.
> 
> Signed-off-by: Gustavo Padovan 

Process nit: Please make sure you Cc: driver maintainers for driver
patches. Best done by putting the Cc: into the patch, then you never
forget ;-)

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/imx/imx-drm-core.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 98df09c..07fe955 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -158,6 +158,7 @@ static int imx_drm_atomic_commit(struct drm_device *dev,
>   struct drm_plane_state *plane_state;
>   struct drm_plane *plane;
>   struct dma_buf *dma_buf;
> + struct dma_fence *fence;
>   int i;
>  
>   /*
> @@ -170,8 +171,9 @@ static int imx_drm_atomic_commit(struct drm_device *dev,
>0)->base.dma_buf;
>   if (!dma_buf)
>   continue;
> - plane_state->fence =
> - reservation_object_get_excl_rcu(dma_buf->resv);
> + fence = reservation_object_get_excl_rcu(dma_buf->resv);
> +
> + drm_atomic_set_fence_for_plane(plane_state, fence);
>   }
>   }
>  
> -- 
> 2.5.5
> 

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


Re: [RFC 0/8] Define coherent device memory node

2016-10-28 Thread Aneesh Kumar K.V
Jerome Glisse  writes:

> On Wed, Oct 26, 2016 at 04:39:19PM +0530, Aneesh Kumar K.V wrote:
>> Jerome Glisse  writes:
>> 
>> > On Tue, Oct 25, 2016 at 09:56:35AM +0530, Aneesh Kumar K.V wrote:
>> >> Jerome Glisse  writes:
>> >> 
>> >> > On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote:
>> >> >
>> >> I looked at the hmm-v13 w.r.t migration and I guess some form of device
>> >> callback/acceleration during migration is something we should definitely
>> >> have. I still haven't figured out how non addressable and coherent device
>> >> memory can fit together there. I was waiting for the page cache
>> >> migration support to be pushed to the repository before I start looking
>> >> at this closely.
>> >> 
>> >
>> > The page cache migration does not touch the migrate code path. My issue 
>> > with
>> > page cache is writeback. The only difference with existing migrate code is
>> > refcount check for ZONE_DEVICE page. Everything else is the same.
>> 
>> What about the radix tree ? does file system migrate_page callback handle
>> replacing normal page with ZONE_DEVICE page/exceptional entries ?
>> 
>
> It use the exact same existing code (from mm/migrate.c) so yes the radix tree
> is updated and buffer_head are migrated.
>

I looked at the the page cache migration patches shared and I find that
you are not using exceptional entries when we migrate a page cache page to
device memory. But I am now not sure how a read from page cache will
work with that.

ie, a file system read will now find the page in page cache. But we
cannot do a copy_to_user of that page because that is now backed by an
unaddressable memory right ?

do_generic_file_read() does
  page = find_get_page(mapping, index);
  
  ret = copy_page_to_iter(page, offset, nr, iter);

which does
void *kaddr = kmap_atomic(page);
size_t wanted = copy_to_iter(kaddr + offset, bytes, i);
kunmap_atomic(kaddr);


-aneesh



Re: [PATCH v10 10/19] vfio iommu: Add blocking notifier to notify DMA_UNMAP

2016-10-28 Thread Jike Song
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Added blocking notifier to IOMMU TYPE1 driver to notify vendor drivers
> about DMA_UNMAP.
> Exported two APIs vfio_register_notifier() and vfio_unregister_notifier().
> Vendor driver should register notifer using these APIs.
> Vendor driver should use VFIO_IOMMU_NOTIFY_DMA_UNMAP action to invalidate
> mappings.
> 
> Signed-off-by: Kirti Wankhede 
> Signed-off-by: Neo Jia 
> Change-Id: I5910d0024d6be87f3e8d3e0ca0eaeaaa0b17f271
> ---
>  drivers/vfio/vfio.c | 73 +
>  drivers/vfio/vfio_iommu_type1.c | 89 
> -
>  include/linux/vfio.h| 11 +
>  3 files changed, 163 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 28b50ca14c52..ff05ac6b1e90 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1891,6 +1891,79 @@ err_unpin_pages:
>  }
>  EXPORT_SYMBOL(vfio_unpin_pages);
>  
> +int vfio_register_notifier(struct device *dev, struct notifier_block *nb)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_register_nb;
> +
> + container = group->container;
> + down_read(&container->group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->register_notifier))
> + ret = driver->ops->register_notifier(container->iommu_data, nb);
> + else
> + ret = -EINVAL;
> +
> + up_read(&container->group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_register_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_register_notifier);
> +
> +int vfio_unregister_notifier(struct device *dev, struct notifier_block *nb)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_unregister_nb;
> +
> + container = group->container;
> + down_read(&container->group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->unregister_notifier))
> + ret = driver->ops->unregister_notifier(container->iommu_data,
> +nb);
> + else
> + ret = -EINVAL;
> +
> + up_read(&container->group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_unregister_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_unregister_notifier);
> +
>  /**
>   * Module/class support
>   */
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 5add11a147e1..a4bd331ac0fd 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DRIVER_VERSION  "0.2"
>  #define DRIVER_AUTHOR   "Alex Williamson "
> @@ -59,6 +60,7 @@ struct vfio_iommu {
>   struct vfio_domain  *external_domain; /* domain for external user */
>   struct mutexlock;
>   struct rb_root  dma_list;
> + struct blocking_notifier_head notifier;
>   boolv2;
>   boolnesting;
>  };
> @@ -549,7 +551,8 @@ static long vfio_iommu_type1_pin_pages(void *iommu_data,
>  
>   mutex_lock(&iommu->lock);
>  
> - if (!iommu->external_domain) {
> + /* Fail if notifier list is empty */
> + if ((!iommu->external_domain) || (!iommu->notifier.head)) {
>   ret = -EINVAL;
>   goto pin_done;
>   }
> @@ -768,6 +771,50 @@ static unsigned long vfio_pgsize_bitmap(struct 
> vfio_iommu *iommu)
>   return bitmap;
>  }
>  
> +/*
> + * This function finds pfn in domain->external_addr_space->pfn_list for given
> + * iova range. If pfn exist, notify pfn to registered notifier list. On
> + * receiving notifier callback, vendor driver should invalidate the mapping 
> and
> + * call vfio_unpin_pages() to unpin this pfn. With that vfio_pfn for this pfn
> + * gets removed from rb tree of pfn_list. That re-arranges rb tree, so while
> + * searching for next vfio_pfn in rb tree, start search from first node 
> again.
> + * If any vendor driver doesn't unpin that pfn, vfio_pfn would not get 
> removed
> + * from rb tree and so in next search vfio_pfn would be same as p

Re: [RFC PATCH 2/3] sched: Introduce Window-Assisted CPU utilization Tracking

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 12:10:41AM -0700, Vikram Mulukutla wrote:
> +static int cpu_is_waiting_on_io(struct rq *rq)
> +{
> + if (!walt_io_is_busy)
> + return 0;
> +
> + return atomic_read(&rq->nr_iowait);
> +}

This is just drug induced nonsense. The per-cpu nr_iowait number is
completely without meaning.


Re: [PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes

2016-10-28 Thread Leo Yan
On Fri, Oct 28, 2016 at 04:33:41PM +0900, Jaehoon Chung wrote:

[...]

> >>> Guodong: Is there any bootloader dependency on that change?
> >>
> >> FYI, I use firmwares available in AOSP
> > 
> > I tried latest firmware [1], still cannot boot up until revert the
> > patch "arm64: dts: hi6220: add resets property into dwmmc nodes".
> 
> Could you share the log? Is there any log about failure?

Sure, please see below log:

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.9.0-rc1-00251-g323792f (leoy@leoy-linaro) (gcc 
version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - 
Linaro GCC 4.9-2014.09) ) #589 SMP PREEMPT Fri Oct 28 15:35:15 CST 2016
[0.00] Boot CPU: AArch64 Processor [410fd033]
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.50 by hikey EFI Oct 26 2016 15:14:29
[0.00] efi:  PROP=0x3d8297d8 
[0.00] Reserved memory: created CMA memory pool at 0x2d00, 
size 128 MiB
[0.00] OF: reserved mem: initialized node linux,cma, compatible id 
shared-dma-pool
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.0 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.
[0.00] percpu: Embedded 21 pages/cpu @80003df1 s48000 r8192 
d29824 u86016
[0.00] Detected VIPT I-cache on CPU0
[0.00] CPU features: enabling workaround for ARM erratum 845719
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 249229
[0.00] Kernel command line: BOOT_IMAGE=(hd0,gpt6)/Image console=tty0 
console=ttyAMA3,115200 root=/dev/disk/by-partlabel/system rootwait rw 
efi=noruntime
[0.00] log_buf_len individual max cpu contribution: 4096 bytes
[0.00] log_buf_len total cpu_extra contributions: 28672 bytes
[0.00] log_buf_len min size: 16384 bytes
[0.00] log_buf_len: 65536 bytes
[0.00] early log buf free: 14468(88%)
[0.00] PID hash table entries: 4096 (order: 3, 32768 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[0.00] Memory: 841572K/1012788K available (8316K kernel code, 860K 
rwdata, 3668K rodata, 1024K init, 283K bss, 40144K reserved, 131072K 
cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] modules : 0x - 0x0800   (   128 
MB)
[0.00] vmalloc : 0x0800 - 0x7dffbfff   (129022 
GB)
[0.00]   .text : 0x0808 - 0x088a   (  8320 
KB)
[0.00] .rodata : 0x088a - 0x08c4   (  3712 
KB)
[0.00]   .init : 0x08c4 - 0x08d4   (  1024 
KB)
[0.00]   .data : 0x08d4 - 0x08e17200   (   861 
KB)
[0.00].bss : 0x08e17200 - 0x08e5e0c0   (   284 
KB)
[0.00] fixed   : 0x7dfffe7fd000 - 0x7dfffec0   (  4108 
KB)
[0.00] PCI I/O : 0x7dfffee0 - 0x7de0   (16 
MB)
[0.00] vmemmap : 0x7e00 - 0x8000   (  2048 
GB maximum)
[0.00]   0x7e00 - 0x7ef8   (15 
MB actual)
[0.00] memory  : 0x8000 - 0x80003e00   (   992 
MB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 64.
[0.00]  RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=8.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=8
[0.00] NR_IRQS:64 nr_irqs:64 0
[0.00] GIC: Using split EOI/Deactivate mode
[0.00] arm_arch_timer: Architected cp15 timer(s) running at 1.20MHz 
(phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x11b661f8e, max_idle_ns: 1763180809113 ns
[0.04] sched_clock: 56 bits at 1200kHz, resolution 833ns, wraps every 
4398046510838ns
[0.000101] clocksource: arm,sp804: mask: 0x max_cycles: 0x, 
max_idle_ns: 99544814920 ns
[0.000108] sched_clock: 32 bits at 19MHz, resolution 52ns, wraps every 
111848106981ns
[0.000495] Console: colour dummy device 80x25
[0.001193] console [tty0] enabled
[0.001224] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 2.40 BogoMIPS (lpj=4800)
[0.001253] pid_max: default: 32768 minimum: 301
[0.001331] Security Framework initialized
[0.001373] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
[0.001392] Mountpoi

Re: [PATCH v6 4/6] drm/fence: add in-fences support

2016-10-28 Thread Daniel Vetter
On Thu, Oct 27, 2016 at 05:37:09PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> There is now a new property called FENCE_FD attached to every plane
> state that receives the sync_file fd from userspace via the atomic commit
> IOCTL.
> 
> The fd is then translated to a fence (that may be a fence_collection
> subclass or just a normal fence) and then used by DRM to fence_wait() for
> all fences in the sync_file to signal. So it only commits when all
> framebuffers are ready to scanout.
> 
> v2: Comments by Daniel Vetter:
>   - remove set state->fence = NULL in destroy phase
>   - accept fence -1 as valid and just return 0
>   - do not call fence_get() - sync_file_fences_get() already calls it
>   - fence_put() if state->fence is already set, in case userspace
>   set the property more than once.
> 
> v3: WARN_ON if fence is set but state has no FB
> 
> v4: Comment from Maarten Lankhorst
>   - allow set fence with no related fb
> 
> v5: rename FENCE_FD to IN_FENCE_FD
> 
> v6: Comments by Daniel Vetter:
>   - rename plane_state->in_fence back to "fence"
> 
>  - rebase after fence -> dma_fence rename
> 
> Signed-off-by: Gustavo Padovan 

Looks good, but I'll wait with full review with all the fence patches
until the igts show up. It's much easier to check for gabs in input
validation code if you also have the testcases at hand. A few comments
below.
-Daniel

> ---
>  drivers/gpu/drm/Kconfig |  1 +
>  drivers/gpu/drm/drm_atomic.c| 15 +++
>  drivers/gpu/drm/drm_atomic_helper.c |  5 +++--
>  drivers/gpu/drm/drm_crtc.c  |  6 ++
>  drivers/gpu/drm/drm_plane.c |  1 +
>  include/drm/drm_crtc.h  |  5 +
>  6 files changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 483059a..43cb33d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -12,6 +12,7 @@ menuconfig DRM
>   select I2C
>   select I2C_ALGOBIT
>   select DMA_SHARED_BUFFER
> + select SYNC_FILE
>   help
> Kernel-level support for the Direct Rendering Infrastructure (DRI)
> introduced in XFree86 4.0. If you say Y here, you need to select
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 5e73954..28d9366 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> @@ -686,6 +687,17 @@ int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>   drm_atomic_set_fb_for_plane(state, fb);
>   if (fb)
>   drm_framebuffer_unreference(fb);
> + } else if (property == config->prop_in_fence_fd) {
> + if (U642I64(val) == -1)
> + return 0;
> +
> + if (state->fence)
> + dma_fence_put(state->fence);
> +
> + state->fence = sync_file_get_fence(val);
> + if (!state->fence)
> + return -EINVAL;
> +
>   } else if (property == config->prop_crtc_id) {
>   struct drm_crtc *crtc = drm_crtc_find(dev, val);
>   return drm_atomic_set_crtc_for_plane(state, crtc);
> @@ -747,6 +759,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>  
>   if (property == config->prop_fb_id) {
>   *val = (state->fb) ? state->fb->base.id : 0;
> + } else if (property == config->prop_in_fence_fd) {
> + *val = -1;
>   } else if (property == config->prop_crtc_id) {
>   *val = (state->crtc) ? state->crtc->base.id : 0;
>   } else if (property == config->prop_crtc_x) {
> @@ -1752,6 +1766,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   drm_mode_object_unreference(obj);
>   }
>  
> +

Spurios whitespace.

>   if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>   struct drm_pending_vblank_event *e;
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 75ad01d..c34da9e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1034,8 +1034,6 @@ int drm_atomic_helper_wait_for_fences(struct drm_device 
> *dev,
>   if (!plane_state->fence)
>   continue;
>  
> - WARN_ON(!plane_state->fb);
> -

Why this? We don't allow a plane to be enabled without an fb, and adding a
fence to a plane which is disabled sounds likea  bug. We probably should
have a bit of code in the core atomic check code to make sure userspace
never asks for a fence when the plane is off.

>   /*
>* If waiting for fences pre-swap (ie: nonblock), userspace can
>* still interrupt the operation. Instead of blocking until the
> @@ -3114

RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

2016-10-28 Thread Y.B. Lu
> -Original Message-
> From: Y.B. Lu
> Sent: Friday, October 28, 2016 2:06 PM
> To: Y.B. Lu; 'Scott Wood'; 'linux-...@vger.kernel.org';
> 'ulf.hans...@linaro.org'; 'Arnd Bergmann'
> Cc: 'linuxppc-...@lists.ozlabs.org'; 'devicet...@vger.kernel.org';
> 'linux-arm-ker...@lists.infradead.org'; 'linux-kernel@vger.kernel.org';
> 'linux-...@vger.kernel.org'; 'linux-...@vger.kernel.org';
> 'io...@lists.linux-foundation.org'; 'net...@vger.kernel.org'; 'Greg
> Kroah-Hartman'; 'Mark Rutland'; 'Rob Herring'; 'Russell King'; 'Jochen
> Friedrich'; 'Joerg Roedel'; 'Claudiu Manoil'; 'Bhupesh Sharma'; Qiang
> Zhao; 'Kumar Gala'; 'Santosh Shilimkar'; Leo Li; X.B. Xie; M.H. Lian
> Subject: RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> 
> > -Original Message-
> > From: Y.B. Lu
> > Sent: Friday, October 28, 2016 2:00 PM
> > To: 'Scott Wood'; linux-...@vger.kernel.org; ulf.hans...@linaro.org;
> > Arnd Bergmann
> > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Greg
> > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> > Xie; M.H. Lian
> > Subject: RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> >
> >
> >
> > > -Original Message-
> > > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > > Sent: Friday, October 28, 2016 12:46 PM
> > > To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> > > Bergmann
> > > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Greg
> > > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> > > Xie; M.H. Lian
> > > Subject: Re: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ
> > > platforms
> > >
> > > On Fri, 2016-10-28 at 11:32 +0800, Yangbo Lu wrote:
> > > > +   guts->regs = of_iomap(np, 0);
> > > > +   if (!guts->regs)
> > > > +   return -ENOMEM;
> > > > +
> > > > +   /* Register soc device */
> > > > +   machine = of_flat_dt_get_machine_name();
> > > > +   if (machine)
> > > > +   soc_dev_attr.machine = devm_kstrdup(dev, machine,
> > > > GFP_KERNEL);
> > > > +
> > > > +   svr = fsl_guts_get_svr();
> > > > +   soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> > > > +   if (soc_die) {
> > > > +   soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > > +    "QorIQ %s", 
> > > > soc_die-
> > > > >die);
> > > > +   } else {
> > > > +   soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > > "QorIQ");
> > > > +   }
> > > > +   soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
> > > > +    "svr:0x%08x", svr);
> > > > +   soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL,
> "%d.%d",
> > > > +      SVR_MAJ(svr), 
> > > > SVR_MIN(svr));
> > > > +
> > > > +   soc_dev = soc_device_register(&soc_dev_attr);
> > > > +   if (IS_ERR(soc_dev))
> > > > +   return PTR_ERR(soc_dev);
> > >
> > > ioremap leaks on this error path.  Use devm_ioremap_resource().
> > >
> >
> > [Lu Yangbo-B47093] Ok. I have fixed it in v14. Thanks :)
> 
> [Lu Yangbo-B47093] Sorry, used the wrong error code... Will resent it

[Lu Yangbo-B47093] The v15 had been sent. And dropped patch 'dt: bindings: 
update Freescale DCFG compatible',
since that work has been done by below patch on ShawnGuo's linux tree.
'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG and DCFG'
https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19

Thanks.

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


Re: [PATCH v6 5/6] drm/fence: add fence timeline to drm_crtc

2016-10-28 Thread Daniel Vetter
On Thu, Oct 27, 2016 at 05:37:10PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Create one timeline context for each CRTC to be able to handle out-fences
> and signal them. It adds a few members to struct drm_crtc: fence_context,
> where we store the context we get from fence_context_alloc(), the
> fence seqno and the fence lock, that we pass in fence_init() to be
> used by the fence.
> 
> v2: Comment by Daniel Stone:
>   - add BUG_ON() to fence_to_crtc() macro
> 
> v3: Comment by Ville Syrjälä
>   - Use more meaningful name as crtc timeline name
> 
> v4: Comments by Brian Starkey
>   - Use even more meaninful name for the crtc timeline
>   - add doc for timeline_name
> Comment by Daniel Vetter
>   - use in-line style for comments
> 
> - rebase after fence -> dma_fence rename
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/drm_crtc.c | 31 +++
>  include/drm/drm_crtc.h | 39 +++
>  2 files changed, 70 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 7878bfd..e2a06c8 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -165,6 +165,32 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
>  #endif
>  }
>  
> +static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
> +{
> + struct drm_crtc *crtc = fence_to_crtc(fence);
> +
> + return crtc->dev->driver->name;
> +}
> +
> +static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
> +{
> + struct drm_crtc *crtc = fence_to_crtc(fence);
> +
> + return crtc->timeline_name;
> +}
> +
> +static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
> +{
> + return true;
> +}
> +
> +const struct dma_fence_ops drm_crtc_fence_ops = {
> + .get_driver_name = drm_crtc_fence_get_driver_name,
> + .get_timeline_name = drm_crtc_fence_get_timeline_name,
> + .enable_signaling = drm_crtc_fence_enable_signaling,
> + .wait = dma_fence_default_wait,
> +};
> +
>  /**
>   * drm_crtc_init_with_planes - Initialise a new CRTC object with
>   *specified primary and cursor planes.
> @@ -222,6 +248,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   return -ENOMEM;
>   }
>  
> + crtc->fence_context = dma_fence_context_alloc(1);
> + spin_lock_init(&crtc->fence_lock);
> + snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
> +  "CRTC:%d-%s", crtc->base.id, crtc->name);
> +
>   crtc->base.properties = &crtc->properties;
>  
>   list_add_tail(&crtc->head, &config->crtc_list);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 719b6a8..278dbdd 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -32,6 +32,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -726,8 +728,45 @@ struct drm_crtc {
>*/
>   struct drm_crtc_crc crc;
>  #endif
> +
> + /**
> +  * @fence_context:
> +  *
> +  * timeline context used for fence operations.
> +  */
> + unsigned int fence_context;
> +
> + /**
> +  * @fence_lock:
> +  *
> +  * spinlock to protect the fences in the fence_context.
> +  */
> +
> + spinlock_t fence_lock;
> + /**
> +  * @fence_seqno:
> +  *
> +  * Seqno variable used as monotonic counter for the fences
> +  * created on the CRTC's timeline.
> +  */
> + unsigned long fence_seqno;
> +
> + /**
> +  * @timeline_name:
> +  *
> +  * The name of the CRTC's fence timeline.
> +  */
> + char timeline_name[32];
>  };
>  
> +extern const struct dma_fence_ops drm_crtc_fence_ops;
> +

Kerneldoc please. With that addressed:

Reviewed-by: Daniel Vetter 

> +static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
> +{
> + BUG_ON(fence->ops != &drm_crtc_fence_ops);
> + return container_of(fence->lock, struct drm_crtc, fence_lock);
> +}
> +
>  /**
>   * struct drm_mode_set - new values for a CRTC config change
>   * @fb: framebuffer to use for new config
> -- 
> 2.5.5
> 

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


Re: [RFC PATCH 2/3] sched: Introduce Window-Assisted CPU utilization Tracking

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 12:10:41AM -0700, Vikram Mulukutla wrote:
> +u64 walt_ktime_clock(void)
> +{
> + if (unlikely(walt_ktime_suspended))
> + return ktime_to_ns(ktime_last);
> + return ktime_get_ns();
> +}

> +static int walt_suspend(void)
> +{
> + ktime_last = ktime_get();
> + walt_ktime_suspended = true;
> + return 0;
> +}

No, ktime_get() will not be used in the scheduler. Imagine the joy if
that thing ends up being the HPET.


Re: [RFC PATCH 2/3] sched: Introduce Window-Assisted CPU utilization Tracking

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 12:10:41AM -0700, Vikram Mulukutla wrote:
> +void walt_finish_migrate(struct task_struct *p, struct rq *dest_rq, bool 
> locked)
> +{
> + u64 wallclock;
> + unsigned long flags;
> +
> + if (!p->on_rq && p->state != TASK_WAKING)
> + return;
> +
> + if (locked == false)
> + raw_spin_lock_irqsave(&dest_rq->lock, flags);
> +

> +
> + if (locked == false)
> + raw_spin_unlock_irqrestore(&dest_rq->lock, flags);
> +}
> +
> +void walt_prepare_migrate(struct task_struct *p, struct rq *src_rq, bool 
> locked)
> +{
> + u64 wallclock;
> + unsigned long flags;
> +
> + if (!p->on_rq && p->state != TASK_WAKING)
> + return;
> +
> + if (locked == false)
> + raw_spin_lock_irqsave(&src_rq->lock, flags);
> +

> +
> + if (locked == false)
> + raw_spin_unlock_irqrestore(&src_rq->lock, flags);
> +}

Seriously bad style that. Please, less bonghits before writing code.


Re: [RFC PATCH 0/3] sched: Introduce Window Assisted Load Tracking

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 12:10:39AM -0700, Vikram Mulukutla wrote:
> This RFC patch has been tested on live X86 machines with the following sanity
> and benchmark results (thanks to Juri Lelli, Dietmar Eggeman, Patrick Bellasi
> for initial code reviews):
> 
> (Tested on an Intel i7 2nd generation CPU, 8GB RAM, Nvidia GTX950Ti graphics,
> with the same frequency list as above. Running Ubuntu 16.04 on a v4.8.2
> baseline. WALT window size was 10ms. Only deltas above 3% are considered
> non-noise.Power measured with Intel RAPL counters)

Was this comparison done using the use_walt_metric sysctl knob?


Re: [RFC PATCH 2/3] sched: Introduce Window-Assisted CPU utilization Tracking

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 12:10:41AM -0700, Vikram Mulukutla wrote:
> +static int account_cpu_busy_time(struct rq *rq, struct task_struct *p,
> +  u64 irqtime, int event)
> +{
> + if (is_idle_task(p)) {
> + /* TASK_WAKE && TASK_MIGRATE is not possible on idle task! */
> + if (event == PICK_NEXT_TASK)
> + return 0;
> +
> + /* PUT_PREV_TASK, TASK_UPDATE && IRQ_UPDATE are left */
> + return irqtime || cpu_is_waiting_on_io(rq);
> + }
> +
> + if (event == TASK_WAKE)
> + return 0;
> +
> + if (event == PUT_PREV_TASK || event == IRQ_UPDATE ||
> +  event == TASK_UPDATE)
> + return 1;
> +
> + /* Only TASK_MIGRATE && PICK_NEXT_TASK left */
> + return walt_freq_account_wait_time;
> +}

switch() wasn't an option?


Re: [PATCH next 1/2] media: mtk-mdp: fix video_device_release argument

2016-10-28 Thread Vincent Stehlé
On Thu, Oct 27, 2016 at 10:23:24PM +0200, Vincent Stehlé wrote:
> video_device_release() takes a pointer to struct video_device as argument.
> Fix two call sites where the address of the pointer is passed instead.

Sorry, I messed up: please ignore that "fix". The 0day robot made me
realize this is indeed not a proper fix.

The issue remains, though: we cannot call video_device_release() on the
vdev structure member, as this will in turn call kfree(). Most probably,
vdev needs to be dynamically allocated, or the call to
video_device_release() dropped completely.

Sorry for the bad patch.

Best regards,

Vincent.


Re: [RFC][PATCH] arm64: Add support for CONFIG_DEBUG_VIRTUAL

2016-10-28 Thread Ard Biesheuvel
Hi Laura,

On 28 October 2016 at 01:18, Laura Abbott  wrote:
> x86 has an option CONFIG_DEBUG_VIRTUAL to do additional checks
> on virt_to_phys calls. The goal is to catch users who are calling
> virt_to_phys on non-linear addresses immediately. As features
> such as CONFIG_VMAP_STACK get enabled for arm64, this becomes
> increasingly important. Add checks to catch bad virt_to_phys
> usage.
>

I think this is a useful thing to have. However, the Kconfig
description talks about virt to page translations, not virt to phys.
Of course, this is a shift away from being equivalent on x86, but not
so much on arm64. Any concerns there?

> Signed-off-by: Laura Abbott 
> ---
> This has been on my TODO list for a while. It caught a few bugs with
> CONFIG_VMAP_STACK on x86 so when that eventually gets added
> for arm64 it will be useful to have. This caught one driver calling __pa on an
> ioremapped address already. RFC for a couple of reasons:
>
> 1) This is basically a direct port of the x86 approach.
> 2) I needed some #ifndef __ASSEMBLY__ which I don't like to throw around.
> 3) I'm not quite sure about the bounds check for the VIRTUAL_BUG_ON with 
> KASLR,
> specifically the _end check.
> 4) Is it worth actually keeping this as DEBUG_VIRTUAL vs. folding it into
> another option?
>
> ---
>  arch/arm64/include/asm/memory.h | 11 ++-
>  arch/arm64/mm/Makefile  |  2 +-
>  arch/arm64/mm/physaddr.c| 17 +
>  lib/Kconfig.debug   |  2 +-
>  mm/cma.c|  2 +-
>  5 files changed, 30 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm64/mm/physaddr.c
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index ba62df8..9805adc 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -106,11 +106,19 @@
>   * private definitions which should NOT be used outside memory.h
>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
>   */
> -#define __virt_to_phys(x) ({   \
> +#define __virt_to_phys_nodebug(x) ({   \
> phys_addr_t __x = (phys_addr_t)(x); \
> __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :   \
>  (__x - kimage_voffset); })
>
> +#ifdef CONFIG_DEBUG_VIRTUAL
> +#ifndef __ASSEMBLY__
> +extern unsigned long __virt_to_phys(unsigned long x);
> +#endif
> +#else
> +#define __virt_to_phys(x)  __virt_to_phys_nodebug(x)
> +#endif
> +

Couldn't you move this whole block into the #ifndef __ASSEMBLY__
section lower down in the file?

>  #define __phys_to_virt(x)  ((unsigned long)((x) - PHYS_OFFSET) | 
> PAGE_OFFSET)
>  #define __phys_to_kimg(x)  ((unsigned long)((x) + kimage_voffset))
>
> @@ -202,6 +210,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>   * Drivers should NOT use these either.
>   */
>  #define __pa(x)__virt_to_phys((unsigned long)(x))
> +#define __pa_nodebug(x)__virt_to_phys_nodebug((unsigned 
> long)(x))
>  #define __va(x)((void 
> *)__phys_to_virt((phys_addr_t)(x)))
>  #define pfn_to_kaddr(pfn)  __va((pfn) << PAGE_SHIFT)
>  #define virt_to_pfn(x)  __phys_to_pfn(__virt_to_phys(x))
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index 54bb209..bcea84e 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -5,6 +5,6 @@ obj-y   := dma-mapping.o extable.o 
> fault.o init.o \
>  obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
>  obj-$(CONFIG_ARM64_PTDUMP) += dump.o
>  obj-$(CONFIG_NUMA) += numa.o
> -
> +obj-$(CONFIG_DEBUG_VIRTUAL)+= physaddr.o
>  obj-$(CONFIG_KASAN)+= kasan_init.o
>  KASAN_SANITIZE_kasan_init.o:= n
> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
> new file mode 100644
> index 000..6c271e2
> --- /dev/null
> +++ b/arch/arm64/mm/physaddr.c
> @@ -0,0 +1,17 @@
> +#include 
> +
> +#include 
> +
> +unsigned long __virt_to_phys(unsigned long x)
> +{
> +   phys_addr_t __x = (phys_addr_t)x;
> +
> +   if (__x & BIT(VA_BITS - 1)) {
> +   /* The bit check ensures this is the right range */

Could you expand the comment to clarify that the linear region starts
right in the middle of the kernel virtual address space, and so we
only have to test the top bit?

> +   return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
> +   } else {l
> +   VIRTUAL_BUG_ON(x < kimage_vaddr || x > (unsigned long)_end);

This looks fine. References to _end are relocated at boot to refer to
the actual runtime offset.

> +   return (__x - kimage_voffset);
> +   }
> +}
> +EXPORT_SYMBOL(__virt_to_phys);
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 33bc56c..e5634bb 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -604,7 +604,7 @@ config DEBUG_VM_PGF

[PATCH v3 0/3] x86/vmware guest improvements

2016-10-28 Thread Alexey Makhalov
Thanks Thomas for the valuable comments.

Changelog for the updated patchset:
v1->v2 - Update pvinfo.name.
v2->v3 - Address comments from Thomas G,
 * Created separate function: vmware_sched_clock_setup() (patch 3/3)
 * Updated commit descriptions for 1/3 and 3/3


Alexey Makhalov (3):
  x86/vmware: Use tsc_khz value for calibrate_cpu()
  x86/vmware: Add basic paravirt ops support
  x86/vmware: Add paravirt sched clock

 Documentation/kernel-parameters.txt |  4 +++
 arch/x86/kernel/cpu/vmware.c| 55 +
 2 files changed, 59 insertions(+)

-- 
2.10.1



[PATCH v3 1/3] x86/vmware: Use tsc_khz value for calibrate_cpu()

2016-10-28 Thread Alexey Makhalov
Commit aa297292d708 ("x86/tsc: Enumerate SKL cpu_khz and tsc_khz via
CPUID") separated the calibration mechanisms for cpu_khz and tsc_khz.

Since the vmware hypervisor provides a constant frequency TSC to the guest,
this change can lead to divergence between the tsc and the cpu frequency
after vmotion, which might confuse the user.

Solve this by overriding the x86 platform cpu calibration callback with the
vmware specific tsc calibration function.

Signed-off-by: Alexey Makhalov 
Acked-by: Alok N Kataria 
---
 arch/x86/kernel/cpu/vmware.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 4e34da4b..480790f 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -83,6 +83,7 @@ static void __init vmware_platform_setup(void)
 
vmware_tsc_khz = tsc_khz;
x86_platform.calibrate_tsc = vmware_get_tsc_khz;
+   x86_platform.calibrate_cpu = vmware_get_tsc_khz;
 
 #ifdef CONFIG_X86_LOCAL_APIC
/* Skip lapic calibration since we know the bus frequency. */
-- 
2.10.1



[PATCH v3 3/3] x86/vmware: Add paravirt sched clock

2016-10-28 Thread Alexey Makhalov
The default sched_clock() implementation is native_sched_clock(). It
contains code to handle non constant frequency TSCs, which creates
overhead for systems with constant frequency TSCs.

The vmware hypervisor guarantees a constant frequency TSC, so
native_sched_clock() is not required and slower than a dedicated function
which operates with one time calculated conversion factors.

Calculate the conversion factors at boot time from the tsc frequency and
install an optimized sched_clock() function via paravirt ops.

The paravirtualized clock can be disabled on the kernel command line with
the new 'no-vmw-sched-clock' option.

Signed-off-by: Alexey Makhalov 
Acked-by: Alok N Kataria 
---
 Documentation/kernel-parameters.txt |  4 
 arch/x86/kernel/cpu/vmware.c| 42 +
 2 files changed, 46 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 37babf9..b3b2ec0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2754,6 +2754,10 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
no-kvmapf   [X86,KVM] Disable paravirtualized asynchronous page
fault handling.
 
+   no-vmw-sched-clock
+   [X86,PV_OPS] Disable paravirtualized VMware scheduler
+   clock and use the default one.
+
no-steal-acc[X86,KVM] Disable paravirtualized steal time accounting.
steal time is computed, but won't influence scheduler
behaviour
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 098a524..cdbe38b 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -24,10 +24,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
+#undef pr_fmt
+#define pr_fmt(fmt)"vmware: " fmt
 
 #define CPUID_VMWARE_INFO_LEAF 0x4000
 #define VMWARE_HYPERVISOR_MAGIC0x564D5868
@@ -62,10 +67,47 @@ static unsigned long vmware_get_tsc_khz(void)
 }
 
 #ifdef CONFIG_PARAVIRT
+static struct cyc2ns_data vmware_cyc2ns __ro_after_init;
+static int vmw_sched_clock __initdata = 1;
+
+static __init int setup_vmw_sched_clock(char *s)
+{
+   vmw_sched_clock = 0;
+   return 0;
+}
+early_param("no-vmw-sched-clock", setup_vmw_sched_clock);
+
+static unsigned long long vmware_sched_clock(void)
+{
+   unsigned long long ns;
+
+   ns = mul_u64_u32_shr(rdtsc(), vmware_cyc2ns.cyc2ns_mul,
+vmware_cyc2ns.cyc2ns_shift);
+   ns -= vmware_cyc2ns.cyc2ns_offset;
+   return ns;
+}
+
+static void __init vmware_sched_clock_setup(void)
+{
+   struct cyc2ns_data *d = &vmware_cyc2ns;
+   unsigned long long tsc_now = rdtsc();
+
+   clocks_calc_mult_shift(&d->cyc2ns_mul, &d->cyc2ns_shift,
+  vmware_tsc_khz, NSEC_PER_MSEC, 0);
+   d->cyc2ns_offset = mul_u64_u32_shr(tsc_now, d->cyc2ns_mul,
+  d->cyc2ns_shift);
+
+   pv_time_ops.sched_clock = vmware_sched_clock;
+   pr_info("using sched offset of %llu ns\n", d->cyc2ns_offset);
+}
+
 static void __init vmware_paravirt_ops_setup(void)
 {
pv_info.name = "VMware hypervisor";
pv_cpu_ops.io_delay = paravirt_nop;
+
+   if (vmware_tsc_khz && vmw_sched_clock)
+   vmware_sched_clock_setup();
 }
 #else
 #define vmware_paravirt_ops_setup() do {} while (0)
-- 
2.10.1



[PATCH v3 2/3] x86/vmware: Add basic paravirt ops support

2016-10-28 Thread Alexey Makhalov
Add basic paravirt support:
 1. set pv_info.name to "VMware hypervisor" to have proper boot log message
Booting paravirtualized kernel on VMware hypervisor
instead of "... on bare hardware"
 2. set pv_cpu_ops.io_delay() to empty function - paravirt_nop() to
avoid vm-exits on IO delays.

Signed-off-by: Alexey Makhalov 
Acked-by: Alok N Kataria 
---
 arch/x86/kernel/cpu/vmware.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 480790f..098a524 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -61,6 +61,16 @@ static unsigned long vmware_get_tsc_khz(void)
return vmware_tsc_khz;
 }
 
+#ifdef CONFIG_PARAVIRT
+static void __init vmware_paravirt_ops_setup(void)
+{
+   pv_info.name = "VMware hypervisor";
+   pv_cpu_ops.io_delay = paravirt_nop;
+}
+#else
+#define vmware_paravirt_ops_setup() do {} while (0)
+#endif
+
 static void __init vmware_platform_setup(void)
 {
uint32_t eax, ebx, ecx, edx;
@@ -94,6 +104,8 @@ static void __init vmware_platform_setup(void)
} else {
pr_warn("Failed to get TSC freq from the hypervisor\n");
}
+
+   vmware_paravirt_ops_setup();
 }
 
 /*
-- 
2.10.1



Re: [RFC PATCH 0/3] sched: Introduce Window Assisted Load Tracking

2016-10-28 Thread Vikram Mulukutla

On 2016-10-28 00:29, Peter Zijlstra wrote:

On Fri, Oct 28, 2016 at 12:10:39AM -0700, Vikram Mulukutla wrote:


We propose Window-Assisted Load Tracking (WALT) as an alternative or 
additional
load tracking scheme in lieu of or along with PELT, one that in our 
estimation
better tracks task demand and CPU utilization especially for use cases 
on
mobile devices. WALT was conceived by Srivatsa Vaddagiri to provide 
better
perf-per-watt numbers on asymmetric CPU (frequency and/or IPC) 
implementations,
(specifically on Qualcomm Snapgdragon chipsets running Android) and 
its metrics
have been used to guide task placement and p-state selection (load 
balancing
in CFS still uses PELT statistics). WALT is now present in the 
android-common

kernel as well.


And how come we only learn of it after its already shipping? Isn't that
arse backwards?


Yes, but also we were not confident that it would be close to being 
acceptable
upstream since it was intricately tied to our HMP scheduler. However now 
that
more parties including the folks at ARM are interested, and given that 
EAS

exists and schedutil was merged into mainline, we felt it the right time
to try and introduce the concept. In general we are seriously trying to 
get

more things upstream and converge.



Re: [RFC PATCH 0/3] sched: Introduce Window Assisted Load Tracking

2016-10-28 Thread Vikram Mulukutla

On 2016-10-28 00:49, Peter Zijlstra wrote:

On Fri, Oct 28, 2016 at 12:10:39AM -0700, Vikram Mulukutla wrote:
This RFC patch has been tested on live X86 machines with the following 
sanity
and benchmark results (thanks to Juri Lelli, Dietmar Eggeman, Patrick 
Bellasi

for initial code reviews):

(Tested on an Intel i7 2nd generation CPU, 8GB RAM, Nvidia GTX950Ti 
graphics,
with the same frequency list as above. Running Ubuntu 16.04 on a 
v4.8.2
baseline. WALT window size was 10ms. Only deltas above 3% are 
considered

non-noise.Power measured with Intel RAPL counters)


Was this comparison done using the use_walt_metric sysctl knob?


Yes, it was. You will want to see numbers against a pure 4.8.2 without 
any

of the WALT code, correct?


Re: [RFC PATCH 3/3] sched: Introduce WALT hooks into core and scheduling classes

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 12:10:42AM -0700, Vikram Mulukutla wrote:
> @@ -2072,13 +2078,19 @@ try_to_wake_up(struct task_struct *p, unsigned int 
> state, int wake_flags)
>*/
>   smp_cond_load_acquire(&p->on_cpu, !VAL);
>  
> + raw_spin_lock(&task_rq(p)->lock);
> + walt_update_task_ravg(p, task_rq(p), TASK_WAKE, walt_ktime_clock(), 0);
> + raw_spin_unlock(&task_rq(p)->lock);
> +

Lol. funny that.

No.


Re: [RFC PATCH 2/3] sched: Introduce Window-Assisted CPU utilization Tracking

2016-10-28 Thread Vikram Mulukutla

On 2016-10-28 00:43, Peter Zijlstra wrote:

On Fri, Oct 28, 2016 at 12:10:41AM -0700, Vikram Mulukutla wrote:

+u64 walt_ktime_clock(void)
+{
+   if (unlikely(walt_ktime_suspended))
+   return ktime_to_ns(ktime_last);
+   return ktime_get_ns();
+}



+static int walt_suspend(void)
+{
+   ktime_last = ktime_get();
+   walt_ktime_suspended = true;
+   return 0;
+}


No, ktime_get() will not be used in the scheduler. Imagine the joy if
that thing ends up being the HPET.


Agreed, this is an artifact from the full implementation that feeds into 
the
interactive governor, and thus both needed to use the same time source. 
It

shall go away.


Re: [PATCH v6 6/6] drm/fence: add out-fences support

2016-10-28 Thread Daniel Vetter
On Thu, Oct 27, 2016 at 05:37:11PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Support DRM out-fences by creating a sync_file with a fence for each CRTC
> that sets the OUT_FENCE_PTR property.
> 
> We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
> the sync_file fd back to userspace.
> 
> The sync_file and fd are allocated/created before commit, but the
> fd_install operation only happens after we know that commit succeed.
> 
> v2: Comment by Rob Clark:
>   - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
> 
> Comment by Daniel Vetter:
>   - Add clean up code for out_fences
> 
> v3: Comments by Daniel Vetter:
>   - create DRM_MODE_ATOMIC_EVENT_MASK
>   - userspace should fill out_fences_ptr with the crtc_ids for which
>   it wants fences back.
> 
> v4: Create OUT_FENCE_PTR properties and remove old approach.
> 
> v5: Comments by Brian Starkey:
>   - Remove extra fence_get() in atomic_ioctl()
>   - Check ret before iterating on the crtc_state
>   - check ret before fd_install
>   - set fence_state to NULL at the beginning
>   - check fence_state->out_fence_ptr before put_user()
>   - change order of fput() and put_unused_fd() on failure
> 
>  - Add access_ok() check to the out_fence_ptr received
>  - Rebase after fence -> dma_fence rename
>  - Store out_fence_ptr in the drm_atomic_state
>  - Split crtc_setup_out_fence()
>  - return -1 as out_fence with TEST_ONLY flag
> 
> Signed-off-by: Gustavo Padovan 

I think this looks good. Again I'll wait with full in-depth review of all
the input validation until the igt shows up, but I think we're mostly
covereed. A few smaller comments for polish below.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c | 199 
> ---
>  drivers/gpu/drm/drm_crtc.c   |   8 ++
>  include/drm/drm_atomic.h |   1 +
>  include/drm/drm_crtc.h   |  17 
>  4 files changed, 196 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 28d9366..9b70a27 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -290,6 +290,46 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
>  EXPORT_SYMBOL(drm_atomic_get_crtc_state);
>  
>  /**
> + * drm_atomic_set_out_fence_for_crtc - set CRTC out fence pointer
> + * @state: global atomic state object
> + * @crtc: crtc to set the out fence pointer
> + * @fence_ptr: the userspace pointer to user
> + *
> + * This function stores the out fence pointer in the atomic state.
> + */
> +static void
> +drm_atomic_set_out_fence_for_crtc(struct drm_atomic_state *state,
> +   struct drm_crtc *crtc, u64 __user *fence_ptr)
> +{
> + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
> +}
> +
> +/**
> + * drm_atomic_get_out_fence_for_crtc - get CRTC out fence pointer
> + * @state: global atomic state object
> + * @crtc: crtc to set the out fence pointer
> + *
> + * Get the user pointer that should be used for to store the out fence fd.
> + * This function should be called only once per atomic state as it clears
> + * the out_fence_ptr store there to prevent drivers to access them.
> + *
> + * Returns:
> + *
> + * The out fence user pointer.
> + */

We don't document non-driver-visble functions and structs, and especially
static functions should be self explanatory. I feel bad for your effort in
typing kernel-doc here :(

> +static u64 __user *
> +drm_atomic_get_out_fence_for_crtc(struct drm_atomic_state *state,
> +  struct drm_crtc *crtc)
> +{
> + u64 __user *fence_ptr;
> +
> + fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
> + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
> +
> + return fence_ptr;
> +}
> +
> +/**
>   * drm_atomic_set_mode_for_crtc - set mode for CRTC
>   * @state: the CRTC whose incoming state to update
>   * @mode: kernel-internal mode to use for the CRTC, or NULL to disable
> @@ -490,6 +530,12 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   &replaced);
>   state->color_mgmt_changed |= replaced;
>   return ret;
> + } else if (property == config->prop_out_fence_ptr) {
> + uint64_t __user *fence_ptr = u64_to_user_ptr(val);
> + if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
> + return -EFAULT;
> +
> + drm_atomic_set_out_fence_for_crtc(state->state, crtc, 
> fence_ptr);
>   } else if (crtc->funcs->atomic_set_property)
>   return crtc->funcs->atomic_set_property(crtc, state, property, 
> val);
>   else
> @@ -532,6 +578,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>   *val = (state->ctm) ? state->ctm->base.id : 0;
>   else if (property == config->gamma_lut_property)
>   *val = (state->gamm

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

2016-10-28 Thread Jan Kara
On Thu 27-10-16 10:26:18, Jens Axboe wrote:
> On 10/27/2016 03:26 AM, Jan Kara wrote:
> >On Wed 26-10-16 10:12:38, Jens Axboe wrote:
> >>On 10/26/2016 10:04 AM, Paolo Valente wrote:
> >>>
> Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe  ha 
> scritto:
> 
> On 10/26/2016 09:29 AM, Christoph Hellwig wrote:
> >On Wed, Oct 26, 2016 at 05:13:07PM +0200, Arnd Bergmann wrote:
> >>The question to ask first is whether to actually have pluggable
> >>schedulers on blk-mq at all, or just have one that is meant to
> >>do the right thing in every case (and possibly can be bypassed
> >>completely).
> >
> >That would be my preference.  Have a BFQ-variant for blk-mq as an
> >option (default to off unless opted in by the driver or user), and
> >not other scheduler for blk-mq.  Don't bother with bfq for non
> >blk-mq.  It's not like there is any advantage in the legacy-request
> >device even for slow devices, except for the option of having I/O
> >scheduling.
> 
> It's the only right way forward. blk-mq might not offer any substantial
> advantages to rotating storage, but with scheduling, it won't offer a
> downside either. And it'll take us towards the real goal, which is to
> have just one IO path.
> >>>
> >>>ok
> >>>
> Adding a new scheduler for the legacy IO path
> makes no sense.
> >>>
> >>>I would fully agree if effective and stable I/O scheduling would be
> >>>available in blk-mq in one or two months.  But I guess that it will
> >>>take at least one year optimistically, given the current status of the
> >>>needed infrastructure, and given the great difficulties of doing
> >>>effective scheduling at the high parallelism and extreme target speeds
> >>>of blk-mq.  Of course, this holds true unless little clever scheduling
> >>>is performed.
> >>>
> >>>So, what's the point in forcing a lot of users wait another year or
> >>>more, for a solution that has yet to be even defined, while they could
> >>>enjoy a much better system, and then switch an even better system when
> >>>scheduling is ready in blk-mq too?
> >>
> >>That same argument could have been made 2 years ago. Saying no to a new
> >>scheduler for the legacy framework goes back roughly that long. We could
> >>have had BFQ for mq NOW, if we didn't keep coming back to this very
> >>point.
> >>
> >>I'm hesistant to add a new scheduler because it's very easy to add, very
> >>difficult to get rid of. If we do add BFQ as a legacy scheduler now,
> >>it'll take us years and years to get rid of it again. We should be
> >>moving towards LESS moving parts in the legacy path, not more.
> >>
> >>We can keep having this discussion every few years, but I think we'd
> >>both prefer to make some actual progress here. It's perfectly fine to
> >>add an interface for a single queue interface for an IO scheduler for
> >>blk-mq, since we don't care too much about scalability there. And that
> >>won't take years, that should be a few weeks. Retrofitting BFQ on top of
> >>that should not be hard either. That can co-exist with a real multiqueue
> >>scheduler as well, something that's geared towards some fairness for
> >>faster devices.
> >
> >OK, so some solution like having a variant of blk_sq_make_request() that
> >will consume requests, do IO scheduling decisions on them, and feed them
> >into the HW queue is it sees fit would be acceptable? That will provide the
> >IO scheduler a global view that it needs for complex scheduling decisions
> >so it should indeed be relatively easy to port BFQ to work like that.
> 
> I'd probably start off Omar's base [1] that switches the software queues
> to store bios instead of requests, since that lifts the of the 1:1
> mapping between what we can queue up and what we can dispatch. Without
> that, the IO scheduler won't have too much to work with. And with that
> in place, it'll be a "bio in, request out" type of setup, which is
> similar to what we have in the legacy path.
>
> I'd keep the software queues, but as a starting point, mandate 1
> hardware queue to keep that as the per-device view of the state. The IO
> scheduler would be responsible for moving one or more bios from the
> software queues to the hardware queue, when they are ready to dispatch.
> 
> [1] 
> https://github.com/osandov/linux/commit/8ef3508628b6cf7c4712cd3d8084ee11ef5d2530

Yeah, but what would be software queues actually good for for a single
queue device with device-global IO scheduling? The IO scheduler doing
complex decisions will keep all the bios / requests in a single structure
anyway so there's no scalability to gain from per-cpu software queues...
So you can directly consume bios in your ->make_request handler, place it
in IO scheduler structures and then push requests out to the HW queue in
response to HW tags getting freed (i.e. IO completion). No need
for intermediate software queues. But maybe I miss something.

  

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-28 Thread Sebastian Andrzej Siewior
On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote:
> > I assume "init_rapl_pmus: maxpkg 4" is from init_rapl_pmus() returning
> > topology_max_packages(). So it says 4 but then returns 65535 for CPU 2
> > and 3. That -1 comes probably from topology_update_package_map(). Could
> > you please send a complete boot log and try the following patch? This
> > one should fix your boot problem and disable RAPL if the info is
> > invalid.
> 
> But sometimes the topology info is correct and if I get lucky, the
> package id could be valid for all the CPU's.  Given the behavior,
> I have seen so far it makes me thing the RAPL isn't being emulated.
> So even if I did boot onto a "valid" set of cores, would I always be
> certain that I will be on those cores?

I don't what vmware does here. Nor do they ship source to check. So if
you have a big HW box with say two packages, it might make sense to give
this information to the guest _if_ the CPUs are pinned and the guest
never migrates.

> Per your request in your next email:
> 
> > One thing I forgot to ask: Could you please check if you get the same
> > pkgid reported for cpu 0-3 on a pre-v4.8 kernel? (before the hotplug
> > rework).
> 
> Our previous kernel was 4.4, and didn't use the logical package id:
I see.

Did the patch I sent fixed it for you and were you not able to test?

Sebastian


Re: [PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes

2016-10-28 Thread Jaehoon Chung
Hi,

On 10/28/2016 04:26 PM, Leo Yan wrote:
> On Fri, Oct 28, 2016 at 08:43:51AM +0200, Vincent Guittot wrote:
> 
> [...]
> 
>>> running with? Also do you have any details about the card in case its
>>> card specific?
>>
>> The sdcard is quite common: sandisk ultra 16GB
>> and my rootfs is on the sdcard
> 
> I'm using rootfs in emmc also have same failure.
> 
>>> Guodong: Is there any bootloader dependency on that change?
>>
>> FYI, I use firmwares available in AOSP
> 
> I tried latest firmware [1], still cannot boot up until revert the
> patch "arm64: dts: hi6220: add resets property into dwmmc nodes".

Could you share the log? Is there any log about failure?

Best Regards,
Jaehoon Chung

> 
> [1] 
> http://builds.96boards.org/snapshots/hikey/linaro/uefi-openplatformpkg/latest/
> 
> Thanks,
> Leo Yan
> 
> 
> 



Re: [RFC PATCH 2/3] sched: Introduce Window-Assisted CPU utilization Tracking

2016-10-28 Thread Vikram Mulukutla

On 2016-10-28 00:46, Peter Zijlstra wrote:

On Fri, Oct 28, 2016 at 12:10:41AM -0700, Vikram Mulukutla wrote:
+void walt_finish_migrate(struct task_struct *p, struct rq *dest_rq, 
bool locked)

+{
+   u64 wallclock;
+   unsigned long flags;
+
+   if (!p->on_rq && p->state != TASK_WAKING)
+   return;
+
+   if (locked == false)
+   raw_spin_lock_irqsave(&dest_rq->lock, flags);
+



+
+   if (locked == false)
+   raw_spin_unlock_irqrestore(&dest_rq->lock, flags);
+}
+
+void walt_prepare_migrate(struct task_struct *p, struct rq *src_rq, 
bool locked)

+{
+   u64 wallclock;
+   unsigned long flags;
+
+   if (!p->on_rq && p->state != TASK_WAKING)
+   return;
+
+   if (locked == false)
+   raw_spin_lock_irqsave(&src_rq->lock, flags);
+



+
+   if (locked == false)
+   raw_spin_unlock_irqrestore(&src_rq->lock, flags);
+}


Seriously bad style that. Please, less bonghits before writing code.


This was my bad personal attempt at eliminating double-locking from the 
original code.
This was pointed out earlier and shall go away once I can come up with a 
way to merge

this into enqeue/dequeue sans bonghits :-)


Re: [RFC PATCH] kbuild: add -fno-PIE

2016-10-28 Thread Sebastian Andrzej Siewior
On 2016-10-27 11:09:06 [-0600], Shuah Khan wrote:
> diff --git a/Makefile b/Makefile
> index 82a36ab..0a01ad1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -651,6 +651,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
>  KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
>  endif
> 
> +# force no-pie for distro compilers that enable pie by default
> +KBUILD_CFLAGS += $(call cc-option, -fno-pie)
> +KBUILD_CFLAGS += $(call cc-option, -no-pie)

so why do we need -no-pie? What is different from -fno-pie

> +KBUILD_AFLAGS += $(call cc-option, -fno-pie)

Why do need to pass this to the assembler? Is this for the
fstack-protector?

> 
> thanks,
> -- Shuah

Sebastian


Re: [RFC 1/2] mmc: sdhci: dt: Add device tree properties sdhci-caps and sdhci-caps-mask

2016-10-28 Thread Ulf Hansson
On 25 October 2016 at 21:58, Zach Brown  wrote:
> On some systems the sdhci capabilty registers are incorrect for one
> reason or another.
>
> The sdhci-caps-mask property specifies which bits in the registers
> are incorrect and should be turned off before using sdhci-caps to turn
> on bits.
>
> The sdhci-caps property specifies which bits should be turned on.
>
> Signed-off-by: Zach Brown 
> ---
>  Documentation/devicetree/bindings/mmc/mmc.txt | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
> b/Documentation/devicetree/bindings/mmc/mmc.txt
> index 8a37782..1415aa0 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt

The bindings in this document are common mmc DT bindings, not bindings
specific to a mmc controller.

So unless these bindings are applicable for another controller than
sdhci, I suggest we create a new file to document these.
How about Documentation/devicetree/bindings/mmc/sdhci.txt?

> @@ -52,6 +52,13 @@ Optional properties:
>  - no-sdio: controller is limited to send sdio cmd during initialization
>  - no-sd: controller is limited to send sd cmd during initialization
>  - no-mmc: controller is limited to send mmc cmd during initialization
> +- sdhci-caps-mask: The sdhci capabilities registers are incorrect. This 64bit

/s/registers/register

This applies to some more places below as well.

> +  property corresponds to the bits in the sdhci capabilty registers. If the 
> bit
> +  is on in the mask then the bit is incorrect in the registers and should be
> +  turned off.
> +- sdhci-caps: The sdhci capabilities registers are incorrect. This 64bit
> +  property corresponds to the bits in the sdhci capability registers. If the
> +  bit is on in the property then the bit should be on in the reigsters.

/s/reigsters/register

>
>  *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers 
> line
>  polarity properties, we have to fix the meaning of the "normal" and 
> "inverted"
> --
> 2.7.4
>

Overall, I like this idea as it gives us good flexibility. Thus it
should avoid us to having to add any further new similar "sdhci broken
cap" DT binding. We could also decide to start deprecate some of the
existing sdhci bindings, if we think that makes sense.

The downside is that we get a "magic" hex value in the dts. Although,
people could address this issue by providing some comments about what
the bits it means in the dts files themselves.

Let's see what Rob thinks about this.

Kind regards
Uffe


Re: [PATCH -v4 RESEND 6/9] mm, THP, swap: Support to add/delete THP to/from swap cache

2016-10-28 Thread Hillf Danton
On Friday, October 28, 2016 1:56 PM Huang, Ying wrote:
> 
> @@ -109,9 +118,16 @@ int __add_to_swap_cache(struct page *page, swp_entry_t 
> entry)
>* So add_to_swap_cache() doesn't returns -EEXIST.
>*/
>   VM_BUG_ON(error == -EEXIST);
> - set_page_private(page, 0UL);
>   ClearPageSwapCache(page);
> - put_page(page);
> + set_page_private(cur_page, 0UL);
> + while (i--) {
> + cur_page--;
> + cur_entry.val--;
> + set_page_private(cur_page, 0UL);
> + radix_tree_delete(&address_space->page_tree,
> +   swp_offset(cur_entry));
> + }

Pull pages out of radix tree with tree lock held?

> + page_ref_sub(page, nr);
>   }
> 
>   return error;
> 



[PATCH v2] ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0>

2016-10-28 Thread Jon Medhurst (Tixy)
If a DAI specifies "#sound-dai-cells = <0>" in device-tree then
hdmi_of_xlate_dai_name() will be called with zero args, which it isn't
implemented to cope with. The resulting use of an uninitialised variable
for the id will usually result in an error like:

  asoc-simple-card sound: parse error -11
  asoc-simple-card: probe of sound failed with error -11

Fix this by using and id of zero if no arg is provided.

Fixes: 9731f82d6016 ("ASoC: hdmi-codec: enable multi probe for same device")

Signed-off-by: Jon Medhurst 
---

Changes since v1
- Replace ternary ?: operator with if/else

 sound/soc/codecs/hdmi-codec.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index b904492..90b5948 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -364,7 +364,12 @@ static int hdmi_of_xlate_dai_name(struct snd_soc_component 
*component,
  struct of_phandle_args *args,
  const char **dai_name)
 {
-   int id = args->args[0];
+   int id;
+
+   if (args->args_count)
+   id = args->args[0];
+   else
+   id = 0;
 
if (id < ARRAY_SIZE(hdmi_dai_name)) {
*dai_name = hdmi_dai_name[id];
-- 
2.1.4






[PATCH] pinctrl: max77620: add OF dependency

2016-10-28 Thread Arnd Bergmann
Drivers using pinconf_generic_params tables cannot be built with
CONFIG_OF disabled:

drivers/pinctrl/pinctrl-max77620.c:53:44: error: array type has incomplete 
element type ‘struct pinconf_generic_params’
drivers/pinctrl/pinctrl-max77620.c:55:3: error: field name not in record or 
union initializer
drivers/pinctrl/pinctrl-max77620.c:55:3: note: (near initialization for 
‘max77620_cfg_params’)
drivers/pinctrl/pinctrl-max77620.c:56:3: error: field name not in record or 
union initializer

This adds a dependency for max77620 to disallow that configuration.

Alternatively, we could rework the pinctrl infrastructure to make the
configuration valid for compile-testing.

Cc: Krzysztof Kozlowski 
Cc: Lee Jones 
Fixes: 453943dc8f45 ("mfd: Enable compile testing for max77620 and max77686")
Signed-off-by: Arnd Bergmann 
---
 drivers/pinctrl/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 801fa8bb05e1..3eea73937ce8 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -223,7 +223,7 @@ config PINCTRL_COH901
 
 config PINCTRL_MAX77620
tristate "MAX77620/MAX20024 Pincontrol support"
-   depends on MFD_MAX77620
+   depends on MFD_MAX77620 && OF
select PINMUX
select GENERIC_PINCONF
help
-- 
2.9.0



Re: [PATCH 2/2] serial: 8250_dw: Add support for IrDA SIR mode

2016-10-28 Thread Heikki Krogerus
Hi Andy,

On Thu, Oct 27, 2016 at 07:56:10PM +0300, Andy Shevchenko wrote:
> On Thu, 2016-10-27 at 17:38 +0100, Ed Blake wrote:
> > Add a set_ldisc function to enable/disable IrDA SIR mode according to
> > the new line discipline.
> 
> Thanks for the patch.
> 
> Consider that not all implementations based on 8250_dw support IRDA
> feature. I suppose you need to read capability register bits 6 and 7,
> set flag and then based on the value accept or reject IRDA mode.
> 
> P.S. Use -n when prepare patches to link them if you consider them
> dependent.

These are numbered? Or do you mean that please prefer sending
series of patches as threads?

% git send-email --thread...

Or something like that? I guess coverletter would be nice too.


Thanks,

-- 
heikki


Re: [PATCH v6 4/5] ARM: DTS: da850: Add cfgchip syscon node

2016-10-28 Thread Sekhar Nori
On Wednesday 26 October 2016 09:38 PM, David Lechner wrote:
> On 10/25/2016 10:06 PM, David Lechner wrote:
>> Add a syscon node for the SoC CFGCHIPn registers. This is needed for
>> the new usb phy driver.
>>
>> Signed-off-by: David Lechner 
>> ---
>>  arch/arm/boot/dts/da850.dtsi | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..6bbf20d 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -188,6 +188,10 @@
>>  };
>>
>>  };
>> +cfgchip: cfgchip@1417c {
> 
> I wonder if there is a more generic name instead of cfgchip@. Is there a
> preferred generic name for syscon nodes?

I did not find anything in ePAPR, but chip-controller might be more
appropriate.

> 
>> +compatible = "ti,da830-cfgchip", "syscon";

Looks like we need "simple-mfd" too in the compatible list?

I think we can also fold patch 5/5 into this patch and add the cfgchip
along with USB phy child node included.

If you respin the patch, I can drop 4/5 and 5/5 that I have queued and
included the updated patch instead.

Thanks,
Sekhar


Linux 4.4.28

2016-10-28 Thread Greg KH
I'm announcing the release of the 4.4.28 kernel.

All users of the 4.4 kernel series must upgrade.

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

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

thanks,

greg k-h



 Documentation/kernel-parameters.txt |9 -
 Makefile|2 
 arch/arc/kernel/signal.c|8 
 arch/arm64/include/asm/percpu.h |  120 ++
 arch/arm64/kernel/head.S|3 
 arch/metag/include/asm/atomic.h |3 
 arch/mips/include/asm/ptrace.h  |2 
 arch/mips/vdso/Makefile |2 
 arch/parisc/include/asm/pgtable.h   |6 
 arch/parisc/kernel/setup.c  |8 
 arch/parisc/kernel/vmlinux.lds.S|7 
 arch/powerpc/kernel/vdso64/datapage.S   |2 
 arch/powerpc/kernel/vdso64/gettimeofday.S   |2 
 arch/powerpc/lib/copyuser_64.S  |2 
 arch/powerpc/mm/copro_fault.c   |2 
 arch/powerpc/platforms/powernv/eeh-powernv.c|4 
 arch/powerpc/platforms/powernv/pci.c|4 
 arch/powerpc/platforms/pseries/lpar.c   |4 
 arch/s390/include/asm/tlbflush.h|3 
 arch/s390/mm/pgtable.c  |4 
 arch/x86/kernel/e820.c  |2 
 arch/x86/kvm/ioapic.c   |2 
 block/blk-cgroup.c  |4 
 crypto/asymmetric_keys/pkcs7_parser.c   |4 
 drivers/acpi/nfit.c |3 
 drivers/acpi/nfit.h |4 
 drivers/base/platform.c |4 
 drivers/clk/imx/clk-imx6q.c |   18 ++
 drivers/cpufreq/intel_pstate.c  |   10 -
 drivers/gpio/gpio-mpc8xxx.c |2 
 drivers/input/mouse/elantech.c  |   25 ++-
 drivers/input/serio/i8042-io.h  |2 
 drivers/input/serio/i8042-ip22io.h  |2 
 drivers/input/serio/i8042-ppcio.h   |2 
 drivers/input/serio/i8042-sparcio.h |2 
 drivers/input/serio/i8042-unicore32io.h |2 
 drivers/input/serio/i8042-x86ia64io.h   |   96 +++
 drivers/input/serio/i8042.c |   55 +-
 drivers/irqchip/irq-gic-v3.c|2 
 drivers/md/dm-crypt.c   |   24 +-
 drivers/md/dm-mpath.c   |6 
 drivers/md/dm.c |   10 -
 drivers/media/dvb-frontends/mb86a20s.c  |  104 ++--
 drivers/media/usb/cx231xx/cx231xx-avcore.c  |5 
 drivers/media/usb/cx231xx/cx231xx-cards.c   |2 
 drivers/media/usb/cx231xx/cx231xx-core.c|3 
 drivers/memstick/host/rtsx_usb_ms.c |6 
 drivers/misc/mei/hw-me-regs.h   |3 
 drivers/misc/mei/pci-me.c   |3 
 drivers/mmc/card/block.c|5 
 drivers/mmc/card/queue.h|2 
 drivers/mmc/host/rtsx_usb_sdmmc.c   |7 
 drivers/mmc/host/sdhci.c|2 
 drivers/mtd/ubi/wl.c|   21 ++
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c|4 
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c  |2 
 drivers/net/wireless/realtek/rtlwifi/regd.c |4 
 drivers/pci/quirks.c|1 
 drivers/regulator/tps65910-regulator.c  |6 
 drivers/s390/scsi/zfcp_dbf.c|  162 +---
 drivers/s390/scsi/zfcp_dbf.h|   14 +
 drivers/s390/scsi/zfcp_erp.c|   12 +
 drivers/s390/scsi/zfcp_ext.h|8 
 drivers/s390/scsi/zfcp_fsf.c|   22 ++
 drivers/s390/scsi/zfcp_fsf.h|4 
 drivers/s390/scsi/zfcp_scsi.c   |8 
 drivers/scsi/hpsa.c |   78 +
 drivers/scsi/scsi_scan.c|2 
 drivers/scsi/sd.c   |8 
 drivers/scsi/sd.h   |5 
 drivers/target/target_core_transport.c  |   11 +
 drivers/target/target_core_xcopy.c  |   34 +++-
 drivers/video/fbdev/efifb.c |6 
 fs/ceph/file.c   

Linux 4.8.5

2016-10-28 Thread Greg KH
I'm announcing the release of the 4.8.5 kernel.

All users of the 4.8 kernel series must upgrade.

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

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

thanks,

greg k-h



 Documentation/ABI/testing/sysfs-class-cxl   |7 
 Documentation/kernel-parameters.txt |9 -
 Makefile|2 
 arch/arc/kernel/signal.c|8 
 arch/arm64/include/asm/kvm_emulate.h|   11 -
 arch/arm64/include/asm/module.h |5 
 arch/arm64/include/asm/percpu.h |  120 ++
 arch/arm64/include/asm/uaccess.h|8 
 arch/arm64/kernel/armv8_deprecated.c|   36 ++--
 arch/arm64/kernel/head.S|3 
 arch/arm64/kernel/traps.c   |   27 +--
 arch/arm64/kvm/hyp/entry.S  |2 
 arch/metag/include/asm/atomic.h |3 
 arch/mips/include/asm/ptrace.h  |2 
 arch/mips/vdso/Makefile |2 
 arch/parisc/include/asm/pgtable.h   |6 
 arch/parisc/kernel/setup.c  |8 
 arch/parisc/kernel/time.c   |6 
 arch/parisc/kernel/vmlinux.lds.S|7 
 arch/powerpc/Kconfig|2 
 arch/powerpc/kernel/eeh_driver.c|8 
 arch/powerpc/kernel/vdso64/datapage.S   |2 
 arch/powerpc/kernel/vdso64/gettimeofday.S   |2 
 arch/powerpc/lib/copyuser_64.S  |2 
 arch/powerpc/mm/copro_fault.c   |2 
 arch/powerpc/mm/hash_utils_64.c |2 
 arch/powerpc/platforms/powernv/eeh-powernv.c|9 -
 arch/powerpc/platforms/powernv/pci.c|4 
 arch/powerpc/platforms/pseries/lpar.c   |4 
 arch/powerpc/sysdev/cpm1.c  |2 
 arch/powerpc/sysdev/cpm2.c  |4 
 arch/powerpc/sysdev/cpm_common.c|   15 +
 arch/powerpc/xmon/spr_access.S  |4 
 arch/s390/kvm/intercept.c   |9 -
 arch/x86/kernel/e820.c  |2 
 arch/x86/kernel/smpboot.c   |   16 +
 arch/x86/kvm/ioapic.c   |2 
 arch/x86/platform/uv/bios_uv.c  |   10 +
 block/blk-cgroup.c  |4 
 drivers/base/platform.c |4 
 drivers/clk/imx/clk-imx6q.c |   46 -
 drivers/cpufreq/cpufreq-dt-platdev.c|2 
 drivers/cpufreq/cpufreq_conservative.c  |   19 +-
 drivers/cpufreq/intel_pstate.c  |   10 -
 drivers/gpio/gpio-mpc8xxx.c |2 
 drivers/infiniband/core/verbs.c |2 
 drivers/infiniband/ulp/srp/ib_srp.c |8 
 drivers/input/mouse/elantech.c  |   25 ++-
 drivers/input/serio/i8042-io.h  |2 
 drivers/input/serio/i8042-ip22io.h  |2 
 drivers/input/serio/i8042-ppcio.h   |2 
 drivers/input/serio/i8042-sparcio.h |2 
 drivers/input/serio/i8042-unicore32io.h |2 
 drivers/input/serio/i8042-x86ia64io.h   |   96 +++
 drivers/input/serio/i8042.c |   55 +-
 drivers/irqchip/irq-eznps.c |4 
 drivers/irqchip/irq-gic-v3.c|2 
 drivers/md/dm-crypt.c   |   24 +-
 drivers/md/dm-mpath.c   |6 
 drivers/md/dm-rq.c  |   19 +-
 drivers/md/dm.c |   10 -
 drivers/media/dvb-frontends/mb86a20s.c  |  104 ++--
 drivers/media/usb/cx231xx/cx231xx-avcore.c  |5 
 drivers/media/usb/cx231xx/cx231xx-cards.c   |2 
 drivers/media/usb/cx231xx/cx231xx-core.c|   27 ++-
 drivers/memstick/host/rtsx_usb_ms.c |6 
 drivers/misc/cxl/api.c  |9 +
 drivers/misc/cxl/context.c  |3 
 drivers/misc/cxl/cxl.h  |   24 ++
 drivers/misc/cxl/file.c |   11 +
 drivers/misc/cxl/guest.c|3 
 drivers/misc/cxl/main.c |   42 +
 drivers/misc/cxl/pci.c  |2 
 drivers/misc/cxl/sysfs.c  

[PATCH v3] staging: iio: cdc: ad7746: add additional config defines

2016-10-28 Thread Eva Rachel Retuya
Introduce defines for shifting and mask under the config register for
better readability. Also, introduce helper variables for index
calculation.

Signed-off-by: Eva Rachel Retuya 
---
This patch might cause a conflict with this patch:
staging: iio: cdc/ad7746: fix missing return value
https://marc.info/?l=linux-driver-devel&m=147741283722806&w=2
I am waiting to rebase to the branch where this commit is present but
I was told it was not yet pushed to kernel.org

Changes in v3:
* Make commit message more detailed.
* Fix incorrect use of GENMASK.
* Drop the AD7746_CONF_*FS(x) macros and use the mask and direct shifting where
  needed.
* With the proper masks set, invert the AND'ng and shifting on the index
  calculations.

Changes in v2:
* Use GENMASK to generate both VTFS and CAPFS masks including offset,
  respectively.
* Introduce helper variables for index calculation.

 drivers/staging/iio/cdc/ad7746.c | 38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index f41251c..e97658a 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -70,8 +70,10 @@
 #define AD7746_EXCSETUP_EXCLVL(x)  (((x) & 0x3) << 0)
 
 /* Config Register Bit Designations (AD7746_REG_CFG) */
-#define AD7746_CONF_VTFS(x)((x) << 6)
-#define AD7746_CONF_CAPFS(x)   ((x) << 3)
+#define AD7746_CONF_VTFS_SHIFT 6
+#define AD7746_CONF_CAPFS_SHIFT3
+#define AD7746_CONF_VTFS_MASK  GENMASK(7, 6)
+#define AD7746_CONF_CAPFS_MASK GENMASK(5, 3)
 #define AD7746_CONF_MODE_IDLE  (0 << 0)
 #define AD7746_CONF_MODE_CONT_CONV (1 << 0)
 #define AD7746_CONF_MODE_SINGLE_CONV   (2 << 0)
@@ -217,15 +219,16 @@ static int ad7746_select_channel(struct iio_dev 
*indio_dev,
struct iio_chan_spec const *chan)
 {
struct ad7746_chip_info *chip = iio_priv(indio_dev);
-   int ret, delay;
+   int ret, delay, idx;
u8 vt_setup, cap_setup;
 
switch (chan->type) {
case IIO_CAPACITANCE:
cap_setup = (chan->address & 0xFF) | AD7746_CAPSETUP_CAPEN;
vt_setup = chip->vt_setup & ~AD7746_VTSETUP_VTEN;
-   delay = ad7746_cap_filter_rate_table[(chip->config >> 3) &
-   0x7][1];
+   idx = (chip->config & AD7746_CONF_CAPFS_MASK) >>
+   AD7746_CONF_CAPFS_SHIFT;
+   delay = ad7746_cap_filter_rate_table[idx][1];
 
if (chip->capdac_set != chan->channel) {
ret = i2c_smbus_write_byte_data(chip->client,
@@ -246,8 +249,9 @@ static int ad7746_select_channel(struct iio_dev *indio_dev,
case IIO_TEMP:
vt_setup = (chan->address & 0xFF) | AD7746_VTSETUP_VTEN;
cap_setup = chip->cap_setup & ~AD7746_CAPSETUP_CAPEN;
-   delay = ad7746_cap_filter_rate_table[(chip->config >> 6) &
-   0x3][1];
+   idx = (chip->config & AD7746_CONF_VTFS_MASK) >>
+   AD7746_CONF_VTFS_SHIFT;
+   delay = ad7746_cap_filter_rate_table[idx][1];
break;
default:
return -EINVAL;
@@ -369,8 +373,8 @@ static int ad7746_store_cap_filter_rate_setup(struct 
ad7746_chip_info *chip,
if (i >= ARRAY_SIZE(ad7746_cap_filter_rate_table))
i = ARRAY_SIZE(ad7746_cap_filter_rate_table) - 1;
 
-   chip->config &= ~AD7746_CONF_CAPFS(0x7);
-   chip->config |= AD7746_CONF_CAPFS(i);
+   chip->config &= ~AD7746_CONF_CAPFS_MASK;
+   chip->config |= i << AD7746_CONF_CAPFS_SHIFT;
 
return 0;
 }
@@ -387,8 +391,8 @@ static int ad7746_store_vt_filter_rate_setup(struct 
ad7746_chip_info *chip,
if (i >= ARRAY_SIZE(ad7746_vt_filter_rate_table))
i = ARRAY_SIZE(ad7746_vt_filter_rate_table) - 1;
 
-   chip->config &= ~AD7746_CONF_VTFS(0x3);
-   chip->config |= AD7746_CONF_VTFS(i);
+   chip->config &= ~AD7746_CONF_VTFS_MASK;
+   chip->config |= i << AD7746_CONF_VTFS_SHIFT;
 
return 0;
 }
@@ -527,7 +531,7 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
   long mask)
 {
struct ad7746_chip_info *chip = iio_priv(indio_dev);
-   int ret, delay;
+   int ret, delay, idx;
u8 regval, reg;
 
mutex_lock(&indio_dev->mlock);
@@ -635,13 +639,15 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_SAMP_FREQ:
switch (chan->type) {
case IIO_CAPACITANCE:
-   *val = ad7746_cap_filter_rate_table[
-   (chip->config >> 3) & 0x7][0];
+   idx = (chip->config & AD7746_CONF_CAPFS_MASK) >>
+   AD7746_CONF_CAPFS_SHIFT;
+   *val = ad7746_cap_filter_rate_table[idx][0]

[GIT PULL] objtool fix

2016-10-28 Thread Ingo Molnar
Linus,

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

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

   # HEAD: 56fb2d6eb63acd48b50437b415b6f7d2fcffe75d objtool: Fix rare switch 
jump table pattern detection

One more objtool fixlet for GCC6 code generation patterns.

 Thanks,

Ingo

-->
Josh Poimboeuf (1):
  objtool: Fix rare switch jump table pattern detection


 tools/objtool/builtin-check.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
index 4490601a9235..e8a1f699058a 100644
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -754,7 +754,7 @@ static struct rela *find_switch_table(struct objtool_file 
*file,
if (insn->type == INSN_JUMP_UNCONDITIONAL &&
insn->jump_dest &&
(insn->jump_dest->offset <= insn->offset ||
-insn->jump_dest->offset >= orig_insn->offset))
+insn->jump_dest->offset > orig_insn->offset))
break;
 
text_rela = find_rela_by_dest_range(insn->sec, insn->offset,


[PATCH 00/10] scripts/basic: Fine-tuning for seven function implementations

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Fri, 28 Oct 2016 10:18:10 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (10):
  bin2c: Complete error handling in main()
  fixdep: Complete error handling in print_deps()
  fixdep: Use the symbol "MAP_FAILED" in print_deps()
  fixdep: Fix error log output in print_deps()
  fixdep: Complete error handling in parse_dep_file()
  fixdep: Complete error handling in do_config_file()
  fixdep: Fix error log output in do_config_file()
  fixdep: Complete error handling in print_config()
  fixdep: Complete error handling in print_cmdline()
  fixdep: Combine two fprintf() calls into one fputs() call in usage()

 scripts/basic/bin2c.c  |  26 ++
 scripts/basic/fixdep.c | 131 +
 2 files changed, 105 insertions(+), 52 deletions(-)

-- 
2.10.1



Re: [PATCH -v4 RESEND 6/9] mm, THP, swap: Support to add/delete THP to/from swap cache

2016-10-28 Thread Huang, Ying
Hi, Hillf,

Hillf Danton  writes:

> On Friday, October 28, 2016 1:56 PM Huang, Ying wrote:
>> 
>> @@ -109,9 +118,16 @@ int __add_to_swap_cache(struct page *page, swp_entry_t 
>> entry)
>>   * So add_to_swap_cache() doesn't returns -EEXIST.
>>   */
>>  VM_BUG_ON(error == -EEXIST);
>> -set_page_private(page, 0UL);
>>  ClearPageSwapCache(page);
>> -put_page(page);
>> +set_page_private(cur_page, 0UL);
>> +while (i--) {
>> +cur_page--;
>> +cur_entry.val--;
>> +set_page_private(cur_page, 0UL);
>> +radix_tree_delete(&address_space->page_tree,
>> +  swp_offset(cur_entry));
>> +}
>
> Pull pages out of radix tree with tree lock held?

OOPS, I should hold the tree lock for the error path too.  Will update
it in the next version.  Thanks for pointing out this!

Best Regards,
Huang, Ying


>> +page_ref_sub(page, nr);
>>  }
>> 
>>  return error;
>> 


Re: [PATCH] phy-rockchip-pcie: remove deassert of phy_rst from exit callback

2016-10-28 Thread Heiko Stuebner
Am Donnerstag, 13. Oktober 2016, 12:42:13 CEST schrieb Shawn Lin:
> The deassert of phy_rst from exit callback is incorrect as when
> doing phy_exit, we expect the phy_rst is on asserted state which was
> done by power_off callback, but not deasserted state. Meanwhile when
> disabling clk_pciephy_ref, the assert/deassert signal can't actually
> take effect on the phy. So let's fix it anyway.
> 
> Signed-off-by: Shawn Lin 

looks ok to have that removed, as any future phy_init call will make sure it 
gets asserted anyway.

Reviewed-by: Heiko Stuebner 



Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

2016-10-28 Thread Jakub Sitnicki
On Thu, Oct 27, 2016 at 10:35 PM GMT, Tom Herbert wrote:
> On Mon, Oct 24, 2016 at 2:28 AM, Jakub Sitnicki  wrote:
>> Same as for the transmit path, let's do our best to ensure that received
>> ICMP errors that may be subject to forwarding will be routed the same
>> path as flow that triggered the error, if it was going in the opposite
>> direction.
>>
> Unfortunately our ability to do this is generally quite limited. This
> patch will select the route for multipath, but I don't believe sets
> the same link in LAG and definitely can't help switches doing ECMP to
> route the ICMP packet in the same way as the flow would be. Did you
> see a problem that warrants solving this case?

The motivation here is to bring IPv6 ECMP routing on par with IPv4 to
enable its wider use, targeting anycast services. Forwarding ICMP errors
back to the source host, at the L3 layer, is what we thought would be a
step forward.

Similar to change in IPv4 routing introduced in commit 79a131592dbb
("ipv4: ICMP packet inspection for multipath", [1]) we do our best at
L3, leaving any potential problems with LAG at lower layer (L2)
unaddressed.

>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index 1184c2b..c0f38ea 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c

[...]

>> @@ -1168,6 +1192,8 @@ void ip6_route_input(struct sk_buff *skb)
>> tun_info = skb_tunnel_info(skb);
>> if (tun_info && !(tun_info->mode & IP_TUNNEL_INFO_TX))
>> fl6.flowi6_tun_key.tun_id = tun_info->key.tun_id;
>> +   if (unlikely(fl6.flowi6_proto == IPPROTO_ICMPV6))
>> +   fl6.mp_hash = ip6_multipath_icmp_hash(skb);
>
> I will point out that this is only

Sorry, looks like part of your reply got cut short. Could you repost?

-Jakub

[1] https://git.kernel.org/torvalds/c/79a131592dbb81a2dba208622a2ffbfc53f28bc0


[PATCH 01/10] scripts/basic/bin2c: Complete error handling in main()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 27 Oct 2016 16:15:04 +0200

Return values were not checked from five calls of the function "printf".

This issue was detected also by using the Coccinelle software.


* Add a bit of exception handling there.

* Optimise this function implementation a bit.

  - Replace two output calls with the functions "fputs" and "puts".

  - Use the preincrement operator for the variable "total".

Signed-off-by: Markus Elfring 
---
 scripts/basic/bin2c.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/scripts/basic/bin2c.c b/scripts/basic/bin2c.c
index c3d7eef..c6c8860 100644
--- a/scripts/basic/bin2c.c
+++ b/scripts/basic/bin2c.c
@@ -8,29 +8,35 @@
  */
 
 #include 
+#include 
 
 int main(int argc, char *argv[])
 {
int ch, total = 0;
 
if (argc > 1)
-   printf("const char %s[] %s=\n",
-   argv[1], argc > 2 ? argv[2] : "");
+   if (printf("const char %s[] %s=\n",
+  argv[1], argc > 2 ? argv[2] : "") < 16)
+   return errno;
 
do {
-   printf("\t\"");
+   if (fputs("\t\"", stdout) < 0)
+   return errno;
+
while ((ch = getchar()) != EOF) {
-   total++;
-   printf("\\x%02x", ch);
-   if (total % 16 == 0)
+   if (printf("\\x%02x", ch) < 4)
+   return errno;
+   if (++total % 16 == 0)
break;
}
-   printf("\"\n");
+
+   if (puts("\"") < 0)
+   return errno;
} while (ch != EOF);
 
if (argc > 1)
-   printf("\t;\n\n#include \n\nconst size_t %s_size 
= %d;\n",
-  argv[1], total);
-
+   if (printf("\t;\n\n#include \n\nconst size_t 
%s_size = %d;\n",
+  argv[1], total) < 54)
+   return errno;
return 0;
 }
-- 
2.10.1



[PATCH 03/10] scripts/basic/fixdep: Use the symbol "MAP_FAILED" in print_deps()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 27 Oct 2016 18:18:54 +0200

Check the return value from a call of the function "mmap" by using
the preprocessor symbol "MAP_FAILED".

Signed-off-by: Markus Elfring 
---
 scripts/basic/fixdep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index c9ce3e3..0dcec29 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -417,7 +417,7 @@ static void print_deps(void)
goto close_fd;
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
-   if ((long) map == -1) {
+   if (map == MAP_FAILED) {
perror("fixdep: mmap");
goto close_fd;
}
-- 
2.10.1



[GIT PULL] irq fix

2016-10-28 Thread Ingo Molnar
Linus,

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

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

   # HEAD: 62c61514191bfe5731b43619b9b1bf4b423beeb0 doc: Add missing parameter 
for msi_setup

A DocBook fix.

 Thanks,

Ingo

-->
Stephen Hemminger (1):
  doc: Add missing parameter for msi_setup


 drivers/pci/msi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index bfdd0744b686..ad70507cfb56 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -610,6 +610,7 @@ static int msi_verify_entries(struct pci_dev *dev)
  * msi_capability_init - configure device's MSI capability structure
  * @dev: pointer to the pci_dev data structure of MSI device function
  * @nvec: number of interrupts to allocate
+ * @affinity: flag to indicate cpu irq affinity mask should be set
  *
  * Setup the MSI capability structure of the device with the requested
  * number of interrupts.  A return value of zero indicates the successful
@@ -752,6 +753,7 @@ static void msix_program_entries(struct pci_dev *dev,
  * @dev: pointer to the pci_dev data structure of MSI-X device function
  * @entries: pointer to an array of struct msix_entry entries
  * @nvec: number of @entries
+ * @affinity: flag to indicate cpu irq affinity mask should be set
  *
  * Setup the MSI-X capability structure of device function with a
  * single MSI-X irq. A return of zero indicates the successful setup of


[PATCH 02/10] scripts/basic/fixdep: Complete error handling in print_deps()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 27 Oct 2016 18:08:30 +0200

Return values were not checked from calls of the functions "close"
and "munmap".

This issue was detected also by using the Coccinelle software.


Add a bit of exception handling there.

Signed-off-by: Markus Elfring 
---
 scripts/basic/fixdep.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index fff818b..c9ce3e3 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -113,6 +113,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int insert_extra_deps;
 char *target;
@@ -413,21 +414,24 @@ static void print_deps(void)
}
if (st.st_size == 0) {
fprintf(stderr,"fixdep: %s is empty\n",depfile);
-   close(fd);
-   return;
+   goto close_fd;
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
if ((long) map == -1) {
perror("fixdep: mmap");
-   close(fd);
-   return;
+   goto close_fd;
}
 
parse_dep_file(map, st.st_size);
-
-   munmap(map, st.st_size);
-
-   close(fd);
+   if (munmap(map, st.st_size))
+   perror("fixdep: munmap");
+close_fd:
+   if (close(fd)) {
+   int code = errno;
+
+   perror("fixdep: close");
+   exit(code);
+   }
 }
 
 int main(int argc, char *argv[])
-- 
2.10.1



[PATCH 04/10] scripts/basic/fixdep: Fix error log output in print_deps()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 27 Oct 2016 19:04:01 +0200

The function "perror" was called after a call of the function "fprintf"
in two if branches. So it could happen that an error message was displayed
for a failed print operation instead of the failure according to the call
of the function "fstat" or "open" here.

* Pass the relevant error data in the logging calls directly.

* Express that the corresponding return values are intentionally unused
  by casts to void.

Signed-off-by: Markus Elfring 
---
 scripts/basic/fixdep.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 0dcec29..9a2ff68 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -403,13 +403,15 @@ static void print_deps(void)
 
fd = open(depfile, O_RDONLY);
if (fd < 0) {
-   fprintf(stderr, "fixdep: error opening depfile: ");
-   perror(depfile);
+   (void) fprintf(stderr,
+  "fixdep: error opening depfile: %s: %s\n",
+  depfile, strerror(errno));
exit(2);
}
if (fstat(fd, &st) < 0) {
-   fprintf(stderr, "fixdep: error fstat'ing depfile: ");
-   perror(depfile);
+   (void) fprintf(stderr,
+  "fixdep: error fstat'ing depfile: %s: %s\n",
+  depfile, strerror(errno));
exit(2);
}
if (st.st_size == 0) {
-- 
2.10.1



Re: [PATCH] drm/mediatek: fix null pointer dereference

2016-10-28 Thread CK Hu
Hi, Matthias:

Even though OVL HW would not be enabled before component_add() in
current design, your patch would be safe for any situation.

Acked-by CK Hu 

Regards,
CK

On Wed, 2016-10-26 at 16:09 +0200, Matthias Brugger wrote:
> The probe function requests the interrupt before initializing
> the ddp component. Which leads to a null pointer dereference at boot.
> Fix this by requesting the interrput after all components got
> initialized properly.
> 
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC
> MT8173.")
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 019b7ca..1e78159 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -250,13 +250,6 @@ static int mtk_disp_ovl_probe(struct platform_device 
> *pdev)
>   if (irq < 0)
>   return irq;
>  
> - ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
> -IRQF_TRIGGER_NONE, dev_name(dev), priv);
> - if (ret < 0) {
> - dev_err(dev, "Failed to request irq %d: %d\n", irq, ret);
> - return ret;
> - }
> -
>   comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_OVL);
>   if (comp_id < 0) {
>   dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
> @@ -272,6 +265,13 @@ static int mtk_disp_ovl_probe(struct platform_device 
> *pdev)
>  
>   platform_set_drvdata(pdev, priv);
>  
> + ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
> +IRQF_TRIGGER_NONE, dev_name(dev), priv);
> + if (ret < 0) {
> + dev_err(dev, "Failed to request irq %d: %d\n", irq, ret);
> + return ret;
> + }
> +
>   ret = component_add(dev, &mtk_disp_ovl_component_ops);
>   if (ret)
>   dev_err(dev, "Failed to add component: %d\n", ret);




[GIT PULL] scheduler fix

2016-10-28 Thread Ingo Molnar
Linus,

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

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

   # HEAD: f5d6d2da0d9098a4aa0ebcc187aa0fc167045d6b sched/fair: Remove unused 
but set variable 'rq'

An unused variable warning fix.

 Thanks,

Ingo

-->
Tobias Klauser (1):
  sched/fair: Remove unused but set variable 'rq'


 kernel/sched/fair.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d941c97dfbc3..c242944f5cbd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8839,7 +8839,6 @@ int alloc_fair_sched_group(struct task_group *tg, struct 
task_group *parent)
 {
struct sched_entity *se;
struct cfs_rq *cfs_rq;
-   struct rq *rq;
int i;
 
tg->cfs_rq = kzalloc(sizeof(cfs_rq) * nr_cpu_ids, GFP_KERNEL);
@@ -8854,8 +8853,6 @@ int alloc_fair_sched_group(struct task_group *tg, struct 
task_group *parent)
init_cfs_bandwidth(tg_cfs_bandwidth(tg));
 
for_each_possible_cpu(i) {
-   rq = cpu_rq(i);
-
cfs_rq = kzalloc_node(sizeof(struct cfs_rq),
  GFP_KERNEL, cpu_to_node(i));
if (!cfs_rq)


[PATCH 05/10] scripts/basic/fixdep: Complete error handling in parse_dep_file()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 27 Oct 2016 19:43:43 +0200

Return values were not checked from five calls of the function "printf".

This issue was detected also by using the Coccinelle software.


* Add a bit of exception handling there.

* Combine these calls into three.

Signed-off-by: Markus Elfring 
---
 scripts/basic/fixdep.c | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 9a2ff68..5f6a4f4 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -366,14 +366,25 @@ static void parse_dep_file(void *map, size_t len)
 */
if (!saw_any_target) {
saw_any_target = 1;
-   printf("source_%s := %s\n\n",
-   target, s);
-   printf("deps_%s := \\\n",
-   target);
+   if (printf("source_%s := %s\n\n"
+  "deps_%s := \\\n",
+  target, s, target)
+  < 24) {
+   int code = errno;
+
+   perror("fixdep: 
printf");
+   exit(code);
+   }
}
is_first_dep = 0;
-   } else
-   printf("  %s \\\n", s);
+   } else {
+   if (printf("  %s \\\n", s) < 5) {
+   int code = errno;
+
+   perror("fixdep: printf");
+   exit(code);
+   }
+   }
do_config_file(s);
}
}
@@ -391,8 +402,13 @@ static void parse_dep_file(void *map, size_t len)
 
do_extra_deps();
 
-   printf("\n%s: $(deps_%s)\n\n", target, target);
-   printf("$(deps_%s):\n", target);
+   if (printf("\n%s: $(deps_%s)\n\n"
+  "$(deps_%s):\n", target, target, target) < 27) {
+   int code = errno;
+
+   perror("fixdep: printf");
+   exit(code);
+   }
 }
 
 static void print_deps(void)
-- 
2.10.1



[PATCH 06/10] scripts/basic/fixdep: Complete error handling in do_config_file()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 27 Oct 2016 22:02:42 +0200

Return values were not checked from four calls of the function "close".

This issue was detected also by using the Coccinelle software.


Add a bit of exception handling there.

Signed-off-by: Markus Elfring 
---
 scripts/basic/fixdep.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 5f6a4f4..be0fdaa 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -284,27 +284,33 @@ static void do_config_file(const char *filename)
perror(filename);
exit(2);
}
-   if (st.st_size == 0) {
-   close(fd);
-   return;
-   }
+   if (st.st_size == 0)
+   goto close_fd;
map = malloc(st.st_size + 1);
if (!map) {
perror("fixdep: malloc");
-   close(fd);
-   return;
+   goto close_fd;
}
if (read(fd, map, st.st_size) != st.st_size) {
perror("fixdep: read");
-   close(fd);
-   return;
+   goto close_fd;
}
map[st.st_size] = '\0';
-   close(fd);
-
+   if (close(fd))
+   goto close_failure;
parse_config_file(map);
-
free(map);
+   return;
+close_fd:
+   if (close(fd)) {
+close_failure:
+   {
+   int code = errno;
+
+   perror("fixdep: close");
+   exit(code);
+   }
+   }
 }
 
 /*
-- 
2.10.1



[GIT PULL] timer fixes

2016-10-28 Thread Ingo Molnar
Linus,

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

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

   # HEAD: 6bad6bccf2d717f652d37e63cf261eaa23466009 timers: Prevent base clock 
corruption when forwarding

Fix four timer locking races: two were noticed by you while reviewing the code 
while chasing for a corruption bug, and two from fixing spurious USB timeouts.

 Thanks,

Ingo

-->
Thomas Gleixner (4):
  timers: Plug locking race vs. timer migration
  timers: Lock base for same bucket optimization
  timers: Prevent base clock rewind when forwarding clock
  timers: Prevent base clock corruption when forwarding


 kernel/time/timer.c | 74 +++--
 1 file changed, 44 insertions(+), 30 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 2d47980a1bc4..c611c47de884 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -878,7 +878,7 @@ static inline struct timer_base *get_timer_base(u32 tflags)
 
 #ifdef CONFIG_NO_HZ_COMMON
 static inline struct timer_base *
-__get_target_base(struct timer_base *base, unsigned tflags)
+get_target_base(struct timer_base *base, unsigned tflags)
 {
 #ifdef CONFIG_SMP
if ((tflags & TIMER_PINNED) || !base->migration_enabled)
@@ -891,25 +891,27 @@ __get_target_base(struct timer_base *base, unsigned 
tflags)
 
 static inline void forward_timer_base(struct timer_base *base)
 {
+   unsigned long jnow = READ_ONCE(jiffies);
+
/*
 * We only forward the base when it's idle and we have a delta between
 * base clock and jiffies.
 */
-   if (!base->is_idle || (long) (jiffies - base->clk) < 2)
+   if (!base->is_idle || (long) (jnow - base->clk) < 2)
return;
 
/*
 * If the next expiry value is > jiffies, then we fast forward to
 * jiffies otherwise we forward to the next expiry value.
 */
-   if (time_after(base->next_expiry, jiffies))
-   base->clk = jiffies;
+   if (time_after(base->next_expiry, jnow))
+   base->clk = jnow;
else
base->clk = base->next_expiry;
 }
 #else
 static inline struct timer_base *
-__get_target_base(struct timer_base *base, unsigned tflags)
+get_target_base(struct timer_base *base, unsigned tflags)
 {
return get_timer_this_cpu_base(tflags);
 }
@@ -917,14 +919,6 @@ __get_target_base(struct timer_base *base, unsigned tflags)
 static inline void forward_timer_base(struct timer_base *base) { }
 #endif
 
-static inline struct timer_base *
-get_target_base(struct timer_base *base, unsigned tflags)
-{
-   struct timer_base *target = __get_target_base(base, tflags);
-
-   forward_timer_base(target);
-   return target;
-}
 
 /*
  * We are using hashed locking: Holding per_cpu(timer_bases[x]).lock means
@@ -943,7 +937,14 @@ static struct timer_base *lock_timer_base(struct 
timer_list *timer,
 {
for (;;) {
struct timer_base *base;
-   u32 tf = timer->flags;
+   u32 tf;
+
+   /*
+* We need to use READ_ONCE() here, otherwise the compiler
+* might re-read @tf between the check for TIMER_MIGRATING
+* and spin_lock().
+*/
+   tf = READ_ONCE(timer->flags);
 
if (!(tf & TIMER_MIGRATING)) {
base = get_timer_base(tf);
@@ -964,6 +965,8 @@ __mod_timer(struct timer_list *timer, unsigned long 
expires, bool pending_only)
unsigned long clk = 0, flags;
int ret = 0;
 
+   BUG_ON(!timer->function);
+
/*
 * This is a common optimization triggered by the networking code - if
 * the timer is re-modified to have the same timeout or ends up in the
@@ -972,13 +975,16 @@ __mod_timer(struct timer_list *timer, unsigned long 
expires, bool pending_only)
if (timer_pending(timer)) {
if (timer->expires == expires)
return 1;
+
/*
-* Take the current timer_jiffies of base, but without holding
-* the lock!
+* We lock timer base and calculate the bucket index right
+* here. If the timer ends up in the same bucket, then we
+* just update the expiry time and avoid the whole
+* dequeue/enqueue dance.
 */
-   base = get_timer_base(timer->flags);
-   clk = base->clk;
+   base = lock_timer_base(timer, &flags);
 
+   clk = base->clk;
idx = calc_wheel_index(expires, clk);
 
/*
@@ -988,14 +994,14 @@ __mod_timer(struct timer_list *timer, unsigned long 
expires, bool pending_only)
 */
if (idx == timer_get_idx(timer)) {
timer->expires = expires;
- 

[PATCH 08/10] scripts/basic/fixdep: Complete error handling in print_config()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 27 Oct 2016 22:45:03 +0200

Return values were not checked from calls of the function "printf"
and "putchar".

This issue was detected also by using the Coccinelle software.

* Add a bit of exception handling there.

* Optimise this function implementation a bit by replacing two output calls
  with the functions "fputs" and "puts".

Signed-off-by: Markus Elfring 
---
 scripts/basic/fixdep.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 2c4ec91..f5ff6eea 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -142,16 +142,26 @@ static void print_config(const char *m, int slen)
 {
int c, i;
 
-   printf("$(wildcard include/config/");
+   if (fputs("$(wildcard include/config/", stdout) < 0)
+   goto put_failure;
for (i = 0; i < slen; i++) {
c = m[i];
if (c == '_')
c = '/';
else
c = tolower(c);
-   putchar(c);
+   if (putchar(c) == EOF)
+   goto put_failure;
+   }
+   if (puts(".h) \\") < 0) {
+put_failure:
+   {
+   int code = errno;
+
+   perror("fixdep: print_config");
+   exit(code);
+   }
}
-   printf(".h) \\\n");
 }
 
 static void do_extra_deps(void)
-- 
2.10.1



[PATCH 07/10] scripts/basic/fixdep: Fix error log output in do_config_file()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 27 Oct 2016 22:15:14 +0200

The function "perror" was called after a call of the function "fprintf"
in two if branches. So it could happen that an error message was displayed
for a failed print operation instead of the failure according to the call
of the function "fstat" or "open" here.

* Pass the relevant error data in the logging calls directly.

* Express that the corresponding return values are intentionally unused
  by casts to void.

Signed-off-by: Markus Elfring 
---
 scripts/basic/fixdep.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index be0fdaa..2c4ec91 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -275,13 +275,15 @@ static void do_config_file(const char *filename)
 
fd = open(filename, O_RDONLY);
if (fd < 0) {
-   fprintf(stderr, "fixdep: error opening config file: ");
-   perror(filename);
+   (void) fprintf(stderr,
+  "fixdep: error opening config file: %s: %s\n",
+  filename, strerror(errno));
exit(2);
}
if (fstat(fd, &st) < 0) {
-   fprintf(stderr, "fixdep: error fstat'ing config file: ");
-   perror(filename);
+   (void) fprintf(stderr,
+  "fixdep: error fstat'ing config file: %s: %s\n",
+  filename, strerror(errno));
exit(2);
}
if (st.st_size == 0)
-- 
2.10.1



[tip:x86/urgent] x86/microcode/AMD: Fix more fallout from CONFIG_RANDOMIZE_MEMORY=y

2016-10-28 Thread tip-bot for Borislav Petkov
Commit-ID:  1c27f646b18fb56308dff82784ca61951bad0b48
Gitweb: http://git.kernel.org/tip/1c27f646b18fb56308dff82784ca61951bad0b48
Author: Borislav Petkov 
AuthorDate: Thu, 27 Oct 2016 14:36:23 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 28 Oct 2016 10:29:59 +0200

x86/microcode/AMD: Fix more fallout from CONFIG_RANDOMIZE_MEMORY=y

We needed the physical address of the container in order to compute the
offset within the relocated ramdisk. And we did this by doing __pa() on
the virtual address.

However, __pa() does checks whether the physical address is within
PAGE_OFFSET and __START_KERNEL_map - see __phys_addr() - which fail
if we have CONFIG_RANDOMIZE_MEMORY enabled: we feed a virtual address
which *doesn't* have the randomization offset into a function which uses
PAGE_OFFSET which *does* have that offset.

This makes this check fire:

VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x));
^^

due to the randomization offset.

The fix is as simple as using __pa_nodebug() because we do that
randomization offset accounting later in that function ourselves.

Reported-by: Bob Peterson 
Tested-by: Bob Peterson 
Signed-off-by: Borislav Petkov 
Cc: Andreas Gruenbacher 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Mel Gorman 
Cc: Peter Zijlstra 
Cc: Steven Whitehouse 
Cc: Thomas Gleixner 
Cc: linux-mm 
Cc: sta...@vger.kernel.org # 4.9
Link: http://lkml.kernel.org/r/20161027123623.j2jri5bandimb...@pd.tnic
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/microcode/amd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
b/arch/x86/kernel/cpu/microcode/amd.c
index 620ab06..017bda1 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -429,7 +429,7 @@ int __init save_microcode_in_initrd_amd(void)
 * We need the physical address of the container for both bitness since
 * boot_params.hdr.ramdisk_image is a physical address.
 */
-   cont= __pa(container);
+   cont= __pa_nodebug(container);
cont_va = container;
 #endif
 


[PATCH 09/10] scripts/basic/fixdep: Complete error handling in print_cmdline()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Fri, 28 Oct 2016 09:29:59 +0200

A return value was not checked from a call of the function "printf".

This issue was detected also by using the Coccinelle software.


Add a bit of exception handling there.

Signed-off-by: Markus Elfring 
---
 scripts/basic/fixdep.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index f5ff6eea..911347a 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -132,7 +132,12 @@ static void usage(void)
  */
 static void print_cmdline(void)
 {
-   printf("cmd_%s := %s\n\n", target, cmdline);
+   if (printf("cmd_%s := %s\n\n", target, cmdline) < 10) {
+   int code = errno;
+
+   perror("fixdep: print_cmdline");
+   exit(code);
+   }
 }
 
 /*
-- 
2.10.1



[GIT PULL] x86 fixes

2016-10-28 Thread Ingo Molnar
Linus,

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

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

   # HEAD: 1c27f646b18fb56308dff82784ca61951bad0b48 x86/microcode/AMD: Fix more 
fallout from CONFIG_RANDOMIZE_MEMORY=y

Misc fixes: three build fixes, an unwinder fix and a microcode loader fix.

 Thanks,

Ingo

-->
Arnd Bergmann (1):
  x86/quirks: Hide maybe-uninitialized warning

Borislav Petkov (1):
  x86/microcode/AMD: Fix more fallout from CONFIG_RANDOMIZE_MEMORY=y

Jan Beulich (1):
  x86/build: Fix build with older GCC versions

Josh Poimboeuf (1):
  x86/unwind: Fix empty stack dereference in guess unwinder

Steven Rostedt (1):
  x86: Fix export for mcount and __fentry__


 arch/x86/entry/Makefile | 4 ++--
 arch/x86/kernel/cpu/microcode/amd.c | 2 +-
 arch/x86/kernel/mcount_64.S | 3 ++-
 arch/x86/kernel/quirks.c| 3 +--
 arch/x86/kernel/unwind_guess.c  | 9 -
 5 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile
index 77f28ce9c646..9976fcecd17e 100644
--- a/arch/x86/entry/Makefile
+++ b/arch/x86/entry/Makefile
@@ -5,8 +5,8 @@
 OBJECT_FILES_NON_STANDARD_entry_$(BITS).o   := y
 OBJECT_FILES_NON_STANDARD_entry_64_compat.o := y
 
-CFLAGS_syscall_64.o+= -Wno-override-init
-CFLAGS_syscall_32.o+= -Wno-override-init
+CFLAGS_syscall_64.o+= $(call cc-option,-Wno-override-init,)
+CFLAGS_syscall_32.o+= $(call cc-option,-Wno-override-init,)
 obj-y  := entry_$(BITS).o thunk_$(BITS).o 
syscall_$(BITS).o
 obj-y  += common.o
 
diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
b/arch/x86/kernel/cpu/microcode/amd.c
index 620ab06bcf45..017bda12caae 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -429,7 +429,7 @@ int __init save_microcode_in_initrd_amd(void)
 * We need the physical address of the container for both bitness since
 * boot_params.hdr.ramdisk_image is a physical address.
 */
-   cont= __pa(container);
+   cont= __pa_nodebug(container);
cont_va = container;
 #endif
 
diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/mcount_64.S
index efe73aacf966..7b0d3da52fb4 100644
--- a/arch/x86/kernel/mcount_64.S
+++ b/arch/x86/kernel/mcount_64.S
@@ -18,8 +18,10 @@
 
 #ifdef CC_USING_FENTRY
 # define function_hook __fentry__
+EXPORT_SYMBOL(__fentry__)
 #else
 # define function_hook mcount
+EXPORT_SYMBOL(mcount)
 #endif
 
 /* All cases save the original rbp (8 bytes) */
@@ -295,7 +297,6 @@ GLOBAL(ftrace_stub)
jmp fgraph_trace
 END(function_hook)
 #endif /* CONFIG_DYNAMIC_FTRACE */
-EXPORT_SYMBOL(function_hook)
 #endif /* CONFIG_FUNCTION_TRACER */
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index 51402a7e4ca6..0bee04d41bed 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -625,8 +625,6 @@ static void amd_disable_seq_and_redirect_scrub(struct 
pci_dev *dev)
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3,
amd_disable_seq_and_redirect_scrub);
 
-#endif
-
 #if defined(CONFIG_X86_64) && defined(CONFIG_X86_MCE)
 #include 
 #include 
@@ -657,3 +655,4 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2fc0, 
quirk_intel_brickland_xeon_
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, 
quirk_intel_brickland_xeon_ras_cap);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2083, 
quirk_intel_purley_xeon_ras_cap);
 #endif
+#endif
diff --git a/arch/x86/kernel/unwind_guess.c b/arch/x86/kernel/unwind_guess.c
index 9298993dc8b7..2d721e533cf4 100644
--- a/arch/x86/kernel/unwind_guess.c
+++ b/arch/x86/kernel/unwind_guess.c
@@ -47,7 +47,14 @@ void __unwind_start(struct unwind_state *state, struct 
task_struct *task,
get_stack_info(first_frame, state->task, &state->stack_info,
   &state->stack_mask);
 
-   if (!__kernel_text_address(*first_frame))
+   /*
+* The caller can provide the address of the first frame directly
+* (first_frame) or indirectly (regs->sp) to indicate which stack frame
+* to start unwinding at.  Skip ahead until we reach it.
+*/
+   if (!unwind_done(state) &&
+   (!on_stack(&state->stack_info, first_frame, sizeof(long)) ||
+   !__kernel_text_address(*first_frame)))
unwind_next_frame(state);
 }
 EXPORT_SYMBOL_GPL(__unwind_start);


[PATCH] ARC: Enable PERF_EVENTS in nSIM driven platforms

2016-10-28 Thread Alexey Brodkin
Now when we have properly working performance counters in nSIM
even with interrupt support (fix should be a part of upcoming
nSIM engineering build 2016.12-005) we may enable perf support
by default for all platforms that use nSIM for ARC cores simulation.

Note all defconfigs were regenerated with "make savedefconfig"
which led to some clean-ups in nsimosci_hs_smp_defconfig:
CONFIG_FRAMEBUFFER_CONSOLE=y was removed because it is automatically
selected now by DRM.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/configs/nsim_700_defconfig| 1 +
 arch/arc/configs/nsim_hs_defconfig | 1 +
 arch/arc/configs/nsim_hs_smp_defconfig | 1 +
 arch/arc/configs/nsimosci_defconfig| 1 +
 arch/arc/configs/nsimosci_hs_defconfig | 1 +
 arch/arc/configs/nsimosci_hs_smp_defconfig | 3 +--
 6 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arc/configs/nsim_700_defconfig 
b/arch/arc/configs/nsim_700_defconfig
index 7314f538847b..b0066a749d4c 100644
--- a/arch/arc/configs/nsim_700_defconfig
+++ b/arch/arc/configs/nsim_700_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsim_hs_defconfig 
b/arch/arc/configs/nsim_hs_defconfig
index 65ab9fbf83f2..ebe9ebb92933 100644
--- a/arch/arc/configs/nsim_hs_defconfig
+++ b/arch/arc/configs/nsim_hs_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsim_hs_smp_defconfig 
b/arch/arc/configs/nsim_hs_smp_defconfig
index 3b3990cddbe1..4bde43278be6 100644
--- a/arch/arc/configs/nsim_hs_smp_defconfig
+++ b/arch/arc/configs/nsim_hs_smp_defconfig
@@ -12,6 +12,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsimosci_defconfig 
b/arch/arc/configs/nsimosci_defconfig
index 98cf20933bbb..f6fb3d26557e 100644
--- a/arch/arc/configs/nsimosci_defconfig
+++ b/arch/arc/configs/nsimosci_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsimosci_hs_defconfig 
b/arch/arc/configs/nsimosci_hs_defconfig
index ddf8b96d494e..b9f0fe00044b 100644
--- a/arch/arc/configs/nsimosci_hs_defconfig
+++ b/arch/arc/configs/nsimosci_hs_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsimosci_hs_smp_defconfig 
b/arch/arc/configs/nsimosci_hs_smp_defconfig
index ceb90745326e..6da71ba253a9 100644
--- a/arch/arc/configs/nsimosci_hs_smp_defconfig
+++ b/arch/arc/configs/nsimosci_hs_smp_defconfig
@@ -10,6 +10,7 @@ CONFIG_IKCONFIG_PROC=y
 # CONFIG_PID_NS is not set
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
+CONFIG_PERF_EVENTS=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
 CONFIG_MODULES=y
@@ -34,7 +35,6 @@ CONFIG_INET=y
 # CONFIG_INET_XFRM_MODE_TRANSPORT is not set
 # CONFIG_INET_XFRM_MODE_TUNNEL is not set
 # CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
 # CONFIG_IPV6 is not set
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
@@ -72,7 +72,6 @@ CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HWMON is not set
 CONFIG_DRM=y
 CONFIG_DRM_ARCPGU=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_HID is not set
 # CONFIG_USB_SUPPORT is not set
-- 
2.7.4



[PATCH 10/10] scripts/basic/fixdep: Combine two fprintf() calls into one fputs() call in usage()

2016-10-28 Thread SF Markus Elfring
From: Markus Elfring 
Date: Fri, 28 Oct 2016 09:45:30 +0200

Some data were printed by two separate function calls.
Print the same data by a single call of the function "fputs" instead.

This issue was detected also by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 scripts/basic/fixdep.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 911347a..bdd031f 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -122,8 +122,10 @@ char *cmdline;
 
 static void usage(void)
 {
-   fprintf(stderr, "Usage: fixdep [-e]   \n");
-   fprintf(stderr, " -e  insert extra dependencies given on stdin\n");
+   if (fputs("Usage: fixdep [-e]   \n"
+ " -e  insert extra dependencies given on stdin\n", stderr)
+  < 0)
+   perror("fixdep: usage");
exit(1);
 }
 
-- 
2.10.1



[PATCH 3/4] drivers: base: cacheinfo: add pr_fmt logging

2016-10-28 Thread Sudeep Holla
This cleanup patch just adds pr_fmt style logging for cacheinfo.

Cc: Greg Kroah-Hartman 
Signed-off-by: Sudeep Holla 
---
 drivers/base/cacheinfo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 70e13cf06ed0..f19d50bd8925 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -16,6 +16,8 @@
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see .
  */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
-- 
2.7.4



[PATCH 0/4] drivers: base: cacheinfo: fixes/updates

2016-10-28 Thread Sudeep Holla
Hi Greg,

Since the couple of fixes here are not too severe, I am considering as
updates only.

Now the x86 allow CONFIG_OF to be enabled and ACPI on arm64, we have
couple of minor bugs in those configurations. The first 2 patches fixes
them. The 3rd patch is cosmetic update to help identify the logs easily.

The last patch adds the basic support for overriding cache properties
using the device tree.

Regards,
Sudeep

Sudeep Holla (4):
  drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
  drivers: base: cacheinfo: fix boot error message when acpi is enabled
  drivers: base: cacheinfo: add pr_fmt logging
  drivers: base: cacheinfo: support DT overrides for cache properties

 arch/x86/kernel/cpu/intel_cacheinfo.c |   2 +
 drivers/base/cacheinfo.c  | 138 +-
 include/linux/cacheinfo.h |   1 +
 3 files changed, 137 insertions(+), 4 deletions(-)

-- 
2.7.4



[PATCH 4/4] drivers: base: cacheinfo: support DT overrides for cache properties

2016-10-28 Thread Sudeep Holla
Few architectures like x86, ia64 and s390 derive the cache topology and
all the properties using a specific architected mechanism while some
other architectures like powerpc all those information id derived from
the device tree.

On ARM, both the mechanism is used. While all the cache properties can
be derived in a architected way, it needs to rely on device tree to get
the cache topology information.

However there are few platforms where this architected mechanism is
broken and the device tree properties can be used to override these
incorrect values.

This patch adds support for overriding the cache properties values to
the values specified in the device tree.

Cc: Alex Van Brunt 
Cc: Greg Kroah-Hartman 
Signed-off-by: Sudeep Holla 
---
 drivers/base/cacheinfo.c | 121 +++
 1 file changed, 121 insertions(+)

diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index f19d50bd8925..2376628c599c 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -88,7 +88,120 @@ static inline bool cache_leaves_are_shared(struct cacheinfo 
*this_leaf,
 {
return sib_leaf->of_node == this_leaf->of_node;
 }
+
+/* OF properties to query for a given cache type */
+struct cache_type_info {
+   const char *size_prop;
+   const char *line_size_props[2];
+   const char *nr_sets_prop;
+};
+
+static const struct cache_type_info cache_type_info[] = {
+   {
+   .size_prop   = "cache-size",
+   .line_size_props = { "cache-line-size",
+"cache-block-size", },
+   .nr_sets_prop= "cache-sets",
+   }, {
+   .size_prop   = "i-cache-size",
+   .line_size_props = { "i-cache-line-size",
+"i-cache-block-size", },
+   .nr_sets_prop= "i-cache-sets",
+   }, {
+   .size_prop   = "d-cache-size",
+   .line_size_props = { "d-cache-line-size",
+"d-cache-block-size", },
+   .nr_sets_prop= "d-cache-sets",
+   },
+};
+
+static inline int get_cacheinfo_idx(enum cache_type type)
+{
+   if (type == CACHE_TYPE_UNIFIED)
+   return 0;
+   return type;
+}
+
+static void cache_size(struct cacheinfo *this_leaf)
+{
+   const char *propname;
+   const __be32 *cache_size;
+   int ct_idx;
+
+   ct_idx = get_cacheinfo_idx(this_leaf->type);
+   propname = cache_type_info[ct_idx].size_prop;
+
+   cache_size = of_get_property(this_leaf->of_node, propname, NULL);
+   if (cache_size)
+   this_leaf->size = of_read_number(cache_size, 1);
+}
+
+/* not cache_line_size() because that's a macro in include/linux/cache.h */
+static void cache_get_line_size(struct cacheinfo *this_leaf)
+{
+   const __be32 *line_size;
+   int i, lim, ct_idx;
+
+   ct_idx = get_cacheinfo_idx(this_leaf->type);
+   lim = ARRAY_SIZE(cache_type_info[ct_idx].line_size_props);
+
+   for (i = 0; i < lim; i++) {
+   const char *propname;
+
+   propname = cache_type_info[ct_idx].line_size_props[i];
+   line_size = of_get_property(this_leaf->of_node, propname, NULL);
+   if (line_size)
+   break;
+   }
+
+   if (line_size)
+   this_leaf->coherency_line_size = of_read_number(line_size, 1);
+}
+
+static void cache_nr_sets(struct cacheinfo *this_leaf)
+{
+   const char *propname;
+   const __be32 *nr_sets;
+   int ct_idx;
+
+   ct_idx = get_cacheinfo_idx(this_leaf->type);
+   propname = cache_type_info[ct_idx].nr_sets_prop;
+
+   nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
+   if (nr_sets)
+   this_leaf->number_of_sets = of_read_number(nr_sets, 1);
+}
+
+static void cache_associativity(struct cacheinfo *this_leaf)
+{
+   unsigned int line_size = this_leaf->coherency_line_size;
+   unsigned int nr_sets = this_leaf->number_of_sets;
+   unsigned int size = this_leaf->size;
+
+   /*
+* If the cache is fully associative, there is no need to
+* check the other properties.
+*/
+   if (!(nr_sets == 1) && (nr_sets > 0 && size > 0 && line_size > 0))
+   this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
+}
+
+static void cache_of_override_properties(unsigned int cpu)
+{
+   int index;
+   struct cacheinfo *this_leaf;
+   struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+
+   for (index = 0; index < cache_leaves(cpu); index++) {
+   this_leaf = this_cpu_ci->info_list + index;
+   cache_size(this_leaf);
+   cache_get_line_size(this_leaf);
+   cache_nr_sets(this_leaf);
+   cache_associativity(this_leaf);
+   }
+}
 #else
+static void cache_of_override_properties(unsigned int cpu) { }
 static inline int ca

[PATCH 1/4] drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled

2016-10-28 Thread Sudeep Holla
With CONFIG_OF enabled on x86, we get the following error on boot:
"
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
"
and the cacheinfo fails to get populated in the corresponding sysfs
entries. This is because cache_setup_of_node looks for of_node for
setting up the shared cpu_map without checking that it's already
populated in the architecture specific callback.

In order to indicate that the shared cpu_map is already populated, this
patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo
that can be used by the generic code to skip cache_shared_cpu_map_setup.

This patch also sets that boolean for x86.

Cc: Greg Kroah-Hartman 
Signed-off-by: Sudeep Holla 
---
 arch/x86/kernel/cpu/intel_cacheinfo.c | 2 ++
 drivers/base/cacheinfo.c  | 3 +++
 include/linux/cacheinfo.h | 1 +
 3 files changed, 6 insertions(+)

diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index de6626c18e42..be6337156502 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -934,6 +934,8 @@ static int __populate_cache_leaves(unsigned int cpu)
ci_leaf_init(this_leaf++, &id4_regs);
__cache_cpumap_setup(cpu, idx, &id4_regs);
}
+   this_cpu_ci->cpu_map_populated = true;
+
return 0;
 }
 
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index e9fd32e91668..ecde8957835a 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -106,6 +106,9 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
unsigned int index;
int ret;
 
+   if (this_cpu_ci->cpu_map_populated)
+   return 0;
+
ret = cache_setup_of_node(cpu);
if (ret)
return ret;
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index 2189935075b4..a951fd10 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -71,6 +71,7 @@ struct cpu_cacheinfo {
struct cacheinfo *info_list;
unsigned int num_levels;
unsigned int num_leaves;
+   bool cpu_map_populated;
 };
 
 /*
-- 
2.7.4



[PATCH 2/4] drivers: base: cacheinfo: fix boot error message when acpi is enabled

2016-10-28 Thread Sudeep Holla
ARM64 enables both CONFIG_OF and CONFIG_ACPI and the firmware can pass
both ACPI tables and the device tree. Based on the kernel parameter, one
of the two will be chosen. If acpi is enabled, then device tree is not
unflattened.

Currently ARM64 platforms report:
"
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
"
which is incorrect when booting with ACPI. Also latest ACPI v6.1 has no
support for cache properties/hierarchy.

This patch adds check for unflattened device tree and also returns as
"not supported" if ACPI is runtime enabled.

It also removes the reference to DT from the error message as the cache
hierarchy can be detected from the firmware(OF/DT/ACPI)

Cc: Greg Kroah-Hartman 
Signed-off-by: Sudeep Holla 
---
 drivers/base/cacheinfo.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index ecde8957835a..70e13cf06ed0 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -16,6 +16,7 @@
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see .
  */
+#include 
 #include 
 #include 
 #include 
@@ -104,12 +105,16 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
struct cacheinfo *this_leaf, *sib_leaf;
unsigned int index;
-   int ret;
+   int ret = 0;
 
if (this_cpu_ci->cpu_map_populated)
return 0;
 
-   ret = cache_setup_of_node(cpu);
+   if (of_have_populated_dt())
+   ret = cache_setup_of_node(cpu);
+   else if (!acpi_disabled)
+   /* No cache property/hierarchy support yet in ACPI */
+   ret = -ENOTSUPP;
if (ret)
return ret;
 
@@ -206,8 +211,7 @@ static int detect_cache_attributes(unsigned int cpu)
 */
ret = cache_shared_cpu_map_setup(cpu);
if (ret) {
-   pr_warn("Unable to detect cache hierarchy from DT for CPU %d\n",
-   cpu);
+   pr_warn("Unable to detect cache hierarchy for CPU %d\n", cpu);
goto free_ci;
}
return 0;
-- 
2.7.4



Re: [RFC PATCH 0/3] sched: Introduce Window Assisted Load Tracking

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 12:57:05AM -0700, Vikram Mulukutla wrote:
> On 2016-10-28 00:49, Peter Zijlstra wrote:
> >On Fri, Oct 28, 2016 at 12:10:39AM -0700, Vikram Mulukutla wrote:
> >>This RFC patch has been tested on live X86 machines with the following
> >>sanity
> >>and benchmark results (thanks to Juri Lelli, Dietmar Eggeman, Patrick
> >>Bellasi
> >>for initial code reviews):
> >>
> >>(Tested on an Intel i7 2nd generation CPU, 8GB RAM, Nvidia GTX950Ti
> >>graphics,
> >>with the same frequency list as above. Running Ubuntu 16.04 on a v4.8.2
> >>baseline. WALT window size was 10ms. Only deltas above 3% are considered
> >>non-noise.Power measured with Intel RAPL counters)
> >
> >Was this comparison done using the use_walt_metric sysctl knob?
> 
> Yes, it was. You will want to see numbers against a pure 4.8.2 without any
> of the WALT code, correct?

Yep, because with the sysctl we still run all the accounting code. So
esp things like the hackbench run are meaningless (note that even the
CONFIG thing doesn't take out everything).

Also, I think it makes sense to always (also) compare against the
"performance" governor. That way you can see the drop in absolute
performance etc..


Re: rowhammer protection [was Re: Getting interrupt every million cache misses]

2016-10-28 Thread Pavel Machek
On Fri 2016-10-28 09:07:01, Ingo Molnar wrote:
> 
> * Pavel Machek  wrote:
> 
> > +static void rh_overflow(struct perf_event *event, struct perf_sample_data 
> > *data, struct pt_regs *regs)
> > +{
> > +   u64 *ts = this_cpu_ptr(&rh_timestamp); /* this is NMI context */
> > +   u64 now = ktime_get_mono_fast_ns();
> > +   s64 delta = now - *ts;
> > +
> > +   *ts = now;
> > +
> > +   /* FIXME msec per usec, reverse logic? */
> > +   if (delta < 64 * NSEC_PER_MSEC)
> > +   mdelay(56);
> > +}
> 
> I'd suggest making the absolute delay sysctl tunable, because 'wait 56 msecs' 
> is 
> very magic, and do we know it 100% that 56 msecs is what is needed
> everywhere?

I agree this needs to be tunable (and with the other suggestions). But
this is actually not the most important tunable: the detection
threshold (rh_attr.sample_period) should be way more important.

And yes, this will all need to be tunable, somehow. But lets verify
that this works, first :-).

Thanks and best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [PATCH v6 5/6] drm/fence: add fence timeline to drm_crtc

2016-10-28 Thread Brian Starkey

On Fri, Oct 28, 2016 at 09:42:12AM +0200, Daniel Vetter wrote:

On Thu, Oct 27, 2016 at 05:37:10PM -0200, Gustavo Padovan wrote:

From: Gustavo Padovan 

Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.

v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro

v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name

v4: Comments by Brian Starkey
- Use even more meaninful name for the crtc timeline
- add doc for timeline_name
Comment by Daniel Vetter
- use in-line style for comments

- rebase after fence -> dma_fence rename

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_crtc.c | 31 +++
 include/drm/drm_crtc.h | 39 +++
 2 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7878bfd..e2a06c8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -165,6 +165,32 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
 #endif
 }

+static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->timeline_name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+const struct dma_fence_ops drm_crtc_fence_ops = {
+   .get_driver_name = drm_crtc_fence_get_driver_name,
+   .get_timeline_name = drm_crtc_fence_get_timeline_name,
+   .enable_signaling = drm_crtc_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -222,6 +248,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
return -ENOMEM;
}

+   crtc->fence_context = dma_fence_context_alloc(1);
+   spin_lock_init(&crtc->fence_lock);
+   snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
+"CRTC:%d-%s", crtc->base.id, crtc->name);
+
crtc->base.properties = &crtc->properties;

list_add_tail(&crtc->head, &config->crtc_list);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 719b6a8..278dbdd 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -32,6 +32,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -726,8 +728,45 @@ struct drm_crtc {
 */
struct drm_crtc_crc crc;
 #endif
+
+   /**
+* @fence_context:
+*
+* timeline context used for fence operations.
+*/
+   unsigned int fence_context;
+
+   /**
+* @fence_lock:
+*
+* spinlock to protect the fences in the fence_context.
+*/
+
+   spinlock_t fence_lock;
+   /**
+* @fence_seqno:
+*
+* Seqno variable used as monotonic counter for the fences
+* created on the CRTC's timeline.
+*/
+   unsigned long fence_seqno;
+
+   /**
+* @timeline_name:
+*
+* The name of the CRTC's fence timeline.
+*/
+   char timeline_name[32];
 };

+extern const struct dma_fence_ops drm_crtc_fence_ops;
+


Kerneldoc please. With that addressed:

Reviewed-by: Daniel Vetter 



For my connector fences I exported a function to get the fence, then
you can keep the ops and fence_to_crtc private to drm_crtc.c. In that
case I think you can drop the BUG_ON.

Either way, lgtm.

Reviewed-by: Brian Starkey 


+static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
+{
+   BUG_ON(fence->ops != &drm_crtc_fence_ops);
+   return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
 /**
  * struct drm_mode_set - new values for a CRTC config change
  * @fb: framebuffer to use for new config
--
2.5.5



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



Re: [PATCH] can: fix warning in bcm_connect/proc_register

2016-10-28 Thread Marc Kleine-Budde
On 10/27/2016 06:28 PM, Cong Wang wrote:
>>> Hmm, bo->bound should guarantee it, so never mind, your patch
>>> looks fine.
>>
>> Can I add your Acked-by?
> 
> Of course.
> 
> Acked-by: Cong Wang 

Thanks,
Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature


Re: rowhammer protection [was Re: Getting interrupt every million cache misses]

2016-10-28 Thread Ingo Molnar

* Pavel Machek  wrote:

> On Fri 2016-10-28 09:07:01, Ingo Molnar wrote:
> > 
> > * Pavel Machek  wrote:
> > 
> > > +static void rh_overflow(struct perf_event *event, struct 
> > > perf_sample_data *data, struct pt_regs *regs)
> > > +{
> > > + u64 *ts = this_cpu_ptr(&rh_timestamp); /* this is NMI context */
> > > + u64 now = ktime_get_mono_fast_ns();
> > > + s64 delta = now - *ts;
> > > +
> > > + *ts = now;
> > > +
> > > + /* FIXME msec per usec, reverse logic? */
> > > + if (delta < 64 * NSEC_PER_MSEC)
> > > + mdelay(56);
> > > +}
> > 
> > I'd suggest making the absolute delay sysctl tunable, because 'wait 56 
> > msecs' is 
> > very magic, and do we know it 100% that 56 msecs is what is needed
> > everywhere?
> 
> I agree this needs to be tunable (and with the other suggestions). But
> this is actually not the most important tunable: the detection
> threshold (rh_attr.sample_period) should be way more important.
> 
> And yes, this will all need to be tunable, somehow. But lets verify
> that this works, first :-).

Yeah.

Btw., a 56 NMI delay is pretty brutal in terms of latencies - it might
result in a smoother system to detect 100,000 cache misses and do a
~5.6 msecs delay instead?

(Assuming the shorter threshold does not trigger too often, of course.)

With all the tunables and statistics it would be possible to enumerate how 
frequently the protection mechanism kicks in during regular workloads.

Thanks,

Ingo


Re: rowhammer protection [was Re: Getting interrupt every million cache misses]

2016-10-28 Thread Peter Zijlstra
On Fri, Oct 28, 2016 at 10:50:39AM +0200, Pavel Machek wrote:
> On Fri 2016-10-28 09:07:01, Ingo Molnar wrote:
> > 
> > * Pavel Machek  wrote:
> > 
> > > +static void rh_overflow(struct perf_event *event, struct 
> > > perf_sample_data *data, struct pt_regs *regs)
> > > +{
> > > + u64 *ts = this_cpu_ptr(&rh_timestamp); /* this is NMI context */
> > > + u64 now = ktime_get_mono_fast_ns();
> > > + s64 delta = now - *ts;
> > > +
> > > + *ts = now;
> > > +
> > > + /* FIXME msec per usec, reverse logic? */
> > > + if (delta < 64 * NSEC_PER_MSEC)
> > > + mdelay(56);
> > > +}
> > 
> > I'd suggest making the absolute delay sysctl tunable, because 'wait 56 
> > msecs' is 
> > very magic, and do we know it 100% that 56 msecs is what is needed
> > everywhere?
> 
> I agree this needs to be tunable (and with the other suggestions). But
> this is actually not the most important tunable: the detection
> threshold (rh_attr.sample_period) should be way more important.

So being totally ignorant of the detail of how rowhammer abuses the DDR
thing, would it make sense to trigger more often and delay shorter? Or
is there some minimal delay required for things to settle or something.


Re: Fwd: Fujitsu PrimePower 450 with SPARC64 V & Linux support

2016-10-28 Thread Stanislav Kholmanskikh


On 10/27/2016 08:50 PM, Allan Tsakuhhin wrote:
> I am trying to build Linux system on Fujitsu PrimePower 450 running by
> SPARC64 V CPUs. Does anyone have supportive materials (manuals,
> overviews, specs) about Fujitsu PP450 and SPARC64 V CPUs. Every kind
> of source material may be useful!
> 
> All I have found from Internet, there is no Linux support to SPARC64
> V. Persons, who have tried to get it work before, please give me some
> advice and let me know about your results.

Have you tried pre-built images on this machine:

Debian:

https://people.debian.org/~glaubitz/debian-cd/2016-05-04/debian-9.0-sparc64-NETINST-1.iso


Linux for SPARC (LFS):

https://oss.oracle.com/linux-sparc/isos/linux-sparc-1.0-DVD.iso

?

The LFS image is pretty old, and, per my knowledge, was not tried on the
system type you are referring to.

Thanks.

> 
> For now I have build a Linux kernel from SPARC Enterprise T2000 as a
> donor kernel and trying to get it work on SPARC64 V.
> 
> 
> Allan Tsakuhhin
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  1   2   3   4   5   6   7   >