[PATCH V2 2/2] ARM: dts: am57xx-beagle-x15: Add support for rev B1

[Nishanth Menon]

Latest update to the BeagleBoard-X15 platform (revision B1)[1] updates
for allowing UHS SD cards to function with the split of supply to SD
card from a dedicated LDO.

As a result of this, AM57xx BeagleBoard-X15 now uses gpio2_30 instead
of gpio6_28 for HDMI because HDMI_LS_OE should now be switched from
GPIO6_28(Y9) to GPIO2_30 (AG8) to avoid a 1.8V GPIO toggling a 3.3V
SoC input when the SD card is in UHS 1.8V mode.

NOTE: For UHS mode to function, we need full fledged IODelay support
in kernel to be functional. IODelay support is yet to be added.

Further, It does not make much sense to spin off a new board
compatible flag since there is no real functional benefit for the
same.

Note: Even though production version is supposed to be B1, there is
over ~200 boards of previous version (A2)[2] out there which continue
to get supported with the existing dts file (to maintain compatibility
with existing bootloaders for A2) and the production board is now
supported as revb1.

[1] 
https://github.com/beagleboard/beagleboard-x15/blob/master/BEAGLEBOARD_X15_REV_B1.pdf
[2] http://marc.info/?l=linux-arm-kernel=147273929820708=2

Tested-by: Tomi Valkeinen 
Signed-off-by: Nishanth Menon 
---
Changes in v2:
- fixed up commit message to better illustrate why we are insisting on
  x15.dts to reflect A2 boards.
- Picked up Tomi's tested-by (no change in HDMI in this patch)
- Added comment to x15.dts for future reader without needing to dig
  through git log and figure out this commit..
- Fixed comment in x15-revb1 for LS OE gpio
- Fixed up vmmc-supply property for x15.dts

and all the notes since v1 (note that the checkpatch.pl does not like long 
weblinks
in commit message, I chose to ignore that warning rather than have broken links)

v1: https://patchwork.kernel.org/patch/9310617/

 arch/arm/boot/dts/Makefile |   1 +
 ...eagle-x15.dts => am57xx-beagle-x15-common.dtsi} |   8 +-
 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts  |  24 +
 arch/arm/boot/dts/am57xx-beagle-x15.dts| 592 +
 4 files changed, 33 insertions(+), 592 deletions(-)
 copy arch/arm/boot/dts/{am57xx-beagle-x15.dts => 
am57xx-beagle-x15-common.dtsi} (97%)
 create mode 100644 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52370d2..b8d9840895c2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -570,6 +570,7 @@ dtb-$(CONFIG_SOC_OMAP5) += \
omap5-uevm.dtb
 dtb-$(CONFIG_SOC_DRA7XX) += \
am57xx-beagle-x15.dtb \
+   am57xx-beagle-x15-revb1.dtb \
am57xx-cl-som-am57x.dtb \
am57xx-sbc-am57x.dtb \
am572x-idk.dtb \
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
similarity index 97%
copy from arch/arm/boot/dts/am57xx-beagle-x15.dts
copy to arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index ef21da558ea3..ec85ff9004e8 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2014-2016 Texas Instruments Incorporated - http://www.ti.com/
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -13,7 +13,6 @@
 #include 
 
 / {
-   model = "TI AM5728 BeagleBoard-X15";
compatible = "ti,am572x-beagle-x15", "ti,am5728", "ti,dra742", 
"ti,dra74", "ti,dra7";
 
aliases {
@@ -114,10 +113,6 @@
tpd12s015: encoder {
compatible = "ti,tpd12s015";
 
-   gpios = < 10 GPIO_ACTIVE_HIGH>,   /* gpio7_10, CT CP HPD 
*/
-   < 28 GPIO_ACTIVE_HIGH>,   /* gpio6_28, LS OE */
-   < 12 GPIO_ACTIVE_HIGH>;   /* gpio7_12/sp1_cs2, 
HPD */
-
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -448,7 +443,6 @@
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
 
-   vmmc-supply = <_reg>;
bus-width = <4>;
cd-gpios = < 27 GPIO_ACTIVE_LOW>; /* gpio 219 */
 };
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
new file mode 100644
index ..ca85570629fd
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2014-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "am57xx-beagle-x15-common.dtsi"
+
+/ {
+   model = "TI AM5728 BeagleBoard-X15 rev B1";
+};
+
+ {
+   gpios = < 

[PATCH V2 1/2] ARM: dts: am57xx-beagle-x15: Remove pinmux configurations for erratum i869

[Nishanth Menon]

Pinmuxing for DRA7x/AM57x family of processors need to be done in IO
isolation as part of initial bootloader executed from SRAM. This is
done as part of iodelay configuration sequence and is required due
to the limitations introduced by erratum ID: i869[1] (IO Glitches
can occur when changing IO settings) and elaborated in the Technical
Reference Manual[2] 18.4.6.1.7 Isolation Requirements.

Only peripheral that is permitted for dynamic pin mux configuration
is MMC and DCAN. MMC is permitted to change to accommodate the
requirements for varied speeds (which require IO-delay support in
kernel as well). DCAN is a result of i893[1] (DCAN initialization
sequence). However, since we don't use DCAN on X15, with the exception
of MMC, all other pin mux configurations are removed from the dts.

[1] http://www.ti.com/lit/pdf/sprz429
[2] http://www.ti.com/lit/pdf/sprui30

Signed-off-by: Nishanth Menon 
---
Changes in v2:
- renamed $subject to indicate we are not removing *every pinmux*
- Update in commit message to encompass DCAN as well - for future
  references as well

v1: https://patchwork.kernel.org/patch/9310615/

 arch/arm/boot/dts/am57xx-beagle-x15.dts | 222 +---
 1 file changed, 1 insertion(+), 221 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 9067ca092dc5..ef21da558ea3 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -59,8 +59,6 @@
 
leds {
compatible = "gpio-leds";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_default>;
 
led0 {
label = "beagle-x15:usr0";
@@ -116,9 +114,6 @@
tpd12s015: encoder {
compatible = "ti,tpd12s015";
 
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-
gpios = < 10 GPIO_ACTIVE_HIGH>,   /* gpio7_10, CT CP HPD 
*/
< 28 GPIO_ACTIVE_HIGH>,   /* gpio6_28, LS OE */
< 12 GPIO_ACTIVE_HIGH>;   /* gpio7_12/sp1_cs2, 
HPD */
@@ -173,43 +168,6 @@
 };
 
 _pmx_core {
-   leds_pins_default: leds_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x37a8, PIN_OUTPUT | MUX_MODE14)  
/* spi1_d1.gpio7_8 */
-   DRA7XX_CORE_IOPAD(0x37ac, PIN_OUTPUT | MUX_MODE14)  
/* spi1_d0.gpio7_9 */
-   DRA7XX_CORE_IOPAD(0x37c0, PIN_OUTPUT | MUX_MODE14)  
/* spi2_sclk.gpio7_14 */
-   DRA7XX_CORE_IOPAD(0x37c4, PIN_OUTPUT | MUX_MODE14)  
/* spi2_d1.gpio7_15 */
-   >;
-   };
-
-   i2c1_pins_default: i2c1_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0) 
/* i2c1_sda.sda */
-   DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0) 
/* i2c1_scl.scl */
-   >;
-   };
-
-   hdmi_pins: pinmux_hdmi_pins {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x3808, PIN_INPUT | MUX_MODE1)
/* i2c2_sda.hdmi1_ddc_scl */
-   DRA7XX_CORE_IOPAD(0x380c, PIN_INPUT | MUX_MODE1)
/* i2c2_scl.hdmi1_ddc_sda */
-   >;
-   };
-
-   i2c3_pins_default: i2c3_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x36a4, PIN_INPUT| MUX_MODE10)
/* mcasp1_aclkx.i2c3_sda */
-   DRA7XX_CORE_IOPAD(0x36a8, PIN_INPUT| MUX_MODE10)
/* mcasp1_fsx.i2c3_scl */
-   >;
-   };
-
-   uart3_pins_default: uart3_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2) 
/* uart2_ctsn.uart3_rxd */
-   DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1) 
/* uart2_rtsn.uart3_txd */
-   >;
-   };
-
mmc1_pins_default: mmc1_pins_default {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x376c, PIN_INPUT | MUX_MODE14)   
/* mmc1sdcd.gpio219 */
@@ -236,154 +194,9 @@
DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a22.mmc2_dat7 */
>;
};
-
-   cpsw_pins_default: cpsw_pins_default {
-   pinctrl-single,pins = <
-   /* Slave 1 */
-   DRA7XX_CORE_IOPAD(0x3650, PIN_OUTPUT | MUX_MODE0)   
/* rgmii1_tclk */
-   DRA7XX_CORE_IOPAD(0x3654, PIN_OUTPUT | MUX_MODE0)   
/* rgmii1_tctl */
-   DRA7XX_CORE_IOPAD(0x3658, PIN_OUTPUT | MUX_MODE0)   
/* rgmii1_td3 */
-   DRA7XX_CORE_IOPAD(0x365c, PIN_OUTPUT | MUX_MODE0)   
/* rgmii1_td2 */
-   DRA7XX_CORE_IOPAD(0x3660, PIN_OUTPUT | 

[PATCH V2 2/2] ARM: dts: am57xx-beagle-x15: Add support for rev B1

[Nishanth Menon]

Latest update to the BeagleBoard-X15 platform (revision B1)[1] updates
for allowing UHS SD cards to function with the split of supply to SD
card from a dedicated LDO.

As a result of this, AM57xx BeagleBoard-X15 now uses gpio2_30 instead
of gpio6_28 for HDMI because HDMI_LS_OE should now be switched from
GPIO6_28(Y9) to GPIO2_30 (AG8) to avoid a 1.8V GPIO toggling a 3.3V
SoC input when the SD card is in UHS 1.8V mode.

NOTE: For UHS mode to function, we need full fledged IODelay support
in kernel to be functional. IODelay support is yet to be added.

Further, It does not make much sense to spin off a new board
compatible flag since there is no real functional benefit for the
same.

Note: Even though production version is supposed to be B1, there is
over ~200 boards of previous version (A2)[2] out there which continue
to get supported with the existing dts file (to maintain compatibility
with existing bootloaders for A2) and the production board is now
supported as revb1.

[1] 
https://github.com/beagleboard/beagleboard-x15/blob/master/BEAGLEBOARD_X15_REV_B1.pdf
[2] http://marc.info/?l=linux-arm-kernel=147273929820708=2

Tested-by: Tomi Valkeinen 
Signed-off-by: Nishanth Menon 
---
Changes in v2:
- fixed up commit message to better illustrate why we are insisting on
  x15.dts to reflect A2 boards.
- Picked up Tomi's tested-by (no change in HDMI in this patch)
- Added comment to x15.dts for future reader without needing to dig
  through git log and figure out this commit..
- Fixed comment in x15-revb1 for LS OE gpio
- Fixed up vmmc-supply property for x15.dts

and all the notes since v1 (note that the checkpatch.pl does not like long 
weblinks
in commit message, I chose to ignore that warning rather than have broken links)

v1: https://patchwork.kernel.org/patch/9310617/

 arch/arm/boot/dts/Makefile |   1 +
 ...eagle-x15.dts => am57xx-beagle-x15-common.dtsi} |   8 +-
 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts  |  24 +
 arch/arm/boot/dts/am57xx-beagle-x15.dts| 592 +
 4 files changed, 33 insertions(+), 592 deletions(-)
 copy arch/arm/boot/dts/{am57xx-beagle-x15.dts => 
am57xx-beagle-x15-common.dtsi} (97%)
 create mode 100644 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52370d2..b8d9840895c2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -570,6 +570,7 @@ dtb-$(CONFIG_SOC_OMAP5) += \
omap5-uevm.dtb
 dtb-$(CONFIG_SOC_DRA7XX) += \
am57xx-beagle-x15.dtb \
+   am57xx-beagle-x15-revb1.dtb \
am57xx-cl-som-am57x.dtb \
am57xx-sbc-am57x.dtb \
am572x-idk.dtb \
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
similarity index 97%
copy from arch/arm/boot/dts/am57xx-beagle-x15.dts
copy to arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index ef21da558ea3..ec85ff9004e8 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2014-2016 Texas Instruments Incorporated - http://www.ti.com/
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -13,7 +13,6 @@
 #include 
 
 / {
-   model = "TI AM5728 BeagleBoard-X15";
compatible = "ti,am572x-beagle-x15", "ti,am5728", "ti,dra742", 
"ti,dra74", "ti,dra7";
 
aliases {
@@ -114,10 +113,6 @@
tpd12s015: encoder {
compatible = "ti,tpd12s015";
 
-   gpios = < 10 GPIO_ACTIVE_HIGH>,   /* gpio7_10, CT CP HPD 
*/
-   < 28 GPIO_ACTIVE_HIGH>,   /* gpio6_28, LS OE */
-   < 12 GPIO_ACTIVE_HIGH>;   /* gpio7_12/sp1_cs2, 
HPD */
-
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -448,7 +443,6 @@
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
 
-   vmmc-supply = <_reg>;
bus-width = <4>;
cd-gpios = < 27 GPIO_ACTIVE_LOW>; /* gpio 219 */
 };
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
new file mode 100644
index ..ca85570629fd
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2014-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "am57xx-beagle-x15-common.dtsi"
+
+/ {
+   model = "TI AM5728 BeagleBoard-X15 rev B1";
+};
+
+ {
+   gpios = < 10 GPIO_ACTIVE_HIGH>,   /* gpio7_10, 

[PATCH V2 1/2] ARM: dts: am57xx-beagle-x15: Remove pinmux configurations for erratum i869

[Nishanth Menon]

Pinmuxing for DRA7x/AM57x family of processors need to be done in IO
isolation as part of initial bootloader executed from SRAM. This is
done as part of iodelay configuration sequence and is required due
to the limitations introduced by erratum ID: i869[1] (IO Glitches
can occur when changing IO settings) and elaborated in the Technical
Reference Manual[2] 18.4.6.1.7 Isolation Requirements.

Only peripheral that is permitted for dynamic pin mux configuration
is MMC and DCAN. MMC is permitted to change to accommodate the
requirements for varied speeds (which require IO-delay support in
kernel as well). DCAN is a result of i893[1] (DCAN initialization
sequence). However, since we don't use DCAN on X15, with the exception
of MMC, all other pin mux configurations are removed from the dts.

[1] http://www.ti.com/lit/pdf/sprz429
[2] http://www.ti.com/lit/pdf/sprui30

Signed-off-by: Nishanth Menon 
---
Changes in v2:
- renamed $subject to indicate we are not removing *every pinmux*
- Update in commit message to encompass DCAN as well - for future
  references as well

v1: https://patchwork.kernel.org/patch/9310615/

 arch/arm/boot/dts/am57xx-beagle-x15.dts | 222 +---
 1 file changed, 1 insertion(+), 221 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 9067ca092dc5..ef21da558ea3 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -59,8 +59,6 @@
 
leds {
compatible = "gpio-leds";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_default>;
 
led0 {
label = "beagle-x15:usr0";
@@ -116,9 +114,6 @@
tpd12s015: encoder {
compatible = "ti,tpd12s015";
 
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-
gpios = < 10 GPIO_ACTIVE_HIGH>,   /* gpio7_10, CT CP HPD 
*/
< 28 GPIO_ACTIVE_HIGH>,   /* gpio6_28, LS OE */
< 12 GPIO_ACTIVE_HIGH>;   /* gpio7_12/sp1_cs2, 
HPD */
@@ -173,43 +168,6 @@
 };
 
 _pmx_core {
-   leds_pins_default: leds_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x37a8, PIN_OUTPUT | MUX_MODE14)  
/* spi1_d1.gpio7_8 */
-   DRA7XX_CORE_IOPAD(0x37ac, PIN_OUTPUT | MUX_MODE14)  
/* spi1_d0.gpio7_9 */
-   DRA7XX_CORE_IOPAD(0x37c0, PIN_OUTPUT | MUX_MODE14)  
/* spi2_sclk.gpio7_14 */
-   DRA7XX_CORE_IOPAD(0x37c4, PIN_OUTPUT | MUX_MODE14)  
/* spi2_d1.gpio7_15 */
-   >;
-   };
-
-   i2c1_pins_default: i2c1_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0) 
/* i2c1_sda.sda */
-   DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0) 
/* i2c1_scl.scl */
-   >;
-   };
-
-   hdmi_pins: pinmux_hdmi_pins {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x3808, PIN_INPUT | MUX_MODE1)
/* i2c2_sda.hdmi1_ddc_scl */
-   DRA7XX_CORE_IOPAD(0x380c, PIN_INPUT | MUX_MODE1)
/* i2c2_scl.hdmi1_ddc_sda */
-   >;
-   };
-
-   i2c3_pins_default: i2c3_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x36a4, PIN_INPUT| MUX_MODE10)
/* mcasp1_aclkx.i2c3_sda */
-   DRA7XX_CORE_IOPAD(0x36a8, PIN_INPUT| MUX_MODE10)
/* mcasp1_fsx.i2c3_scl */
-   >;
-   };
-
-   uart3_pins_default: uart3_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2) 
/* uart2_ctsn.uart3_rxd */
-   DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1) 
/* uart2_rtsn.uart3_txd */
-   >;
-   };
-
mmc1_pins_default: mmc1_pins_default {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x376c, PIN_INPUT | MUX_MODE14)   
/* mmc1sdcd.gpio219 */
@@ -236,154 +194,9 @@
DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a22.mmc2_dat7 */
>;
};
-
-   cpsw_pins_default: cpsw_pins_default {
-   pinctrl-single,pins = <
-   /* Slave 1 */
-   DRA7XX_CORE_IOPAD(0x3650, PIN_OUTPUT | MUX_MODE0)   
/* rgmii1_tclk */
-   DRA7XX_CORE_IOPAD(0x3654, PIN_OUTPUT | MUX_MODE0)   
/* rgmii1_tctl */
-   DRA7XX_CORE_IOPAD(0x3658, PIN_OUTPUT | MUX_MODE0)   
/* rgmii1_td3 */
-   DRA7XX_CORE_IOPAD(0x365c, PIN_OUTPUT | MUX_MODE0)   
/* rgmii1_td2 */
-   DRA7XX_CORE_IOPAD(0x3660, PIN_OUTPUT | MUX_MODE0)   

Re: [PATCH 1/4] Documentation: mmc: sdhci-of-arasan: Add clk_syscon as an optional one

[Rob Herring]

On Fri, Sep 2, 2016 at 11:12 AM, Doug Anderson  wrote:
> Rob,
>
> On Fri, Sep 2, 2016 at 7:15 AM, Rob Herring  wrote:
>> On Mon, Aug 29, 2016 at 04:02:56PM +0800, Shawn Lin wrote:
>>> We introduced soc-ctl-syscon to do several things, for instance, update
>>> baseclk or update clkmul, etc. In odrder to access this physical block,
>>> we need to explicitly enable its clock. Currently we don't control this
>>> clock as we always add a CLK_IGNORE_UNUSED flag for it to indicate that
>>> we will not gate it even if not referenced. This is not a correct way since
>>> it is a clock parenting from clk_ahb which is used by sdhci-of-arasan now.
>>> Without enabling clk_ahb, the flag don't guarantee we could access
>>> soc-ctl-syscon. Moreover, we can't find a reason not to gate clk_syscon
>>> once we remove/power-down emmc controller. So let's add clk_syscon and
>>> enable/disable it explicitly when needed.
>>>
>>> Signed-off-by: Shawn Lin 
>>>
>>> ---
>>>
>>>  Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 7 +--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
>>> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>>> index 3404afa..b04eb02 100644
>>> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>>> @@ -33,6 +33,9 @@ Optional Properties:
>>>- clock-output-names: If specified, this will be the name of the card 
>>> clock
>>>  which will be exposed by this device.  Required if #clock-cells is
>>>  specified.
>>> +  - clock-names: From clock bindings: Although we treat clock-names as 
>>> required
>>> +property, there is still one, "clk_syscon", should be optional as it 
>>> depends
>>> +on whether we need to control soc-ctl-syscon or not.
>>
>> No. This doesn't look right to me. The syscon is a separate block
>> and the clock for it belongs in the syscon node itself. Probably there
>> needs to be some sort of ref counting in the syscon so it can do
>> runtime-pm.
>
> I'm not an expert, but one thing to note is that this is actually a
> separate clock just for this small part of the GRF (general register
> files).  Yeah, it's bizarre.

I wasn't doubting that. Only that the connection is not to the sdhci block.

> Said another way, the GRF is a sorta hodgepodge location for all sorts
> of stuff.  ...included in there are the "corecfg" registers that are
> used by the SDHCI IP block.  Within the GRF register space these
> registers are 0x0f000 - 0x0f050 (last register is at 0x0f04c).  I
> believe that only registers in that special range need this clock.
>
> Maybe the right answer is that we should actually have had a sub-node
> of the GRF for these registers and then SDHCI should have referenced
> that as its syscon?

Sub-node or not is an orthogonal question. The main part is now we
have a syscon link and we need to power manage the syscon. Or is there
really a need to manage this clock at runtime? Perhaps it can just be
turned on and left on, but that should be in the syscon driver. The
SDHCI driver could retrieve the clocks from syscon node and manage it
directly. I'd be fine with that from a binding perspective, but seems
a bit hacky from a kernel perspective.

Rob

Re: [PATCH 1/4] Documentation: mmc: sdhci-of-arasan: Add clk_syscon as an optional one

[Rob Herring]

On Fri, Sep 2, 2016 at 11:12 AM, Doug Anderson  wrote:
> Rob,
>
> On Fri, Sep 2, 2016 at 7:15 AM, Rob Herring  wrote:
>> On Mon, Aug 29, 2016 at 04:02:56PM +0800, Shawn Lin wrote:
>>> We introduced soc-ctl-syscon to do several things, for instance, update
>>> baseclk or update clkmul, etc. In odrder to access this physical block,
>>> we need to explicitly enable its clock. Currently we don't control this
>>> clock as we always add a CLK_IGNORE_UNUSED flag for it to indicate that
>>> we will not gate it even if not referenced. This is not a correct way since
>>> it is a clock parenting from clk_ahb which is used by sdhci-of-arasan now.
>>> Without enabling clk_ahb, the flag don't guarantee we could access
>>> soc-ctl-syscon. Moreover, we can't find a reason not to gate clk_syscon
>>> once we remove/power-down emmc controller. So let's add clk_syscon and
>>> enable/disable it explicitly when needed.
>>>
>>> Signed-off-by: Shawn Lin 
>>>
>>> ---
>>>
>>>  Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 7 +--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
>>> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>>> index 3404afa..b04eb02 100644
>>> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>>> @@ -33,6 +33,9 @@ Optional Properties:
>>>- clock-output-names: If specified, this will be the name of the card 
>>> clock
>>>  which will be exposed by this device.  Required if #clock-cells is
>>>  specified.
>>> +  - clock-names: From clock bindings: Although we treat clock-names as 
>>> required
>>> +property, there is still one, "clk_syscon", should be optional as it 
>>> depends
>>> +on whether we need to control soc-ctl-syscon or not.
>>
>> No. This doesn't look right to me. The syscon is a separate block
>> and the clock for it belongs in the syscon node itself. Probably there
>> needs to be some sort of ref counting in the syscon so it can do
>> runtime-pm.
>
> I'm not an expert, but one thing to note is that this is actually a
> separate clock just for this small part of the GRF (general register
> files).  Yeah, it's bizarre.

I wasn't doubting that. Only that the connection is not to the sdhci block.

> Said another way, the GRF is a sorta hodgepodge location for all sorts
> of stuff.  ...included in there are the "corecfg" registers that are
> used by the SDHCI IP block.  Within the GRF register space these
> registers are 0x0f000 - 0x0f050 (last register is at 0x0f04c).  I
> believe that only registers in that special range need this clock.
>
> Maybe the right answer is that we should actually have had a sub-node
> of the GRF for these registers and then SDHCI should have referenced
> that as its syscon?

Sub-node or not is an orthogonal question. The main part is now we
have a syscon link and we need to power manage the syscon. Or is there
really a need to manage this clock at runtime? Perhaps it can just be
turned on and left on, but that should be in the syscon driver. The
SDHCI driver could retrieve the clocks from syscon node and manage it
directly. I'd be fine with that from a binding perspective, but seems
a bit hacky from a kernel perspective.

Rob

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

[Vivien Didelot]

Hi Andrew,

Andrew Lunn  writes:

>> What do you think?
>
> I think the probe() needs to fail with a very obvious error message
> saying you need to recompile your kernel with option XYZ enabled in
> order to support this switch, when the optional stuff is not
> optional...

I agree. Does the following snippet looks OK?


#ifndef CONFIG_NET_DSA_MV88E6XXX_GLOBAL2
if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_GLOBAL2)) {
dev_err(chip->dev, "Missing support for Global 2 
registers\n");
return -EOPNOTSUPP;
}
#endif /* CONFIG_NET_DSA_MV88E6XXX_GLOBAL2 */


Thanks,

Vivien

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

[Vivien Didelot]

Hi Andrew,

Andrew Lunn  writes:

>> What do you think?
>
> I think the probe() needs to fail with a very obvious error message
> saying you need to recompile your kernel with option XYZ enabled in
> order to support this switch, when the optional stuff is not
> optional...

I agree. Does the following snippet looks OK?


#ifndef CONFIG_NET_DSA_MV88E6XXX_GLOBAL2
if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_GLOBAL2)) {
dev_err(chip->dev, "Missing support for Global 2 
registers\n");
return -EOPNOTSUPP;
}
#endif /* CONFIG_NET_DSA_MV88E6XXX_GLOBAL2 */


Thanks,

Vivien

Re: [PATCH] IB/mlx5: Fix a parameter of find_first_bit

[Doug Ledford]

On 8/26/2016 1:16 AM, Christophe JAILLET wrote:
> The 2nd parameter of 'find_first_bit' is the number of bits to search.
> In this case, we are passing 'sizeof(tmp)' which is likely to be 4 or 8
> because 'tmp' is an 'unsigned long'.
> 
> It is likely that the number of bits of 'tmp' was expected here. So use
> BITS_PER_LONG instead.

Thanks, applied.


-- 
Doug Ledford 
GPG Key ID: 0E572FDD



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] IB/mlx5: Fix a parameter of find_first_bit

[Doug Ledford]

On 8/26/2016 1:16 AM, Christophe JAILLET wrote:
> The 2nd parameter of 'find_first_bit' is the number of bits to search.
> In this case, we are passing 'sizeof(tmp)' which is likely to be 4 or 8
> because 'tmp' is an 'unsigned long'.
> 
> It is likely that the number of bits of 'tmp' was expected here. So use
> BITS_PER_LONG instead.

Thanks, applied.


-- 
Doug Ledford 
GPG Key ID: 0E572FDD



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] IB/hfi1: Fix a parameter of find_first_bit.

[Doug Ledford]

On 8/27/2016 1:25 AM, Christophe JAILLET wrote:
> Le 26/08/2016 à 15:35, Doug Ledford a écrit :
>> On 8/26/2016 12:49 AM, Christophe JAILLET wrote:
>>> The 2nd parameter of 'find_first_bit' is the number of bits to search.
>>> In this case, we are passing 'sizeof(unsigned long)' which is likely to
>>> be 4 or 8.
>> If the size can be 4 or 8, then using 64 universally is not correct.
>> Why not use sizeof() * 8 (or << 3)?
> I agree with you...
> 
> BTW, the log message is wrong. 'port_mask' is a u64. (not an unsigned
> long). So the sizeof should always be 8.
> (cut and paste error from another patch, sorry)

Log message modified, then patch modified to use sizeof() * 8, result
applied.  Thanks.

>>
>>> It is likely that the number of bits of 'port_mask' was expected
>>> here. This
>>> variable is a 'u64', so use 64 instead.
>>>
>>> It has been spotted by the following coccinelle script:
>>> @@
>>> expression ret, x;
>>>
>>> @@
>>> *  ret = \(find_first_bit \| find_first_zero_bit\) (x, sizeof(...));
>>>
>>> Signed-off-by: Christophe JAILLET
>>> 
>>> ---
>>> Not sure that using 64 directly is the best option.
>>> Maybe '8 * sizeof(port_mask)' as used in the same file for
>>> 'for_each_set_bit' would be better
>>> ---
> ... as noted here
> 
> Would you like a v2 patch or, will you update it by yourself?
> 
> Best regards,
> CJ
> 
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
> 


-- 
Doug Ledford 
GPG Key ID: 0E572FDD



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] IB/hfi1: Fix a parameter of find_first_bit.

[Doug Ledford]

On 8/27/2016 1:25 AM, Christophe JAILLET wrote:
> Le 26/08/2016 à 15:35, Doug Ledford a écrit :
>> On 8/26/2016 12:49 AM, Christophe JAILLET wrote:
>>> The 2nd parameter of 'find_first_bit' is the number of bits to search.
>>> In this case, we are passing 'sizeof(unsigned long)' which is likely to
>>> be 4 or 8.
>> If the size can be 4 or 8, then using 64 universally is not correct.
>> Why not use sizeof() * 8 (or << 3)?
> I agree with you...
> 
> BTW, the log message is wrong. 'port_mask' is a u64. (not an unsigned
> long). So the sizeof should always be 8.
> (cut and paste error from another patch, sorry)

Log message modified, then patch modified to use sizeof() * 8, result
applied.  Thanks.

>>
>>> It is likely that the number of bits of 'port_mask' was expected
>>> here. This
>>> variable is a 'u64', so use 64 instead.
>>>
>>> It has been spotted by the following coccinelle script:
>>> @@
>>> expression ret, x;
>>>
>>> @@
>>> *  ret = \(find_first_bit \| find_first_zero_bit\) (x, sizeof(...));
>>>
>>> Signed-off-by: Christophe JAILLET
>>> 
>>> ---
>>> Not sure that using 64 directly is the best option.
>>> Maybe '8 * sizeof(port_mask)' as used in the same file for
>>> 'for_each_set_bit' would be better
>>> ---
> ... as noted here
> 
> Would you like a v2 patch or, will you update it by yourself?
> 
> Best regards,
> CJ
> 
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
> 


-- 
Doug Ledford 
GPG Key ID: 0E572FDD



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3] iio: humidity: hdc100x: add triggered buffer support for HDC100X

[Alison Schofield]

On Fri, Sep 02, 2016 at 07:30:38AM +0100, Julia Lawall wrote:
> Please check on the lines marked with @.  An unlock may be needed at line
> 210.
> 
> julia

Yes, needs unlock. Thanks!
alisons

> 
> -- Forwarded message --
> Date: Fri, 2 Sep 2016 07:19:23 +0800
> From: kbuild test robot <fengguang...@intel.com>
> To: kbu...@01.org
> Cc: Julia Lawall <julia.law...@lip6.fr>
> Subject: Re: [PATCH v3] iio: humidity: hdc100x: add triggered buffer support 
> for
>  HDC100X
> 
> Hi Alison,
> 
> [auto build test WARNING on next-20160825]
> [also build test WARNING on v4.8-rc4]
> [cannot apply to iio/togreg v4.8-rc4 v4.8-rc3 v4.8-rc2]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
> convenience) to record what (public, well-known) commit your patch series was 
> built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
> 
> url:
> https://github.com/0day-ci/linux/commits/Alison-Schofield/iio-humidity-hdc100x-add-triggered-buffer-support-for-HDC100X/20160902-055115
> :: branch date: 88 minutes ago
> :: commit date: 88 minutes ago
> 
> >> drivers/iio/humidity/hdc100x.c:210:4-10: preceding lock on line 203
>drivers/iio/humidity/hdc100x.c:345:1-7: preceding lock on line 325
> 
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout f6862a537522f8d668f7daec0aa0817f87706017
> vim +210 drivers/iio/humidity/hdc100x.c
> 
> 4839367d9 Matt Ranostay2015-09-06  197struct hdc100x_data *data = 
> iio_priv(indio_dev);
> 4839367d9 Matt Ranostay2015-09-06  198
> 4839367d9 Matt Ranostay2015-09-06  199switch (mask) {
> 4839367d9 Matt Ranostay2015-09-06  200case IIO_CHAN_INFO_RAW: {
> 4839367d9 Matt Ranostay2015-09-06  201int ret;
> 4839367d9 Matt Ranostay2015-09-06  202
> 4839367d9 Matt Ranostay2015-09-06 @203mutex_lock(>lock);
> 4839367d9 Matt Ranostay2015-09-06  204if (chan->type == 
> IIO_CURRENT) {
> 4839367d9 Matt Ranostay2015-09-06  205*val = 
> hdc100x_get_heater_status(data);
> 4839367d9 Matt Ranostay2015-09-06  206ret = 
> IIO_VAL_INT;
> 4839367d9 Matt Ranostay2015-09-06  207} else {
> f6862a537 Alison Schofield 2016-09-01  208ret = 
> iio_device_claim_direct_mode(indio_dev);
> f6862a537 Alison Schofield 2016-09-01  209if (ret)
> f6862a537 Alison Schofield 2016-09-01 @210return 
> ret;
> f6862a537 Alison Schofield 2016-09-01  211
> 4839367d9 Matt Ranostay2015-09-06  212ret = 
> hdc100x_get_measurement(data, chan);
> f6862a537 Alison Schofield 2016-09-01  213
> iio_device_release_direct_mode(indio_dev);
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v3] iio: humidity: hdc100x: add triggered buffer support for HDC100X

[Alison Schofield]

On Fri, Sep 02, 2016 at 07:30:38AM +0100, Julia Lawall wrote:
> Please check on the lines marked with @.  An unlock may be needed at line
> 210.
> 
> julia

Yes, needs unlock. Thanks!
alisons

> 
> -- Forwarded message --
> Date: Fri, 2 Sep 2016 07:19:23 +0800
> From: kbuild test robot 
> To: kbu...@01.org
> Cc: Julia Lawall 
> Subject: Re: [PATCH v3] iio: humidity: hdc100x: add triggered buffer support 
> for
>  HDC100X
> 
> Hi Alison,
> 
> [auto build test WARNING on next-20160825]
> [also build test WARNING on v4.8-rc4]
> [cannot apply to iio/togreg v4.8-rc4 v4.8-rc3 v4.8-rc2]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
> convenience) to record what (public, well-known) commit your patch series was 
> built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
> 
> url:
> https://github.com/0day-ci/linux/commits/Alison-Schofield/iio-humidity-hdc100x-add-triggered-buffer-support-for-HDC100X/20160902-055115
> :: branch date: 88 minutes ago
> :: commit date: 88 minutes ago
> 
> >> drivers/iio/humidity/hdc100x.c:210:4-10: preceding lock on line 203
>drivers/iio/humidity/hdc100x.c:345:1-7: preceding lock on line 325
> 
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout f6862a537522f8d668f7daec0aa0817f87706017
> vim +210 drivers/iio/humidity/hdc100x.c
> 
> 4839367d9 Matt Ranostay2015-09-06  197struct hdc100x_data *data = 
> iio_priv(indio_dev);
> 4839367d9 Matt Ranostay2015-09-06  198
> 4839367d9 Matt Ranostay2015-09-06  199switch (mask) {
> 4839367d9 Matt Ranostay2015-09-06  200case IIO_CHAN_INFO_RAW: {
> 4839367d9 Matt Ranostay2015-09-06  201int ret;
> 4839367d9 Matt Ranostay2015-09-06  202
> 4839367d9 Matt Ranostay2015-09-06 @203mutex_lock(>lock);
> 4839367d9 Matt Ranostay2015-09-06  204if (chan->type == 
> IIO_CURRENT) {
> 4839367d9 Matt Ranostay2015-09-06  205*val = 
> hdc100x_get_heater_status(data);
> 4839367d9 Matt Ranostay2015-09-06  206ret = 
> IIO_VAL_INT;
> 4839367d9 Matt Ranostay2015-09-06  207} else {
> f6862a537 Alison Schofield 2016-09-01  208ret = 
> iio_device_claim_direct_mode(indio_dev);
> f6862a537 Alison Schofield 2016-09-01  209if (ret)
> f6862a537 Alison Schofield 2016-09-01 @210return 
> ret;
> f6862a537 Alison Schofield 2016-09-01  211
> 4839367d9 Matt Ranostay2015-09-06  212ret = 
> hdc100x_get_measurement(data, chan);
> f6862a537 Alison Schofield 2016-09-01  213
> iio_device_release_direct_mode(indio_dev);
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH 3/4] KVM: x86: introduce get_kvmclock_ns

[Roman Kagan]

On Fri, Sep 02, 2016 at 06:57:10PM +0200, Paolo Bonzini wrote:
> 
> 
> On 02/09/2016 18:55, Roman Kagan wrote:
> >> > I'll change patch 4 to store the parameters and use them when accessing
> >> > the time reference counter MSR.  I'll still keep the procedure that goes
> >> > through kvmclock.  It's a bit more involved for the scale, but
> >> > vcpu->last_guest_tsc only provides a part of the offset computation; the
> >> > other half is vcpu->hv_clock.system_time and it's not stored anywhere.
> > Erm... It is stored right there, in vcpu->hv_clock.system_time, you can
> > access it just fine when you populate tsc_ref_page values.  Am I missing
> > anything?
> 
> No.  It's not stored anywhere outside vcpu->hv_clock.  My reasoning goes
> that if I have to use vcpu->hv_clock.system_time I might as well use
> vcpu->hv_clock for everything. :)

Well, there're plenty of ways to bring the necessary values to where
they are needed.

But that's a matter of simplicity, not correctness, so I won't mind that
much.

Thanks,
Roman.

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Nishanth Menon]

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:
> On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:
[...]
>> +
>> +TI-SCI Client Device Node:
>> +
>> +
>> +Client nodes refer to the required TI-SCI device using the "ti,sci" 
>> property.
>
> As I mentioned for power domains, for clients that are self contained
> (i.e. a single function) I think the should be child nodes.
>

Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


---
Regards,
Nishanth Menon

Re: [PATCH 3/4] KVM: x86: introduce get_kvmclock_ns

[Roman Kagan]

On Fri, Sep 02, 2016 at 06:57:10PM +0200, Paolo Bonzini wrote:
> 
> 
> On 02/09/2016 18:55, Roman Kagan wrote:
> >> > I'll change patch 4 to store the parameters and use them when accessing
> >> > the time reference counter MSR.  I'll still keep the procedure that goes
> >> > through kvmclock.  It's a bit more involved for the scale, but
> >> > vcpu->last_guest_tsc only provides a part of the offset computation; the
> >> > other half is vcpu->hv_clock.system_time and it's not stored anywhere.
> > Erm... It is stored right there, in vcpu->hv_clock.system_time, you can
> > access it just fine when you populate tsc_ref_page values.  Am I missing
> > anything?
> 
> No.  It's not stored anywhere outside vcpu->hv_clock.  My reasoning goes
> that if I have to use vcpu->hv_clock.system_time I might as well use
> vcpu->hv_clock for everything. :)

Well, there're plenty of ways to bring the necessary values to where
they are needed.

But that's a matter of simplicity, not correctness, so I won't mind that
much.

Thanks,
Roman.

Re: [PATCH V2 1/5] Documentation: Add support for TI System Control Interface (TI-SCI) protocol

[Nishanth Menon]

Rob,

On Fri, Sep 2, 2016 at 10:06 AM, Rob Herring  wrote:
> On Tue, Aug 30, 2016 at 08:06:43AM -0500, Nishanth Menon wrote:
[...]
>> +
>> +TI-SCI Client Device Node:
>> +
>> +
>> +Client nodes refer to the required TI-SCI device using the "ti,sci" 
>> property.
>
> As I mentioned for power domains, for clients that are self contained
> (i.e. a single function) I think the should be child nodes.
>

Thanks for the feedback. I think we should be able to do that and also
assume you have no further improvements you'd like to see here.

Looking at current Documentation/devicetree/bindings/arm/arm,scpi.txt
-> it makes sense to stick along the same lines as you mentioned.

Dave, Tero: do you guys have any objections?


---
Regards,
Nishanth Menon

Re: [PATCH] tpm: invalid self test error message

[Jason Gunthorpe]

On Fri, Sep 02, 2016 at 08:56:29AM +0300, Jarkko Sakkinen wrote:
> The driver emits invalid self test error message even though the init
> succeeds.
> 
> Signed-off-by: Jarkko Sakkinen 
> Fixes: cae8b441fc20 ("tpm: Factor out common startup code")

Reviewed-by: Jason Gunthorpe 
Reported-by: Petr Vandrovec 

Jason

Re: [PATCH] tpm: invalid self test error message

[Jason Gunthorpe]

On Fri, Sep 02, 2016 at 08:56:29AM +0300, Jarkko Sakkinen wrote:
> The driver emits invalid self test error message even though the init
> succeeds.
> 
> Signed-off-by: Jarkko Sakkinen 
> Fixes: cae8b441fc20 ("tpm: Factor out common startup code")

Reviewed-by: Jason Gunthorpe 
Reported-by: Petr Vandrovec 

Jason

Re: [GIT PULL] firmware: add support for TI System Control Interface (TI-SCI) protocol driver

[Santosh Shilimkar]

On 9/2/2016 10:03 AM, Nishanth Menon wrote:

On Thu, Sep 1, 2016 at 2:24 AM, Tero Kristo  wrote:

Hi Santosh,

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  https://github.com/t-kristo/linux-pm.git 4.8-rc1-ti-sci-fw

for you to fetch changes up to 7a2c510cdfa6a4b2f4200c122a377c4d5f4af552:

  firmware: ti_sci: Add support for reboot core service (2016-08-31 14:50:20
+0300)


Nishanth Menon (5):
  Documentation: Add support for TI System Control Interface (TI-SCI)
protocol
  firmware: Add basic support for TI System Control Interface (TI-SCI)
protocol
  firmware: ti_sci: Add support for Device control
  firmware: ti_sci: Add support for Clock control
  firmware: ti_sci: Add support for reboot core service

 .../devicetree/bindings/arm/keystone/ti,sci.txt|   66 +
 MAINTAINERS|   10 +
 drivers/firmware/Kconfig   |   15 +
 drivers/firmware/Makefile  |1 +
 drivers/firmware/ti_sci.c  | 1997

 drivers/firmware/ti_sci.h  |  492 +
 include/linux/soc/ti/ti_sci_protocol.h |  249 +++
 7 files changed, 2830 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
 create mode 100644 drivers/firmware/ti_sci.c
 create mode 100644 drivers/firmware/ti_sci.h
 create mode 100644 include/linux/soc/ti/ti_sci_protocol.h



Folks, could you hold back on this pull request.. Rob did have a
comment on https://patchwork.kernel.org/patch/9305413/ which I think
should be discussed as well -> has implications to the driver arch
ofcourse.


Sure !!

Re: [GIT PULL] firmware: add support for TI System Control Interface (TI-SCI) protocol driver

[Santosh Shilimkar]

On 9/2/2016 10:03 AM, Nishanth Menon wrote:

On Thu, Sep 1, 2016 at 2:24 AM, Tero Kristo  wrote:

Hi Santosh,

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  https://github.com/t-kristo/linux-pm.git 4.8-rc1-ti-sci-fw

for you to fetch changes up to 7a2c510cdfa6a4b2f4200c122a377c4d5f4af552:

  firmware: ti_sci: Add support for reboot core service (2016-08-31 14:50:20
+0300)


Nishanth Menon (5):
  Documentation: Add support for TI System Control Interface (TI-SCI)
protocol
  firmware: Add basic support for TI System Control Interface (TI-SCI)
protocol
  firmware: ti_sci: Add support for Device control
  firmware: ti_sci: Add support for Clock control
  firmware: ti_sci: Add support for reboot core service

 .../devicetree/bindings/arm/keystone/ti,sci.txt|   66 +
 MAINTAINERS|   10 +
 drivers/firmware/Kconfig   |   15 +
 drivers/firmware/Makefile  |1 +
 drivers/firmware/ti_sci.c  | 1997

 drivers/firmware/ti_sci.h  |  492 +
 include/linux/soc/ti/ti_sci_protocol.h |  249 +++
 7 files changed, 2830 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
 create mode 100644 drivers/firmware/ti_sci.c
 create mode 100644 drivers/firmware/ti_sci.h
 create mode 100644 include/linux/soc/ti/ti_sci_protocol.h



Folks, could you hold back on this pull request.. Rob did have a
comment on https://patchwork.kernel.org/patch/9305413/ which I think
should be discussed as well -> has implications to the driver arch
ofcourse.


Sure !!

Re: [GIT PULL] firmware: add support for TI System Control Interface (TI-SCI) protocol driver

[Nishanth Menon]

On Thu, Sep 1, 2016 at 2:24 AM, Tero Kristo  wrote:
> Hi Santosh,
>
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
>   Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>
> are available in the git repository at:
>
>   https://github.com/t-kristo/linux-pm.git 4.8-rc1-ti-sci-fw
>
> for you to fetch changes up to 7a2c510cdfa6a4b2f4200c122a377c4d5f4af552:
>
>   firmware: ti_sci: Add support for reboot core service (2016-08-31 14:50:20
> +0300)
>
> 
> Nishanth Menon (5):
>   Documentation: Add support for TI System Control Interface (TI-SCI)
> protocol
>   firmware: Add basic support for TI System Control Interface (TI-SCI)
> protocol
>   firmware: ti_sci: Add support for Device control
>   firmware: ti_sci: Add support for Clock control
>   firmware: ti_sci: Add support for reboot core service
>
>  .../devicetree/bindings/arm/keystone/ti,sci.txt|   66 +
>  MAINTAINERS|   10 +
>  drivers/firmware/Kconfig   |   15 +
>  drivers/firmware/Makefile  |1 +
>  drivers/firmware/ti_sci.c  | 1997
> 
>  drivers/firmware/ti_sci.h  |  492 +
>  include/linux/soc/ti/ti_sci_protocol.h |  249 +++
>  7 files changed, 2830 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>  create mode 100644 drivers/firmware/ti_sci.c
>  create mode 100644 drivers/firmware/ti_sci.h
>  create mode 100644 include/linux/soc/ti/ti_sci_protocol.h
>

Folks, could you hold back on this pull request.. Rob did have a
comment on https://patchwork.kernel.org/patch/9305413/ which I think
should be discussed as well -> has implications to the driver arch
ofcourse.

-- 
---
Regards,
Nishanth Menon

Re: [GIT PULL] firmware: add support for TI System Control Interface (TI-SCI) protocol driver

[Nishanth Menon]

On Thu, Sep 1, 2016 at 2:24 AM, Tero Kristo  wrote:
> Hi Santosh,
>
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
>   Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>
> are available in the git repository at:
>
>   https://github.com/t-kristo/linux-pm.git 4.8-rc1-ti-sci-fw
>
> for you to fetch changes up to 7a2c510cdfa6a4b2f4200c122a377c4d5f4af552:
>
>   firmware: ti_sci: Add support for reboot core service (2016-08-31 14:50:20
> +0300)
>
> 
> Nishanth Menon (5):
>   Documentation: Add support for TI System Control Interface (TI-SCI)
> protocol
>   firmware: Add basic support for TI System Control Interface (TI-SCI)
> protocol
>   firmware: ti_sci: Add support for Device control
>   firmware: ti_sci: Add support for Clock control
>   firmware: ti_sci: Add support for reboot core service
>
>  .../devicetree/bindings/arm/keystone/ti,sci.txt|   66 +
>  MAINTAINERS|   10 +
>  drivers/firmware/Kconfig   |   15 +
>  drivers/firmware/Makefile  |1 +
>  drivers/firmware/ti_sci.c  | 1997
> 
>  drivers/firmware/ti_sci.h  |  492 +
>  include/linux/soc/ti/ti_sci_protocol.h |  249 +++
>  7 files changed, 2830 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>  create mode 100644 drivers/firmware/ti_sci.c
>  create mode 100644 drivers/firmware/ti_sci.h
>  create mode 100644 include/linux/soc/ti/ti_sci_protocol.h
>

Folks, could you hold back on this pull request.. Rob did have a
comment on https://patchwork.kernel.org/patch/9305413/ which I think
should be discussed as well -> has implications to the driver arch
ofcourse.

-- 
---
Regards,
Nishanth Menon

i2c: imx: add slave support. v2 status

[Baxter, Jim]

Hi Maxim,

On 2016-03-04 11:06:10 in the thread "Re: [PATCH] i2c: imx: add slave support. 
v2"
referenced here:   https://patchwork.ozlabs.org/patch/573353/  you said:
> Hi Wolfram,
> I'm now working on creating new driver version. I think I'll be able to 
> sent it soon.

Do you still plan to release a driver update for an i2c imx driver slave 
support?

Best regards,
Jim Baxter

i2c: imx: add slave support. v2 status

[Baxter, Jim]

Hi Maxim,

On 2016-03-04 11:06:10 in the thread "Re: [PATCH] i2c: imx: add slave support. 
v2"
referenced here:   https://patchwork.ozlabs.org/patch/573353/  you said:
> Hi Wolfram,
> I'm now working on creating new driver version. I think I'll be able to 
> sent it soon.

Do you still plan to release a driver update for an i2c imx driver slave 
support?

Best regards,
Jim Baxter

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Paolo Bonzini]

On 31/08/2016 19:05, Luiz Capitulino wrote:
>   vcpu0: 18446742405270834952
>   vcpu1: 18446742405270834952
>   vcpu2: 18446742405270834952
>   vcpu3: 18446742405270834952
> 
>  - We'll probably need to export the TSC multiplier too.
>However, I've been using only the TSC offset for now.
>So, let's get this merged first and do the TSC multiplier
>as a second step

You'll need to export the number of fractional bits in the multiplier,
too.  It's going to be a very simple patch, so please do everything now.

arch/x86/kvm/x86.c is huge; please create a new file arch/x86/kvm/debugfs.c.

> Signed-off-by: Luiz Capitulino 
> ---
>  arch/x86/include/asm/kvm_host.h |  1 +
>  arch/x86/kvm/svm.c  |  1 +
>  arch/x86/kvm/vmx.c  |  8 
>  arch/x86/kvm/x86.c  | 30 ++
>  4 files changed, 40 insertions(+)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 33ae3a4..5714bbd 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -952,6 +952,7 @@ struct kvm_x86_ops {
>   bool (*has_wbinvd_exit)(void);
>  
>   u64 (*read_tsc_offset)(struct kvm_vcpu *vcpu);
> + u64 (*read_cached_tsc_offset)(struct kvm_vcpu *vcpu);
>   void (*write_tsc_offset)(struct kvm_vcpu *vcpu, u64 offset);
>  
>   u64 (*read_l1_tsc)(struct kvm_vcpu *vcpu, u64 host_tsc);
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index af523d8..c851477 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -5065,6 +5065,7 @@ static struct kvm_x86_ops svm_x86_ops = {
>   .has_wbinvd_exit = svm_has_wbinvd_exit,
>  
>   .read_tsc_offset = svm_read_tsc_offset,
> + .read_cached_tsc_offset = svm_read_tsc_offset,
>   .write_tsc_offset = svm_write_tsc_offset,
>   .adjust_tsc_offset_guest = svm_adjust_tsc_offset_guest,
>   .read_l1_tsc = svm_read_l1_tsc,
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 5cede40..82dfe42 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -616,6 +616,7 @@ struct vcpu_vmx {
>   u64 hv_deadline_tsc;
>  
>   u64 current_tsc_ratio;
> + u64 cached_tsc_offset;
>  
>   bool guest_pkru_valid;
>   u32 guest_pkru;
> @@ -2608,6 +2609,11 @@ static u64 vmx_read_tsc_offset(struct kvm_vcpu *vcpu)
>   return vmcs_read64(TSC_OFFSET);
>  }
>  
> +static u64 vmx_read_cached_tsc_offset(struct kvm_vcpu *vcpu)
> +{
> + return to_vmx(vcpu)->cached_tsc_offset;
> +}
> +
>  /*
>   * writes 'offset' into guest's timestamp counter offset register
>   */
> @@ -2632,6 +2638,7 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, 
> u64 offset)
>  vmcs_read64(TSC_OFFSET), offset);
>   vmcs_write64(TSC_OFFSET, offset);
>   }
> + to_vmx(vcpu)->cached_tsc_offset = offset;
>  }
>  
>  static void vmx_adjust_tsc_offset_guest(struct kvm_vcpu *vcpu, s64 
> adjustment)
> @@ -11275,6 +11282,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
>   .has_wbinvd_exit = cpu_has_vmx_wbinvd_exit,
>  
>   .read_tsc_offset = vmx_read_tsc_offset,
> + .read_cached_tsc_offset = vmx_read_cached_tsc_offset,
>   .write_tsc_offset = vmx_write_tsc_offset,
>   .adjust_tsc_offset_guest = vmx_adjust_tsc_offset_guest,
>   .read_l1_tsc = vmx_read_l1_tsc,

You need to handle SVM as well.  So you might as well simplify the code:

- add a kvm_vcpu_write_tsc_offset wrapper for kvm_x86_ops->write_tsc_offset

- add a tsc_offset field in struct kvm_vcpu_arch

- replace kvm_x86_ops->read_tsc_offset with accesses to the new field

Then in a fifth patch export the TSC offset (and multiplier ;)) to
userspace.

I'm not very happy about having a single file for all TSC offsets.
Creating subdirectories under the PID-FD per-VM directory would be nicer
in the long run.

Paolo

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Paolo Bonzini]

On 31/08/2016 19:05, Luiz Capitulino wrote:
>   vcpu0: 18446742405270834952
>   vcpu1: 18446742405270834952
>   vcpu2: 18446742405270834952
>   vcpu3: 18446742405270834952
> 
>  - We'll probably need to export the TSC multiplier too.
>However, I've been using only the TSC offset for now.
>So, let's get this merged first and do the TSC multiplier
>as a second step

You'll need to export the number of fractional bits in the multiplier,
too.  It's going to be a very simple patch, so please do everything now.

arch/x86/kvm/x86.c is huge; please create a new file arch/x86/kvm/debugfs.c.

> Signed-off-by: Luiz Capitulino 
> ---
>  arch/x86/include/asm/kvm_host.h |  1 +
>  arch/x86/kvm/svm.c  |  1 +
>  arch/x86/kvm/vmx.c  |  8 
>  arch/x86/kvm/x86.c  | 30 ++
>  4 files changed, 40 insertions(+)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 33ae3a4..5714bbd 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -952,6 +952,7 @@ struct kvm_x86_ops {
>   bool (*has_wbinvd_exit)(void);
>  
>   u64 (*read_tsc_offset)(struct kvm_vcpu *vcpu);
> + u64 (*read_cached_tsc_offset)(struct kvm_vcpu *vcpu);
>   void (*write_tsc_offset)(struct kvm_vcpu *vcpu, u64 offset);
>  
>   u64 (*read_l1_tsc)(struct kvm_vcpu *vcpu, u64 host_tsc);
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index af523d8..c851477 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -5065,6 +5065,7 @@ static struct kvm_x86_ops svm_x86_ops = {
>   .has_wbinvd_exit = svm_has_wbinvd_exit,
>  
>   .read_tsc_offset = svm_read_tsc_offset,
> + .read_cached_tsc_offset = svm_read_tsc_offset,
>   .write_tsc_offset = svm_write_tsc_offset,
>   .adjust_tsc_offset_guest = svm_adjust_tsc_offset_guest,
>   .read_l1_tsc = svm_read_l1_tsc,
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 5cede40..82dfe42 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -616,6 +616,7 @@ struct vcpu_vmx {
>   u64 hv_deadline_tsc;
>  
>   u64 current_tsc_ratio;
> + u64 cached_tsc_offset;
>  
>   bool guest_pkru_valid;
>   u32 guest_pkru;
> @@ -2608,6 +2609,11 @@ static u64 vmx_read_tsc_offset(struct kvm_vcpu *vcpu)
>   return vmcs_read64(TSC_OFFSET);
>  }
>  
> +static u64 vmx_read_cached_tsc_offset(struct kvm_vcpu *vcpu)
> +{
> + return to_vmx(vcpu)->cached_tsc_offset;
> +}
> +
>  /*
>   * writes 'offset' into guest's timestamp counter offset register
>   */
> @@ -2632,6 +2638,7 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, 
> u64 offset)
>  vmcs_read64(TSC_OFFSET), offset);
>   vmcs_write64(TSC_OFFSET, offset);
>   }
> + to_vmx(vcpu)->cached_tsc_offset = offset;
>  }
>  
>  static void vmx_adjust_tsc_offset_guest(struct kvm_vcpu *vcpu, s64 
> adjustment)
> @@ -11275,6 +11282,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
>   .has_wbinvd_exit = cpu_has_vmx_wbinvd_exit,
>  
>   .read_tsc_offset = vmx_read_tsc_offset,
> + .read_cached_tsc_offset = vmx_read_cached_tsc_offset,
>   .write_tsc_offset = vmx_write_tsc_offset,
>   .adjust_tsc_offset_guest = vmx_adjust_tsc_offset_guest,
>   .read_l1_tsc = vmx_read_l1_tsc,

You need to handle SVM as well.  So you might as well simplify the code:

- add a kvm_vcpu_write_tsc_offset wrapper for kvm_x86_ops->write_tsc_offset

- add a tsc_offset field in struct kvm_vcpu_arch

- replace kvm_x86_ops->read_tsc_offset with accesses to the new field

Then in a fifth patch export the TSC offset (and multiplier ;)) to
userspace.

I'm not very happy about having a single file for all TSC offsets.
Creating subdirectories under the PID-FD per-VM directory would be nicer
in the long run.

Paolo

Re: [PATCH 3/4] KVM: x86: introduce get_kvmclock_ns

[Paolo Bonzini]

On 02/09/2016 18:55, Roman Kagan wrote:
>> > I'll change patch 4 to store the parameters and use them when accessing
>> > the time reference counter MSR.  I'll still keep the procedure that goes
>> > through kvmclock.  It's a bit more involved for the scale, but
>> > vcpu->last_guest_tsc only provides a part of the offset computation; the
>> > other half is vcpu->hv_clock.system_time and it's not stored anywhere.
> Erm... It is stored right there, in vcpu->hv_clock.system_time, you can
> access it just fine when you populate tsc_ref_page values.  Am I missing
> anything?

No.  It's not stored anywhere outside vcpu->hv_clock.  My reasoning goes
that if I have to use vcpu->hv_clock.system_time I might as well use
vcpu->hv_clock for everything. :)

Paolo

Re: e1000e on Thinkpad x60: gigabit not available due to "SmartSpeed"

[Lennart Sorensen]

On Thu, Sep 01, 2016 at 02:58:13PM -0700, Greg wrote:
> On Thu, 2016-09-01 at 22:14 +0200, Pavel Machek wrote:
> > Hi!
> > 
> > I have trouble getting 1000mbit out of my ethernet card.
> > 
> > I tried direct connection between two PCs with different cables, and
> > no luck.
> > 
> > Today I tried connection to 1000mbit switch, and no luck, either. (Two
> > cables, one was cat6, both short).
> > 
> > My computer sees 1000mbit being advertised by the other side, but does
> > not advertise 1000mbit, "Link Speed was downgraded by SmartSpeed".
> 
> Check your cables?
> 
> https://vmxp.wordpress.com/2015/01/06/1gbe-intel-nic-throttled-to-100mbit-by-smartspeed/

Of course if it isn't the cable, then it could even be a broken pin in
the port.  As far as I can tell, anything that causes one of the 3rd
or 4th pairs of wires to not work will degrade to 100Mbit on just the
first 2 pairs of wires and give that message.  Some badly implemented
switches can also cause it of course.

-- 
Len Sorensen

Re: [PATCH 3/4] KVM: x86: introduce get_kvmclock_ns

[Paolo Bonzini]

On 02/09/2016 18:55, Roman Kagan wrote:
>> > I'll change patch 4 to store the parameters and use them when accessing
>> > the time reference counter MSR.  I'll still keep the procedure that goes
>> > through kvmclock.  It's a bit more involved for the scale, but
>> > vcpu->last_guest_tsc only provides a part of the offset computation; the
>> > other half is vcpu->hv_clock.system_time and it's not stored anywhere.
> Erm... It is stored right there, in vcpu->hv_clock.system_time, you can
> access it just fine when you populate tsc_ref_page values.  Am I missing
> anything?

No.  It's not stored anywhere outside vcpu->hv_clock.  My reasoning goes
that if I have to use vcpu->hv_clock.system_time I might as well use
vcpu->hv_clock for everything. :)

Paolo

Re: e1000e on Thinkpad x60: gigabit not available due to "SmartSpeed"

[Lennart Sorensen]

On Thu, Sep 01, 2016 at 02:58:13PM -0700, Greg wrote:
> On Thu, 2016-09-01 at 22:14 +0200, Pavel Machek wrote:
> > Hi!
> > 
> > I have trouble getting 1000mbit out of my ethernet card.
> > 
> > I tried direct connection between two PCs with different cables, and
> > no luck.
> > 
> > Today I tried connection to 1000mbit switch, and no luck, either. (Two
> > cables, one was cat6, both short).
> > 
> > My computer sees 1000mbit being advertised by the other side, but does
> > not advertise 1000mbit, "Link Speed was downgraded by SmartSpeed".
> 
> Check your cables?
> 
> https://vmxp.wordpress.com/2015/01/06/1gbe-intel-nic-throttled-to-100mbit-by-smartspeed/

Of course if it isn't the cable, then it could even be a broken pin in
the port.  As far as I can tell, anything that causes one of the 3rd
or 4th pairs of wires to not work will degrade to 100Mbit on just the
first 2 pairs of wires and give that message.  Some badly implemented
switches can also cause it of course.

-- 
Len Sorensen

Re: [PATCH v2 1/2] perf: add container identifier entry in perf sample data

[Hari Bathini]

On Friday 02 September 2016 07:29 PM, Peter Zijlstra wrote:

On Fri, Sep 02, 2016 at 07:25:31PM +0530, Hari Bathini wrote:

I'm thinking this value is mostly the same for tasks, just like COMM and

I think so, too. Namespaces aren't changed that often for tasks...


MMAP. Could we therefore not emit (sideband) events whenever a task
changes namespace and get the same information but with tons less data?

You mean, something like PERF_RECORD_NAMESPACE that
emits events on fork, clone, setns..?

Yep.


Ok. Thanks!




That also gives the possibility of recording all namespaces, not just
the one.

True. If we record all namespaces, container identifier interpretation
can be left to the userspace to decide, which is much more flexible...

The only complication is initial state, on record start you'd have to
trawl /proc and generate 'fake' namespace records for all (relevant)
tasks.

We do the same with MMAP records, we parse /proc/$pid/maps for that.

Is this namespace stuff available in /proc somewhere?



Yes, Peter. /proc/$pid/ns
Will work on this and respin...

Thanks
Hari

Re: [PATCH v2 1/2] perf: add container identifier entry in perf sample data

[Hari Bathini]

On Friday 02 September 2016 07:29 PM, Peter Zijlstra wrote:

On Fri, Sep 02, 2016 at 07:25:31PM +0530, Hari Bathini wrote:

I'm thinking this value is mostly the same for tasks, just like COMM and

I think so, too. Namespaces aren't changed that often for tasks...


MMAP. Could we therefore not emit (sideband) events whenever a task
changes namespace and get the same information but with tons less data?

You mean, something like PERF_RECORD_NAMESPACE that
emits events on fork, clone, setns..?

Yep.


Ok. Thanks!




That also gives the possibility of recording all namespaces, not just
the one.

True. If we record all namespaces, container identifier interpretation
can be left to the userspace to decide, which is much more flexible...

The only complication is initial state, on record start you'd have to
trawl /proc and generate 'fake' namespace records for all (relevant)
tasks.

We do the same with MMAP records, we parse /proc/$pid/maps for that.

Is this namespace stuff available in /proc somewhere?



Yes, Peter. /proc/$pid/ns
Will work on this and respin...

Thanks
Hari

Re: [PATCH] trivial treewide: Convert dev_set_uevent_suppress argument to bool

[Joe Perches]

On Fri, 2016-09-02 at 08:59 -0700, Bart Van Assche wrote:
> How about the following:
> 
> dev_set_uevent_suppress() expects a boolean as second argument. Make 
> this clear by passing true/false instead of 1/0 as the second
> argument.

dev_set_uevent_suppress() doesn't currently expect a boolean.

The patch changes the function definition argument from int to bool
and also changes all callers of the function to true/false from 1/0.

Re: [PATCH] trivial treewide: Convert dev_set_uevent_suppress argument to bool

[Joe Perches]

On Fri, 2016-09-02 at 08:59 -0700, Bart Van Assche wrote:
> How about the following:
> 
> dev_set_uevent_suppress() expects a boolean as second argument. Make 
> this clear by passing true/false instead of 1/0 as the second
> argument.

dev_set_uevent_suppress() doesn't currently expect a boolean.

The patch changes the function definition argument from int to bool
and also changes all callers of the function to true/false from 1/0.

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

[Bjorn Andersson]

On Fri 02 Sep 09:24 PDT 2016, Kalle Valo wrote:

> Bjorn Andersson  writes:
> 
> > The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> > channel, as such it should be a SMD client. This patch makes this
> > transition, now that we have the necessary frameworks available.
> >
> > Signed-off-by: Bjorn Andersson 
> 
> [...]
> 
> > --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
> > +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
> > @@ -1,6 +1,6 @@
> >  config WCN36XX
> > tristate "Qualcomm Atheros WCN3660/3680 support"
> > -   depends on MAC80211 && HAS_DMA
> > +   depends on MAC80211 && HAS_DMA && QCOM_SMD
> 
> While I had this patch on my pending branch I noticed that I can't
> compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
> example then it's easy to miss mac80211 API changes etc. Is there any
> way we could continue build testing wcn36xx on x86 (or all) platforms?
> 

Sorry about that, we should at least be able to COMPILE_TEST it in
non-qcom builds. Thanks for letting me know.

And the driver should also depend on QCOM_WCNSS_CTRL, in the normal
case.

I'll respin this, unless you prefer an incremental patch for those
changes(?)

> Also what about older platforms? Earlier I used wcn36xx on my Nexus 4
> with help of backports project. I can't do that anymore, right?
> 

This has been tested on 8064, 8974 and 8916. So your Nexus 4 is covered.

Unfortunately I don't have a Nexus 4, but we currently have Nexus 7
(the 8064 version), Xperia Z, Xperia Z1 and DB410c using this chip and
all four has been tested with this code.

I've staged the PIL/remoteproc (firmware "loader") driver for v4.9, so
with this patch the only thing missing to fill in the dts files is one
clock from the RPM.


JFYI, There seems to be some race in the removal path, which I will look
into. But I would prefer if we could merge this to make the driver
usable, and more accessible to work on.

Regards,
Bjorn

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

[Bjorn Andersson]

On Fri 02 Sep 09:24 PDT 2016, Kalle Valo wrote:

> Bjorn Andersson  writes:
> 
> > The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> > channel, as such it should be a SMD client. This patch makes this
> > transition, now that we have the necessary frameworks available.
> >
> > Signed-off-by: Bjorn Andersson 
> 
> [...]
> 
> > --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
> > +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
> > @@ -1,6 +1,6 @@
> >  config WCN36XX
> > tristate "Qualcomm Atheros WCN3660/3680 support"
> > -   depends on MAC80211 && HAS_DMA
> > +   depends on MAC80211 && HAS_DMA && QCOM_SMD
> 
> While I had this patch on my pending branch I noticed that I can't
> compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
> example then it's easy to miss mac80211 API changes etc. Is there any
> way we could continue build testing wcn36xx on x86 (or all) platforms?
> 

Sorry about that, we should at least be able to COMPILE_TEST it in
non-qcom builds. Thanks for letting me know.

And the driver should also depend on QCOM_WCNSS_CTRL, in the normal
case.

I'll respin this, unless you prefer an incremental patch for those
changes(?)

> Also what about older platforms? Earlier I used wcn36xx on my Nexus 4
> with help of backports project. I can't do that anymore, right?
> 

This has been tested on 8064, 8974 and 8916. So your Nexus 4 is covered.

Unfortunately I don't have a Nexus 4, but we currently have Nexus 7
(the 8064 version), Xperia Z, Xperia Z1 and DB410c using this chip and
all four has been tested with this code.

I've staged the PIL/remoteproc (firmware "loader") driver for v4.9, so
with this patch the only thing missing to fill in the dts files is one
clock from the RPM.


JFYI, There seems to be some race in the removal path, which I will look
into. But I would prefer if we could merge this to make the driver
usable, and more accessible to work on.

Regards,
Bjorn

Re: chipidea: udc: kernel panic in isr_setup_status_phase

[Clemens Gruber]

On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> the lower vbus voltage causes the USB LDO voltage less than 3.0v, then
> cause the unstable for USB PHY. If possible, you can connect MAIN 5V
> (if it exists) directly to USB_H1_VBUS to see if this problem is fixed.

Yes, USB_H1_VBUS is supplied from internal 5V and it is accurate (+/-
0.03V). The USB_H_EN signal enables USB_H1_VBUS through a MIC2026-1.

The USB_OTG_VBUS signal from the picture with 4.69V came from the host
PC and is not under our control.

I read in the ReferenceManual that the USBPHY defaults to USB_H1_VBUS if
both USB_OTG_VBUS and USB_H1_VBUS are available.
If we imagine the following situation: USB OTG cable is plugged-in, the
board is powered on, USB_OTG_VBUS is supplied externally and USBPHY uses
it because USB_H1_EN is not high yet and did not enable USB_H1_VBUS.
If the USBPHY started out being supplied by USB_OTG_VBUS and later on,
USB_H1_VBUS comes up, will the USBPHY switch to USB_H1_VBUS immediately
or stay at being supplied by USB_OTG_VBUS as long as that is available?

> Great. Can you see the sudden lower for vbus again? If it still exists, it may
> be GND issue.

Yes it is still visible. Does not seem to be a problem though.

> Avoid NULL pointer deference is necessary. Patch is welcome :)

Yes, but should we also stop the gadget driver and print an error
message? Or just return from the isr and neither report nor stop?

Regards,
Clemens

Re: chipidea: udc: kernel panic in isr_setup_status_phase

[Clemens Gruber]

On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> the lower vbus voltage causes the USB LDO voltage less than 3.0v, then
> cause the unstable for USB PHY. If possible, you can connect MAIN 5V
> (if it exists) directly to USB_H1_VBUS to see if this problem is fixed.

Yes, USB_H1_VBUS is supplied from internal 5V and it is accurate (+/-
0.03V). The USB_H_EN signal enables USB_H1_VBUS through a MIC2026-1.

The USB_OTG_VBUS signal from the picture with 4.69V came from the host
PC and is not under our control.

I read in the ReferenceManual that the USBPHY defaults to USB_H1_VBUS if
both USB_OTG_VBUS and USB_H1_VBUS are available.
If we imagine the following situation: USB OTG cable is plugged-in, the
board is powered on, USB_OTG_VBUS is supplied externally and USBPHY uses
it because USB_H1_EN is not high yet and did not enable USB_H1_VBUS.
If the USBPHY started out being supplied by USB_OTG_VBUS and later on,
USB_H1_VBUS comes up, will the USBPHY switch to USB_H1_VBUS immediately
or stay at being supplied by USB_OTG_VBUS as long as that is available?

> Great. Can you see the sudden lower for vbus again? If it still exists, it may
> be GND issue.

Yes it is still visible. Does not seem to be a problem though.

> Avoid NULL pointer deference is necessary. Patch is welcome :)

Yes, but should we also stop the gadget driver and print an error
message? Or just return from the isr and neither report nor stop?

Regards,
Clemens

RE: [PATCH] ARM: fix linker call for ARM_MODULE_PLTS

[Wiebe, Wladislav (Nokia - DE/Ulm)]

> From: Russell King - ARM Linux [mailto:li...@armlinux.org.uk]
> Sent: Friday, September 02, 2016 11:25 AM
> 
> On Fri, Sep 02, 2016 at 09:17:58AM +, Wiebe, Wladislav (Nokia - DE/Ulm)
> wrote:
> > module.lds script doesn't get called when
> > CONFIG_ARM_MODULE_PLTS is enabled.
> > Use KBUILD_LDFLAGS_MODULE to fix it.
> 
> For those of us who haven't encountered this problem, could you include
> some commentry in the commit message describing the failure mechanism
> and why you think this is the correct solution?
> 
> The final link for modules is:
> 
> quiet_cmd_ld_ko_o = LD [M]  $@
>   cmd_ld_ko_o = $(LD) -r $(LDFLAGS) \
>  $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
>  -o $@ $(filter-out FORCE,$^)
> 
> which seems to always include both flags.  Why is it ignored when it's
> in LDFLAGS_MODULE?  What about the other flags we pass in
> LDFLAGS_MODULE?

aah -- just found an issue in my environment where LDFLAGS_MODULE gets 
overwritten
due to a none upstream patch on scripts/Makefile.modpost.

It worked only for me when using the KBUILD_LDFLAGS_MODULE
and I did not get deep inside after I saw in 
https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt
+
KBUILD_LDFLAGS_MODULE   Options for $(LD) when linking modules

$(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
used when linking modules. This is often a linker script.
From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
+

and found that all other architectures are also users of KBUILD_LDFLAGS_MODULE 
for that purpose
$ git grep LDFLAGS_MODULE arch/
arch/arm/Makefile:LDFLAGS_MODULE+= --be8
arch/arm/Makefile:LDFLAGS_MODULE+= -T 
$(srctree)/arch/arm/kernel/module.lds
arch/arm64/Makefile:KBUILD_LDFLAGS_MODULE   += -T 
$(srctree)/arch/arm64/kernel/module.lds
arch/hexagon/Makefile:# LDFLAGS_MODULE += -shared
arch/ia64/Makefile:KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/ia64/module.lds
arch/m68k/Makefile:KBUILD_LDFLAGS_MODULE += -T 
$(srctree)/arch/m68k/kernel/module.lds
arch/powerpc/Makefile:KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
arch/powerpc/Makefile:  KBUILD_LDFLAGS_MODULE += --ppc476-workaround \


Anyway, feel free to ignore this patch and thanks a lot for the fast feedback.



> 
> Thanks.
> 
> >
> > Signed-off-by: Wladislav Wiebe 
> > ---
> >  arch/arm/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index 61f6ccc..01c6025 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -20,7 +20,7 @@ LDFLAGS_MODULE+= --be8
> >  endif
> >
> >  ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
> > -LDFLAGS_MODULE += -T $(srctree)/arch/arm/kernel/module.lds
> > +KBUILD_LDFLAGS_MODULE  += -T $(srctree)/arch/arm/kernel/module.lds
> >  endif
> >
> >  OBJCOPYFLAGS   :=-O binary -R .comment -S
> > --
> > 1.7.12.4
> 
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

RE: [PATCH] ARM: fix linker call for ARM_MODULE_PLTS

[Wiebe, Wladislav (Nokia - DE/Ulm)]

> From: Russell King - ARM Linux [mailto:li...@armlinux.org.uk]
> Sent: Friday, September 02, 2016 11:25 AM
> 
> On Fri, Sep 02, 2016 at 09:17:58AM +, Wiebe, Wladislav (Nokia - DE/Ulm)
> wrote:
> > module.lds script doesn't get called when
> > CONFIG_ARM_MODULE_PLTS is enabled.
> > Use KBUILD_LDFLAGS_MODULE to fix it.
> 
> For those of us who haven't encountered this problem, could you include
> some commentry in the commit message describing the failure mechanism
> and why you think this is the correct solution?
> 
> The final link for modules is:
> 
> quiet_cmd_ld_ko_o = LD [M]  $@
>   cmd_ld_ko_o = $(LD) -r $(LDFLAGS) \
>  $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
>  -o $@ $(filter-out FORCE,$^)
> 
> which seems to always include both flags.  Why is it ignored when it's
> in LDFLAGS_MODULE?  What about the other flags we pass in
> LDFLAGS_MODULE?

aah -- just found an issue in my environment where LDFLAGS_MODULE gets 
overwritten
due to a none upstream patch on scripts/Makefile.modpost.

It worked only for me when using the KBUILD_LDFLAGS_MODULE
and I did not get deep inside after I saw in 
https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt
+
KBUILD_LDFLAGS_MODULE   Options for $(LD) when linking modules

$(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
used when linking modules. This is often a linker script.
From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
+

and found that all other architectures are also users of KBUILD_LDFLAGS_MODULE 
for that purpose
$ git grep LDFLAGS_MODULE arch/
arch/arm/Makefile:LDFLAGS_MODULE+= --be8
arch/arm/Makefile:LDFLAGS_MODULE+= -T 
$(srctree)/arch/arm/kernel/module.lds
arch/arm64/Makefile:KBUILD_LDFLAGS_MODULE   += -T 
$(srctree)/arch/arm64/kernel/module.lds
arch/hexagon/Makefile:# LDFLAGS_MODULE += -shared
arch/ia64/Makefile:KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/ia64/module.lds
arch/m68k/Makefile:KBUILD_LDFLAGS_MODULE += -T 
$(srctree)/arch/m68k/kernel/module.lds
arch/powerpc/Makefile:KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
arch/powerpc/Makefile:  KBUILD_LDFLAGS_MODULE += --ppc476-workaround \


Anyway, feel free to ignore this patch and thanks a lot for the fast feedback.



> 
> Thanks.
> 
> >
> > Signed-off-by: Wladislav Wiebe 
> > ---
> >  arch/arm/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index 61f6ccc..01c6025 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -20,7 +20,7 @@ LDFLAGS_MODULE+= --be8
> >  endif
> >
> >  ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
> > -LDFLAGS_MODULE += -T $(srctree)/arch/arm/kernel/module.lds
> > +KBUILD_LDFLAGS_MODULE  += -T $(srctree)/arch/arm/kernel/module.lds
> >  endif
> >
> >  OBJCOPYFLAGS   :=-O binary -R .comment -S
> > --
> > 1.7.12.4
> 
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

Re: [PATCH] x86/paravirt: Do not trace _paravirt_ident_*() functions

[Linus Torvalds]

On Fri, Sep 2, 2016 at 7:46 AM, Steven Rostedt  wrote:
>
> Can someone please pull this in. And mark it for stable, it goes
> probably as far back as 2.6.32.

Applied.

 Linus

Re: [PATCH] x86/paravirt: Do not trace _paravirt_ident_*() functions

[Linus Torvalds]

On Fri, Sep 2, 2016 at 7:46 AM, Steven Rostedt  wrote:
>
> Can someone please pull this in. And mark it for stable, it goes
> probably as far back as 2.6.32.

Applied.

 Linus

Re: [PATCH v15 04/13] task_isolation: add initial support

[Peter Zijlstra]

On Fri, Sep 02, 2016 at 10:03:52AM -0400, Chris Metcalf wrote:
> Any thoughts on the question of "just re-enter the loop" vs. 
> schedule_timeout()?

schedule_timeout() should only be used for things you do not have
control over, like things outside of the machine.

If you want to actually block running, use that completion you were
talking of.

Re: [PATCH v15 04/13] task_isolation: add initial support

[Peter Zijlstra]

On Fri, Sep 02, 2016 at 10:03:52AM -0400, Chris Metcalf wrote:
> Any thoughts on the question of "just re-enter the loop" vs. 
> schedule_timeout()?

schedule_timeout() should only be used for things you do not have
control over, like things outside of the machine.

If you want to actually block running, use that completion you were
talking of.

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

[Marcel Holtmann]

Hi Kalle,

>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
>> channel, as such it should be a SMD client. This patch makes this
>> transition, now that we have the necessary frameworks available.
>> 
>> Signed-off-by: Bjorn Andersson 
> 
> [...]
> 
>> --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
>> +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
>> @@ -1,6 +1,6 @@
>> config WCN36XX
>>  tristate "Qualcomm Atheros WCN3660/3680 support"
>> -depends on MAC80211 && HAS_DMA
>> +depends on MAC80211 && HAS_DMA && QCOM_SMD
> 
> While I had this patch on my pending branch I noticed that I can't
> compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
> example then it's easy to miss mac80211 API changes etc. Is there any
> way we could continue build testing wcn36xx on x86 (or all) platforms?

I would also like that for the btqcomsmd Bluetooth driver. Doing quick build 
tests on x86 would be great.

Regards

Marcel

Re: [PATCH 3/4] KVM: x86: introduce get_kvmclock_ns

[Paolo Bonzini]

On 02/09/2016 16:51, Roman Kagan wrote:
> On Fri, Sep 02, 2016 at 04:09:42PM +0200, Paolo Bonzini wrote:
>> On 02/09/2016 15:52, Roman Kagan wrote:
>> vs. using a single offset as in the TSC ref page is one nanosecond---and
>> the ref page only has a resolution of 100 ns.
> 
> AFAICS it's not a matter of resolution.  If one calculation flips from
> value T to T+1 at tsc1, while the other at tsc2, during the window
> between tsc1 and tsc2 we can have monotonicity violation.

Ok, tried "empirically" (throw numbers in a spreadsheet :)) and indeed
the maximum error is not 1 ns but 100 ns (1 unit in the time reference
count MSR).

You can get a flip between T/T+1 because the time reference counter may
be more precise with its rounding due to the separation between
tsc_timestamp and system_time.  This separation provides some extra
decimal digits to the offset, which the TSC page lacks.  For example:

51256391tsc_timestamp
3311474323  tsc_to_system_mul
254246  system_time
-1  shift
-195054.1816offset (computed exactly)

So the flip happens when the nanoseconds are around 81/82:

tsckvmclock refcount  TSC page
51256391   254246   2542  2542
51256483   254281   2542  2542
51256484   254281   2542  2543
51256486   254282   2542  2543
51256746   254382   2543  2544

I'll change patch 4 to store the parameters and use them when accessing
the time reference counter MSR.  I'll still keep the procedure that goes
through kvmclock.  It's a bit more involved for the scale, but
vcpu->last_guest_tsc only provides a part of the offset computation; the
other half is vcpu->hv_clock.system_time and it's not stored anywhere.

Paolo

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

[Marcel Holtmann]

Hi Kalle,

>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
>> channel, as such it should be a SMD client. This patch makes this
>> transition, now that we have the necessary frameworks available.
>> 
>> Signed-off-by: Bjorn Andersson 
> 
> [...]
> 
>> --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
>> +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
>> @@ -1,6 +1,6 @@
>> config WCN36XX
>>  tristate "Qualcomm Atheros WCN3660/3680 support"
>> -depends on MAC80211 && HAS_DMA
>> +depends on MAC80211 && HAS_DMA && QCOM_SMD
> 
> While I had this patch on my pending branch I noticed that I can't
> compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
> example then it's easy to miss mac80211 API changes etc. Is there any
> way we could continue build testing wcn36xx on x86 (or all) platforms?

I would also like that for the btqcomsmd Bluetooth driver. Doing quick build 
tests on x86 would be great.

Regards

Marcel

Re: [PATCH 3/4] KVM: x86: introduce get_kvmclock_ns

[Paolo Bonzini]

On 02/09/2016 16:51, Roman Kagan wrote:
> On Fri, Sep 02, 2016 at 04:09:42PM +0200, Paolo Bonzini wrote:
>> On 02/09/2016 15:52, Roman Kagan wrote:
>> vs. using a single offset as in the TSC ref page is one nanosecond---and
>> the ref page only has a resolution of 100 ns.
> 
> AFAICS it's not a matter of resolution.  If one calculation flips from
> value T to T+1 at tsc1, while the other at tsc2, during the window
> between tsc1 and tsc2 we can have monotonicity violation.

Ok, tried "empirically" (throw numbers in a spreadsheet :)) and indeed
the maximum error is not 1 ns but 100 ns (1 unit in the time reference
count MSR).

You can get a flip between T/T+1 because the time reference counter may
be more precise with its rounding due to the separation between
tsc_timestamp and system_time.  This separation provides some extra
decimal digits to the offset, which the TSC page lacks.  For example:

51256391tsc_timestamp
3311474323  tsc_to_system_mul
254246  system_time
-1  shift
-195054.1816offset (computed exactly)

So the flip happens when the nanoseconds are around 81/82:

tsckvmclock refcount  TSC page
51256391   254246   2542  2542
51256483   254281   2542  2542
51256484   254281   2542  2543
51256486   254282   2542  2543
51256746   254382   2543  2544

I'll change patch 4 to store the parameters and use them when accessing
the time reference counter MSR.  I'll still keep the procedure that goes
through kvmclock.  It's a bit more involved for the scale, but
vcpu->last_guest_tsc only provides a part of the offset computation; the
other half is vcpu->hv_clock.system_time and it's not stored anywhere.

Paolo

Re: [GIT PULL 4/4] ARM: defconfig: Exynos for v4.9

[Krzysztof Kozlowski]

On Fri, Sep 02, 2016 at 05:47:11PM +0200, Arnd Bergmann wrote:
> On Tuesday, August 30, 2016 11:18:56 AM CEST Krzysztof Kozlowski wrote:
> > Expected conflict in multi_v7 - take all the changes:
> > 
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> > @@@ -135,8 -136,7 +136,8 @@@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=
> >   CONFIG_CPU_FREQ_GOV_POWERSAVE=m
> >   CONFIG_CPU_FREQ_GOV_USERSPACE=m
> >   CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
> > - CONFIG_CPU_FREQ_GOV_SCHEDUTIL=m
> > + CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
> >  +CONFIG_ARM_IMX6Q_CPUFREQ=y
> >   CONFIG_QORIQ_CPUFREQ=y
> >   CONFIG_CPU_IDLE=y
> >   CONFIG_ARM_CPUIDLE=y
> > 
> > 
> 
> I pulled this into next/defconfig, but didn't see the conflict,
> presumably I'll get it after merging the other branches?

The conflict is between my tree and imx-mxs tree so you might encounter
it later when merging IMX changes.

Best regards,
Krzysztof

Re: [GIT PULL 4/4] ARM: defconfig: Exynos for v4.9

[Krzysztof Kozlowski]

On Fri, Sep 02, 2016 at 05:47:11PM +0200, Arnd Bergmann wrote:
> On Tuesday, August 30, 2016 11:18:56 AM CEST Krzysztof Kozlowski wrote:
> > Expected conflict in multi_v7 - take all the changes:
> > 
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> > @@@ -135,8 -136,7 +136,8 @@@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=
> >   CONFIG_CPU_FREQ_GOV_POWERSAVE=m
> >   CONFIG_CPU_FREQ_GOV_USERSPACE=m
> >   CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
> > - CONFIG_CPU_FREQ_GOV_SCHEDUTIL=m
> > + CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
> >  +CONFIG_ARM_IMX6Q_CPUFREQ=y
> >   CONFIG_QORIQ_CPUFREQ=y
> >   CONFIG_CPU_IDLE=y
> >   CONFIG_ARM_CPUIDLE=y
> > 
> > 
> 
> I pulled this into next/defconfig, but didn't see the conflict,
> presumably I'll get it after merging the other branches?

The conflict is between my tree and imx-mxs tree so you might encounter
it later when merging IMX changes.

Best regards,
Krzysztof

Re: [PATCH 2/5] irqtime: Remove needless IRQs disablement on kcpustat update

[Peter Zijlstra]

On Fri, Sep 02, 2016 at 04:53:47PM +0200, Paolo Bonzini wrote:
> 
> 
> On 02/09/2016 16:03, Frederic Weisbecker wrote:
> > The callers of the functions performing irqtime kcpustat updates have
> > IRQS disabled, no need to disable them again.
> 
> They do, but perhaps this should be annotated through some sparse magic.
>  It's starting to be hairy, with the requirement spanning many separate
> files.

Sparse sucks for those things...

maybe just add something like lockdep_assert_irqsoff(). Such a call both
documents the requirement and validates at runtime when CONFIG_LOCKDEP.

Re: [PATCH 2/5] irqtime: Remove needless IRQs disablement on kcpustat update

[Peter Zijlstra]

On Fri, Sep 02, 2016 at 04:53:47PM +0200, Paolo Bonzini wrote:
> 
> 
> On 02/09/2016 16:03, Frederic Weisbecker wrote:
> > The callers of the functions performing irqtime kcpustat updates have
> > IRQS disabled, no need to disable them again.
> 
> They do, but perhaps this should be annotated through some sparse magic.
>  It's starting to be hairy, with the requirement spanning many separate
> files.

Sparse sucks for those things...

maybe just add something like lockdep_assert_irqsoff(). Such a call both
documents the requirement and validates at runtime when CONFIG_LOCKDEP.

Re: [GIT PULL 1/4] ARM: exynos: SoC/Mach for v4.9

[Krzysztof Kozlowski]

On Fri, Sep 02, 2016 at 06:26:42PM +0200, Arnd Bergmann wrote:
> On Tuesday, August 30, 2016 11:18:59 AM CEST Krzysztof Kozlowski wrote:
> > Samsung mach/soc update for v4.9:
> > 1. Fix for DMA on S3C24xx. This was probably broken for long time, nobody 
> > runs
> >this code... till now.
> 
> Good to know. This reminds me that the s3c24xx DMA code is one of those
> that need to be converted to dma_slave_map at some point. Maybe if someone
> is now running that code, they could give that a try as well?
> 
> It shouldn't be hard to convert, let me know if you need more information.

+Cc Sylwester,

Sylwester recently dig into this platform. I think he managed to play
some audio.

Best regards,
Krzysztof

Re: [GIT PULL 1/4] ARM: exynos: SoC/Mach for v4.9

[Krzysztof Kozlowski]

On Fri, Sep 02, 2016 at 06:26:42PM +0200, Arnd Bergmann wrote:
> On Tuesday, August 30, 2016 11:18:59 AM CEST Krzysztof Kozlowski wrote:
> > Samsung mach/soc update for v4.9:
> > 1. Fix for DMA on S3C24xx. This was probably broken for long time, nobody 
> > runs
> >this code... till now.
> 
> Good to know. This reminds me that the s3c24xx DMA code is one of those
> that need to be converted to dma_slave_map at some point. Maybe if someone
> is now running that code, they could give that a try as well?
> 
> It shouldn't be hard to convert, let me know if you need more information.

+Cc Sylwester,

Sylwester recently dig into this platform. I think he managed to play
some audio.

Best regards,
Krzysztof

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Luiz Capitulino]

On Fri, 2 Sep 2016 12:26:55 -0400
Luiz Capitulino  wrote:

> I guess that what tools like trace-cmd want to do in those cases
> is to warn the user and discard the trace. A simple way of doing
> this would be to re-check that the TSC offset are the same after
> tracing is done. It could also use inotify, in case it works
> for debugfs (never tried it myself).

The second idea was probably stupid, never mind me :)

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Luiz Capitulino]

On Fri, 2 Sep 2016 12:26:55 -0400
Luiz Capitulino  wrote:

> I guess that what tools like trace-cmd want to do in those cases
> is to warn the user and discard the trace. A simple way of doing
> this would be to re-check that the TSC offset are the same after
> tracing is done. It could also use inotify, in case it works
> for debugfs (never tried it myself).

The second idea was probably stupid, never mind me :)

Re: [v10,2/2] PCI: Rockchip: Add Rockchip PCIe controller support

[Heiko Stübner]

Am Freitag, 2. September 2016, 10:44:09 schrieb Bjorn Helgaas:
> On Thu, Sep 01, 2016 at 12:48:52PM -0500, Bjorn Helgaas wrote:
> > On Thu, Sep 01, 2016 at 10:14:01AM -0700, Brian Norris wrote:
> > > The use of HIWORD_UPDATE can indeed be a bit confusing, IMO, but this is
> > > really a common Rockchip-ism that, once you read several of their
> > > drivers, can make a little more sense. If you grep around, it's in at
> > > least their clock, ethernet, SDHCI, PHY, and DP/DRM drivers. I might
> > > defer to Heiko (upstream maintainer of Rockchip code) for a decision.
> > > Maybe there's some intermediate ground where we keep the HIWORK_UPDATE()
> > > logic (it does make sure we get the 16-bit shift right, I think) while
> > > still refactoring a few other bits (like PCIE_CLIENT_CONF_LANE_NUM() and
> > > PCIE_CLIENT_GEN_SEL() for wrapping HIWORK_UPDATE()?).
> 
> Here's a second proposal.  It retains HIWORD_UPDATE (though the structure
> is different) so grep finds it along with the other Rockchip ones.
> 
> I'll post updated actual patches; this is just to give the idea:
> 
> -/*
> -  * The higher 16-bit of this register is used for write protection
> -  * only if BIT(x + 16) set to 1 the BIT(x) can be written.
> -  */
> -#define HIWORD_UPDATE(val, mask, shift) \
> - ((val) << (shift) | (mask) << ((shift) + 16))
> 
> -#define PCIE_CLIENT_CONF_ENABLE  BIT(0)
> -#define PCIE_CLIENT_CONF_ENABLE_SHIFT0
> -#define PCIE_CLIENT_CONF_ENABLE_MASK 0x1
> -#define PCIE_CLIENT_LINK_TRAIN_ENABLE1
> -#define PCIE_CLIENT_LINK_TRAIN_SHIFT 1
> -#define PCIE_CLIENT_LINK_TRAIN_MASK  0x1
> -#define PCIE_CLIENT_ARI_ENABLE   BIT(0)
> -#define PCIE_CLIENT_ARI_ENABLE_SHIFT 3
> -#define PCIE_CLIENT_ARI_ENABLE_MASK  0x1
> -#define PCIE_CLIENT_CONF_LANE_NUM(x) (x / 2)
> -#define PCIE_CLIENT_CONF_LANE_NUM_SHIFT  4
> -#define PCIE_CLIENT_CONF_LANE_NUM_MASK   0x3
> -#define PCIE_CLIENT_MODE_RC  BIT(0)
> -#define PCIE_CLIENT_MODE_SHIFT   6
> -#define PCIE_CLIENT_MODE_MASK0x1
> -#define PCIE_CLIENT_GEN_SEL_21
> -#define PCIE_CLIENT_GEN_SEL_SHIFT7
> -#define PCIE_CLIENT_GEN_SEL_MASK 0x1
> 
> +/*
> + * The upper 16 bits of the PCIE_CLIENT registers are a write mask for the
> + * lower 16 bits.  This allows atomic updates of the register without
> + * locking.
> + */
> +#define HIWORD_UPDATE(mask, val) ((mask << 16) | val)
> +
> +#define ENCODE_LANES(x)  (((x >> 1) & 3) << 4)
> +
> +#define PCIE_CLIENT_CONF_ENABLE  HIWORD_UPDATE(0x0001, 0x0001)
> +#define PCIE_CLIENT_LINK_TRAIN_ENABLEHIWORD_UPDATE(0x0002, 0x0002)
> +#define PCIE_CLIENT_CONF_LANE_NUM(x) HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
> +#define PCIE_CLIENT_GEN_SEL_2HIWORD_UPDATE(0x0040, 0x0040)
> 
>   rockchip_pcie_write(rockchip,
> -HIWORD_UPDATE(PCIE_CLIENT_CONF_ENABLE,
> -  PCIE_CLIENT_CONF_ENABLE_MASK,
> -  PCIE_CLIENT_CONF_ENABLE_SHIFT) |
> -HIWORD_UPDATE(PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes),
> -  PCIE_CLIENT_CONF_LANE_NUM_MASK,
> -  PCIE_CLIENT_CONF_LANE_NUM_SHIFT) |
> -HIWORD_UPDATE(PCIE_CLIENT_MODE_RC,
> -  PCIE_CLIENT_MODE_MASK,
> -  PCIE_CLIENT_MODE_SHIFT) |
> -HIWORD_UPDATE(PCIE_CLIENT_ARI_ENABLE,
> -  PCIE_CLIENT_ARI_ENABLE_MASK,
> -  PCIE_CLIENT_ARI_ENABLE_SHIFT) |
> -HIWORD_UPDATE(PCIE_CLIENT_GEN_SEL_2,
> -  PCIE_CLIENT_GEN_SEL_MASK,
> -  PCIE_CLIENT_GEN_SEL_SHIFT),
> -PCIE_CLIENT_BASE);
> + PCIE_CLIENT_CONF_ENABLE |
> + PCIE_CLIENT_LINK_TRAIN_ENABLE |
> + PCIE_CLIENT_ARI_ENABLE |
> + PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
> + PCIE_CLIENT_MODE_RC |
> + PCIE_CLIENT_GEN_SEL_2,
> + PCIE_CLIENT_BASE);

I like this new approach :-)
Improves the readability in the code but also future readability of the defined 
constants, when comparing with register descriptions


Thanks
Heiko

Re: [v10,2/2] PCI: Rockchip: Add Rockchip PCIe controller support

[Heiko Stübner]

Am Freitag, 2. September 2016, 10:44:09 schrieb Bjorn Helgaas:
> On Thu, Sep 01, 2016 at 12:48:52PM -0500, Bjorn Helgaas wrote:
> > On Thu, Sep 01, 2016 at 10:14:01AM -0700, Brian Norris wrote:
> > > The use of HIWORD_UPDATE can indeed be a bit confusing, IMO, but this is
> > > really a common Rockchip-ism that, once you read several of their
> > > drivers, can make a little more sense. If you grep around, it's in at
> > > least their clock, ethernet, SDHCI, PHY, and DP/DRM drivers. I might
> > > defer to Heiko (upstream maintainer of Rockchip code) for a decision.
> > > Maybe there's some intermediate ground where we keep the HIWORK_UPDATE()
> > > logic (it does make sure we get the 16-bit shift right, I think) while
> > > still refactoring a few other bits (like PCIE_CLIENT_CONF_LANE_NUM() and
> > > PCIE_CLIENT_GEN_SEL() for wrapping HIWORK_UPDATE()?).
> 
> Here's a second proposal.  It retains HIWORD_UPDATE (though the structure
> is different) so grep finds it along with the other Rockchip ones.
> 
> I'll post updated actual patches; this is just to give the idea:
> 
> -/*
> -  * The higher 16-bit of this register is used for write protection
> -  * only if BIT(x + 16) set to 1 the BIT(x) can be written.
> -  */
> -#define HIWORD_UPDATE(val, mask, shift) \
> - ((val) << (shift) | (mask) << ((shift) + 16))
> 
> -#define PCIE_CLIENT_CONF_ENABLE  BIT(0)
> -#define PCIE_CLIENT_CONF_ENABLE_SHIFT0
> -#define PCIE_CLIENT_CONF_ENABLE_MASK 0x1
> -#define PCIE_CLIENT_LINK_TRAIN_ENABLE1
> -#define PCIE_CLIENT_LINK_TRAIN_SHIFT 1
> -#define PCIE_CLIENT_LINK_TRAIN_MASK  0x1
> -#define PCIE_CLIENT_ARI_ENABLE   BIT(0)
> -#define PCIE_CLIENT_ARI_ENABLE_SHIFT 3
> -#define PCIE_CLIENT_ARI_ENABLE_MASK  0x1
> -#define PCIE_CLIENT_CONF_LANE_NUM(x) (x / 2)
> -#define PCIE_CLIENT_CONF_LANE_NUM_SHIFT  4
> -#define PCIE_CLIENT_CONF_LANE_NUM_MASK   0x3
> -#define PCIE_CLIENT_MODE_RC  BIT(0)
> -#define PCIE_CLIENT_MODE_SHIFT   6
> -#define PCIE_CLIENT_MODE_MASK0x1
> -#define PCIE_CLIENT_GEN_SEL_21
> -#define PCIE_CLIENT_GEN_SEL_SHIFT7
> -#define PCIE_CLIENT_GEN_SEL_MASK 0x1
> 
> +/*
> + * The upper 16 bits of the PCIE_CLIENT registers are a write mask for the
> + * lower 16 bits.  This allows atomic updates of the register without
> + * locking.
> + */
> +#define HIWORD_UPDATE(mask, val) ((mask << 16) | val)
> +
> +#define ENCODE_LANES(x)  (((x >> 1) & 3) << 4)
> +
> +#define PCIE_CLIENT_CONF_ENABLE  HIWORD_UPDATE(0x0001, 0x0001)
> +#define PCIE_CLIENT_LINK_TRAIN_ENABLEHIWORD_UPDATE(0x0002, 0x0002)
> +#define PCIE_CLIENT_CONF_LANE_NUM(x) HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
> +#define PCIE_CLIENT_GEN_SEL_2HIWORD_UPDATE(0x0040, 0x0040)
> 
>   rockchip_pcie_write(rockchip,
> -HIWORD_UPDATE(PCIE_CLIENT_CONF_ENABLE,
> -  PCIE_CLIENT_CONF_ENABLE_MASK,
> -  PCIE_CLIENT_CONF_ENABLE_SHIFT) |
> -HIWORD_UPDATE(PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes),
> -  PCIE_CLIENT_CONF_LANE_NUM_MASK,
> -  PCIE_CLIENT_CONF_LANE_NUM_SHIFT) |
> -HIWORD_UPDATE(PCIE_CLIENT_MODE_RC,
> -  PCIE_CLIENT_MODE_MASK,
> -  PCIE_CLIENT_MODE_SHIFT) |
> -HIWORD_UPDATE(PCIE_CLIENT_ARI_ENABLE,
> -  PCIE_CLIENT_ARI_ENABLE_MASK,
> -  PCIE_CLIENT_ARI_ENABLE_SHIFT) |
> -HIWORD_UPDATE(PCIE_CLIENT_GEN_SEL_2,
> -  PCIE_CLIENT_GEN_SEL_MASK,
> -  PCIE_CLIENT_GEN_SEL_SHIFT),
> -PCIE_CLIENT_BASE);
> + PCIE_CLIENT_CONF_ENABLE |
> + PCIE_CLIENT_LINK_TRAIN_ENABLE |
> + PCIE_CLIENT_ARI_ENABLE |
> + PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
> + PCIE_CLIENT_MODE_RC |
> + PCIE_CLIENT_GEN_SEL_2,
> + PCIE_CLIENT_BASE);

I like this new approach :-)
Improves the readability in the code but also future readability of the defined 
constants, when comparing with register descriptions


Thanks
Heiko

Re: [GIT PULL 1/4] ARM: exynos: SoC/Mach for v4.9

[Arnd Bergmann]

On Tuesday, August 30, 2016 11:18:59 AM CEST Krzysztof Kozlowski wrote:
> Samsung mach/soc update for v4.9:
> 1. Fix for DMA on S3C24xx. This was probably broken for long time, nobody runs
>this code... till now.

Good to know. This reminds me that the s3c24xx DMA code is one of those
that need to be converted to dma_slave_map at some point. Maybe if someone
is now running that code, they could give that a try as well?

It shouldn't be hard to convert, let me know if you need more information.

> 2. After fixes from Matthew Leach and Ben Dooks, most of our mach code
>and drivers is now endian-safe. Mark the platform as supporting big endian.
> 3. Cleanups.
> 
> 

Pulled into next/soc, thanks!

Arnd

Re: [GIT PULL 1/4] ARM: exynos: SoC/Mach for v4.9

[Arnd Bergmann]

On Tuesday, August 30, 2016 11:18:59 AM CEST Krzysztof Kozlowski wrote:
> Samsung mach/soc update for v4.9:
> 1. Fix for DMA on S3C24xx. This was probably broken for long time, nobody runs
>this code... till now.

Good to know. This reminds me that the s3c24xx DMA code is one of those
that need to be converted to dma_slave_map at some point. Maybe if someone
is now running that code, they could give that a try as well?

It shouldn't be hard to convert, let me know if you need more information.

> 2. After fixes from Matthew Leach and Ben Dooks, most of our mach code
>and drivers is now endian-safe. Mark the platform as supporting big endian.
> 3. Cleanups.
> 
> 

Pulled into next/soc, thanks!

Arnd

Re: [PATCH v2 2/2] arm64: dts: Fix broken architected timer interrupt trigger

[Arnd Bergmann]

On Monday, August 1, 2016 7:00:50 PM CEST Masahiro Yamada wrote:
> > Acked-by: Duc Dang 
> > Acked-by: Carlo Caione 
> > Acked-by: Michal Simek 
> > Acked-by: Krzysztof Kozlowski 
> > Acked-by: Dinh Nguyen 
> > Signed-off-by: Marc Zyngier 
> > ---
> >  arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi| 8 
> >  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 8 
> >  arch/arm64/boot/dts/apm/apm-storm.dtsi   | 8 
> >  arch/arm64/boot/dts/broadcom/ns2.dtsi| 8 
> >  arch/arm64/boot/dts/cavium/thunder-88xx.dtsi | 8 
> >  arch/arm64/boot/dts/exynos/exynos7.dtsi  | 8 
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi   | 8 
> >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi   | 8 
> >  arch/arm64/boot/dts/marvell/armada-ap806.dtsi| 8 
> >  arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 8 
> 
> 
> For uniphier-ph1-ld20.dtsi,
> 
> Acked-by: Masahiro Yamada 
> 
> 

Applied to the fixes branch for 4.8, thanks

Arnd

Re: [PATCH v2 2/2] arm64: dts: Fix broken architected timer interrupt trigger

[Arnd Bergmann]

On Monday, August 1, 2016 7:00:50 PM CEST Masahiro Yamada wrote:
> > Acked-by: Duc Dang 
> > Acked-by: Carlo Caione 
> > Acked-by: Michal Simek 
> > Acked-by: Krzysztof Kozlowski 
> > Acked-by: Dinh Nguyen 
> > Signed-off-by: Marc Zyngier 
> > ---
> >  arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi| 8 
> >  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 8 
> >  arch/arm64/boot/dts/apm/apm-storm.dtsi   | 8 
> >  arch/arm64/boot/dts/broadcom/ns2.dtsi| 8 
> >  arch/arm64/boot/dts/cavium/thunder-88xx.dtsi | 8 
> >  arch/arm64/boot/dts/exynos/exynos7.dtsi  | 8 
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi   | 8 
> >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi   | 8 
> >  arch/arm64/boot/dts/marvell/armada-ap806.dtsi| 8 
> >  arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 8 
> 
> 
> For uniphier-ph1-ld20.dtsi,
> 
> Acked-by: Masahiro Yamada 
> 
> 

Applied to the fixes branch for 4.8, thanks

Arnd

Re: [PATCH 11/12] power: reset: Add Intel PIIX4 poweroff driver

[Sebastian Reichel]

Hi Paul,

The driver looks fine to me, just two notes:

On Fri, Sep 02, 2016 at 04:48:57PM +0100, Paul Burton wrote:
> Add a driver which allows powering off the system via an Intel PIIX4
> southbridge, by entering the PIIX4 SOff state. This is useful on the
> MIPS Malta development board, where it will power down the FPGA based
> board until its ON/NMI button is pressed, or the QEMU implementation of
> the MIPS Malta board where it will cause QEMU to exit.
> 
> Signed-off-by: Paul Burton 
> ---
> 
>  drivers/power/reset/Kconfig  |   9 +++
>  drivers/power/reset/Makefile |   1 +
>  drivers/power/reset/piix4-poweroff.c | 103 
> +++
>  3 files changed, 113 insertions(+)
>  create mode 100644 drivers/power/reset/piix4-poweroff.c
> 
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index c74c3f6..b27ca50 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -104,6 +104,15 @@ config POWER_RESET_MSM
>   help
> Power off and restart support for Qualcomm boards.
>  
> +config POWER_RESET_PIIX4_POWEROFF
> + tristate "Intel PIIX4 power-off driver"
> + depends on MIPS && PCI

depends on PCI
depends on MIPS || COMPILE_TEST

> + help
> +   This driver supports powering off a system using the Intel PIIX4
> +   southbridge, for example the MIPS Malta development board. The
> +   southbridge SOff state is entered in response to a request to
> +   power off the system.
> +
>  config POWER_RESET_LTC2952
>   bool "LTC2952 PowerPath power-off driver"
>   depends on OF_GPIO
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 1be307c..11dae3b 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
>  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
>  obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
>  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> +obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
>  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
>  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
>  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
> diff --git a/drivers/power/reset/piix4-poweroff.c 
> b/drivers/power/reset/piix4-poweroff.c
> new file mode 100644
> index 000..bfa8bea
> --- /dev/null
> +++ b/drivers/power/reset/piix4-poweroff.c

[...]

> +
> +module_pci_driver(piix4_poweroff_driver);
> +MODULE_AUTHOR("Paul Burton ");

missing MODULE_LICENSE()

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

[Bjorn Helgaas]

On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner wrote:
> On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote:
> > People reported that they can not do a poweroff nor a
> > suspend to ram on their Mac Pro 11. After some investigations
> > it was found that, once the PCI bridge :00:1c.0 reassigns its
> > mm windows to ([mem 0x7fa0-0x7fbf] and
> > [mem 0x7fc0-0x7fdf 64bit pref]), the region of ACPI
> > io resource 0x1804 becomes unaccessible immediately, where the
> > ACPI Sleep register is located, as a result neither poweroff(S5)
> > nor suspend to ram(S3) works.
> 
> To provide a bit more context:
> 
> The root port in question (:00:1c.0) is not listed in the DSDT.
> On macOS, only devices present in the ACPI namespace are incorporated
> into the I/O Kit registry. Consequently macOS pretends that this root
> port doesn't exist. It's not listed in the "ioreg -l" output and thus
> no driver is attached to this device.
> 
> So what we're dealing with is sloppiness on the part of Apple:
> Some engineer probably forgot to disable this unused root port
> and they didn't notice it during testing because their OS ignores
> such devices.
> 
> We could in principle achieve the same behaviour by adding a PCI
> device only if it has an ACPI companion, perhaps quirk this only
> to Macs. I'm not sure if that's the right thing to do though.
> What if they hide devices from macOS but we want to access them
> on Linux?
> 
> What's really odd is that changing *memory* windows affects
> accessibility of *I/O ports*.
> 
> One theory would be that I/O ports are somehow mapped into memory.
> The GPIO pins of Intel chipsets are usually accessible through
> I/O ports, but I've recently looked at the DSDT of the newest
> MacBook9,1 (2016) and it looks like they're now accessed through
> SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> about these intricacies of their chipsets.

Hey, look, Chen Yu works at Intel :)

This apparent connection between memory windows and I/O port
accessibility is indeed very concerning.

I know there are PCI host bridges with windows that translate CPU
memory accesses into PCI I/O port accesses.  If this is one of them,
and it has such a window enabled at the address we happened to choose
for the mem window, that would be a problem.

I assume this would be documented somewhere in the chipset datasheet.

> If I/O ports are indeed mapped into memory, we need to find a way
> to identify and reserve that region. So while this patch seems
> like a workable and sufficiently small fix, it might mask a larger
> underlying issue. It's certainly a problem though that these
> machines currently cannot power off or suspend.
> 
> FWIW, we have a somewhat similar issue with the Apple gmux
> (a microcontroller built into dual GPU MacBook Pros). That chip
> is attached to the LPC bus and accessed through I/O ports.
> It turns out that once VGA IO is locked to the discrete GPU
> using vgaarb, gmux' I/O ports suddenly become inaccessible.
> Apparently its I/O ports are routed to the secondary PCI bus
> to which the discrete GPU is connected, and no longer to the
> root bus on which the LPC bridge resides. However gmux' I/O ports
> are in the 0x700-0x7ff range, whereas the VGA registers are in
> the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
> of Intel chipsets with regards to I/O accessibility.
> 
> Best regards,
> 
> Lukas
> 
> > 
> > As suggested by Bjorn, further testing shows that, there is an
> > unreported device may be (using) conflict with above aperture,
> > which brings unpredictable result such as the failure of accessing
> > the io port, which blocks the poweroff(S5). Besides if we reassign
> > the memory aperture to the other place, the poweroff works again.
> > 
> > As we do not find any resource declared in _CRS which contain above
> > memory aperture, and Mac OS does not use this pci bridge neither, we
> > choose a simple workaround to clear the hotplug flag(suggested by
> > Yinghai Lu), thus do not allocate any resource for this pci bridge,
> > and thereby no conflict anymore.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
> > Cc: Bjorn Helgaas 
> > Cc: Rafael J. Wysocki 
> > Cc: Lukas Wunner 
> > Signed-off-by: Chen Yu 
> > ---
> >  drivers/pci/quirks.c | 20 
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 37ff015..04bbdba 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -2776,6 +2776,26 @@ static void quirk_hotplug_bridge(struct pci_dev *dev)
> >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020, quirk_hotplug_bridge);
> >  
> >  /*
> > + * Apple: Avoid programming the memory/io aperture of 00:1c.0
> > + *
> > + * BIOS does not declare any resource for 00:1c.0, but with
> > + * hotplug flag set, thus the OS allocates:

Re: [PATCH 11/12] power: reset: Add Intel PIIX4 poweroff driver

[Sebastian Reichel]

Hi Paul,

The driver looks fine to me, just two notes:

On Fri, Sep 02, 2016 at 04:48:57PM +0100, Paul Burton wrote:
> Add a driver which allows powering off the system via an Intel PIIX4
> southbridge, by entering the PIIX4 SOff state. This is useful on the
> MIPS Malta development board, where it will power down the FPGA based
> board until its ON/NMI button is pressed, or the QEMU implementation of
> the MIPS Malta board where it will cause QEMU to exit.
> 
> Signed-off-by: Paul Burton 
> ---
> 
>  drivers/power/reset/Kconfig  |   9 +++
>  drivers/power/reset/Makefile |   1 +
>  drivers/power/reset/piix4-poweroff.c | 103 
> +++
>  3 files changed, 113 insertions(+)
>  create mode 100644 drivers/power/reset/piix4-poweroff.c
> 
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index c74c3f6..b27ca50 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -104,6 +104,15 @@ config POWER_RESET_MSM
>   help
> Power off and restart support for Qualcomm boards.
>  
> +config POWER_RESET_PIIX4_POWEROFF
> + tristate "Intel PIIX4 power-off driver"
> + depends on MIPS && PCI

depends on PCI
depends on MIPS || COMPILE_TEST

> + help
> +   This driver supports powering off a system using the Intel PIIX4
> +   southbridge, for example the MIPS Malta development board. The
> +   southbridge SOff state is entered in response to a request to
> +   power off the system.
> +
>  config POWER_RESET_LTC2952
>   bool "LTC2952 PowerPath power-off driver"
>   depends on OF_GPIO
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 1be307c..11dae3b 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
>  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
>  obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
>  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> +obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
>  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
>  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
>  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
> diff --git a/drivers/power/reset/piix4-poweroff.c 
> b/drivers/power/reset/piix4-poweroff.c
> new file mode 100644
> index 000..bfa8bea
> --- /dev/null
> +++ b/drivers/power/reset/piix4-poweroff.c

[...]

> +
> +module_pci_driver(piix4_poweroff_driver);
> +MODULE_AUTHOR("Paul Burton ");

missing MODULE_LICENSE()

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

[Bjorn Helgaas]

On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner wrote:
> On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote:
> > People reported that they can not do a poweroff nor a
> > suspend to ram on their Mac Pro 11. After some investigations
> > it was found that, once the PCI bridge :00:1c.0 reassigns its
> > mm windows to ([mem 0x7fa0-0x7fbf] and
> > [mem 0x7fc0-0x7fdf 64bit pref]), the region of ACPI
> > io resource 0x1804 becomes unaccessible immediately, where the
> > ACPI Sleep register is located, as a result neither poweroff(S5)
> > nor suspend to ram(S3) works.
> 
> To provide a bit more context:
> 
> The root port in question (:00:1c.0) is not listed in the DSDT.
> On macOS, only devices present in the ACPI namespace are incorporated
> into the I/O Kit registry. Consequently macOS pretends that this root
> port doesn't exist. It's not listed in the "ioreg -l" output and thus
> no driver is attached to this device.
> 
> So what we're dealing with is sloppiness on the part of Apple:
> Some engineer probably forgot to disable this unused root port
> and they didn't notice it during testing because their OS ignores
> such devices.
> 
> We could in principle achieve the same behaviour by adding a PCI
> device only if it has an ACPI companion, perhaps quirk this only
> to Macs. I'm not sure if that's the right thing to do though.
> What if they hide devices from macOS but we want to access them
> on Linux?
> 
> What's really odd is that changing *memory* windows affects
> accessibility of *I/O ports*.
> 
> One theory would be that I/O ports are somehow mapped into memory.
> The GPIO pins of Intel chipsets are usually accessible through
> I/O ports, but I've recently looked at the DSDT of the newest
> MacBook9,1 (2016) and it looks like they're now accessed through
> SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> about these intricacies of their chipsets.

Hey, look, Chen Yu works at Intel :)

This apparent connection between memory windows and I/O port
accessibility is indeed very concerning.

I know there are PCI host bridges with windows that translate CPU
memory accesses into PCI I/O port accesses.  If this is one of them,
and it has such a window enabled at the address we happened to choose
for the mem window, that would be a problem.

I assume this would be documented somewhere in the chipset datasheet.

> If I/O ports are indeed mapped into memory, we need to find a way
> to identify and reserve that region. So while this patch seems
> like a workable and sufficiently small fix, it might mask a larger
> underlying issue. It's certainly a problem though that these
> machines currently cannot power off or suspend.
> 
> FWIW, we have a somewhat similar issue with the Apple gmux
> (a microcontroller built into dual GPU MacBook Pros). That chip
> is attached to the LPC bus and accessed through I/O ports.
> It turns out that once VGA IO is locked to the discrete GPU
> using vgaarb, gmux' I/O ports suddenly become inaccessible.
> Apparently its I/O ports are routed to the secondary PCI bus
> to which the discrete GPU is connected, and no longer to the
> root bus on which the LPC bridge resides. However gmux' I/O ports
> are in the 0x700-0x7ff range, whereas the VGA registers are in
> the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
> of Intel chipsets with regards to I/O accessibility.
> 
> Best regards,
> 
> Lukas
> 
> > 
> > As suggested by Bjorn, further testing shows that, there is an
> > unreported device may be (using) conflict with above aperture,
> > which brings unpredictable result such as the failure of accessing
> > the io port, which blocks the poweroff(S5). Besides if we reassign
> > the memory aperture to the other place, the poweroff works again.
> > 
> > As we do not find any resource declared in _CRS which contain above
> > memory aperture, and Mac OS does not use this pci bridge neither, we
> > choose a simple workaround to clear the hotplug flag(suggested by
> > Yinghai Lu), thus do not allocate any resource for this pci bridge,
> > and thereby no conflict anymore.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
> > Cc: Bjorn Helgaas 
> > Cc: Rafael J. Wysocki 
> > Cc: Lukas Wunner 
> > Signed-off-by: Chen Yu 
> > ---
> >  drivers/pci/quirks.c | 20 
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 37ff015..04bbdba 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -2776,6 +2776,26 @@ static void quirk_hotplug_bridge(struct pci_dev *dev)
> >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020, quirk_hotplug_bridge);
> >  
> >  /*
> > + * Apple: Avoid programming the memory/io aperture of 00:1c.0
> > + *
> > + * BIOS does not declare any resource for 00:1c.0, but with
> > + * hotplug flag set, thus the OS allocates:
> > + * [mem 0x7fa0 - 0x7fbf]
> > + * [mem 0x7fc0-0x7fdf 64bit 

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Luiz Capitulino]

On Fri, 2 Sep 2016 09:43:01 -0400
Stefan Hajnoczi  wrote:

> On Wed, Aug 31, 2016 at 01:05:45PM -0400, Luiz Capitulino wrote:
> > We need to retrieve a VM's TSC offset in order to use
> > the host's TSC to merge host and guest traces. This is
> > explained in detail in this thread:
> > 
> >   [Qemu-devel] [RFC] host and guest kernel trace merging
> >   https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html
> > 
> > Today, the only way to retrieve a VM's TSC offset is
> > by using the kvm_write_tsc_offset tracepoint. This has
> > a few problems. First, the tracepoint is only emitted
> > when the VM boots, which requires a reboot to get it if
> > the VM is already running. Second, tracepoints are not
> > supposed to be ABIs in case they need to be consumed by
> > user-space tools.
> > 
> > This commit exports a VM's TSC offset to user-space via
> > debugfs. A new file called "tsc-offset" is created in
> > the VM's debugfs directory. For example:
> > 
> >   /sys/kernel/debug/kvm/51696-10/tsc-offset
> > 
> > This file contains one TSC offset per line, for each
> > vCPU. For example:
> > 
> >   vcpu0: 18446742405270834952
> >   vcpu1: 18446742405270834952
> >   vcpu2: 18446742405270834952
> >   vcpu3: 18446742405270834952
> > 
> > There are some important observations about this
> > solution:
> > 
> >  - While all vCPUs TSC offsets should be equal for the
> >cases we care about (ie. stable TSC and no write to
> >the TSC MSR), I chose to follow the spec and export
> >each vCPU's TSC offset (might also be helpful for
> >debugging)
> > 
> >  - The TSC offset is only useful after the VM has booted
> > 
> >  - We'll probably need to export the TSC multiplier too.
> >However, I've been using only the TSC offset for now.
> >So, let's get this merged first and do the TSC multiplier
> >as a second step  
> 
> Can TSC offset changes occur at runtime?

Yes. IIRC, if the system has an unstable TSC, KVM will adjust the
TSC offset when migrating the vCPU to other cores (although
tracing with unstable TSC is not supported). Also, the guest can
write to the TSC MSR at any time (although I don't know if Linux
ever does this).

> One example is vcpu hotplug where the tracing tool would need to fetch
> the new vcpu's TSC offset after tracing has already started.
> 
> Another example is if QEMU or the guest change the TSC offset while
> running.  If the tracing tool doesn't notice this then trace events will have
> incorrect timestamps.

I guess that what tools like trace-cmd want to do in those cases
is to warn the user and discard the trace. A simple way of doing
this would be to re-check that the TSC offset are the same after
tracing is done. It could also use inotify, in case it works
for debugfs (never tried it myself).

Re: [PATCH 4/4] kvm: x86: export TSC offset to user-space

[Luiz Capitulino]

On Fri, 2 Sep 2016 09:43:01 -0400
Stefan Hajnoczi  wrote:

> On Wed, Aug 31, 2016 at 01:05:45PM -0400, Luiz Capitulino wrote:
> > We need to retrieve a VM's TSC offset in order to use
> > the host's TSC to merge host and guest traces. This is
> > explained in detail in this thread:
> > 
> >   [Qemu-devel] [RFC] host and guest kernel trace merging
> >   https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html
> > 
> > Today, the only way to retrieve a VM's TSC offset is
> > by using the kvm_write_tsc_offset tracepoint. This has
> > a few problems. First, the tracepoint is only emitted
> > when the VM boots, which requires a reboot to get it if
> > the VM is already running. Second, tracepoints are not
> > supposed to be ABIs in case they need to be consumed by
> > user-space tools.
> > 
> > This commit exports a VM's TSC offset to user-space via
> > debugfs. A new file called "tsc-offset" is created in
> > the VM's debugfs directory. For example:
> > 
> >   /sys/kernel/debug/kvm/51696-10/tsc-offset
> > 
> > This file contains one TSC offset per line, for each
> > vCPU. For example:
> > 
> >   vcpu0: 18446742405270834952
> >   vcpu1: 18446742405270834952
> >   vcpu2: 18446742405270834952
> >   vcpu3: 18446742405270834952
> > 
> > There are some important observations about this
> > solution:
> > 
> >  - While all vCPUs TSC offsets should be equal for the
> >cases we care about (ie. stable TSC and no write to
> >the TSC MSR), I chose to follow the spec and export
> >each vCPU's TSC offset (might also be helpful for
> >debugging)
> > 
> >  - The TSC offset is only useful after the VM has booted
> > 
> >  - We'll probably need to export the TSC multiplier too.
> >However, I've been using only the TSC offset for now.
> >So, let's get this merged first and do the TSC multiplier
> >as a second step  
> 
> Can TSC offset changes occur at runtime?

Yes. IIRC, if the system has an unstable TSC, KVM will adjust the
TSC offset when migrating the vCPU to other cores (although
tracing with unstable TSC is not supported). Also, the guest can
write to the TSC MSR at any time (although I don't know if Linux
ever does this).

> One example is vcpu hotplug where the tracing tool would need to fetch
> the new vcpu's TSC offset after tracing has already started.
> 
> Another example is if QEMU or the guest change the TSC offset while
> running.  If the tracing tool doesn't notice this then trace events will have
> incorrect timestamps.

I guess that what tools like trace-cmd want to do in those cases
is to warn the user and discard the trace. A simple way of doing
this would be to re-check that the TSC offset are the same after
tracing is done. It could also use inotify, in case it works
for debugfs (never tried it myself).

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

[Kalle Valo]

Bjorn Andersson  writes:

> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> channel, as such it should be a SMD client. This patch makes this
> transition, now that we have the necessary frameworks available.
>
> Signed-off-by: Bjorn Andersson 

[...]

> --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
> +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
> @@ -1,6 +1,6 @@
>  config WCN36XX
>   tristate "Qualcomm Atheros WCN3660/3680 support"
> - depends on MAC80211 && HAS_DMA
> + depends on MAC80211 && HAS_DMA && QCOM_SMD

While I had this patch on my pending branch I noticed that I can't
compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
example then it's easy to miss mac80211 API changes etc. Is there any
way we could continue build testing wcn36xx on x86 (or all) platforms?

Also what about older platforms? Earlier I used wcn36xx on my Nexus 4
with help of backports project. I can't do that anymore, right?

-- 
Kalle Valo

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Grygorii Strashko]

On 09/02/2016 02:08 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Russell King - ARM Linux  writes:
>> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:

 Hi Felipe and Arnd,

 It has been a while since the last response to this discussion, but we
 haven't reached an agreement yet!  Can we get to a conclusion on if it
 is valid to create child platform device for abstraction purpose?  If
 yes, can this child device do DMA by itself?
>>>
>>> I'd say it's no problem for a driver to create child devices in order
>>> to represent different aspects of a device, but you should not rely on
>>> those devices working when used with the dma-mapping interfaces.
>>
>> That's absolutely right.  Consider the USB model - only the USB host
>> controller can perform DMA, not the USB devices themselves.  All DMA
>> mappings need to be mapped using the USB host controller device struct
>> not the USB device struct.
>>
>> The same _should_ be true everywhere else: the struct device representing
>> the device performing DMA must be the one used to map the transfer.
> 
> How do we fix dwc3 in dual-role, then?
> 
> Peripheral-side dwc3 is easy, we just require a glue-layer to be present
> and use dwc3.ko's parent device (which will be the PCI device or OF
> device). But for host side dwc3, the problem is slightly more complex
> because we're using xhci-plat.ko by just instantiating a xhci-platform
> device so xhci-plat can probe.
> 
> xhci core has no means to know if its own device or the parent of its
> parent should be used for DMA. Any ideas?
> 

Wouldn't be possible to use dma_mask for such purposes?
Like, case 1:
 dwc3-omap (dma_mask=X) -> dwc3 (dma_mask = NULL) -> xhci-plat (NULL)
and then it might be possible to find proper parent by traversing DD
hierarchy.

or :
dwc3 (dma_mask = X) -> xhci-plat (NULL)

or :
xhci-plat (dma_mask = X)

of course, it might be needed to skip DMA configuration for devices
which parents have been configured for dma already (easy for xhci-plat,
but can be not easy for dwc3).

just thinking..

Also, I'd like to note that problem become more complex when scsi layer is used
on top USB ;(

-- 
regards,
-grygorii

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

[Kalle Valo]

Bjorn Andersson  writes:

> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> channel, as such it should be a SMD client. This patch makes this
> transition, now that we have the necessary frameworks available.
>
> Signed-off-by: Bjorn Andersson 

[...]

> --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
> +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
> @@ -1,6 +1,6 @@
>  config WCN36XX
>   tristate "Qualcomm Atheros WCN3660/3680 support"
> - depends on MAC80211 && HAS_DMA
> + depends on MAC80211 && HAS_DMA && QCOM_SMD

While I had this patch on my pending branch I noticed that I can't
compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
example then it's easy to miss mac80211 API changes etc. Is there any
way we could continue build testing wcn36xx on x86 (or all) platforms?

Also what about older platforms? Earlier I used wcn36xx on my Nexus 4
with help of backports project. I can't do that anymore, right?

-- 
Kalle Valo

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Grygorii Strashko]

On 09/02/2016 02:08 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Russell King - ARM Linux  writes:
>> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:

 Hi Felipe and Arnd,

 It has been a while since the last response to this discussion, but we
 haven't reached an agreement yet!  Can we get to a conclusion on if it
 is valid to create child platform device for abstraction purpose?  If
 yes, can this child device do DMA by itself?
>>>
>>> I'd say it's no problem for a driver to create child devices in order
>>> to represent different aspects of a device, but you should not rely on
>>> those devices working when used with the dma-mapping interfaces.
>>
>> That's absolutely right.  Consider the USB model - only the USB host
>> controller can perform DMA, not the USB devices themselves.  All DMA
>> mappings need to be mapped using the USB host controller device struct
>> not the USB device struct.
>>
>> The same _should_ be true everywhere else: the struct device representing
>> the device performing DMA must be the one used to map the transfer.
> 
> How do we fix dwc3 in dual-role, then?
> 
> Peripheral-side dwc3 is easy, we just require a glue-layer to be present
> and use dwc3.ko's parent device (which will be the PCI device or OF
> device). But for host side dwc3, the problem is slightly more complex
> because we're using xhci-plat.ko by just instantiating a xhci-platform
> device so xhci-plat can probe.
> 
> xhci core has no means to know if its own device or the parent of its
> parent should be used for DMA. Any ideas?
> 

Wouldn't be possible to use dma_mask for such purposes?
Like, case 1:
 dwc3-omap (dma_mask=X) -> dwc3 (dma_mask = NULL) -> xhci-plat (NULL)
and then it might be possible to find proper parent by traversing DD
hierarchy.

or :
dwc3 (dma_mask = X) -> xhci-plat (NULL)

or :
xhci-plat (dma_mask = X)

of course, it might be needed to skip DMA configuration for devices
which parents have been configured for dma already (easy for xhci-plat,
but can be not easy for dwc3).

just thinking..

Also, I'd like to note that problem become more complex when scsi layer is used
on top USB ;(

-- 
regards,
-grygorii

Re: [PATCH v2 1/6] rtl8723au: remove declaration of unimplemented functions

[Kalle Valo]

Luca Ceresoli  writes:

> These functions have been declared without any implementation since
> the first commit (364e30ebd2dbaccba430c603da03e68746eb932a) and there
> has been no mention of them in following commits.
>
> Signed-off-by: Luca Ceresoli 
> Cc: Larry Finger 
> Cc: Jes Sorensen 
> Cc: Greg Kroah-Hartman 
> Cc: linux-wirel...@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
>
> Changes v1 -> v2:
> - improve the commit message.
> ---
>  drivers/staging/rtl8723au/include/recv_osdep.h | 3 ---
>  1 file changed, 3 deletions(-)

Please prefix staging drivers with "staging:".

-- 
Kalle Valo

Re: [PATCH v2 1/6] rtl8723au: remove declaration of unimplemented functions

[Kalle Valo]

Luca Ceresoli  writes:

> These functions have been declared without any implementation since
> the first commit (364e30ebd2dbaccba430c603da03e68746eb932a) and there
> has been no mention of them in following commits.
>
> Signed-off-by: Luca Ceresoli 
> Cc: Larry Finger 
> Cc: Jes Sorensen 
> Cc: Greg Kroah-Hartman 
> Cc: linux-wirel...@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
>
> Changes v1 -> v2:
> - improve the commit message.
> ---
>  drivers/staging/rtl8723au/include/recv_osdep.h | 3 ---
>  1 file changed, 3 deletions(-)

Please prefix staging drivers with "staging:".

-- 
Kalle Valo

[tip:irq/core] irqdomain: Mask irq type in irq_domain_xlate_onetwocell()

[tip-bot for Sebastian Frias]

Commit-ID:  0c228919e04ddec195402296e7ebf2472ed6caef
Gitweb: http://git.kernel.org/tip/0c228919e04ddec195402296e7ebf2472ed6caef
Author: Sebastian Frias 
AuthorDate: Tue, 2 Aug 2016 10:52:45 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:50 +0200

irqdomain: Mask irq type in irq_domain_xlate_onetwocell()

According to the xlate() callback definition, the 'out_type' parameter
needs to be the "linux irq type".

A mask for such bits exists, IRQ_TYPE_SENSE_MASK, which is correctly
applied in irq_domain_xlate_twocell()

So use it for irq_domain_xlate_onetwocell() as well.

Signed-off-by: Sebastian Frias 
Cc: Grant Likely 
Cc: Marc Zyngier 
Cc: Mason 
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/57a05f5d@laposte.net
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/irqdomain.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 4752b43..f10cffe 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -868,7 +868,10 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d,
if (WARN_ON(intsize < 1))
return -EINVAL;
*out_hwirq = intspec[0];
-   *out_type = (intsize > 1) ? intspec[1] : IRQ_TYPE_NONE;
+   if (intsize > 1)
+   *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
+   else
+   *out_type = IRQ_TYPE_NONE;
return 0;
 }
 EXPORT_SYMBOL_GPL(irq_domain_xlate_onetwocell);

[tip:irq/core] genirq/generic_chip: Verify irqs_per_chip <= 32

[tip-bot for Sebastian Frias]

Commit-ID:  895d3b95ed05f72a94f69ab52cb313915a6b889f
Gitweb: http://git.kernel.org/tip/895d3b95ed05f72a94f69ab52cb313915a6b889f
Author: Sebastian Frias 
AuthorDate: Tue, 16 Aug 2016 16:05:08 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:50 +0200

genirq/generic_chip: Verify irqs_per_chip <= 32

Most (if not all) code here implicitly assumes that the maximum number of
IRQs per chip will be 32, and thus uses 'u32' or 'unsigned long' for many
tasks (for example "struct irq_data" declares its 'mask' field as 'u32',
and "struct irq_chip_generic" declares its 'installed' field as 'unsigned
long')

However, there is no check to verify that irqs_per_chip is <= 32.  Hence,
calling irq_alloc_domain_generic_chips() with a bigger value will result in
unexpected results.

Provide a wrapper with a MAYBE_BUILD_BUG_ON(nrirqs >= 32) to catch such
cases.

[ tglx: Reduced changelog to the essential information ]

Signed-off-by: Sebastian Frias 
Cc: Marc Zyngier 
Cc: Mason 
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/57b31d94.5040...@laposte.net
Signed-off-by: Thomas Gleixner 

---
 include/linux/irq.h   | 18 +-
 kernel/irq/generic-chip.c | 16 
 2 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index b52424e..9a96860 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -916,12 +916,20 @@ void irq_remove_generic_chip(struct irq_chip_generic *gc, 
u32 msk,
 unsigned int clr, unsigned int set);
 
 struct irq_chip_generic *irq_get_domain_generic_chip(struct irq_domain *d, 
unsigned int hw_irq);
-int irq_alloc_domain_generic_chips(struct irq_domain *d, int irqs_per_chip,
-  int num_ct, const char *name,
-  irq_flow_handler_t handler,
-  unsigned int clr, unsigned int set,
-  enum irq_gc_flags flags);
 
+int __irq_alloc_domain_generic_chips(struct irq_domain *d, int irqs_per_chip,
+int num_ct, const char *name,
+irq_flow_handler_t handler,
+unsigned int clr, unsigned int set,
+enum irq_gc_flags flags);
+
+#define irq_alloc_domain_generic_chips(d, irqs_per_chip, num_ct, name, \
+  handler, clr, set, flags)\
+({ \
+   MAYBE_BUILD_BUG_ON(irqs_per_chip > 32); \
+   __irq_alloc_domain_generic_chips(d, irqs_per_chip, num_ct,  \
+handler, clr, set, flags); \
+})
 
 static inline struct irq_chip_type *irq_data_get_chip_type(struct irq_data *d)
 {
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index a3a3920..ee32870 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -260,9 +260,9 @@ irq_gc_init_mask_cache(struct irq_chip_generic *gc, enum 
irq_gc_flags flags)
 }
 
 /**
- * irq_alloc_domain_generic_chip - Allocate generic chips for an irq domain
+ * __irq_alloc_domain_generic_chip - Allocate generic chips for an irq domain
  * @d: irq domain for which to allocate chips
- * @irqs_per_chip: Number of interrupts each chip handles
+ * @irqs_per_chip: Number of interrupts each chip handles (max 32)
  * @num_ct:Number of irq_chip_type instances associated with this
  * @name:  Name of the irq chip
  * @handler:   Default flow handler associated with these chips
@@ -270,11 +270,11 @@ irq_gc_init_mask_cache(struct irq_chip_generic *gc, enum 
irq_gc_flags flags)
  * @set:   IRQ_* bits to set in the mapping function
  * @gcflags:   Generic chip specific setup flags
  */
-int irq_alloc_domain_generic_chips(struct irq_domain *d, int irqs_per_chip,
-  int num_ct, const char *name,
-  irq_flow_handler_t handler,
-  unsigned int clr, unsigned int set,
-  enum irq_gc_flags gcflags)
+int __irq_alloc_domain_generic_chips(struct irq_domain *d, int irqs_per_chip,
+int num_ct, const char *name,
+irq_flow_handler_t handler,
+unsigned int clr, unsigned int set,
+enum irq_gc_flags gcflags)
 {
struct irq_domain_chip_generic *dgc;
struct irq_chip_generic *gc;
@@ -326,7 +326,7 @@ int irq_alloc_domain_generic_chips(struct irq_domain *d, 
int irqs_per_chip,
d->name = name;
return 0;
 }

[tip:irq/core] irqdomain: Mask irq type in irq_domain_xlate_onetwocell()

[tip-bot for Sebastian Frias]

Commit-ID:  0c228919e04ddec195402296e7ebf2472ed6caef
Gitweb: http://git.kernel.org/tip/0c228919e04ddec195402296e7ebf2472ed6caef
Author: Sebastian Frias 
AuthorDate: Tue, 2 Aug 2016 10:52:45 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:50 +0200

irqdomain: Mask irq type in irq_domain_xlate_onetwocell()

According to the xlate() callback definition, the 'out_type' parameter
needs to be the "linux irq type".

A mask for such bits exists, IRQ_TYPE_SENSE_MASK, which is correctly
applied in irq_domain_xlate_twocell()

So use it for irq_domain_xlate_onetwocell() as well.

Signed-off-by: Sebastian Frias 
Cc: Grant Likely 
Cc: Marc Zyngier 
Cc: Mason 
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/57a05f5d@laposte.net
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/irqdomain.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 4752b43..f10cffe 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -868,7 +868,10 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d,
if (WARN_ON(intsize < 1))
return -EINVAL;
*out_hwirq = intspec[0];
-   *out_type = (intsize > 1) ? intspec[1] : IRQ_TYPE_NONE;
+   if (intsize > 1)
+   *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
+   else
+   *out_type = IRQ_TYPE_NONE;
return 0;
 }
 EXPORT_SYMBOL_GPL(irq_domain_xlate_onetwocell);

[tip:irq/core] genirq/generic_chip: Verify irqs_per_chip <= 32

[tip-bot for Sebastian Frias]

Commit-ID:  895d3b95ed05f72a94f69ab52cb313915a6b889f
Gitweb: http://git.kernel.org/tip/895d3b95ed05f72a94f69ab52cb313915a6b889f
Author: Sebastian Frias 
AuthorDate: Tue, 16 Aug 2016 16:05:08 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:50 +0200

genirq/generic_chip: Verify irqs_per_chip <= 32

Most (if not all) code here implicitly assumes that the maximum number of
IRQs per chip will be 32, and thus uses 'u32' or 'unsigned long' for many
tasks (for example "struct irq_data" declares its 'mask' field as 'u32',
and "struct irq_chip_generic" declares its 'installed' field as 'unsigned
long')

However, there is no check to verify that irqs_per_chip is <= 32.  Hence,
calling irq_alloc_domain_generic_chips() with a bigger value will result in
unexpected results.

Provide a wrapper with a MAYBE_BUILD_BUG_ON(nrirqs >= 32) to catch such
cases.

[ tglx: Reduced changelog to the essential information ]

Signed-off-by: Sebastian Frias 
Cc: Marc Zyngier 
Cc: Mason 
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/57b31d94.5040...@laposte.net
Signed-off-by: Thomas Gleixner 

---
 include/linux/irq.h   | 18 +-
 kernel/irq/generic-chip.c | 16 
 2 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index b52424e..9a96860 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -916,12 +916,20 @@ void irq_remove_generic_chip(struct irq_chip_generic *gc, 
u32 msk,
 unsigned int clr, unsigned int set);
 
 struct irq_chip_generic *irq_get_domain_generic_chip(struct irq_domain *d, 
unsigned int hw_irq);
-int irq_alloc_domain_generic_chips(struct irq_domain *d, int irqs_per_chip,
-  int num_ct, const char *name,
-  irq_flow_handler_t handler,
-  unsigned int clr, unsigned int set,
-  enum irq_gc_flags flags);
 
+int __irq_alloc_domain_generic_chips(struct irq_domain *d, int irqs_per_chip,
+int num_ct, const char *name,
+irq_flow_handler_t handler,
+unsigned int clr, unsigned int set,
+enum irq_gc_flags flags);
+
+#define irq_alloc_domain_generic_chips(d, irqs_per_chip, num_ct, name, \
+  handler, clr, set, flags)\
+({ \
+   MAYBE_BUILD_BUG_ON(irqs_per_chip > 32); \
+   __irq_alloc_domain_generic_chips(d, irqs_per_chip, num_ct,  \
+handler, clr, set, flags); \
+})
 
 static inline struct irq_chip_type *irq_data_get_chip_type(struct irq_data *d)
 {
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index a3a3920..ee32870 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -260,9 +260,9 @@ irq_gc_init_mask_cache(struct irq_chip_generic *gc, enum 
irq_gc_flags flags)
 }
 
 /**
- * irq_alloc_domain_generic_chip - Allocate generic chips for an irq domain
+ * __irq_alloc_domain_generic_chip - Allocate generic chips for an irq domain
  * @d: irq domain for which to allocate chips
- * @irqs_per_chip: Number of interrupts each chip handles
+ * @irqs_per_chip: Number of interrupts each chip handles (max 32)
  * @num_ct:Number of irq_chip_type instances associated with this
  * @name:  Name of the irq chip
  * @handler:   Default flow handler associated with these chips
@@ -270,11 +270,11 @@ irq_gc_init_mask_cache(struct irq_chip_generic *gc, enum 
irq_gc_flags flags)
  * @set:   IRQ_* bits to set in the mapping function
  * @gcflags:   Generic chip specific setup flags
  */
-int irq_alloc_domain_generic_chips(struct irq_domain *d, int irqs_per_chip,
-  int num_ct, const char *name,
-  irq_flow_handler_t handler,
-  unsigned int clr, unsigned int set,
-  enum irq_gc_flags gcflags)
+int __irq_alloc_domain_generic_chips(struct irq_domain *d, int irqs_per_chip,
+int num_ct, const char *name,
+irq_flow_handler_t handler,
+unsigned int clr, unsigned int set,
+enum irq_gc_flags gcflags)
 {
struct irq_domain_chip_generic *dgc;
struct irq_chip_generic *gc;
@@ -326,7 +326,7 @@ int irq_alloc_domain_generic_chips(struct irq_domain *d, 
int irqs_per_chip,
d->name = name;
return 0;
 }
-EXPORT_SYMBOL_GPL(irq_alloc_domain_generic_chips);
+EXPORT_SYMBOL_GPL(__irq_alloc_domain_generic_chips);
 
 static struct irq_chip_generic *
 

Re: [PATCH] fs/proc/kcore.c: Omit kernel text area for hardened usercopy feature

[Jiri Olsa]

On Fri, Sep 02, 2016 at 08:17:13AM -0700, Andi Kleen wrote:
> On Fri, Sep 02, 2016 at 02:25:45PM +0200, Jiri Olsa wrote:
> > One of the bullets for hardened usercopy feature is:
> >   - object must not overlap with kernel text
> > 
> > which is what we expose via /proc/kcore. We can hit
> > this check and crash the system very easily just by
> > reading the text area in kcore file:
> > 
> >   usercopy: kernel memory exposure attempt detected from 8179a01f 
> > () (4065 bytes)
> >   kernel BUG at mm/usercopy.c:75!
> > 
> > Omitting kernel text area from kcore when there's
> > hardened usercopy feature is enabled.
> 
> That will completely break PT decoding, which relies on looking
> at the kernel text in /proc/kcore.
> 
> Need a different fix here, perhaps some special copy function
> that is not hardened.

ok, I'll try to come up with something

thanks,
jirka

[tip:irq/core] genirq/generic_chip: Add irq_unmap callback

[tip-bot for Sebastian Frias]

Commit-ID:  ee26c013cdee0b947e29d6cadfb9ff3341c69ff9
Gitweb: http://git.kernel.org/tip/ee26c013cdee0b947e29d6cadfb9ff3341c69ff9
Author: Sebastian Frias 
AuthorDate: Mon, 1 Aug 2016 16:27:38 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:49 +0200

genirq/generic_chip: Add irq_unmap callback

Without this patch irq_domain_disassociate() cannot properly release the
interrupt. In fact, irq_map_generic_chip() checks a bit on 'gc->installed'
but said bit is never cleared, only set.

Commit 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
added irq_map_generic_chip() function and also stated "This lacks a removal
function for now".

This commit provides an implementation of an unmap function that can be
called by irq_domain_disassociate().

[ tglx: Made the function static and removed the export as we have neither
a prototype nor a modular user. ]

Fixes: 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
Signed-off-by: Sebastian Frias 
Cc: Marc Zyngier 
Cc: Mason 
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/579f5c5a.2070...@laposte.net
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/generic-chip.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index 11ad73b..a3a3920 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -414,8 +414,29 @@ int irq_map_generic_chip(struct irq_domain *d, unsigned 
int virq,
return 0;
 }
 
+static void irq_unmap_generic_chip(struct irq_domain *d, unsigned int virq)
+{
+   struct irq_data *data = irq_domain_get_irq_data(d, virq);
+   struct irq_domain_chip_generic *dgc = d->gc;
+   unsigned int hw_irq = data->hwirq;
+   struct irq_chip_generic *gc;
+   int irq_idx;
+
+   gc = irq_get_domain_generic_chip(d, hw_irq);
+   if (!gc)
+   return;
+
+   irq_idx = hw_irq % dgc->irqs_per_chip;
+
+   clear_bit(irq_idx, >installed);
+   irq_domain_set_info(d, virq, hw_irq, _irq_chip, NULL, NULL, NULL,
+   NULL);
+
+}
+
 struct irq_domain_ops irq_generic_chip_ops = {
.map= irq_map_generic_chip,
+   .unmap  = irq_unmap_generic_chip,
.xlate  = irq_domain_xlate_onetwocell,
 };
 EXPORT_SYMBOL_GPL(irq_generic_chip_ops);

Re: [PATCH] fs/proc/kcore.c: Omit kernel text area for hardened usercopy feature

[Jiri Olsa]

On Fri, Sep 02, 2016 at 08:17:13AM -0700, Andi Kleen wrote:
> On Fri, Sep 02, 2016 at 02:25:45PM +0200, Jiri Olsa wrote:
> > One of the bullets for hardened usercopy feature is:
> >   - object must not overlap with kernel text
> > 
> > which is what we expose via /proc/kcore. We can hit
> > this check and crash the system very easily just by
> > reading the text area in kcore file:
> > 
> >   usercopy: kernel memory exposure attempt detected from 8179a01f 
> > () (4065 bytes)
> >   kernel BUG at mm/usercopy.c:75!
> > 
> > Omitting kernel text area from kcore when there's
> > hardened usercopy feature is enabled.
> 
> That will completely break PT decoding, which relies on looking
> at the kernel text in /proc/kcore.
> 
> Need a different fix here, perhaps some special copy function
> that is not hardened.

ok, I'll try to come up with something

thanks,
jirka

[tip:irq/core] genirq/generic_chip: Add irq_unmap callback

[tip-bot for Sebastian Frias]

Commit-ID:  ee26c013cdee0b947e29d6cadfb9ff3341c69ff9
Gitweb: http://git.kernel.org/tip/ee26c013cdee0b947e29d6cadfb9ff3341c69ff9
Author: Sebastian Frias 
AuthorDate: Mon, 1 Aug 2016 16:27:38 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:49 +0200

genirq/generic_chip: Add irq_unmap callback

Without this patch irq_domain_disassociate() cannot properly release the
interrupt. In fact, irq_map_generic_chip() checks a bit on 'gc->installed'
but said bit is never cleared, only set.

Commit 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
added irq_map_generic_chip() function and also stated "This lacks a removal
function for now".

This commit provides an implementation of an unmap function that can be
called by irq_domain_disassociate().

[ tglx: Made the function static and removed the export as we have neither
a prototype nor a modular user. ]

Fixes: 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
Signed-off-by: Sebastian Frias 
Cc: Marc Zyngier 
Cc: Mason 
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/579f5c5a.2070...@laposte.net
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/generic-chip.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index 11ad73b..a3a3920 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -414,8 +414,29 @@ int irq_map_generic_chip(struct irq_domain *d, unsigned 
int virq,
return 0;
 }
 
+static void irq_unmap_generic_chip(struct irq_domain *d, unsigned int virq)
+{
+   struct irq_data *data = irq_domain_get_irq_data(d, virq);
+   struct irq_domain_chip_generic *dgc = d->gc;
+   unsigned int hw_irq = data->hwirq;
+   struct irq_chip_generic *gc;
+   int irq_idx;
+
+   gc = irq_get_domain_generic_chip(d, hw_irq);
+   if (!gc)
+   return;
+
+   irq_idx = hw_irq % dgc->irqs_per_chip;
+
+   clear_bit(irq_idx, >installed);
+   irq_domain_set_info(d, virq, hw_irq, _irq_chip, NULL, NULL, NULL,
+   NULL);
+
+}
+
 struct irq_domain_ops irq_generic_chip_ops = {
.map= irq_map_generic_chip,
+   .unmap  = irq_unmap_generic_chip,
.xlate  = irq_domain_xlate_onetwocell,
 };
 EXPORT_SYMBOL_GPL(irq_generic_chip_ops);

[tip:irq/core] genirq/generic_chip: Get rid of code duplication

[tip-bot for Sebastian Frias]

Commit-ID:  f0c450eaa364cb77c778f2a46ee2aa3ff464b332
Gitweb: http://git.kernel.org/tip/f0c450eaa364cb77c778f2a46ee2aa3ff464b332
Author: Sebastian Frias 
AuthorDate: Mon, 1 Aug 2016 16:27:53 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:49 +0200

genirq/generic_chip: Get rid of code duplication

irq_map_generic_chip() contains about the same code as
irq_get_domain_generic_chip() except for the return values.

Split out the irq_get_domain_generic_chip() implementation so it can be
reused.

[ tglx: Removed the extra churn in irq_get_domain_generic_chip() callers
and massaged changelog ]

Signed-off-by: Sebastian Frias 
Cc: Marc Zyngier 
Cc: Mason 
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/579f5c69.8070...@laposte.net
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/generic-chip.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index 5fbb94b..11ad73b 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -328,6 +328,20 @@ int irq_alloc_domain_generic_chips(struct irq_domain *d, 
int irqs_per_chip,
 }
 EXPORT_SYMBOL_GPL(irq_alloc_domain_generic_chips);
 
+static struct irq_chip_generic *
+__irq_get_domain_generic_chip(struct irq_domain *d, unsigned int hw_irq)
+{
+   struct irq_domain_chip_generic *dgc = d->gc;
+   int idx;
+
+   if (!dgc)
+   return ERR_PTR(-ENODEV);
+   idx = hw_irq / dgc->irqs_per_chip;
+   if (idx >= dgc->num_chips)
+   return ERR_PTR(-EINVAL);
+   return dgc->gc[idx];
+}
+
 /**
  * irq_get_domain_generic_chip - Get a pointer to the generic chip of a hw_irq
  * @d: irq domain pointer
@@ -336,15 +350,9 @@ EXPORT_SYMBOL_GPL(irq_alloc_domain_generic_chips);
 struct irq_chip_generic *
 irq_get_domain_generic_chip(struct irq_domain *d, unsigned int hw_irq)
 {
-   struct irq_domain_chip_generic *dgc = d->gc;
-   int idx;
+   struct irq_chip_generic *gc = __irq_get_domain_generic_chip(d, hw_irq);
 
-   if (!dgc)
-   return NULL;
-   idx = hw_irq / dgc->irqs_per_chip;
-   if (idx >= dgc->num_chips)
-   return NULL;
-   return dgc->gc[idx];
+   return !IS_ERR(gc) ? gc : NULL;
 }
 EXPORT_SYMBOL_GPL(irq_get_domain_generic_chip);
 
@@ -368,13 +376,9 @@ int irq_map_generic_chip(struct irq_domain *d, unsigned 
int virq,
unsigned long flags;
int idx;
 
-   if (!d->gc)
-   return -ENODEV;
-
-   idx = hw_irq / dgc->irqs_per_chip;
-   if (idx >= dgc->num_chips)
-   return -EINVAL;
-   gc = dgc->gc[idx];
+   gc = __irq_get_domain_generic_chip(d, hw_irq);
+   if (IS_ERR(gc))
+   return PTR_ERR(gc);
 
idx = hw_irq % dgc->irqs_per_chip;
 

[tip:irq/core] genirq/generic_chip: Get rid of code duplication

[tip-bot for Sebastian Frias]

Commit-ID:  f0c450eaa364cb77c778f2a46ee2aa3ff464b332
Gitweb: http://git.kernel.org/tip/f0c450eaa364cb77c778f2a46ee2aa3ff464b332
Author: Sebastian Frias 
AuthorDate: Mon, 1 Aug 2016 16:27:53 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:49 +0200

genirq/generic_chip: Get rid of code duplication

irq_map_generic_chip() contains about the same code as
irq_get_domain_generic_chip() except for the return values.

Split out the irq_get_domain_generic_chip() implementation so it can be
reused.

[ tglx: Removed the extra churn in irq_get_domain_generic_chip() callers
and massaged changelog ]

Signed-off-by: Sebastian Frias 
Cc: Marc Zyngier 
Cc: Mason 
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/579f5c69.8070...@laposte.net
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/generic-chip.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index 5fbb94b..11ad73b 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -328,6 +328,20 @@ int irq_alloc_domain_generic_chips(struct irq_domain *d, 
int irqs_per_chip,
 }
 EXPORT_SYMBOL_GPL(irq_alloc_domain_generic_chips);
 
+static struct irq_chip_generic *
+__irq_get_domain_generic_chip(struct irq_domain *d, unsigned int hw_irq)
+{
+   struct irq_domain_chip_generic *dgc = d->gc;
+   int idx;
+
+   if (!dgc)
+   return ERR_PTR(-ENODEV);
+   idx = hw_irq / dgc->irqs_per_chip;
+   if (idx >= dgc->num_chips)
+   return ERR_PTR(-EINVAL);
+   return dgc->gc[idx];
+}
+
 /**
  * irq_get_domain_generic_chip - Get a pointer to the generic chip of a hw_irq
  * @d: irq domain pointer
@@ -336,15 +350,9 @@ EXPORT_SYMBOL_GPL(irq_alloc_domain_generic_chips);
 struct irq_chip_generic *
 irq_get_domain_generic_chip(struct irq_domain *d, unsigned int hw_irq)
 {
-   struct irq_domain_chip_generic *dgc = d->gc;
-   int idx;
+   struct irq_chip_generic *gc = __irq_get_domain_generic_chip(d, hw_irq);
 
-   if (!dgc)
-   return NULL;
-   idx = hw_irq / dgc->irqs_per_chip;
-   if (idx >= dgc->num_chips)
-   return NULL;
-   return dgc->gc[idx];
+   return !IS_ERR(gc) ? gc : NULL;
 }
 EXPORT_SYMBOL_GPL(irq_get_domain_generic_chip);
 
@@ -368,13 +376,9 @@ int irq_map_generic_chip(struct irq_domain *d, unsigned 
int virq,
unsigned long flags;
int idx;
 
-   if (!d->gc)
-   return -ENODEV;
-
-   idx = hw_irq / dgc->irqs_per_chip;
-   if (idx >= dgc->num_chips)
-   return -EINVAL;
-   gc = dgc->gc[idx];
+   gc = __irq_get_domain_generic_chip(d, hw_irq);
+   if (IS_ERR(gc))
+   return PTR_ERR(gc);
 
idx = hw_irq % dgc->irqs_per_chip;
 

[tip:irq/core] genirq: Robustify handle_percpu_devid_irq()

[tip-bot for Thomas Gleixner]

Commit-ID:  fc590c22f9f056ab50190b797f6cacead29f9b75
Gitweb: http://git.kernel.org/tip/fc590c22f9f056ab50190b797f6cacead29f9b75
Author: Thomas Gleixner 
AuthorDate: Fri, 2 Sep 2016 14:45:19 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:49 +0200

genirq: Robustify handle_percpu_devid_irq()

The percpu_devid handler is not robust against spurious interrupts. If a
spurious interrupt happens and no action is installed then the handler
crashes with a NULL pointer dereference.

Add a sanity check for this and log the wreckage once in dmesg.

Reported-by: Majun 
Signed-off-by: Thomas Gleixner 
Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: guohan...@huawei.com
Cc: dingtianh...@huawei.com
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1609021436160.5647@nanos

---
 kernel/irq/chip.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index b4c1bc7..93c373a 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -756,7 +756,6 @@ void handle_percpu_devid_irq(struct irq_desc *desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irqaction *action = desc->action;
-   void *dev_id = raw_cpu_ptr(action->percpu_dev_id);
unsigned int irq = irq_desc_get_irq(desc);
irqreturn_t res;
 
@@ -765,9 +764,20 @@ void handle_percpu_devid_irq(struct irq_desc *desc)
if (chip->irq_ack)
chip->irq_ack(>irq_data);
 
-   trace_irq_handler_entry(irq, action);
-   res = action->handler(irq, dev_id);
-   trace_irq_handler_exit(irq, action, res);
+   if (likely(action)) {
+   trace_irq_handler_entry(irq, action);
+   res = action->handler(irq, raw_cpu_ptr(action->percpu_dev_id));
+   trace_irq_handler_exit(irq, action, res);
+   } else {
+   unsigned int cpu = smp_processor_id();
+   bool enabled = cpumask_test_cpu(cpu, desc->percpu_enabled);
+
+   if (enabled)
+   irq_percpu_disable(desc, cpu);
+
+   pr_err_once("Spurious%s percpu IRQ%u on CPU%u\n",
+   enabled ? " and unmasked" : "", irq, cpu);
+   }
 
if (chip->irq_eoi)
chip->irq_eoi(>irq_data);

[tip:irq/core] genirq: Robustify handle_percpu_devid_irq()

[tip-bot for Thomas Gleixner]

Commit-ID:  fc590c22f9f056ab50190b797f6cacead29f9b75
Gitweb: http://git.kernel.org/tip/fc590c22f9f056ab50190b797f6cacead29f9b75
Author: Thomas Gleixner 
AuthorDate: Fri, 2 Sep 2016 14:45:19 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Sep 2016 18:06:49 +0200

genirq: Robustify handle_percpu_devid_irq()

The percpu_devid handler is not robust against spurious interrupts. If a
spurious interrupt happens and no action is installed then the handler
crashes with a NULL pointer dereference.

Add a sanity check for this and log the wreckage once in dmesg.

Reported-by: Majun 
Signed-off-by: Thomas Gleixner 
Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: guohan...@huawei.com
Cc: dingtianh...@huawei.com
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1609021436160.5647@nanos

---
 kernel/irq/chip.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index b4c1bc7..93c373a 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -756,7 +756,6 @@ void handle_percpu_devid_irq(struct irq_desc *desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irqaction *action = desc->action;
-   void *dev_id = raw_cpu_ptr(action->percpu_dev_id);
unsigned int irq = irq_desc_get_irq(desc);
irqreturn_t res;
 
@@ -765,9 +764,20 @@ void handle_percpu_devid_irq(struct irq_desc *desc)
if (chip->irq_ack)
chip->irq_ack(>irq_data);
 
-   trace_irq_handler_entry(irq, action);
-   res = action->handler(irq, dev_id);
-   trace_irq_handler_exit(irq, action, res);
+   if (likely(action)) {
+   trace_irq_handler_entry(irq, action);
+   res = action->handler(irq, raw_cpu_ptr(action->percpu_dev_id));
+   trace_irq_handler_exit(irq, action, res);
+   } else {
+   unsigned int cpu = smp_processor_id();
+   bool enabled = cpumask_test_cpu(cpu, desc->percpu_enabled);
+
+   if (enabled)
+   irq_percpu_disable(desc, cpu);
+
+   pr_err_once("Spurious%s percpu IRQ%u on CPU%u\n",
+   enabled ? " and unmasked" : "", irq, cpu);
+   }
 
if (chip->irq_eoi)
chip->irq_eoi(>irq_data);

Re: [PATCH 1/4] Documentation: mmc: sdhci-of-arasan: Add clk_syscon as an optional one

[Doug Anderson]

Rob,

On Fri, Sep 2, 2016 at 7:15 AM, Rob Herring  wrote:
> On Mon, Aug 29, 2016 at 04:02:56PM +0800, Shawn Lin wrote:
>> We introduced soc-ctl-syscon to do several things, for instance, update
>> baseclk or update clkmul, etc. In odrder to access this physical block,
>> we need to explicitly enable its clock. Currently we don't control this
>> clock as we always add a CLK_IGNORE_UNUSED flag for it to indicate that
>> we will not gate it even if not referenced. This is not a correct way since
>> it is a clock parenting from clk_ahb which is used by sdhci-of-arasan now.
>> Without enabling clk_ahb, the flag don't guarantee we could access
>> soc-ctl-syscon. Moreover, we can't find a reason not to gate clk_syscon
>> once we remove/power-down emmc controller. So let's add clk_syscon and
>> enable/disable it explicitly when needed.
>>
>> Signed-off-by: Shawn Lin 
>>
>> ---
>>
>>  Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
>> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> index 3404afa..b04eb02 100644
>> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> @@ -33,6 +33,9 @@ Optional Properties:
>>- clock-output-names: If specified, this will be the name of the card 
>> clock
>>  which will be exposed by this device.  Required if #clock-cells is
>>  specified.
>> +  - clock-names: From clock bindings: Although we treat clock-names as 
>> required
>> +property, there is still one, "clk_syscon", should be optional as it 
>> depends
>> +on whether we need to control soc-ctl-syscon or not.
>
> No. This doesn't look right to me. The syscon is a separate block
> and the clock for it belongs in the syscon node itself. Probably there
> needs to be some sort of ref counting in the syscon so it can do
> runtime-pm.

I'm not an expert, but one thing to note is that this is actually a
separate clock just for this small part of the GRF (general register
files).  Yeah, it's bizarre.

Said another way, the GRF is a sorta hodgepodge location for all sorts
of stuff.  ...included in there are the "corecfg" registers that are
used by the SDHCI IP block.  Within the GRF register space these
registers are 0x0f000 - 0x0f050 (last register is at 0x0f04c).  I
believe that only registers in that special range need this clock.

Maybe the right answer is that we should actually have had a sub-node
of the GRF for these registers and then SDHCI should have referenced
that as its syscon?

-Doug

Re: [PATCH 1/4] Documentation: mmc: sdhci-of-arasan: Add clk_syscon as an optional one

[Doug Anderson]

Rob,

On Fri, Sep 2, 2016 at 7:15 AM, Rob Herring  wrote:
> On Mon, Aug 29, 2016 at 04:02:56PM +0800, Shawn Lin wrote:
>> We introduced soc-ctl-syscon to do several things, for instance, update
>> baseclk or update clkmul, etc. In odrder to access this physical block,
>> we need to explicitly enable its clock. Currently we don't control this
>> clock as we always add a CLK_IGNORE_UNUSED flag for it to indicate that
>> we will not gate it even if not referenced. This is not a correct way since
>> it is a clock parenting from clk_ahb which is used by sdhci-of-arasan now.
>> Without enabling clk_ahb, the flag don't guarantee we could access
>> soc-ctl-syscon. Moreover, we can't find a reason not to gate clk_syscon
>> once we remove/power-down emmc controller. So let's add clk_syscon and
>> enable/disable it explicitly when needed.
>>
>> Signed-off-by: Shawn Lin 
>>
>> ---
>>
>>  Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
>> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> index 3404afa..b04eb02 100644
>> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> @@ -33,6 +33,9 @@ Optional Properties:
>>- clock-output-names: If specified, this will be the name of the card 
>> clock
>>  which will be exposed by this device.  Required if #clock-cells is
>>  specified.
>> +  - clock-names: From clock bindings: Although we treat clock-names as 
>> required
>> +property, there is still one, "clk_syscon", should be optional as it 
>> depends
>> +on whether we need to control soc-ctl-syscon or not.
>
> No. This doesn't look right to me. The syscon is a separate block
> and the clock for it belongs in the syscon node itself. Probably there
> needs to be some sort of ref counting in the syscon so it can do
> runtime-pm.

I'm not an expert, but one thing to note is that this is actually a
separate clock just for this small part of the GRF (general register
files).  Yeah, it's bizarre.

Said another way, the GRF is a sorta hodgepodge location for all sorts
of stuff.  ...included in there are the "corecfg" registers that are
used by the SDHCI IP block.  Within the GRF register space these
registers are 0x0f000 - 0x0f050 (last register is at 0x0f04c).  I
believe that only registers in that special range need this clock.

Maybe the right answer is that we should actually have had a sub-node
of the GRF for these registers and then SDHCI should have referenced
that as its syscon?

-Doug

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

[Andrew Lunn]

Hi Vivien

> What do you think?

I think the probe() needs to fail with a very obvious error message
saying you need to recompile your kernel with option XYZ enabled in
order to support this switch, when the optional stuff is not
optional...

Andrew

Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: make global2 code optional

[Andrew Lunn]

Hi Vivien

> What do you think?

I think the probe() needs to fail with a very obvious error message
saying you need to recompile your kernel with option XYZ enabled in
order to support this switch, when the optional stuff is not
optional...

Andrew

Re: [v2] ath9k: mark ath_fill_led_pin() static

[Kalle Valo]

Baoyou Xie  wrote:
> We get 1 warning about global functions without a declaration
> in the ath9k gpio driver when building with W=1:
> drivers/net/wireless/ath/ath9k/gpio.c:25:6: warning: no previous prototype 
> for 'ath_fill_led_pin' [-Wmissing-prototypes]
> 
> In fact, this function is only used in the file in which it is declared
> and don't need a declaration, but can be made static.
> so this patch marks it 'static'.
> 
> Signed-off-by: Baoyou Xie 

Thanks, 1 patch applied to ath-next branch of ath.git:

c39265f72ae6 ath9k: mark ath_fill_led_pin() static

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9303795/

Re: [v2] ath9k: mark ath_fill_led_pin() static

[Kalle Valo]

Baoyou Xie  wrote:
> We get 1 warning about global functions without a declaration
> in the ath9k gpio driver when building with W=1:
> drivers/net/wireless/ath/ath9k/gpio.c:25:6: warning: no previous prototype 
> for 'ath_fill_led_pin' [-Wmissing-prototypes]
> 
> In fact, this function is only used in the file in which it is declared
> and don't need a declaration, but can be made static.
> so this patch marks it 'static'.
> 
> Signed-off-by: Baoyou Xie 

Thanks, 1 patch applied to ath-next branch of ath.git:

c39265f72ae6 ath9k: mark ath_fill_led_pin() static

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9303795/

Re: [PATCHv2] pwm: lpc-18xx: use pwm_set_chip_data

[Ariel D'Alessandro]

Hi Olliver,

On 08/25/2016 01:47 PM, Olliver Schinagl wrote:
> The lpc18xx driver currently manipulates the pwm_device struct directly
> rather then using the pwm_set_chip_data. While the current method may
> save a clock cycle or two, it is more obvious that data is set to
> the local chip data pointer.
> 
> Signed-off-by: Olliver Schinagl 
Reviewed-by: Ariel D'Alessandro 

> ---
> Hi,
> 
> This is a resend of a patch-series I sent last year. There was no technical
> related feedback and so I am re-sending the patch as is. I did rebase it to
> Linus's current master.
> 
> Changes since v1:
>   - removed wrongfully added sun4i patch
>   - split patch series into a single patch
>   - added author
> 
>  drivers/pwm/pwm-lpc18xx-sct.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
> index 19dc64c..a630fc5 100644
> --- a/drivers/pwm/pwm-lpc18xx-sct.c
> +++ b/drivers/pwm/pwm-lpc18xx-sct.c
> @@ -413,14 +413,17 @@ static int lpc18xx_pwm_probe(struct platform_device 
> *pdev)
>   }
>  
>   for (i = 0; i < lpc18xx_pwm->chip.npwm; i++) {
> + struct lpc18xx_pwm_data *lpc18xx_data;
> +
>   pwm = _pwm->chip.pwms[i];
> - pwm->chip_data = devm_kzalloc(lpc18xx_pwm->dev,
> -   sizeof(struct lpc18xx_pwm_data),
> -   GFP_KERNEL);
> - if (!pwm->chip_data) {
> + lpc18xx_data = devm_kzalloc(lpc18xx_pwm->dev,
> + sizeof(struct lpc18xx_pwm_data),
> + GFP_KERNEL);
> + if (!lpc18xx_data) {
>   ret = -ENOMEM;
>   goto remove_pwmchip;
>   }
> + pwm_set_chip_data(pwm, lpc18xx_data);
>   }
>  
>   platform_set_drvdata(pdev, lpc18xx_pwm);
> 

-- 
Ariel D'Alessandro, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCHv2] pwm: lpc-18xx: use pwm_set_chip_data

[Ariel D'Alessandro]

Hi Olliver,

On 08/25/2016 01:47 PM, Olliver Schinagl wrote:
> The lpc18xx driver currently manipulates the pwm_device struct directly
> rather then using the pwm_set_chip_data. While the current method may
> save a clock cycle or two, it is more obvious that data is set to
> the local chip data pointer.
> 
> Signed-off-by: Olliver Schinagl 
Reviewed-by: Ariel D'Alessandro 

> ---
> Hi,
> 
> This is a resend of a patch-series I sent last year. There was no technical
> related feedback and so I am re-sending the patch as is. I did rebase it to
> Linus's current master.
> 
> Changes since v1:
>   - removed wrongfully added sun4i patch
>   - split patch series into a single patch
>   - added author
> 
>  drivers/pwm/pwm-lpc18xx-sct.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
> index 19dc64c..a630fc5 100644
> --- a/drivers/pwm/pwm-lpc18xx-sct.c
> +++ b/drivers/pwm/pwm-lpc18xx-sct.c
> @@ -413,14 +413,17 @@ static int lpc18xx_pwm_probe(struct platform_device 
> *pdev)
>   }
>  
>   for (i = 0; i < lpc18xx_pwm->chip.npwm; i++) {
> + struct lpc18xx_pwm_data *lpc18xx_data;
> +
>   pwm = _pwm->chip.pwms[i];
> - pwm->chip_data = devm_kzalloc(lpc18xx_pwm->dev,
> -   sizeof(struct lpc18xx_pwm_data),
> -   GFP_KERNEL);
> - if (!pwm->chip_data) {
> + lpc18xx_data = devm_kzalloc(lpc18xx_pwm->dev,
> + sizeof(struct lpc18xx_pwm_data),
> + GFP_KERNEL);
> + if (!lpc18xx_data) {
>   ret = -ENOMEM;
>   goto remove_pwmchip;
>   }
> + pwm_set_chip_data(pwm, lpc18xx_data);
>   }
>  
>   platform_set_drvdata(pdev, lpc18xx_pwm);
> 

-- 
Ariel D'Alessandro, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH 2/2] arm64: Use static keys for CPU features

[Suzuki K Poulose]

On 02/09/16 16:52, Catalin Marinas wrote:

On Fri, Aug 26, 2016 at 10:22:13AM +0100, Suzuki K. Poulose wrote:

On 25/08/16 18:26, Catalin Marinas wrote:




Just a heads up. I have a patch [1] which moves the "check_local_cpu_errata()"
around to smp_prepare_boot_cpu(). This patch should still work fine with that
case. Only that may be we could move the jump_lable_init() to 
smp_prepare_boot_cpu(),
before we call "update_cpu_errata_work_arounds()" for Boot CPU.


IIUC, we wouldn't call update_cpu_errata_work_arounds() until the CPU
feature infrastructure is initialised via cpuinfo_store_boot_cpu(). So
I don't think moving the jump_label_init() call above is necessary.


Right, as I said, your patch should work fine even with that change. Its just 
that,
jump_label_init() (a generic kernel setup) can be called from a better visible
place (smp_prepare_boot_cpu()) than from a less interesting place with the patch
below.

Cheers
Suzuki





[1] 
https://lkml.kernel.org/r/1471525832-21209-4-git-send-email-suzuki.poul...@arm.com

Re: [PATCH 2/2] arm64: Use static keys for CPU features

[Suzuki K Poulose]

On 02/09/16 16:52, Catalin Marinas wrote:

On Fri, Aug 26, 2016 at 10:22:13AM +0100, Suzuki K. Poulose wrote:

On 25/08/16 18:26, Catalin Marinas wrote:




Just a heads up. I have a patch [1] which moves the "check_local_cpu_errata()"
around to smp_prepare_boot_cpu(). This patch should still work fine with that
case. Only that may be we could move the jump_lable_init() to 
smp_prepare_boot_cpu(),
before we call "update_cpu_errata_work_arounds()" for Boot CPU.


IIUC, we wouldn't call update_cpu_errata_work_arounds() until the CPU
feature infrastructure is initialised via cpuinfo_store_boot_cpu(). So
I don't think moving the jump_label_init() call above is necessary.


Right, as I said, your patch should work fine even with that change. Its just 
that,
jump_label_init() (a generic kernel setup) can be called from a better visible
place (smp_prepare_boot_cpu()) than from a less interesting place with the patch
below.

Cheers
Suzuki





[1] 
https://lkml.kernel.org/r/1471525832-21209-4-git-send-email-suzuki.poul...@arm.com

Re: [PATCH 2/4] KVM: x86: initialize kvmclock_offset

[Roman Kagan]

On Thu, Sep 01, 2016 at 05:26:13PM +0200, Paolo Bonzini wrote:
> Make the guest's kvmclock count up from zero, not from the host boot
> time.  The guest cannot rely on that anyway because it changes on
> migration, the numbers are easier on the eye and finally it matches the
> desired semantics of the Hyper-V time reference counter.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/x86.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Roman Kagan 

Re: [PATCH 2/4] KVM: x86: initialize kvmclock_offset

[Roman Kagan]

On Thu, Sep 01, 2016 at 05:26:13PM +0200, Paolo Bonzini wrote:
> Make the guest's kvmclock count up from zero, not from the host boot
> time.  The guest cannot rely on that anyway because it changes on
> migration, the numbers are easier on the eye and finally it matches the
> desired semantics of the Hyper-V time reference counter.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/x86.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Roman Kagan