Re: [PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information

[Lokesh Vutla]

On Thursday 10 August 2017 05:30 AM, Rob Herring wrote:
> On Tue, Aug 01, 2017 at 10:11:14AM +0530, Lokesh Vutla wrote:
>> Update ti,edma binding documentation to reflect 66AK2G specific
>> properties.
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  Documentation/devicetree/bindings/dma/ti-edma.txt | 95 
>> +--
>>  1 file changed, 90 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
>> b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> index 18090e7226b4..05fe2931d025 100644
>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> @@ -9,7 +9,12 @@ execute the actual DMA tansfer.
>>  eDMA3 Channel Controller
>>  
>>  Required properties:
>> -- compatible:   "ti,edma3-tpcc" for the channel controller(s)
>> +
>> +- compatible:   Should be:
>> +- "ti,edma3-tpcc" for the channel controller(s) on OMAP,
>> +  AM33xx and AM43xx SoCs.
>> +- "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the
> 
> If power-domains is mandatory, I don't think the fallback is 
> appropriate. Or do you expect it to work if the driver ignores the power 
> domain?

power-domains is required for pm_runtime_*() apis to work on 66AK2G.
Driver doesn't handle this property separately. Driver still works with
"ti,edma3-tpcc" compatible.

Thanks and regards,
Lokesh

Re: [PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information

[Lokesh Vutla]

On Thursday 10 August 2017 05:30 AM, Rob Herring wrote:
> On Tue, Aug 01, 2017 at 10:11:14AM +0530, Lokesh Vutla wrote:
>> Update ti,edma binding documentation to reflect 66AK2G specific
>> properties.
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  Documentation/devicetree/bindings/dma/ti-edma.txt | 95 
>> +--
>>  1 file changed, 90 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
>> b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> index 18090e7226b4..05fe2931d025 100644
>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> @@ -9,7 +9,12 @@ execute the actual DMA tansfer.
>>  eDMA3 Channel Controller
>>  
>>  Required properties:
>> -- compatible:   "ti,edma3-tpcc" for the channel controller(s)
>> +
>> +- compatible:   Should be:
>> +- "ti,edma3-tpcc" for the channel controller(s) on OMAP,
>> +  AM33xx and AM43xx SoCs.
>> +- "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the
> 
> If power-domains is mandatory, I don't think the fallback is 
> appropriate. Or do you expect it to work if the driver ignores the power 
> domain?

power-domains is required for pm_runtime_*() apis to work on 66AK2G.
Driver doesn't handle this property separately. Driver still works with
"ti,edma3-tpcc" compatible.

Thanks and regards,
Lokesh

[PATCH 1/3] bus: kconfig: Enable SUNXI RSB for arm64

[Jagan Teki]

From: Jagan Teki 

Sunxi arm64 doesn't have separate configs for
h5 and a64 so enable SUNXI_RSB bus for ARM64.

Signed-off-by: Jagan Teki 
---
 drivers/bus/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 2408ea3..ae3d8f3 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -132,7 +132,7 @@ config SIMPLE_PM_BUS
 
 config SUNXI_RSB
tristate "Allwinner sunXi Reduced Serial Bus Driver"
- default MACH_SUN8I || MACH_SUN9I
+ default MACH_SUN8I || MACH_SUN9I || ARM64
  depends on ARCH_SUNXI
  select REGMAP
  help
-- 
2.7.4

[PATCH 1/3] bus: kconfig: Enable SUNXI RSB for arm64

[Jagan Teki]

From: Jagan Teki 

Sunxi arm64 doesn't have separate configs for
h5 and a64 so enable SUNXI_RSB bus for ARM64.

Signed-off-by: Jagan Teki 
---
 drivers/bus/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 2408ea3..ae3d8f3 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -132,7 +132,7 @@ config SIMPLE_PM_BUS
 
 config SUNXI_RSB
tristate "Allwinner sunXi Reduced Serial Bus Driver"
- default MACH_SUN8I || MACH_SUN9I
+ default MACH_SUN8I || MACH_SUN9I || ARM64
  depends on ARCH_SUNXI
  select REGMAP
  help
-- 
2.7.4

[PATCH 3/3] arm64: defconfig: Enable CONFIG_REGULATOR_AXP20X

[Jagan Teki]

From: Jagan Teki 

X-POWERS AXP20X PMIC Regulators is need for sunxi a64
so make it default in defconfig.

Signed-off-by: Jagan Teki 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index a11fce7..d8f23c5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -323,6 +323,7 @@ CONFIG_MFD_MAX77620=y
 CONFIG_MFD_SPMI_PMIC=y
 CONFIG_MFD_RK808=y
 CONFIG_MFD_SEC_CORE=y
+CONFIG_REGULATOR_AXP20X=y
 CONFIG_REGULATOR_FAN53555=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_GPIO=y
-- 
2.7.4

[PATCH 2/3] arm64: defconfig: Enable CONFIG_MFD_AXP20X_RSB

[Jagan Teki]

From: Jagan Teki 

X-Powers AXP series PMICs with RSB is need for sunxi a64
so make it default in defconfig.

Signed-off-by: Jagan Teki 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 33d2d62..a11fce7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -313,6 +313,7 @@ CONFIG_MESON_GXBB_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=m
 CONFIG_RENESAS_WDT=y
 CONFIG_BCM2835_WDT=y
+CONFIG_MFD_AXP20X_RSB=y
 CONFIG_MFD_CROS_EC=y
 CONFIG_MFD_CROS_EC_I2C=y
 CONFIG_MFD_CROS_EC_SPI=y
-- 
2.7.4

[PATCH 3/3] arm64: defconfig: Enable CONFIG_REGULATOR_AXP20X

[Jagan Teki]

From: Jagan Teki 

X-POWERS AXP20X PMIC Regulators is need for sunxi a64
so make it default in defconfig.

Signed-off-by: Jagan Teki 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index a11fce7..d8f23c5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -323,6 +323,7 @@ CONFIG_MFD_MAX77620=y
 CONFIG_MFD_SPMI_PMIC=y
 CONFIG_MFD_RK808=y
 CONFIG_MFD_SEC_CORE=y
+CONFIG_REGULATOR_AXP20X=y
 CONFIG_REGULATOR_FAN53555=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_GPIO=y
-- 
2.7.4

[PATCH 2/3] arm64: defconfig: Enable CONFIG_MFD_AXP20X_RSB

[Jagan Teki]

From: Jagan Teki 

X-Powers AXP series PMICs with RSB is need for sunxi a64
so make it default in defconfig.

Signed-off-by: Jagan Teki 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 33d2d62..a11fce7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -313,6 +313,7 @@ CONFIG_MESON_GXBB_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=m
 CONFIG_RENESAS_WDT=y
 CONFIG_BCM2835_WDT=y
+CONFIG_MFD_AXP20X_RSB=y
 CONFIG_MFD_CROS_EC=y
 CONFIG_MFD_CROS_EC_I2C=y
 CONFIG_MFD_CROS_EC_SPI=y
-- 
2.7.4

[PATCH] arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Jagan Teki]

From: Jagan Teki 

Since current tree support AXP803 regulators, replace
fixed regulator with AXP803 dcdc1 regulator.

Tested on pine64.

Signed-off-by: Jagan Teki 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 122b5d8..604cdae 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -62,13 +62,6 @@
chosen {
stdout-path = "serial0:115200n8";
};
-
-   reg_vcc3v3: vcc3v3 {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc3v3";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   };
 };
 
  {
@@ -109,7 +102,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   vmmc-supply = <_vcc3v3>;
+   vmmc-supply = <_dcdc1>;
cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
cd-inverted;
disable-wp;
-- 
2.7.4

[PATCH] arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Jagan Teki]

From: Jagan Teki 

Since current tree support AXP803 regulators, replace
fixed regulator with AXP803 dcdc1 regulator.

Tested on pine64.

Signed-off-by: Jagan Teki 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 122b5d8..604cdae 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -62,13 +62,6 @@
chosen {
stdout-path = "serial0:115200n8";
};
-
-   reg_vcc3v3: vcc3v3 {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc3v3";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   };
 };
 
  {
@@ -109,7 +102,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   vmmc-supply = <_vcc3v3>;
+   vmmc-supply = <_dcdc1>;
cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
cd-inverted;
disable-wp;
-- 
2.7.4

[PATCH v5] arm64: allwinner: a64: Add initial NanoPi A64 support

[Jagan Teki]

From: Jagan Teki 

NanoPi A64 is a new board of high performance with low cost
designed by FriendlyElec., using the Allwinner A64 SOC.

Nanopi A64 features
- Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS
- 1GB DDR3 RAM
- MicroSD
- Gigabit Ethernet (RTL8211E)
- Wi-Fi 802.11b/g/n
- IR receiver
- Audio In/Out
- Video In/Out
- Serial Debug Port
- microUSB 5V 2A DC power-supply

Signed-off-by: Jagan Teki 
---
Changes for v5:
- Add AXP803 PMIC regulator support. 
Changes for v4:
- Rebased and droped wi-fi related nodes, since it require
  other changes to taken care.
Changes for v3:
- Fix to use mmc1 for SDIO instead of mmc2
- Replace buswidth by 4 instead of 8 mmc1
- Drop cap-mmc-hw-reset for mmc1
Changes for v2:
- Added ohci0, ehci0, ohic1, ehci1, usbphy.
- Tested on A64

 arch/arm64/boot/dts/allwinner/Makefile |   1 +
 .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 205 +
 2 files changed, 206 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 108f12c..c997b5c 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
new file mode 100644
index 000..de98da1
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -0,0 +1,205 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi A64";
+   compatible = "friendlyarm,nanopi-a64", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+_pins {
+   bias-pull-up;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dcdc1>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
+   cd-inverted;
+   disable-wp;
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp803: pmic@3a3 {
+   compatible = "x-powers,axp803";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   

[PATCH v5] arm64: allwinner: a64: Add initial NanoPi A64 support

[Jagan Teki]

From: Jagan Teki 

NanoPi A64 is a new board of high performance with low cost
designed by FriendlyElec., using the Allwinner A64 SOC.

Nanopi A64 features
- Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS
- 1GB DDR3 RAM
- MicroSD
- Gigabit Ethernet (RTL8211E)
- Wi-Fi 802.11b/g/n
- IR receiver
- Audio In/Out
- Video In/Out
- Serial Debug Port
- microUSB 5V 2A DC power-supply

Signed-off-by: Jagan Teki 
---
Changes for v5:
- Add AXP803 PMIC regulator support. 
Changes for v4:
- Rebased and droped wi-fi related nodes, since it require
  other changes to taken care.
Changes for v3:
- Fix to use mmc1 for SDIO instead of mmc2
- Replace buswidth by 4 instead of 8 mmc1
- Drop cap-mmc-hw-reset for mmc1
Changes for v2:
- Added ohci0, ehci0, ohic1, ehci1, usbphy.
- Tested on A64

 arch/arm64/boot/dts/allwinner/Makefile |   1 +
 .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 205 +
 2 files changed, 206 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 108f12c..c997b5c 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
new file mode 100644
index 000..de98da1
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -0,0 +1,205 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi A64";
+   compatible = "friendlyarm,nanopi-a64", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+_pins {
+   bias-pull-up;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dcdc1>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
+   cd-inverted;
+   disable-wp;
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp803: pmic@3a3 {
+   compatible = "x-powers,axp803";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   };
+};
+
+ {
+   pinctrl-names = 

[PATCH 2/3] libnvdimm, pfn, dax: show supported dax/pfn region alignments in sysfs

[Dan Williams]

From: Oliver O'Halloran 

The alignment of a DAX and PFN regions dictates the page sizes that can
be used to map the region. Even if the hardware page sizes are known the
actual range of supported page sizes that can be used with DAX depends
on the kernel configuration. As a result it's best that the kernel
advertises the alignments that should be used with these region types.

This patch adds the 'supported_alignments' region attribute to expose
this information to userspace.

Signed-off-by: Oliver O'Halloran 
[djbw: integrate with nd_size_select_show() rename and other fixups]
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/pfn_devs.c |   28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 2ae9a000b090..610dd17a17f6 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -111,6 +111,26 @@ static ssize_t align_show(struct device *dev,
return sprintf(buf, "%ld\n", nd_pfn->align);
 }
 
+static const unsigned long *nd_pfn_supported_alignments(void)
+{
+   /*
+* This needs to be a local variable because the *_SIZE macros
+* aren't always constants.
+*/
+   static const unsigned long supported_alignments[] = {
+   PAGE_SIZE,
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   HPAGE_PMD_SIZE,
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+   HPAGE_PUD_SIZE,
+#endif
+#endif
+   0,
+   };
+
+   return supported_alignments;
+}
+
 static ssize_t __align_store(struct nd_pfn *nd_pfn, const char *buf)
 {
unsigned long val;
@@ -260,6 +280,13 @@ static ssize_t size_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(size);
 
+static ssize_t supported_alignments_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   return nd_size_select_show(0, nd_pfn_supported_alignments(), buf);
+}
+static DEVICE_ATTR_RO(supported_alignments);
+
 static struct attribute *nd_pfn_attributes[] = {
_attr_mode.attr,
_attr_namespace.attr,
@@ -267,6 +294,7 @@ static struct attribute *nd_pfn_attributes[] = {
_attr_align.attr,
_attr_resource.attr,
_attr_size.attr,
+   _attr_supported_alignments.attr,
NULL,
 };
 

[PATCH 2/3] libnvdimm, pfn, dax: show supported dax/pfn region alignments in sysfs

[Dan Williams]

From: Oliver O'Halloran 

The alignment of a DAX and PFN regions dictates the page sizes that can
be used to map the region. Even if the hardware page sizes are known the
actual range of supported page sizes that can be used with DAX depends
on the kernel configuration. As a result it's best that the kernel
advertises the alignments that should be used with these region types.

This patch adds the 'supported_alignments' region attribute to expose
this information to userspace.

Signed-off-by: Oliver O'Halloran 
[djbw: integrate with nd_size_select_show() rename and other fixups]
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/pfn_devs.c |   28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 2ae9a000b090..610dd17a17f6 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -111,6 +111,26 @@ static ssize_t align_show(struct device *dev,
return sprintf(buf, "%ld\n", nd_pfn->align);
 }
 
+static const unsigned long *nd_pfn_supported_alignments(void)
+{
+   /*
+* This needs to be a local variable because the *_SIZE macros
+* aren't always constants.
+*/
+   static const unsigned long supported_alignments[] = {
+   PAGE_SIZE,
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   HPAGE_PMD_SIZE,
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+   HPAGE_PUD_SIZE,
+#endif
+#endif
+   0,
+   };
+
+   return supported_alignments;
+}
+
 static ssize_t __align_store(struct nd_pfn *nd_pfn, const char *buf)
 {
unsigned long val;
@@ -260,6 +280,13 @@ static ssize_t size_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(size);
 
+static ssize_t supported_alignments_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   return nd_size_select_show(0, nd_pfn_supported_alignments(), buf);
+}
+static DEVICE_ATTR_RO(supported_alignments);
+
 static struct attribute *nd_pfn_attributes[] = {
_attr_mode.attr,
_attr_namespace.attr,
@@ -267,6 +294,7 @@ static struct attribute *nd_pfn_attributes[] = {
_attr_align.attr,
_attr_resource.attr,
_attr_size.attr,
+   _attr_supported_alignments.attr,
NULL,
 };
 

[PATCH 3/3] libnvdimm, pfn, dax: limit namespace alignments to the supported set

[Dan Williams]

Now that we properly advertise the supported pte, pmd, and pud sizes,
restrict the supported alignments that can be set on a namespace. This
assumes that userspace was not previously relying on the ability to set
odd alignments. At least ndctl only ever supported setting the namespace
alignment to 4K, 2M, or 1G.

Cc: Oliver O'Halloran 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/pfn_devs.c |   23 ++-
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 610dd17a17f6..f447a1eb919d 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -131,26 +131,6 @@ static const unsigned long 
*nd_pfn_supported_alignments(void)
return supported_alignments;
 }
 
-static ssize_t __align_store(struct nd_pfn *nd_pfn, const char *buf)
-{
-   unsigned long val;
-   int rc;
-
-   rc = kstrtoul(buf, 0, );
-   if (rc)
-   return rc;
-
-   if (!is_power_of_2(val) || val < PAGE_SIZE || val > SZ_1G)
-   return -EINVAL;
-
-   if (nd_pfn->dev.driver)
-   return -EBUSY;
-   else
-   nd_pfn->align = val;
-
-   return 0;
-}
-
 static ssize_t align_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
 {
@@ -159,7 +139,8 @@ static ssize_t align_store(struct device *dev,
 
device_lock(dev);
nvdimm_bus_lock(dev);
-   rc = __align_store(nd_pfn, buf);
+   rc = nd_size_select_store(dev, buf, _pfn->align,
+   nd_pfn_supported_alignments());
dev_dbg(dev, "%s: result: %zd wrote: %s%s", __func__,
rc, buf, buf[len - 1] == '\n' ? "" : "\n");
nvdimm_bus_unlock(dev);

[PATCH 3/3] libnvdimm, pfn, dax: limit namespace alignments to the supported set

[Dan Williams]

Now that we properly advertise the supported pte, pmd, and pud sizes,
restrict the supported alignments that can be set on a namespace. This
assumes that userspace was not previously relying on the ability to set
odd alignments. At least ndctl only ever supported setting the namespace
alignment to 4K, 2M, or 1G.

Cc: Oliver O'Halloran 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/pfn_devs.c |   23 ++-
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 610dd17a17f6..f447a1eb919d 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -131,26 +131,6 @@ static const unsigned long 
*nd_pfn_supported_alignments(void)
return supported_alignments;
 }
 
-static ssize_t __align_store(struct nd_pfn *nd_pfn, const char *buf)
-{
-   unsigned long val;
-   int rc;
-
-   rc = kstrtoul(buf, 0, );
-   if (rc)
-   return rc;
-
-   if (!is_power_of_2(val) || val < PAGE_SIZE || val > SZ_1G)
-   return -EINVAL;
-
-   if (nd_pfn->dev.driver)
-   return -EBUSY;
-   else
-   nd_pfn->align = val;
-
-   return 0;
-}
-
 static ssize_t align_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
 {
@@ -159,7 +139,8 @@ static ssize_t align_store(struct device *dev,
 
device_lock(dev);
nvdimm_bus_lock(dev);
-   rc = __align_store(nd_pfn, buf);
+   rc = nd_size_select_store(dev, buf, _pfn->align,
+   nd_pfn_supported_alignments());
dev_dbg(dev, "%s: result: %zd wrote: %s%s", __func__,
rc, buf, buf[len - 1] == '\n' ? "" : "\n");
nvdimm_bus_unlock(dev);

[PATCH 1/3] libnvdimm: rename nd_sector_size_{show, store} to nd_size_select_{show, store}

[Dan Williams]

Prepare for other another consumer of this size selection scheme that is
not a 'sector size'.

Cc: Oliver O'Halloran 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/btt_devs.c   |4 ++--
 drivers/nvdimm/core.c   |   10 +-
 drivers/nvdimm/namespace_devs.c |6 +++---
 drivers/nvdimm/nd.h |6 +++---
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 3e359d282f8e..d58925295aa7 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -61,7 +61,7 @@ static ssize_t sector_size_show(struct device *dev,
 {
struct nd_btt *nd_btt = to_nd_btt(dev);
 
-   return nd_sector_size_show(nd_btt->lbasize, btt_lbasize_supported, buf);
+   return nd_size_select_show(nd_btt->lbasize, btt_lbasize_supported, buf);
 }
 
 static ssize_t sector_size_store(struct device *dev,
@@ -72,7 +72,7 @@ static ssize_t sector_size_store(struct device *dev,
 
device_lock(dev);
nvdimm_bus_lock(dev);
-   rc = nd_sector_size_store(dev, buf, _btt->lbasize,
+   rc = nd_size_select_store(dev, buf, _btt->lbasize,
btt_lbasize_supported);
dev_dbg(dev, "%s: result: %zd wrote: %s%s", __func__,
rc, buf, buf[len - 1] == '\n' ? "" : "\n");
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index 75bc08c6838c..bb71f0cf8f5d 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -277,14 +277,14 @@ int nd_uuid_store(struct device *dev, u8 **uuid_out, 
const char *buf,
return 0;
 }
 
-ssize_t nd_sector_size_show(unsigned long current_lbasize,
+ssize_t nd_size_select_show(unsigned long current_size,
const unsigned long *supported, char *buf)
 {
ssize_t len = 0;
int i;
 
for (i = 0; supported[i]; i++)
-   if (current_lbasize == supported[i])
+   if (current_size == supported[i])
len += sprintf(buf + len, "[%ld] ", supported[i]);
else
len += sprintf(buf + len, "%ld ", supported[i]);
@@ -292,8 +292,8 @@ ssize_t nd_sector_size_show(unsigned long current_lbasize,
return len;
 }
 
-ssize_t nd_sector_size_store(struct device *dev, const char *buf,
-   unsigned long *current_lbasize, const unsigned long *supported)
+ssize_t nd_size_select_store(struct device *dev, const char *buf,
+   unsigned long *current_size, const unsigned long *supported)
 {
unsigned long lbasize;
int rc, i;
@@ -310,7 +310,7 @@ ssize_t nd_sector_size_store(struct device *dev, const char 
*buf,
break;
 
if (supported[i]) {
-   *current_lbasize = lbasize;
+   *current_size = lbasize;
return 0;
} else {
return -EINVAL;
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 5f1c6756e57c..1427a386a033 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1313,14 +1313,14 @@ static ssize_t sector_size_show(struct device *dev,
if (is_namespace_blk(dev)) {
struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
-   return nd_sector_size_show(nsblk->lbasize,
+   return nd_size_select_show(nsblk->lbasize,
blk_lbasize_supported, buf);
}
 
if (is_namespace_pmem(dev)) {
struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
 
-   return nd_sector_size_show(nspm->lbasize,
+   return nd_size_select_show(nspm->lbasize,
pmem_lbasize_supported, buf);
}
return -ENXIO;
@@ -1352,7 +1352,7 @@ static ssize_t sector_size_store(struct device *dev,
if (to_ndns(dev)->claim)
rc = -EBUSY;
if (rc >= 0)
-   rc = nd_sector_size_store(dev, buf, lbasize, supported);
+   rc = nd_size_select_store(dev, buf, lbasize, supported);
if (rc >= 0)
rc = nd_namespace_label_update(nd_region, dev);
dev_dbg(dev, "%s: result: %zd %s: %s%s", __func__,
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index a08fc2e24fb3..251c7e6d2588 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -234,10 +234,10 @@ void nd_device_unregister(struct device *dev, enum 
nd_async_mode mode);
 void nd_device_notify(struct device *dev, enum nvdimm_event event);
 int nd_uuid_store(struct device *dev, u8 **uuid_out, const char *buf,
size_t len);
-ssize_t nd_sector_size_show(unsigned long current_lbasize,
+ssize_t nd_size_select_show(unsigned long current_size,
const unsigned long *supported, char *buf);
-ssize_t nd_sector_size_store(struct device *dev, const char *buf,
-   unsigned long *current_lbasize, const 

[PATCH 1/3] libnvdimm: rename nd_sector_size_{show, store} to nd_size_select_{show, store}

[Dan Williams]

Prepare for other another consumer of this size selection scheme that is
not a 'sector size'.

Cc: Oliver O'Halloran 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/btt_devs.c   |4 ++--
 drivers/nvdimm/core.c   |   10 +-
 drivers/nvdimm/namespace_devs.c |6 +++---
 drivers/nvdimm/nd.h |6 +++---
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 3e359d282f8e..d58925295aa7 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -61,7 +61,7 @@ static ssize_t sector_size_show(struct device *dev,
 {
struct nd_btt *nd_btt = to_nd_btt(dev);
 
-   return nd_sector_size_show(nd_btt->lbasize, btt_lbasize_supported, buf);
+   return nd_size_select_show(nd_btt->lbasize, btt_lbasize_supported, buf);
 }
 
 static ssize_t sector_size_store(struct device *dev,
@@ -72,7 +72,7 @@ static ssize_t sector_size_store(struct device *dev,
 
device_lock(dev);
nvdimm_bus_lock(dev);
-   rc = nd_sector_size_store(dev, buf, _btt->lbasize,
+   rc = nd_size_select_store(dev, buf, _btt->lbasize,
btt_lbasize_supported);
dev_dbg(dev, "%s: result: %zd wrote: %s%s", __func__,
rc, buf, buf[len - 1] == '\n' ? "" : "\n");
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index 75bc08c6838c..bb71f0cf8f5d 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -277,14 +277,14 @@ int nd_uuid_store(struct device *dev, u8 **uuid_out, 
const char *buf,
return 0;
 }
 
-ssize_t nd_sector_size_show(unsigned long current_lbasize,
+ssize_t nd_size_select_show(unsigned long current_size,
const unsigned long *supported, char *buf)
 {
ssize_t len = 0;
int i;
 
for (i = 0; supported[i]; i++)
-   if (current_lbasize == supported[i])
+   if (current_size == supported[i])
len += sprintf(buf + len, "[%ld] ", supported[i]);
else
len += sprintf(buf + len, "%ld ", supported[i]);
@@ -292,8 +292,8 @@ ssize_t nd_sector_size_show(unsigned long current_lbasize,
return len;
 }
 
-ssize_t nd_sector_size_store(struct device *dev, const char *buf,
-   unsigned long *current_lbasize, const unsigned long *supported)
+ssize_t nd_size_select_store(struct device *dev, const char *buf,
+   unsigned long *current_size, const unsigned long *supported)
 {
unsigned long lbasize;
int rc, i;
@@ -310,7 +310,7 @@ ssize_t nd_sector_size_store(struct device *dev, const char 
*buf,
break;
 
if (supported[i]) {
-   *current_lbasize = lbasize;
+   *current_size = lbasize;
return 0;
} else {
return -EINVAL;
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 5f1c6756e57c..1427a386a033 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1313,14 +1313,14 @@ static ssize_t sector_size_show(struct device *dev,
if (is_namespace_blk(dev)) {
struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
-   return nd_sector_size_show(nsblk->lbasize,
+   return nd_size_select_show(nsblk->lbasize,
blk_lbasize_supported, buf);
}
 
if (is_namespace_pmem(dev)) {
struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
 
-   return nd_sector_size_show(nspm->lbasize,
+   return nd_size_select_show(nspm->lbasize,
pmem_lbasize_supported, buf);
}
return -ENXIO;
@@ -1352,7 +1352,7 @@ static ssize_t sector_size_store(struct device *dev,
if (to_ndns(dev)->claim)
rc = -EBUSY;
if (rc >= 0)
-   rc = nd_sector_size_store(dev, buf, lbasize, supported);
+   rc = nd_size_select_store(dev, buf, lbasize, supported);
if (rc >= 0)
rc = nd_namespace_label_update(nd_region, dev);
dev_dbg(dev, "%s: result: %zd %s: %s%s", __func__,
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index a08fc2e24fb3..251c7e6d2588 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -234,10 +234,10 @@ void nd_device_unregister(struct device *dev, enum 
nd_async_mode mode);
 void nd_device_notify(struct device *dev, enum nvdimm_event event);
 int nd_uuid_store(struct device *dev, u8 **uuid_out, const char *buf,
size_t len);
-ssize_t nd_sector_size_show(unsigned long current_lbasize,
+ssize_t nd_size_select_show(unsigned long current_size,
const unsigned long *supported, char *buf);
-ssize_t nd_sector_size_store(struct device *dev, const char *buf,
-   unsigned long *current_lbasize, const unsigned long *supported);
+ssize_t 

[PATCH 0/3] libnvdimm: export supported page size alignments

[Dan Williams]

This series is a minor rework of Oliver's original patch:
https://patchwork.kernel.org/patch/9811257/

It allows userspace to discover the system huge and gigantic page sizes
for aligning devices to support larger than PAGE_SIZE mappings for dax.

---

Dan Williams (2):
  libnvdimm: rename nd_sector_size_{show,store} to 
nd_size_select_{show,store}
  libnvdimm, pfn, dax: limit namespace alignments to the supported set

Oliver O'Halloran (1):
  libnvdimm, pfn, dax: show supported dax/pfn region alignments in sysfs


 drivers/nvdimm/btt_devs.c   |4 ++--
 drivers/nvdimm/core.c   |   10 +
 drivers/nvdimm/namespace_devs.c |6 +++--
 drivers/nvdimm/nd.h |6 +++--
 drivers/nvdimm/pfn_devs.c   |   43 ---
 5 files changed, 39 insertions(+), 30 deletions(-)

[PATCH 0/3] libnvdimm: export supported page size alignments

[Dan Williams]

This series is a minor rework of Oliver's original patch:
https://patchwork.kernel.org/patch/9811257/

It allows userspace to discover the system huge and gigantic page sizes
for aligning devices to support larger than PAGE_SIZE mappings for dax.

---

Dan Williams (2):
  libnvdimm: rename nd_sector_size_{show,store} to 
nd_size_select_{show,store}
  libnvdimm, pfn, dax: limit namespace alignments to the supported set

Oliver O'Halloran (1):
  libnvdimm, pfn, dax: show supported dax/pfn region alignments in sysfs


 drivers/nvdimm/btt_devs.c   |4 ++--
 drivers/nvdimm/core.c   |   10 +
 drivers/nvdimm/namespace_devs.c |6 +++--
 drivers/nvdimm/nd.h |6 +++--
 drivers/nvdimm/pfn_devs.c   |   43 ---
 5 files changed, 39 insertions(+), 30 deletions(-)

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[Chen-Yu Tsai]

On Sat, Aug 12, 2017 at 12:51 PM,   wrote:
> 在 2017-08-12 12:04，Chen-Yu Tsai 写道：
>>
>> On Sat, Jul 22, 2017 at 11:00 AM,   wrote:
>>>
>>> 在 2017-05-29 15:34，Chen-Yu Tsai 写道：


 Hi,

 On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:
>>
>>
>> [...]
>>
> +
> +/*
> + * For the special bit in gate part, please see the BSP source code at
> + *
>
> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/clk/sunxi/clk-sun8iw11.c#L665
> + */
> +static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_sata_clk, "pll-sata",
> +   "osc24M", 0x034,
> +   8, 5,   /* N */
> +   4, 2,   /* K */
> +   0, 2,   /* M */
> +   BIT(31) | BIT(14),  /* gate */
> +   BIT(28),/* lock */
> +   0);



 I think this is a somewhat simplified approach. From what I understand
 of the user manual, the SATA clock path look like:


 [ PLL-PERIPH0-SATA ] -\
   mux @ 0x34 bit 30 --- gate @ 0x34 bit 14 --- ...
 [ PLL-SATA ] -/

 ... from above ... --\
  mux @ 0xc8 bit 24 --- gate @ 0xc8 bit 31
 [ external oscillator ] -/

 If you choose to simplify the implementation, please include a detailed
 note as to why you chose to do so, and the validity of the
 simplification.
>>>
>>>
>>>
>>> I think it can be fully implemented...
>>>
>>> But how should I call the internal clock controlled by the mux @ 0x34 bit
>>> 30?
>>
>>
>> sata-pll-mux?
>
>
> I choose to call it pll-sata-out, as the mux @ 0x34 bit 30 is called
> "PLL_OUTPUT_SEL".

Cool. Note that the clock names don't really matter for end users.
The only place this is visible is debugfs, or if some driver prints
it out for debug messages. So the only real requirement is that the
name makes some sense to any developers using it, in a way that they
can spot if they are using it wrong, like accidentally using a clock
for another module, and being able to roughly match it up to the
datasheet.

ChenYu

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[Chen-Yu Tsai]

On Sat, Aug 12, 2017 at 12:51 PM,   wrote:
> 在 2017-08-12 12:04，Chen-Yu Tsai 写道：
>>
>> On Sat, Jul 22, 2017 at 11:00 AM,   wrote:
>>>
>>> 在 2017-05-29 15:34，Chen-Yu Tsai 写道：


 Hi,

 On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:
>>
>>
>> [...]
>>
> +
> +/*
> + * For the special bit in gate part, please see the BSP source code at
> + *
>
> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/clk/sunxi/clk-sun8iw11.c#L665
> + */
> +static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_sata_clk, "pll-sata",
> +   "osc24M", 0x034,
> +   8, 5,   /* N */
> +   4, 2,   /* K */
> +   0, 2,   /* M */
> +   BIT(31) | BIT(14),  /* gate */
> +   BIT(28),/* lock */
> +   0);



 I think this is a somewhat simplified approach. From what I understand
 of the user manual, the SATA clock path look like:


 [ PLL-PERIPH0-SATA ] -\
   mux @ 0x34 bit 30 --- gate @ 0x34 bit 14 --- ...
 [ PLL-SATA ] -/

 ... from above ... --\
  mux @ 0xc8 bit 24 --- gate @ 0xc8 bit 31
 [ external oscillator ] -/

 If you choose to simplify the implementation, please include a detailed
 note as to why you chose to do so, and the validity of the
 simplification.
>>>
>>>
>>>
>>> I think it can be fully implemented...
>>>
>>> But how should I call the internal clock controlled by the mux @ 0x34 bit
>>> 30?
>>
>>
>> sata-pll-mux?
>
>
> I choose to call it pll-sata-out, as the mux @ 0x34 bit 30 is called
> "PLL_OUTPUT_SEL".

Cool. Note that the clock names don't really matter for end users.
The only place this is visible is debugfs, or if some driver prints
it out for debug messages. So the only real requirement is that the
name makes some sense to any developers using it, in a way that they
can spot if they are using it wrong, like accidentally using a clock
for another module, and being able to roughly match it up to the
datasheet.

ChenYu

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[icenowy]

在 2017-08-12 12:04，Chen-Yu Tsai 写道：

On Sat, Jul 22, 2017 at 11:00 AM,   wrote:

在 2017-05-29 15:34，Chen-Yu Tsai 写道：


Hi,

On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:


[...]


+
+/*
+ * For the special bit in gate part, please see the BSP source code 
at

+ *
https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/clk/sunxi/clk-sun8iw11.c#L665
+ */
+static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_sata_clk, "pll-sata",
+   "osc24M", 0x034,
+   8, 5,   /* N */
+   4, 2,   /* K */
+   0, 2,   /* M */
+   BIT(31) | BIT(14),  /* gate */
+   BIT(28),/* lock */
+   0);



I think this is a somewhat simplified approach. From what I 
understand

of the user manual, the SATA clock path look like:


[ PLL-PERIPH0-SATA ] -\
  mux @ 0x34 bit 30 --- gate @ 0x34 bit 14 --- 
...

[ PLL-SATA ] -/

... from above ... --\
 mux @ 0xc8 bit 24 --- gate @ 0xc8 bit 31
[ external oscillator ] -/

If you choose to simplify the implementation, please include a 
detailed
note as to why you chose to do so, and the validity of the 
simplification.



I think it can be fully implemented...

But how should I call the internal clock controlled by the mux @ 0x34 
bit

30?


sata-pll-mux?


I choose to call it pll-sata-out, as the mux @ 0x34 bit 30 is called
"PLL_OUTPUT_SEL".



ChenYu

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[icenowy]

在 2017-08-12 12:04，Chen-Yu Tsai 写道：

On Sat, Jul 22, 2017 at 11:00 AM,   wrote:

在 2017-05-29 15:34，Chen-Yu Tsai 写道：


Hi,

On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:


[...]


+
+/*
+ * For the special bit in gate part, please see the BSP source code 
at

+ *
https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/clk/sunxi/clk-sun8iw11.c#L665
+ */
+static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_sata_clk, "pll-sata",
+   "osc24M", 0x034,
+   8, 5,   /* N */
+   4, 2,   /* K */
+   0, 2,   /* M */
+   BIT(31) | BIT(14),  /* gate */
+   BIT(28),/* lock */
+   0);



I think this is a somewhat simplified approach. From what I 
understand

of the user manual, the SATA clock path look like:


[ PLL-PERIPH0-SATA ] -\
  mux @ 0x34 bit 30 --- gate @ 0x34 bit 14 --- 
...

[ PLL-SATA ] -/

... from above ... --\
 mux @ 0xc8 bit 24 --- gate @ 0xc8 bit 31
[ external oscillator ] -/

If you choose to simplify the implementation, please include a 
detailed
note as to why you chose to do so, and the validity of the 
simplification.



I think it can be fully implemented...

But how should I call the internal clock controlled by the mux @ 0x34 
bit

30?


sata-pll-mux?


I choose to call it pll-sata-out, as the mux @ 0x34 bit 30 is called
"PLL_OUTPUT_SEL".



ChenYu

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [linux-sunxi] Re: [PATCH v6 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

[icenowy]

在 2017-08-12 12:13，Chen-Yu Tsai 写道：

On Sat, Aug 12, 2017 at 11:07 AM,   wrote:

在 2017-07-17 16:52，Maxime Ripard 写道：


On Fri, Jul 14, 2017 at 05:49:23PM +0300, Priit Laes wrote:


SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
6 is fixed post-divider.

Signed-off-by: Priit Laes 
---
 drivers/clk/sunxi-ng/ccu_div.c | 15 +--
 drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c
b/drivers/clk/sunxi-ng/ccu_div.c
index c0e5c10..744502a 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct
ccu_mux_internal *mux,
 {
struct ccu_div *cd = data;

+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate *= cd->fixed_post_div;
+
return divider_round_rate_parent(>common.hw, parent,
 rate, parent_rate,
 cd->div.table, 
cd->div.width,




You still haven't addressed the biggest issue with this patch, see:
https://patchwork.kernel.org/patch/9825565/



I think he has already did the changes suggested in the review.


Nope. Only half of it is fixed. First you "unapply" the post-divider,
i.e. multiply the rate by the divider. Then you pass it to
divider_round_rate_parent. You still have to reapply the divider
to the result. This last part is missing. This means the clock
rate returned by ccu_div_round_rate is going to be off.

Instead the return statement should be

return divider_round_rate_parent(...) / cd->fixed_post_div


Oh, got it by reading other CCU clock types that has fixed postdiv.

Thanks!



ChenYu



(P.S. during developing R40 CCU driver I found that pll-periph0-sata
also needs this patch, so I'm rechecking it)



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
You received this message because you are subscribed to the Google 
Groups

"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send 
an

email to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [linux-sunxi] Re: [PATCH v6 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

[icenowy]

在 2017-08-12 12:13，Chen-Yu Tsai 写道：

On Sat, Aug 12, 2017 at 11:07 AM,   wrote:

在 2017-07-17 16:52，Maxime Ripard 写道：


On Fri, Jul 14, 2017 at 05:49:23PM +0300, Priit Laes wrote:


SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
6 is fixed post-divider.

Signed-off-by: Priit Laes 
---
 drivers/clk/sunxi-ng/ccu_div.c | 15 +--
 drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c
b/drivers/clk/sunxi-ng/ccu_div.c
index c0e5c10..744502a 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct
ccu_mux_internal *mux,
 {
struct ccu_div *cd = data;

+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate *= cd->fixed_post_div;
+
return divider_round_rate_parent(>common.hw, parent,
 rate, parent_rate,
 cd->div.table, 
cd->div.width,




You still haven't addressed the biggest issue with this patch, see:
https://patchwork.kernel.org/patch/9825565/



I think he has already did the changes suggested in the review.


Nope. Only half of it is fixed. First you "unapply" the post-divider,
i.e. multiply the rate by the divider. Then you pass it to
divider_round_rate_parent. You still have to reapply the divider
to the result. This last part is missing. This means the clock
rate returned by ccu_div_round_rate is going to be off.

Instead the return statement should be

return divider_round_rate_parent(...) / cd->fixed_post_div


Oh, got it by reading other CCU clock types that has fixed postdiv.

Thanks!



ChenYu



(P.S. during developing R40 CCU driver I found that pll-periph0-sata
also needs this patch, so I'm rechecking it)



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
You received this message because you are subscribed to the Google 
Groups

"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send 
an

email to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

[Dan Williams]

On Fri, Aug 11, 2017 at 8:57 PM, Andy Lutomirski  wrote:
> On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams  
> wrote:
>> On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig  wrote:
>>> Please explain how this interface allows for any sort of safe userspace
>>> DMA.
>>
>> So this is where I continue to see S_IOMAP_IMMUTABLE being able to
>> support applications that MAP_SYNC does not. Dave mentioned userspace
>> pNFS4 servers, but there's also Samba and other protocols that want to
>> negotiate a direct path to pmem outside the kernel. Xen support has
>> thus far not been able to follow in the footsteps of KVM enabling due
>> to a dependence on static M2P tables that assume a static
>> guest-physical to host-physical relationship [1]. Immutable files
>> would allow Xen to follow the same "mmap a file" semantic as KVM.
>
> One thing that makes me quite nervous about S_IOMAP_IMMUTABLE is the
> degree to which things go badly if one program relies on it while
> another program clears the flag: you risk corrupting unrelated
> filesystem metadata.  I think a userspace interface to pin the extent
> mapping of a file really wants a way to reliably keep it pinned (or to
> reliably zap the userspace application if it gets unpinned).

In the current patches, mapping_mapped() pins the immutable state.

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

[Dan Williams]

On Fri, Aug 11, 2017 at 8:57 PM, Andy Lutomirski  wrote:
> On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams  
> wrote:
>> On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig  wrote:
>>> Please explain how this interface allows for any sort of safe userspace
>>> DMA.
>>
>> So this is where I continue to see S_IOMAP_IMMUTABLE being able to
>> support applications that MAP_SYNC does not. Dave mentioned userspace
>> pNFS4 servers, but there's also Samba and other protocols that want to
>> negotiate a direct path to pmem outside the kernel. Xen support has
>> thus far not been able to follow in the footsteps of KVM enabling due
>> to a dependence on static M2P tables that assume a static
>> guest-physical to host-physical relationship [1]. Immutable files
>> would allow Xen to follow the same "mmap a file" semantic as KVM.
>
> One thing that makes me quite nervous about S_IOMAP_IMMUTABLE is the
> degree to which things go badly if one program relies on it while
> another program clears the flag: you risk corrupting unrelated
> filesystem metadata.  I think a userspace interface to pin the extent
> mapping of a file really wants a way to reliably keep it pinned (or to
> reliably zap the userspace application if it gets unpinned).

In the current patches, mapping_mapped() pins the immutable state.

Re: [linux-sunxi] Re: [PATCH v6 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

[Chen-Yu Tsai]

On Sat, Aug 12, 2017 at 11:07 AM,   wrote:
> 在 2017-07-17 16:52，Maxime Ripard 写道：
>>
>> On Fri, Jul 14, 2017 at 05:49:23PM +0300, Priit Laes wrote:
>>>
>>> SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
>>> 6 is fixed post-divider.
>>>
>>> Signed-off-by: Priit Laes 
>>> ---
>>>  drivers/clk/sunxi-ng/ccu_div.c | 15 +--
>>>  drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
>>>  2 files changed, 15 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/ccu_div.c
>>> b/drivers/clk/sunxi-ng/ccu_div.c
>>> index c0e5c10..744502a 100644
>>> --- a/drivers/clk/sunxi-ng/ccu_div.c
>>> +++ b/drivers/clk/sunxi-ng/ccu_div.c
>>> @@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct
>>> ccu_mux_internal *mux,
>>>  {
>>> struct ccu_div *cd = data;
>>>
>>> +   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
>>> +   rate *= cd->fixed_post_div;
>>> +
>>> return divider_round_rate_parent(>common.hw, parent,
>>>  rate, parent_rate,
>>>  cd->div.table, cd->div.width,
>>
>>
>>
>> You still haven't addressed the biggest issue with this patch, see:
>> https://patchwork.kernel.org/patch/9825565/
>
>
> I think he has already did the changes suggested in the review.

Nope. Only half of it is fixed. First you "unapply" the post-divider,
i.e. multiply the rate by the divider. Then you pass it to
divider_round_rate_parent. You still have to reapply the divider
to the result. This last part is missing. This means the clock
rate returned by ccu_div_round_rate is going to be off.

Instead the return statement should be

return divider_round_rate_parent(...) / cd->fixed_post_div

ChenYu

>
> (P.S. during developing R40 CCU driver I found that pll-periph0-sata
> also needs this patch, so I'm rechecking it)
>
>>
>> Maxime
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH v6 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

[Chen-Yu Tsai]

On Sat, Aug 12, 2017 at 11:07 AM,   wrote:
> 在 2017-07-17 16:52，Maxime Ripard 写道：
>>
>> On Fri, Jul 14, 2017 at 05:49:23PM +0300, Priit Laes wrote:
>>>
>>> SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
>>> 6 is fixed post-divider.
>>>
>>> Signed-off-by: Priit Laes 
>>> ---
>>>  drivers/clk/sunxi-ng/ccu_div.c | 15 +--
>>>  drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
>>>  2 files changed, 15 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/ccu_div.c
>>> b/drivers/clk/sunxi-ng/ccu_div.c
>>> index c0e5c10..744502a 100644
>>> --- a/drivers/clk/sunxi-ng/ccu_div.c
>>> +++ b/drivers/clk/sunxi-ng/ccu_div.c
>>> @@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct
>>> ccu_mux_internal *mux,
>>>  {
>>> struct ccu_div *cd = data;
>>>
>>> +   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
>>> +   rate *= cd->fixed_post_div;
>>> +
>>> return divider_round_rate_parent(>common.hw, parent,
>>>  rate, parent_rate,
>>>  cd->div.table, cd->div.width,
>>
>>
>>
>> You still haven't addressed the biggest issue with this patch, see:
>> https://patchwork.kernel.org/patch/9825565/
>
>
> I think he has already did the changes suggested in the review.

Nope. Only half of it is fixed. First you "unapply" the post-divider,
i.e. multiply the rate by the divider. Then you pass it to
divider_round_rate_parent. You still have to reapply the divider
to the result. This last part is missing. This means the clock
rate returned by ccu_div_round_rate is going to be off.

Instead the return statement should be

return divider_round_rate_parent(...) / cd->fixed_post_div

ChenYu

>
> (P.S. during developing R40 CCU driver I found that pll-periph0-sata
> also needs this patch, so I'm rechecking it)
>
>>
>> Maxime
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

[Dave Chinner]

On Fri, Aug 11, 2017 at 07:31:54PM -0700, Darrick J. Wong wrote:
> On Sat, Aug 12, 2017 at 10:30:34AM +1000, Dave Chinner wrote:
> > On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote:
> > > On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner  wrote:
> > > > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote:
> > > >> >From falloc.h:
> > > >>
> > > >> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of 
> > > >> the
> > > >> file logical-to-physical extent offset mappings in the file. The
> > > >> purpose is to allow an application to assume that there are no 
> > > >> holes
> > > >> or shared extents in the file and that the metadata needed to find
> > > >> all the physical extents of the file is stable and can never be
> > > >> dirtied.
> > > >>
> > > >> For now this patch only permits setting the in-memory state of
> > > >> S_IOMAP_IMMMUTABLE. Support for clearing and persisting the state is
> > > >> saved for later patches.
> > > >>
> > > >> The implementation is careful to not allow the immutable state to 
> > > >> change
> > > >> while any process might have any established mappings. It reuses the
> > > >> existing xfs_reflink_unshare() and xfs_alloc_file_space() to unshare
> > > >> extents and fill all holes in the file. It then holds XFS_ILOCK_EXCL
> > > >> while it validates the file is in the proper state and sets
> > > >> S_IOMAP_IMMUTABLE.
> > > >
> > > > SO I've been thinking about this - I'm thinking that we need to
> > > > separate the changes to the extent map from the action of sealing
> > > > the extent map.
> > > >
> > > > That is, I have a need to freeze an extent map without any
> > > > modification to it at all and breaking all the sharing and filling
> > > > all the holes completely screws up the file layout I need to
> > > > preserve. i.e. I want to be able to freeze the maps of a pair of
> > > > reflinked files so I can use FIEMAP to query only the changed blocks
> > > > and then read out the data in the private/changed blocks in the
> > > > reflinked file. I only need a temporary seal (if we crash it goes
> > > > away), so maybe there's another command modifier flag needed here,
> > > > too.
> > > >
> > > > The DAX allocation requirements can be handled by a preallocation
> > > > call to filll holes with zeros, followed by an unshare call to break
> > > > all the COW mappings, and then the extent map can be sealed. If you
> > > > need to check for holes after sealing, SEEK_HOLE will tell you what
> > > > you need to know...
> > > >
> > > > My preference really is for each fallocate command to do just one
> > > > thing - having the seal operation also modify the extent map
> > > > means it's not useful for the use cases where we need the extent map
> > > > to remain unmodified
> > > >
> > > > Thoughts?
> > > 
> > > That does seem to better follow the principle of least surprise and
> > > make the interface more composable. However, for the DAX case do we
> > > now end up needing a SEEK_SHARED, or something similar to check that
> > > we sealed the file without shared extents?
> 
> Well, fiemap/bmap will tell you (presumably after you confirm that the
> file got sealed or whatever) if there are shared extents.

Iterating potentially hundreds of thousands of extents just to find
the one shared extent seems like crazy thing to ask people to do.

> > Don't we have an inode attribute flag for that? There's definitely a
> > flag in the on disk XFS inode to indicate that there are shared
> > extents on the file.
> > 
> > H - for some reason it's not exposed in FS_IOC_FSGETXATTR.
> > Darrick? Any reason we don't expose the "this file has shared
> > extents" flag to userspace? How are we checking that on-disk state
> > in xfstests?
> > 
> > As it is, if we're adding an immutable extent flag, we've got to be
> > able to query the immutable extent state of a file from userspace so
> > I'm thinking that we'd need to expose it via the same interface that
> > exposes the immutable flag. i.e. we could add the "shared extents
> > present" flag to FS_IOC_FSGETXATTR at the same time...
> 
> We used to have a FSGETXATTR flag; iirc hch nak'd it during the review.

Ok, got a link? Seems strange to not be able to query this state
even for testing/validation purposes...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

[Dave Chinner]

On Fri, Aug 11, 2017 at 07:31:54PM -0700, Darrick J. Wong wrote:
> On Sat, Aug 12, 2017 at 10:30:34AM +1000, Dave Chinner wrote:
> > On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote:
> > > On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner  wrote:
> > > > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote:
> > > >> >From falloc.h:
> > > >>
> > > >> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of 
> > > >> the
> > > >> file logical-to-physical extent offset mappings in the file. The
> > > >> purpose is to allow an application to assume that there are no 
> > > >> holes
> > > >> or shared extents in the file and that the metadata needed to find
> > > >> all the physical extents of the file is stable and can never be
> > > >> dirtied.
> > > >>
> > > >> For now this patch only permits setting the in-memory state of
> > > >> S_IOMAP_IMMMUTABLE. Support for clearing and persisting the state is
> > > >> saved for later patches.
> > > >>
> > > >> The implementation is careful to not allow the immutable state to 
> > > >> change
> > > >> while any process might have any established mappings. It reuses the
> > > >> existing xfs_reflink_unshare() and xfs_alloc_file_space() to unshare
> > > >> extents and fill all holes in the file. It then holds XFS_ILOCK_EXCL
> > > >> while it validates the file is in the proper state and sets
> > > >> S_IOMAP_IMMUTABLE.
> > > >
> > > > SO I've been thinking about this - I'm thinking that we need to
> > > > separate the changes to the extent map from the action of sealing
> > > > the extent map.
> > > >
> > > > That is, I have a need to freeze an extent map without any
> > > > modification to it at all and breaking all the sharing and filling
> > > > all the holes completely screws up the file layout I need to
> > > > preserve. i.e. I want to be able to freeze the maps of a pair of
> > > > reflinked files so I can use FIEMAP to query only the changed blocks
> > > > and then read out the data in the private/changed blocks in the
> > > > reflinked file. I only need a temporary seal (if we crash it goes
> > > > away), so maybe there's another command modifier flag needed here,
> > > > too.
> > > >
> > > > The DAX allocation requirements can be handled by a preallocation
> > > > call to filll holes with zeros, followed by an unshare call to break
> > > > all the COW mappings, and then the extent map can be sealed. If you
> > > > need to check for holes after sealing, SEEK_HOLE will tell you what
> > > > you need to know...
> > > >
> > > > My preference really is for each fallocate command to do just one
> > > > thing - having the seal operation also modify the extent map
> > > > means it's not useful for the use cases where we need the extent map
> > > > to remain unmodified
> > > >
> > > > Thoughts?
> > > 
> > > That does seem to better follow the principle of least surprise and
> > > make the interface more composable. However, for the DAX case do we
> > > now end up needing a SEEK_SHARED, or something similar to check that
> > > we sealed the file without shared extents?
> 
> Well, fiemap/bmap will tell you (presumably after you confirm that the
> file got sealed or whatever) if there are shared extents.

Iterating potentially hundreds of thousands of extents just to find
the one shared extent seems like crazy thing to ask people to do.

> > Don't we have an inode attribute flag for that? There's definitely a
> > flag in the on disk XFS inode to indicate that there are shared
> > extents on the file.
> > 
> > H - for some reason it's not exposed in FS_IOC_FSGETXATTR.
> > Darrick? Any reason we don't expose the "this file has shared
> > extents" flag to userspace? How are we checking that on-disk state
> > in xfstests?
> > 
> > As it is, if we're adding an immutable extent flag, we've got to be
> > able to query the immutable extent state of a file from userspace so
> > I'm thinking that we'd need to expose it via the same interface that
> > exposes the immutable flag. i.e. we could add the "shared extents
> > present" flag to FS_IOC_FSGETXATTR at the same time...
> 
> We used to have a FSGETXATTR flag; iirc hch nak'd it during the review.

Ok, got a link? Seems strange to not be able to query this state
even for testing/validation purposes...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[Chen-Yu Tsai]

On Sat, Aug 12, 2017 at 12:04 PM,   wrote:
> 在 2017-05-29 15:34，Chen-Yu Tsai 写道：
>>
>> Hi,
>>
>> On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:
>>>
>>> Allwinner R40 SoC have a clock controller module in the style of the
>>> SoCs beyond sun6i, however, it's more rich and complex.
>>>
>>> Add support for it.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>> Changes in v3:
>>> - Rebased on current linux-next.
>>> Changes in v2:
>>> - Fixes according to the SoC's user manual.
>>>
>>>  drivers/clk/sunxi-ng/Kconfig  |   10 +
>>>  drivers/clk/sunxi-ng/Makefile |1 +
>>>  drivers/clk/sunxi-ng/ccu-sun8i-r40.c  | 1153
>>> +
>>>  drivers/clk/sunxi-ng/ccu-sun8i-r40.h  |   68 ++
>>>  include/dt-bindings/clock/sun8i-r40-ccu.h |  191 +
>>>  include/dt-bindings/reset/sun8i-r40-ccu.h |  129 
>>>  6 files changed, 1552 insertions(+)
>>>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.c
>>>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.h
>>>  create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h
>>>  create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h
>>>
>> ...
>>>
>>> +static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
>>> +  "osc24M", 0x04c,
>>> +  8, 7,/* N */
>>
>>
>> N has minimum and maximum limits.
>
>
> These constraints are never implemented in old SoCs.

Then we should implement them if we find that they are
missing.

ChenYu

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[Chen-Yu Tsai]

On Sat, Aug 12, 2017 at 12:04 PM,   wrote:
> 在 2017-05-29 15:34，Chen-Yu Tsai 写道：
>>
>> Hi,
>>
>> On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:
>>>
>>> Allwinner R40 SoC have a clock controller module in the style of the
>>> SoCs beyond sun6i, however, it's more rich and complex.
>>>
>>> Add support for it.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>> Changes in v3:
>>> - Rebased on current linux-next.
>>> Changes in v2:
>>> - Fixes according to the SoC's user manual.
>>>
>>>  drivers/clk/sunxi-ng/Kconfig  |   10 +
>>>  drivers/clk/sunxi-ng/Makefile |1 +
>>>  drivers/clk/sunxi-ng/ccu-sun8i-r40.c  | 1153
>>> +
>>>  drivers/clk/sunxi-ng/ccu-sun8i-r40.h  |   68 ++
>>>  include/dt-bindings/clock/sun8i-r40-ccu.h |  191 +
>>>  include/dt-bindings/reset/sun8i-r40-ccu.h |  129 
>>>  6 files changed, 1552 insertions(+)
>>>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.c
>>>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.h
>>>  create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h
>>>  create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h
>>>
>> ...
>>>
>>> +static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
>>> +  "osc24M", 0x04c,
>>> +  8, 7,/* N */
>>
>>
>> N has minimum and maximum limits.
>
>
> These constraints are never implemented in old SoCs.

Then we should implement them if we find that they are
missing.

ChenYu

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[Chen-Yu Tsai]

On Sat, Jul 22, 2017 at 11:00 AM,   wrote:
> 在 2017-05-29 15:34，Chen-Yu Tsai 写道：
>>
>> Hi,
>>
>> On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:

[...]

>>> +
>>> +/*
>>> + * For the special bit in gate part, please see the BSP source code at
>>> + *
>>> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/clk/sunxi/clk-sun8iw11.c#L665
>>> + */
>>> +static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_sata_clk, "pll-sata",
>>> +   "osc24M", 0x034,
>>> +   8, 5,   /* N */
>>> +   4, 2,   /* K */
>>> +   0, 2,   /* M */
>>> +   BIT(31) | BIT(14),  /* gate */
>>> +   BIT(28),/* lock */
>>> +   0);
>>
>>
>> I think this is a somewhat simplified approach. From what I understand
>> of the user manual, the SATA clock path look like:
>>
>>
>> [ PLL-PERIPH0-SATA ] -\
>>   mux @ 0x34 bit 30 --- gate @ 0x34 bit 14 --- ...
>> [ PLL-SATA ] -/
>>
>> ... from above ... --\
>>  mux @ 0xc8 bit 24 --- gate @ 0xc8 bit 31
>> [ external oscillator ] -/
>>
>> If you choose to simplify the implementation, please include a detailed
>> note as to why you chose to do so, and the validity of the simplification.
>
>
> I think it can be fully implemented...
>
> But how should I call the internal clock controlled by the mux @ 0x34 bit
> 30?

sata-pll-mux?

ChenYu

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[Chen-Yu Tsai]

On Sat, Jul 22, 2017 at 11:00 AM,   wrote:
> 在 2017-05-29 15:34，Chen-Yu Tsai 写道：
>>
>> Hi,
>>
>> On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:

[...]

>>> +
>>> +/*
>>> + * For the special bit in gate part, please see the BSP source code at
>>> + *
>>> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/clk/sunxi/clk-sun8iw11.c#L665
>>> + */
>>> +static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_sata_clk, "pll-sata",
>>> +   "osc24M", 0x034,
>>> +   8, 5,   /* N */
>>> +   4, 2,   /* K */
>>> +   0, 2,   /* M */
>>> +   BIT(31) | BIT(14),  /* gate */
>>> +   BIT(28),/* lock */
>>> +   0);
>>
>>
>> I think this is a somewhat simplified approach. From what I understand
>> of the user manual, the SATA clock path look like:
>>
>>
>> [ PLL-PERIPH0-SATA ] -\
>>   mux @ 0x34 bit 30 --- gate @ 0x34 bit 14 --- ...
>> [ PLL-SATA ] -/
>>
>> ... from above ... --\
>>  mux @ 0xc8 bit 24 --- gate @ 0xc8 bit 31
>> [ external oscillator ] -/
>>
>> If you choose to simplify the implementation, please include a detailed
>> note as to why you chose to do so, and the validity of the simplification.
>
>
> I think it can be fully implemented...
>
> But how should I call the internal clock controlled by the mux @ 0x34 bit
> 30?

sata-pll-mux?

ChenYu

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[icenowy]

在 2017-05-29 15:34，Chen-Yu Tsai 写道：

Hi,

On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:

Allwinner R40 SoC have a clock controller module in the style of the
SoCs beyond sun6i, however, it's more rich and complex.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v3:
- Rebased on current linux-next.
Changes in v2:
- Fixes according to the SoC's user manual.

 drivers/clk/sunxi-ng/Kconfig  |   10 +
 drivers/clk/sunxi-ng/Makefile |1 +
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c  | 1153 
+

 drivers/clk/sunxi-ng/ccu-sun8i-r40.h  |   68 ++
 include/dt-bindings/clock/sun8i-r40-ccu.h |  191 +
 include/dt-bindings/reset/sun8i-r40-ccu.h |  129 
 6 files changed, 1552 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.h
 create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h


...

+static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
+  "osc24M", 0x04c,
+  8, 7,/* N */


N has minimum and maximum limits.


These constraints are never implemented in old SoCs.


--
2.12.2

Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

[icenowy]

在 2017-05-29 15:34，Chen-Yu Tsai 写道：

Hi,

On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:

Allwinner R40 SoC have a clock controller module in the style of the
SoCs beyond sun6i, however, it's more rich and complex.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v3:
- Rebased on current linux-next.
Changes in v2:
- Fixes according to the SoC's user manual.

 drivers/clk/sunxi-ng/Kconfig  |   10 +
 drivers/clk/sunxi-ng/Makefile |1 +
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c  | 1153 
+

 drivers/clk/sunxi-ng/ccu-sun8i-r40.h  |   68 ++
 include/dt-bindings/clock/sun8i-r40-ccu.h |  191 +
 include/dt-bindings/reset/sun8i-r40-ccu.h |  129 
 6 files changed, 1552 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.h
 create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h


...

+static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
+  "osc24M", 0x04c,
+  8, 7,/* N */


N has minimum and maximum limits.


These constraints are never implemented in old SoCs.


--
2.12.2

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

[Andy Lutomirski]

On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams  wrote:
> On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig  wrote:
>> Please explain how this interface allows for any sort of safe userspace
>> DMA.
>
> So this is where I continue to see S_IOMAP_IMMUTABLE being able to
> support applications that MAP_SYNC does not. Dave mentioned userspace
> pNFS4 servers, but there's also Samba and other protocols that want to
> negotiate a direct path to pmem outside the kernel. Xen support has
> thus far not been able to follow in the footsteps of KVM enabling due
> to a dependence on static M2P tables that assume a static
> guest-physical to host-physical relationship [1]. Immutable files
> would allow Xen to follow the same "mmap a file" semantic as KVM.

One thing that makes me quite nervous about S_IOMAP_IMMUTABLE is the
degree to which things go badly if one program relies on it while
another program clears the flag: you risk corrupting unrelated
filesystem metadata.  I think a userspace interface to pin the extent
mapping of a file really wants a way to reliably keep it pinned (or to
reliably zap the userspace application if it gets unpinned).

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

[Andy Lutomirski]

On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams  wrote:
> On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig  wrote:
>> Please explain how this interface allows for any sort of safe userspace
>> DMA.
>
> So this is where I continue to see S_IOMAP_IMMUTABLE being able to
> support applications that MAP_SYNC does not. Dave mentioned userspace
> pNFS4 servers, but there's also Samba and other protocols that want to
> negotiate a direct path to pmem outside the kernel. Xen support has
> thus far not been able to follow in the footsteps of KVM enabling due
> to a dependence on static M2P tables that assume a static
> guest-physical to host-physical relationship [1]. Immutable files
> would allow Xen to follow the same "mmap a file" semantic as KVM.

One thing that makes me quite nervous about S_IOMAP_IMMUTABLE is the
degree to which things go badly if one program relies on it while
another program clears the flag: you risk corrupting unrelated
filesystem metadata.  I think a userspace interface to pin the extent
mapping of a file really wants a way to reliably keep it pinned (or to
reliably zap the userspace application if it gets unpinned).

[RFC PATCH] kvm: x86: reduce rtc 0x70 access vm-exit time

[Peng Hao]

some versions of windows guest access rtc frequently because of
rtc as system tick.guest access rtc like this: write register index
to 0x70, then write or read data from 0x71. writing 0x70 port is
just as index and do nothing else. So we can use coalesced mmio to
handle this scene to reduce VM-EXIT time.
without my patch, get the vm-exit time of accessing rtc 0x70 using
perf tools: (guest OS : windows 7 64bit)
IO Port Access  Samples Samples%  Time%  Min Time  Max Time  Avg time
0x70:POUT86 30.99%74.59%   9us  29us10.75us (+- 3.41%)

with my patch
IO Port Access  Samples Samples%  Time%   Min Time  Max Time   Avg time
 0x70:POUT   10632.02%29.47%0us  10us 1.57us (+- 7.38%)

the patch is a part of optimizing rtc 0x70 port access. Another is in
qemu.

Signed-off-by: Peng Hao 
---
 virt/kvm/coalesced_mmio.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c
index 571c1ce..f640c2f 100644
--- a/virt/kvm/coalesced_mmio.c
+++ b/virt/kvm/coalesced_mmio.c
@@ -82,6 +82,7 @@ static int coalesced_mmio_write(struct kvm_vcpu *vcpu,
ring->coalesced_mmio[ring->last].phys_addr = addr;
ring->coalesced_mmio[ring->last].len = len;
memcpy(ring->coalesced_mmio[ring->last].data, val, len);
+   ring->coalesced_mmio[ring->last].pad = dev->zone.pad;
smp_wmb();
ring->last = (ring->last + 1) % KVM_COALESCED_MMIO_MAX;
spin_unlock(>kvm->ring_lock);
@@ -148,8 +149,12 @@ int kvm_vm_ioctl_register_coalesced_mmio(struct kvm *kvm,
dev->zone = *zone;
 
mutex_lock(>slots_lock);
-   ret = kvm_io_bus_register_dev(kvm, KVM_MMIO_BUS, zone->addr,
- zone->size, >dev);
+   if (zone->pad == 0)
+   ret = kvm_io_bus_register_dev(kvm, KVM_MMIO_BUS, zone->addr,
+   zone->size, >dev);
+   else
+   ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS, zone->addr,
+   zone->size, >dev);
if (ret < 0)
goto out_free_dev;
list_add_tail(>list, >coalesced_zones);
@@ -173,7 +178,10 @@ int kvm_vm_ioctl_unregister_coalesced_mmio(struct kvm *kvm,
 
list_for_each_entry_safe(dev, tmp, >coalesced_zones, list)
if (coalesced_mmio_in_range(dev, zone->addr, zone->size)) {
-   kvm_io_bus_unregister_dev(kvm, KVM_MMIO_BUS, >dev);
+   if (zone->pad == 0)
+   kvm_io_bus_unregister_dev(kvm, KVM_MMIO_BUS, 
>dev);
+   else
+   kvm_io_bus_unregister_dev(kvm, KVM_PIO_BUS, 
>dev);
kvm_iodevice_destructor(>dev);
}
 
-- 
1.8.3.1

[RFC PATCH] kvm: x86: reduce rtc 0x70 access vm-exit time

[Peng Hao]

some versions of windows guest access rtc frequently because of
rtc as system tick.guest access rtc like this: write register index
to 0x70, then write or read data from 0x71. writing 0x70 port is
just as index and do nothing else. So we can use coalesced mmio to
handle this scene to reduce VM-EXIT time.
without my patch, get the vm-exit time of accessing rtc 0x70 using
perf tools: (guest OS : windows 7 64bit)
IO Port Access  Samples Samples%  Time%  Min Time  Max Time  Avg time
0x70:POUT86 30.99%74.59%   9us  29us10.75us (+- 3.41%)

with my patch
IO Port Access  Samples Samples%  Time%   Min Time  Max Time   Avg time
 0x70:POUT   10632.02%29.47%0us  10us 1.57us (+- 7.38%)

the patch is a part of optimizing rtc 0x70 port access. Another is in
qemu.

Signed-off-by: Peng Hao 
---
 virt/kvm/coalesced_mmio.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c
index 571c1ce..f640c2f 100644
--- a/virt/kvm/coalesced_mmio.c
+++ b/virt/kvm/coalesced_mmio.c
@@ -82,6 +82,7 @@ static int coalesced_mmio_write(struct kvm_vcpu *vcpu,
ring->coalesced_mmio[ring->last].phys_addr = addr;
ring->coalesced_mmio[ring->last].len = len;
memcpy(ring->coalesced_mmio[ring->last].data, val, len);
+   ring->coalesced_mmio[ring->last].pad = dev->zone.pad;
smp_wmb();
ring->last = (ring->last + 1) % KVM_COALESCED_MMIO_MAX;
spin_unlock(>kvm->ring_lock);
@@ -148,8 +149,12 @@ int kvm_vm_ioctl_register_coalesced_mmio(struct kvm *kvm,
dev->zone = *zone;
 
mutex_lock(>slots_lock);
-   ret = kvm_io_bus_register_dev(kvm, KVM_MMIO_BUS, zone->addr,
- zone->size, >dev);
+   if (zone->pad == 0)
+   ret = kvm_io_bus_register_dev(kvm, KVM_MMIO_BUS, zone->addr,
+   zone->size, >dev);
+   else
+   ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS, zone->addr,
+   zone->size, >dev);
if (ret < 0)
goto out_free_dev;
list_add_tail(>list, >coalesced_zones);
@@ -173,7 +178,10 @@ int kvm_vm_ioctl_unregister_coalesced_mmio(struct kvm *kvm,
 
list_for_each_entry_safe(dev, tmp, >coalesced_zones, list)
if (coalesced_mmio_in_range(dev, zone->addr, zone->size)) {
-   kvm_io_bus_unregister_dev(kvm, KVM_MMIO_BUS, >dev);
+   if (zone->pad == 0)
+   kvm_io_bus_unregister_dev(kvm, KVM_MMIO_BUS, 
>dev);
+   else
+   kvm_io_bus_unregister_dev(kvm, KVM_PIO_BUS, 
>dev);
kvm_iodevice_destructor(>dev);
}
 
-- 
1.8.3.1

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[David Ahern]

On 8/11/17 6:25 PM, Wei Wang wrote:
> By "a patch to fix that" do you mean after your patch, for every rt6,
> rt6->rt6i_idev will be the same as rt6->dst.dev?

FIB entries should have them the same device with my patch.

The copies done (ip6_rt_cache_alloc and ip6_rt_pcpu_alloc) will have to
set dst.dev to loopback or VRF device for RTF_LOCAL routes; it's the
only way to get local traffic to work and this is similar to what IPv4 does.

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[David Ahern]

On 8/11/17 6:25 PM, Wei Wang wrote:
> By "a patch to fix that" do you mean after your patch, for every rt6,
> rt6->rt6i_idev will be the same as rt6->dst.dev?

FIB entries should have them the same device with my patch.

The copies done (ip6_rt_cache_alloc and ip6_rt_pcpu_alloc) will have to
set dst.dev to loopback or VRF device for RTF_LOCAL routes; it's the
only way to get local traffic to work and this is similar to what IPv4 does.

Re: make clean all broken with -j? + question regarding modpost

[Masahiro Yamada]

Hi.

2017-08-11 3:28 GMT+09:00 Randy Dunlap :

>> 2.) compile modpost with debug symbols, -g
>> how do I compile the modpost helper program with debug symbols? In what
>> makefile, kbuild file do I need to add the compiler flag?
>> Any help would be appreciated!


If you want to pass extra options to the build command of host-programs,
HOST_EXTRACFLAGS is supported.

For example,  HOST_EXTRACFLAGS=-g





-- 
Best Regards
Masahiro Yamada

Re: make clean all broken with -j? + question regarding modpost

[Masahiro Yamada]

Hi.

2017-08-11 3:28 GMT+09:00 Randy Dunlap :

>> 2.) compile modpost with debug symbols, -g
>> how do I compile the modpost helper program with debug symbols? In what
>> makefile, kbuild file do I need to add the compiler flag?
>> Any help would be appreciated!


If you want to pass extra options to the build command of host-programs,
HOST_EXTRACFLAGS is supported.

For example,  HOST_EXTRACFLAGS=-g





-- 
Best Regards
Masahiro Yamada

Re: make clean all broken with -j? + question regarding modpost

[Masahiro Yamada]

Hi.


2017-08-11 7:11 GMT+09:00 Jim Davis :
> On Thu, Aug 10, 2017 at 11:28 AM, Randy Dunlap  wrote:
>> [adding linux-kbuild]
>>
>> On 08/10/2017 08:42 AM, Thomas Meyer wrote:
>>> Hi,
>>>
>>> 1.) make with multiple targets
>>>
>>> When running
>>> $ make -j4 clean all
>>> I get error from make (probably in scripts/Makefile.modbuiltin):
>
> With 4.13-rc4 I can get a similar build failure on my Fedora 26 workstation 
> with
>
> make allnoconfig; make -j2 clean all
>
> /bin/sh: scripts/mod/empty.o: No such file or directory
> make[2]: *** [scripts/mod/Makefile:24: scripts/mod/elfconfig.h] Error 1
> make[1]: *** [scripts/Makefile.build:561: scripts/mod] Error 2
>
> Here's an ugly workaround for that test case.
>
> diff --git a/Makefile b/Makefile
> index 6eba23bcb5ad..6a1fd24dcf31 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1297,6 +1297,7 @@ MRPROPER_FILES += .config .config.old .version
> .old_version \
>
>  # clean - Delete most, but leave enough to build external modules
>  #
> +.NOTPARALLEL: clean
>  clean: rm-dirs  := $(CLEAN_DIRS)
>  clean: rm-files := $(CLEAN_FILES)
>  clean-dirs  := $(addprefix _clean_, . $(vmlinux-alldirs)
> Documentation samples)
>


If config targets and build targets are given from the command line
(for example,  "make -j8 defconfig all"
they are processed one by one.

Kbuild does not cater to the mixture of clean targets and build targets,
but I do not know why.

I wrote as follows.



--- a/Makefile
+++ b/Makefile
@@ -482,7 +482,8 @@ uapi-asm-generic:
 version_h := include/generated/uapi/linux/version.h
 old_version_h := include/linux/version.h

-no-dot-config-targets := clean mrproper distclean \
+clean-targets := %clean mrproper cleandocs
+no-dot-config-targets := $(clean-targets) \
 cscope gtags TAGS tags help% %docs check% coccicheck \
 $(version_h) headers_% archheaders archscripts \
 kernelversion %src-pkg
@@ -505,6 +506,14 @@ ifeq ($(KBUILD_EXTMOD),)
 endif
 endif
 endif
+
+# For "make -j clean all", "make mrproper defconfig all", etc.
+ifneq ($(filter $(clean-targets),$(MAKECMDGOALS)),)
+   ifneq ($(filter-out $(clean-targets),$(MAKECMDGOALS)),)
+   mixed-targets := 1
+   endif
+endif
+
 # install and module_install need also be processed one by one
 ifneq ($(filter install,$(MAKECMDGOALS)),)
 ifneq ($(filter modules_install,$(MAKECMDGOALS)),)








-- 
Best Regards
Masahiro Yamada

Re: make clean all broken with -j? + question regarding modpost

[Masahiro Yamada]

Hi.


2017-08-11 7:11 GMT+09:00 Jim Davis :
> On Thu, Aug 10, 2017 at 11:28 AM, Randy Dunlap  wrote:
>> [adding linux-kbuild]
>>
>> On 08/10/2017 08:42 AM, Thomas Meyer wrote:
>>> Hi,
>>>
>>> 1.) make with multiple targets
>>>
>>> When running
>>> $ make -j4 clean all
>>> I get error from make (probably in scripts/Makefile.modbuiltin):
>
> With 4.13-rc4 I can get a similar build failure on my Fedora 26 workstation 
> with
>
> make allnoconfig; make -j2 clean all
>
> /bin/sh: scripts/mod/empty.o: No such file or directory
> make[2]: *** [scripts/mod/Makefile:24: scripts/mod/elfconfig.h] Error 1
> make[1]: *** [scripts/Makefile.build:561: scripts/mod] Error 2
>
> Here's an ugly workaround for that test case.
>
> diff --git a/Makefile b/Makefile
> index 6eba23bcb5ad..6a1fd24dcf31 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1297,6 +1297,7 @@ MRPROPER_FILES += .config .config.old .version
> .old_version \
>
>  # clean - Delete most, but leave enough to build external modules
>  #
> +.NOTPARALLEL: clean
>  clean: rm-dirs  := $(CLEAN_DIRS)
>  clean: rm-files := $(CLEAN_FILES)
>  clean-dirs  := $(addprefix _clean_, . $(vmlinux-alldirs)
> Documentation samples)
>


If config targets and build targets are given from the command line
(for example,  "make -j8 defconfig all"
they are processed one by one.

Kbuild does not cater to the mixture of clean targets and build targets,
but I do not know why.

I wrote as follows.



--- a/Makefile
+++ b/Makefile
@@ -482,7 +482,8 @@ uapi-asm-generic:
 version_h := include/generated/uapi/linux/version.h
 old_version_h := include/linux/version.h

-no-dot-config-targets := clean mrproper distclean \
+clean-targets := %clean mrproper cleandocs
+no-dot-config-targets := $(clean-targets) \
 cscope gtags TAGS tags help% %docs check% coccicheck \
 $(version_h) headers_% archheaders archscripts \
 kernelversion %src-pkg
@@ -505,6 +506,14 @@ ifeq ($(KBUILD_EXTMOD),)
 endif
 endif
 endif
+
+# For "make -j clean all", "make mrproper defconfig all", etc.
+ifneq ($(filter $(clean-targets),$(MAKECMDGOALS)),)
+   ifneq ($(filter-out $(clean-targets),$(MAKECMDGOALS)),)
+   mixed-targets := 1
+   endif
+endif
+
 # install and module_install need also be processed one by one
 ifneq ($(filter install,$(MAKECMDGOALS)),)
 ifneq ($(filter modules_install,$(MAKECMDGOALS)),)








-- 
Best Regards
Masahiro Yamada

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[John Stultz]

On Fri, Aug 11, 2017 at 5:31 PM, John Stultz  wrote:
> On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang  wrote:
>>> If after Cong's fix, the issue still happens, could you help try the
>>> patch attached and collect all logs when you try the reproduce the
>>> issue? It would be great to have logs for both success case and the
>>> failure case.
>>>
>>> Thanks so much for your help.
>>>
>>
>> I think we have a potential fix for this issue.
>> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
>> possible that rt6->dst.dev points to loopback device while
>> rt6->rt6i_idev->dev points to a real device.
>> When the real device goes down, the current fib6 clean up code only
>> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
>> That leaves unreleased refcnt on the real device if rt6->dst.dev
>> points to loopback dev.
>>
>> The attached potential fix is tested by Martin and made sure it fixes his 
>> issue.
>>
>> John,
>> It will be great if you can also give it a try and see if it fixes the
>> issue on your side before I submit an official patch.
>
> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch  (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.

Looks good so far! I've not hit the issue yet.

Thanks so much for sorting out a fix!

If its useful:
Tested-by: John Stultz 

thanks again
-john

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[John Stultz]

On Fri, Aug 11, 2017 at 5:31 PM, John Stultz  wrote:
> On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang  wrote:
>>> If after Cong's fix, the issue still happens, could you help try the
>>> patch attached and collect all logs when you try the reproduce the
>>> issue? It would be great to have logs for both success case and the
>>> failure case.
>>>
>>> Thanks so much for your help.
>>>
>>
>> I think we have a potential fix for this issue.
>> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
>> possible that rt6->dst.dev points to loopback device while
>> rt6->rt6i_idev->dev points to a real device.
>> When the real device goes down, the current fib6 clean up code only
>> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
>> That leaves unreleased refcnt on the real device if rt6->dst.dev
>> points to loopback dev.
>>
>> The attached potential fix is tested by Martin and made sure it fixes his 
>> issue.
>>
>> John,
>> It will be great if you can also give it a try and see if it fixes the
>> issue on your side before I submit an official patch.
>
> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch  (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.

Looks good so far! I've not hit the issue yet.

Thanks so much for sorting out a fix!

If its useful:
Tested-by: John Stultz 

thanks again
-john

Re: [PATCH v6 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

[icenowy]

在 2017-07-17 16:52，Maxime Ripard 写道：

On Fri, Jul 14, 2017 at 05:49:23PM +0300, Priit Laes wrote:

SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
6 is fixed post-divider.

Signed-off-by: Priit Laes 
---
 drivers/clk/sunxi-ng/ccu_div.c | 15 +--
 drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c 
b/drivers/clk/sunxi-ng/ccu_div.c

index c0e5c10..744502a 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct 
ccu_mux_internal *mux,

 {
struct ccu_div *cd = data;

+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate *= cd->fixed_post_div;
+
return divider_round_rate_parent(>common.hw, parent,
 rate, parent_rate,
 cd->div.table, cd->div.width,



You still haven't addressed the biggest issue with this patch, see:
https://patchwork.kernel.org/patch/9825565/


I think he has already did the changes suggested in the review.

(P.S. during developing R40 CCU driver I found that pll-periph0-sata
also needs this patch, so I'm rechecking it)



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v6 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

[icenowy]

在 2017-07-17 16:52，Maxime Ripard 写道：

On Fri, Jul 14, 2017 at 05:49:23PM +0300, Priit Laes wrote:

SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
6 is fixed post-divider.

Signed-off-by: Priit Laes 
---
 drivers/clk/sunxi-ng/ccu_div.c | 15 +--
 drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c 
b/drivers/clk/sunxi-ng/ccu_div.c

index c0e5c10..744502a 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct 
ccu_mux_internal *mux,

 {
struct ccu_div *cd = data;

+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate *= cd->fixed_post_div;
+
return divider_round_rate_parent(>common.hw, parent,
 rate, parent_rate,
 cd->div.table, cd->div.width,



You still haven't addressed the biggest issue with this patch, see:
https://patchwork.kernel.org/patch/9825565/


I think he has already did the changes suggested in the review.

(P.S. during developing R40 CCU driver I found that pll-periph0-sata
also needs this patch, so I'm rechecking it)



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 0/2] Add i2c dt-binding and compatible for Mediatek MT7622 SoC

[Jun Gao]

This patch series based on v4.13-rc1, include MT7622 i2c dt-binding
and compatible.

changes since v1:
- Modify commit message
- Revise dt-binding documentation

Jun Gao (2):
  dt-bindings: i2c: Add MediaTek MT7622 i2c binding
  i2c: mediatek: Add i2c compatible for MediaTek MT7622

 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
 drivers/i2c/busses/i2c-mt65xx.c   | 18 ++
 2 files changed, 24 insertions(+), 5 deletions(-)

--
1.8.1.1

[PATCH v2 1/2] dt-bindings: i2c: Add MediaTek MT7622 i2c binding

[Jun Gao]

From: Jun Gao 

Add MT7622 i2c binding to binding file and change the compatible
information formats of all SoCs to the same.

Signed-off-by: Jun Gao 
---
 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index bd5a7be..71fc0b3 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with I2C 
devices.
 
 Required properties:
   - compatible: value should be either of the following.
-  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701
-  "mediatek,mt6577-i2c": for i2c compatible with mt6577.
-  "mediatek,mt6589-i2c": for i2c compatible with mt6589.
-  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible with 
mt7623.
-  "mediatek,mt8173-i2c": for i2c compatible with mt8173.
+  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek MT2701
+  "mediatek,mt6577-i2c": for Mediatek MT6577
+  "mediatek,mt6589-i2c": for Mediatek MT6589
+  "mediatek,mt7622-i2c": for Mediatek MT7622
+  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for Mediatek MT7623
+  "mediatek,mt8173-i2c": for Mediatek MT8173
   - reg: physical base address of the controller and dma base, length of memory
 mapped region.
   - interrupts: interrupt number to the cpu.
-- 
1.8.1.1

[PATCH v2 0/2] Add i2c dt-binding and compatible for Mediatek MT7622 SoC

[Jun Gao]

This patch series based on v4.13-rc1, include MT7622 i2c dt-binding
and compatible.

changes since v1:
- Modify commit message
- Revise dt-binding documentation

Jun Gao (2):
  dt-bindings: i2c: Add MediaTek MT7622 i2c binding
  i2c: mediatek: Add i2c compatible for MediaTek MT7622

 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
 drivers/i2c/busses/i2c-mt65xx.c   | 18 ++
 2 files changed, 24 insertions(+), 5 deletions(-)

--
1.8.1.1

[PATCH v2 1/2] dt-bindings: i2c: Add MediaTek MT7622 i2c binding

[Jun Gao]

From: Jun Gao 

Add MT7622 i2c binding to binding file and change the compatible
information formats of all SoCs to the same.

Signed-off-by: Jun Gao 
---
 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index bd5a7be..71fc0b3 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with I2C 
devices.
 
 Required properties:
   - compatible: value should be either of the following.
-  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701
-  "mediatek,mt6577-i2c": for i2c compatible with mt6577.
-  "mediatek,mt6589-i2c": for i2c compatible with mt6589.
-  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible with 
mt7623.
-  "mediatek,mt8173-i2c": for i2c compatible with mt8173.
+  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek MT2701
+  "mediatek,mt6577-i2c": for Mediatek MT6577
+  "mediatek,mt6589-i2c": for Mediatek MT6589
+  "mediatek,mt7622-i2c": for Mediatek MT7622
+  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for Mediatek MT7623
+  "mediatek,mt8173-i2c": for Mediatek MT8173
   - reg: physical base address of the controller and dma base, length of memory
 mapped region.
   - interrupts: interrupt number to the cpu.
-- 
1.8.1.1

[PATCH v2 2/2] i2c: mediatek: Add i2c compatible for MediaTek MT7622

[Jun Gao]

From: Jun Gao 

Add i2c compatible for MT7622. Compare to MT8173 i2c controller,
MT7622 limits message numbers to 255, and does not support 4GB
DMA mode.

Signed-off-by: Jun Gao 
---
 drivers/i2c/busses/i2c-mt65xx.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 9bedf0b..2c7f847 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -172,6 +172,14 @@ struct mtk_i2c {
.max_comb_2nd_msg_len = 31,
 };
 
+static const struct i2c_adapter_quirks mt7622_i2c_quirks = {
+   .max_num_msgs = 255,
+   .max_write_len = 65535,
+   .max_read_len = 65535,
+   .max_comb_1st_msg_len = 65535,
+   .max_comb_2nd_msg_len = 65535,
+};
+
 static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = _i2c_quirks,
.pmic_i2c = 0,
@@ -190,6 +198,15 @@ struct mtk_i2c {
.support_33bits = 0,
 };
 
+static const struct mtk_i2c_compatible mt7622_compat = {
+   .quirks = _i2c_quirks,
+   .pmic_i2c = 0,
+   .dcm = 1,
+   .auto_restart = 1,
+   .aux_len_reg = 1,
+   .support_33bits = 0,
+};
+
 static const struct mtk_i2c_compatible mt8173_compat = {
.pmic_i2c = 0,
.dcm = 1,
@@ -201,6 +218,7 @@ struct mtk_i2c {
 static const struct of_device_id mtk_i2c_of_match[] = {
{ .compatible = "mediatek,mt6577-i2c", .data = _compat },
{ .compatible = "mediatek,mt6589-i2c", .data = _compat },
+   { .compatible = "mediatek,mt7622-i2c", .data = _compat },
{ .compatible = "mediatek,mt8173-i2c", .data = _compat },
{}
 };
-- 
1.8.1.1

[PATCH v2 2/2] i2c: mediatek: Add i2c compatible for MediaTek MT7622

[Jun Gao]

From: Jun Gao 

Add i2c compatible for MT7622. Compare to MT8173 i2c controller,
MT7622 limits message numbers to 255, and does not support 4GB
DMA mode.

Signed-off-by: Jun Gao 
---
 drivers/i2c/busses/i2c-mt65xx.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 9bedf0b..2c7f847 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -172,6 +172,14 @@ struct mtk_i2c {
.max_comb_2nd_msg_len = 31,
 };
 
+static const struct i2c_adapter_quirks mt7622_i2c_quirks = {
+   .max_num_msgs = 255,
+   .max_write_len = 65535,
+   .max_read_len = 65535,
+   .max_comb_1st_msg_len = 65535,
+   .max_comb_2nd_msg_len = 65535,
+};
+
 static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = _i2c_quirks,
.pmic_i2c = 0,
@@ -190,6 +198,15 @@ struct mtk_i2c {
.support_33bits = 0,
 };
 
+static const struct mtk_i2c_compatible mt7622_compat = {
+   .quirks = _i2c_quirks,
+   .pmic_i2c = 0,
+   .dcm = 1,
+   .auto_restart = 1,
+   .aux_len_reg = 1,
+   .support_33bits = 0,
+};
+
 static const struct mtk_i2c_compatible mt8173_compat = {
.pmic_i2c = 0,
.dcm = 1,
@@ -201,6 +218,7 @@ struct mtk_i2c {
 static const struct of_device_id mtk_i2c_of_match[] = {
{ .compatible = "mediatek,mt6577-i2c", .data = _compat },
{ .compatible = "mediatek,mt6589-i2c", .data = _compat },
+   { .compatible = "mediatek,mt7622-i2c", .data = _compat },
{ .compatible = "mediatek,mt8173-i2c", .data = _compat },
{}
 };
-- 
1.8.1.1

Re: [PATCH net-next V2 3/3] tap: XDP support

[Jason Wang]

On 2017年08月12日 07:12, Jakub Kicinski wrote:

On Fri, 11 Aug 2017 19:41:18 +0800, Jason Wang wrote:

This patch tries to implement XDP for tun. The implementation was
split into two parts:

- fast path: small and no gso packet. We try to do XDP at page level
   before build_skb(). For XDP_TX, since creating/destroying queues
   were completely under control of userspace, it was implemented
   through generic XDP helper after skb has been built. This could be
   optimized in the future.
- slow path: big or gso packet. We try to do it after skb was created
   through generic XDP helpers.

Test were done through pktgen with small packets.

xdp1 test shows ~41.1% improvement:

Before: ~1.7Mpps
After:  ~2.3Mpps

xdp_redirect to ixgbe shows ~60% improvement:

Before: ~0.8Mpps
After:  ~1.38Mpps

Suggested-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 

Looks OK to me now :)

Out of curiosity, you say the build_skb() is for "small packets", and it
seems you are always reserving the 256B regardless of XDP being
installed.  Does this have no performance impact on non-XDP case?


Have a test, only less than 1% were noticed which I think could be ignored.

Thanks

Re: [PATCH net-next V2 3/3] tap: XDP support

[Jason Wang]

On 2017年08月12日 07:12, Jakub Kicinski wrote:

On Fri, 11 Aug 2017 19:41:18 +0800, Jason Wang wrote:

This patch tries to implement XDP for tun. The implementation was
split into two parts:

- fast path: small and no gso packet. We try to do XDP at page level
   before build_skb(). For XDP_TX, since creating/destroying queues
   were completely under control of userspace, it was implemented
   through generic XDP helper after skb has been built. This could be
   optimized in the future.
- slow path: big or gso packet. We try to do it after skb was created
   through generic XDP helpers.

Test were done through pktgen with small packets.

xdp1 test shows ~41.1% improvement:

Before: ~1.7Mpps
After:  ~2.3Mpps

xdp_redirect to ixgbe shows ~60% improvement:

Before: ~0.8Mpps
After:  ~1.38Mpps

Suggested-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 

Looks OK to me now :)

Out of curiosity, you say the build_skb() is for "small packets", and it
seems you are always reserving the 256B regardless of XDP being
installed.  Does this have no performance impact on non-XDP case?


Have a test, only less than 1% were noticed which I think could be ignored.

Thanks

Re: [PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts

[Philip Prindeville]

> On Aug 11, 2017, at 8:13 PM, Philip Prindeville 
>  wrote:
> 
>> 
>> On Jul 21, 2017, at 12:48 PM, Lennart Sorensen 
>>  wrote:
>> 
>> On Fri, Jul 21, 2017 at 11:36:27AM -0700, Benjamin Poirier wrote:
>>> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
>>> adapter (when operating in msix mode) raises the Other interrupt to signal
>>> Receiver Overrun.
>>> 
>>> This is a double problem because 1) at the moment e1000_msix_other()
>>> assumes that it is only called in case of Link Status Change and 2) if the
>>> condition persists, the interrupt is repeatedly raised again in quick
>>> succession.
>>> 
>>> Ideally we would configure the Other interrupt to not be raised in case of
>>> receiver overrun but this doesn't seem possible on this adapter. Instead,
>>> we handle the first part of the problem by reverting to the practice of
>>> reading ICR in the other interrupt handler, like before commit 16ecba59bc33
>>> ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
>>> 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME
>>> from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
>>> anymore. We handle the second part of the problem by not re-enabling the
>>> Other interrupt right away when there is overrun. Instead, we wait until
>>> traffic subsides, napi polling mode is exited and interrupts are
>>> re-enabled.
>>> 
>>> Reported-by: Lennart Sorensen 
>>> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
>>> Signed-off-by: Benjamin Poirier 
>> 
>> Any chance of this fix hitting -stable?  After all adapter reset under
>> load is not nice.
>> 
> 
> 
> I tried this patch sequence and I’m seeing a 2% drop in throughput.  CPU 
> utilization at softIRQ is also about 8% higher.  The previous single patch 
> that went out to fix this problem had better performance.
> 
> This is on an Atom D525 with an 82574L and running 2 GB streams across a pair 
> of interfaces with iperf3.
> 
> -Philip


Actually, after turning off MSI-X mode (and using MSI mode instead), and 
setting InterruptRateThrottle to “4” (conservative dynamic mode) across all 
interfaces, I’m actually seeing slightly better throughput than the earlier 
patch… with comparable overall CPU utilization and SoftIRQ utilization.

So setting the module parameters correctly for routing (and not end-system 
parameters) makes a big difference when routing.

-Philip

Re: [PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts

[Philip Prindeville]

> On Aug 11, 2017, at 8:13 PM, Philip Prindeville 
>  wrote:
> 
>> 
>> On Jul 21, 2017, at 12:48 PM, Lennart Sorensen 
>>  wrote:
>> 
>> On Fri, Jul 21, 2017 at 11:36:27AM -0700, Benjamin Poirier wrote:
>>> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
>>> adapter (when operating in msix mode) raises the Other interrupt to signal
>>> Receiver Overrun.
>>> 
>>> This is a double problem because 1) at the moment e1000_msix_other()
>>> assumes that it is only called in case of Link Status Change and 2) if the
>>> condition persists, the interrupt is repeatedly raised again in quick
>>> succession.
>>> 
>>> Ideally we would configure the Other interrupt to not be raised in case of
>>> receiver overrun but this doesn't seem possible on this adapter. Instead,
>>> we handle the first part of the problem by reverting to the practice of
>>> reading ICR in the other interrupt handler, like before commit 16ecba59bc33
>>> ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
>>> 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME
>>> from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
>>> anymore. We handle the second part of the problem by not re-enabling the
>>> Other interrupt right away when there is overrun. Instead, we wait until
>>> traffic subsides, napi polling mode is exited and interrupts are
>>> re-enabled.
>>> 
>>> Reported-by: Lennart Sorensen 
>>> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
>>> Signed-off-by: Benjamin Poirier 
>> 
>> Any chance of this fix hitting -stable?  After all adapter reset under
>> load is not nice.
>> 
> 
> 
> I tried this patch sequence and I’m seeing a 2% drop in throughput.  CPU 
> utilization at softIRQ is also about 8% higher.  The previous single patch 
> that went out to fix this problem had better performance.
> 
> This is on an Atom D525 with an 82574L and running 2 GB streams across a pair 
> of interfaces with iperf3.
> 
> -Philip


Actually, after turning off MSI-X mode (and using MSI mode instead), and 
setting InterruptRateThrottle to “4” (conservative dynamic mode) across all 
interfaces, I’m actually seeing slightly better throughput than the earlier 
patch… with comparable overall CPU utilization and SoftIRQ utilization.

So setting the module parameters correctly for routing (and not end-system 
parameters) makes a big difference when routing.

-Philip

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

[Darrick J. Wong]

On Sat, Aug 12, 2017 at 10:30:34AM +1000, Dave Chinner wrote:
> On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote:
> > On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner  wrote:
> > > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote:
> > >> >From falloc.h:
> > >>
> > >> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of the
> > >> file logical-to-physical extent offset mappings in the file. The
> > >> purpose is to allow an application to assume that there are no holes
> > >> or shared extents in the file and that the metadata needed to find
> > >> all the physical extents of the file is stable and can never be
> > >> dirtied.
> > >>
> > >> For now this patch only permits setting the in-memory state of
> > >> S_IOMAP_IMMMUTABLE. Support for clearing and persisting the state is
> > >> saved for later patches.
> > >>
> > >> The implementation is careful to not allow the immutable state to change
> > >> while any process might have any established mappings. It reuses the
> > >> existing xfs_reflink_unshare() and xfs_alloc_file_space() to unshare
> > >> extents and fill all holes in the file. It then holds XFS_ILOCK_EXCL
> > >> while it validates the file is in the proper state and sets
> > >> S_IOMAP_IMMUTABLE.
> > >
> > > SO I've been thinking about this - I'm thinking that we need to
> > > separate the changes to the extent map from the action of sealing
> > > the extent map.
> > >
> > > That is, I have a need to freeze an extent map without any
> > > modification to it at all and breaking all the sharing and filling
> > > all the holes completely screws up the file layout I need to
> > > preserve. i.e. I want to be able to freeze the maps of a pair of
> > > reflinked files so I can use FIEMAP to query only the changed blocks
> > > and then read out the data in the private/changed blocks in the
> > > reflinked file. I only need a temporary seal (if we crash it goes
> > > away), so maybe there's another command modifier flag needed here,
> > > too.
> > >
> > > The DAX allocation requirements can be handled by a preallocation
> > > call to filll holes with zeros, followed by an unshare call to break
> > > all the COW mappings, and then the extent map can be sealed. If you
> > > need to check for holes after sealing, SEEK_HOLE will tell you what
> > > you need to know...
> > >
> > > My preference really is for each fallocate command to do just one
> > > thing - having the seal operation also modify the extent map
> > > means it's not useful for the use cases where we need the extent map
> > > to remain unmodified
> > >
> > > Thoughts?
> > 
> > That does seem to better follow the principle of least surprise and
> > make the interface more composable. However, for the DAX case do we
> > now end up needing a SEEK_SHARED, or something similar to check that
> > we sealed the file without shared extents?

Well, fiemap/bmap will tell you (presumably after you confirm that the
file got sealed or whatever) if there are shared extents.

> Don't we have an inode attribute flag for that? There's definitely a
> flag in the on disk XFS inode to indicate that there are shared
> extents on the file.
> 
> H - for some reason it's not exposed in FS_IOC_FSGETXATTR.
> Darrick? Any reason we don't expose the "this file has shared
> extents" flag to userspace? How are we checking that on-disk state
> in xfstests?
> 
> As it is, if we're adding an immutable extent flag, we've got to be
> able to query the immutable extent state of a file from userspace so
> I'm thinking that we'd need to expose it via the same interface that
> exposes the immutable flag. i.e. we could add the "shared extents
> present" flag to FS_IOC_FSGETXATTR at the same time...

We used to have a FSGETXATTR flag; iirc hch nak'd it during the review.

--D

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

[Darrick J. Wong]

On Sat, Aug 12, 2017 at 10:30:34AM +1000, Dave Chinner wrote:
> On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote:
> > On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner  wrote:
> > > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote:
> > >> >From falloc.h:
> > >>
> > >> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of the
> > >> file logical-to-physical extent offset mappings in the file. The
> > >> purpose is to allow an application to assume that there are no holes
> > >> or shared extents in the file and that the metadata needed to find
> > >> all the physical extents of the file is stable and can never be
> > >> dirtied.
> > >>
> > >> For now this patch only permits setting the in-memory state of
> > >> S_IOMAP_IMMMUTABLE. Support for clearing and persisting the state is
> > >> saved for later patches.
> > >>
> > >> The implementation is careful to not allow the immutable state to change
> > >> while any process might have any established mappings. It reuses the
> > >> existing xfs_reflink_unshare() and xfs_alloc_file_space() to unshare
> > >> extents and fill all holes in the file. It then holds XFS_ILOCK_EXCL
> > >> while it validates the file is in the proper state and sets
> > >> S_IOMAP_IMMUTABLE.
> > >
> > > SO I've been thinking about this - I'm thinking that we need to
> > > separate the changes to the extent map from the action of sealing
> > > the extent map.
> > >
> > > That is, I have a need to freeze an extent map without any
> > > modification to it at all and breaking all the sharing and filling
> > > all the holes completely screws up the file layout I need to
> > > preserve. i.e. I want to be able to freeze the maps of a pair of
> > > reflinked files so I can use FIEMAP to query only the changed blocks
> > > and then read out the data in the private/changed blocks in the
> > > reflinked file. I only need a temporary seal (if we crash it goes
> > > away), so maybe there's another command modifier flag needed here,
> > > too.
> > >
> > > The DAX allocation requirements can be handled by a preallocation
> > > call to filll holes with zeros, followed by an unshare call to break
> > > all the COW mappings, and then the extent map can be sealed. If you
> > > need to check for holes after sealing, SEEK_HOLE will tell you what
> > > you need to know...
> > >
> > > My preference really is for each fallocate command to do just one
> > > thing - having the seal operation also modify the extent map
> > > means it's not useful for the use cases where we need the extent map
> > > to remain unmodified
> > >
> > > Thoughts?
> > 
> > That does seem to better follow the principle of least surprise and
> > make the interface more composable. However, for the DAX case do we
> > now end up needing a SEEK_SHARED, or something similar to check that
> > we sealed the file without shared extents?

Well, fiemap/bmap will tell you (presumably after you confirm that the
file got sealed or whatever) if there are shared extents.

> Don't we have an inode attribute flag for that? There's definitely a
> flag in the on disk XFS inode to indicate that there are shared
> extents on the file.
> 
> H - for some reason it's not exposed in FS_IOC_FSGETXATTR.
> Darrick? Any reason we don't expose the "this file has shared
> extents" flag to userspace? How are we checking that on-disk state
> in xfstests?
> 
> As it is, if we're adding an immutable extent flag, we've got to be
> able to query the immutable extent state of a file from userspace so
> I'm thinking that we'd need to expose it via the same interface that
> exposes the immutable flag. i.e. we could add the "shared extents
> present" flag to FS_IOC_FSGETXATTR at the same time...

We used to have a FSGETXATTR flag; iirc hch nak'd it during the review.

--D

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] Add /proc/pid/smaps_rollup

[Daniel Colascione]

/proc/pid/smaps_rollup is a new proc file that improves the
performance of user programs that determine aggregate memory
statistics (e.g., total PSS) of a process.

Android regularly "samples" the memory usage of various processes in
order to balance its memory pool sizes. This sampling process involves
opening /proc/pid/smaps and summing certain fields. For very large
processes, sampling memory use this way can take several hundred
milliseconds, due mostly to the overhead of the seq_printf calls in
task_mmu.c.

smaps_rollup improves the situation. It contains most of the fields of
/proc/pid/smaps, but instead of a set of fields for each VMA,
smaps_rollup instead contains one synthetic smaps-format entry
representing the whole process. In the single smaps_rollup synthetic
entry, each field is the summation of the corresponding field in all
of the real-smaps VMAs. Using a common format for smaps_rollup and
smaps allows userspace parsers to repurpose parsers meant for use with
non-rollup smaps for smaps_rollup, and it allows userspace to switch
between smaps_rollup and smaps at runtime (say, based on the
availability of smaps_rollup in a given kernel) with minimal fuss.

By using smaps_rollup instead of smaps, a caller can avoid the
significant overhead of formatting, reading, and parsing each of a
large process's potentially very numerous memory mappings. For
sampling system_server's PSS in Android, we measured a 12x speedup,
representing a savings of several hundred milliseconds.

One alternative to a new per-process proc file would have been
including PSS information in /proc/pid/status. We considered this
option but thought that PSS would be too expensive (by a few orders of
magnitude) to collect relative to what's already emitted as part of
/proc/pid/status, and slowing every user of /proc/pid/status for the
sake of readers that happen to want PSS feels wrong.

The code itself works by reusing the existing VMA-walking framework we
use for regular smaps generation and keeping the mem_size_stats
structure around between VMA walks instead of using a fresh one for
each VMA.  In this way, summation happens automatically.  We let
seq_file walk over the VMAs just as it does for regular smaps and just
emit nothing to the seq_file until we hit the last VMA.

Benchmarks:

using smaps:
iterations:1000 pid:1163 pss:220023808
0m29.46s real 0m08.28s user 0m20.98s system

using smaps_rollup:
iterations:1000 pid:1163 pss:220702720
0m04.39s real 0m00.03s user 0m04.31s system

Patch changelog:

v2: Fix typo in commit message
Add ABI documentation as requested by gregkh
v3: Fix typo in ABI documentation
Add benchmarks to commit message

Signed-off-by: Daniel Colascione 
---
 Documentation/ABI/testing/procfs-smaps_rollup |  34 +
 fs/proc/base.c|   2 +
 fs/proc/internal.h|   3 +
 fs/proc/task_mmu.c| 196 ++
 4 files changed, 173 insertions(+), 62 deletions(-)
 create mode 100644 Documentation/ABI/testing/procfs-smaps_rollup

diff --git a/Documentation/ABI/testing/procfs-smaps_rollup 
b/Documentation/ABI/testing/procfs-smaps_rollup
new file mode 100644
index ..8c24138a7279
--- /dev/null
+++ b/Documentation/ABI/testing/procfs-smaps_rollup
@@ -0,0 +1,34 @@
+What:  /proc/pid/smaps_rollup
+Date:  August 2017
+Contact:   Daniel Colascione 
+Description:
+   This file provides pre-summed memory information for a
+   process.  The format is identical to /proc/pid/smaps,
+   except instead of an entry for each VMA in a process,
+   smaps_rollup has a single entry (tagged "[rollup]")
+   for which each field is the sum of the corresponding
+   fields from all the maps in /proc/pid/smaps.
+   For more details, see the procfs man page.
+
+   Typical output looks like this:
+
+   0010-ff709000 ---p  00:00 0  [rollup]
+   Rss: 884 kB
+   Pss: 385 kB
+   Shared_Clean:696 kB
+   Shared_Dirty:  0 kB
+   Private_Clean:   120 kB
+   Private_Dirty:68 kB
+   Referenced:  884 kB
+   Anonymous:68 kB
+   LazyFree:  0 kB
+   AnonHugePages: 0 kB
+   ShmemPmdMapped:0 kB
+   Shared_Hugetlb:0 kB
+   Private_Hugetlb:   0 kB
+   Swap:  0 kB
+   SwapPss:   0 kB
+   Locked:  385 kB
+
+
+   
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 719c2e943ea1..a9587b9cace5 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2930,6 +2930,7 @@ static const struct 

[PATCH v3] Add /proc/pid/smaps_rollup

[Daniel Colascione]

/proc/pid/smaps_rollup is a new proc file that improves the
performance of user programs that determine aggregate memory
statistics (e.g., total PSS) of a process.

Android regularly "samples" the memory usage of various processes in
order to balance its memory pool sizes. This sampling process involves
opening /proc/pid/smaps and summing certain fields. For very large
processes, sampling memory use this way can take several hundred
milliseconds, due mostly to the overhead of the seq_printf calls in
task_mmu.c.

smaps_rollup improves the situation. It contains most of the fields of
/proc/pid/smaps, but instead of a set of fields for each VMA,
smaps_rollup instead contains one synthetic smaps-format entry
representing the whole process. In the single smaps_rollup synthetic
entry, each field is the summation of the corresponding field in all
of the real-smaps VMAs. Using a common format for smaps_rollup and
smaps allows userspace parsers to repurpose parsers meant for use with
non-rollup smaps for smaps_rollup, and it allows userspace to switch
between smaps_rollup and smaps at runtime (say, based on the
availability of smaps_rollup in a given kernel) with minimal fuss.

By using smaps_rollup instead of smaps, a caller can avoid the
significant overhead of formatting, reading, and parsing each of a
large process's potentially very numerous memory mappings. For
sampling system_server's PSS in Android, we measured a 12x speedup,
representing a savings of several hundred milliseconds.

One alternative to a new per-process proc file would have been
including PSS information in /proc/pid/status. We considered this
option but thought that PSS would be too expensive (by a few orders of
magnitude) to collect relative to what's already emitted as part of
/proc/pid/status, and slowing every user of /proc/pid/status for the
sake of readers that happen to want PSS feels wrong.

The code itself works by reusing the existing VMA-walking framework we
use for regular smaps generation and keeping the mem_size_stats
structure around between VMA walks instead of using a fresh one for
each VMA.  In this way, summation happens automatically.  We let
seq_file walk over the VMAs just as it does for regular smaps and just
emit nothing to the seq_file until we hit the last VMA.

Benchmarks:

using smaps:
iterations:1000 pid:1163 pss:220023808
0m29.46s real 0m08.28s user 0m20.98s system

using smaps_rollup:
iterations:1000 pid:1163 pss:220702720
0m04.39s real 0m00.03s user 0m04.31s system

Patch changelog:

v2: Fix typo in commit message
Add ABI documentation as requested by gregkh
v3: Fix typo in ABI documentation
Add benchmarks to commit message

Signed-off-by: Daniel Colascione 
---
 Documentation/ABI/testing/procfs-smaps_rollup |  34 +
 fs/proc/base.c|   2 +
 fs/proc/internal.h|   3 +
 fs/proc/task_mmu.c| 196 ++
 4 files changed, 173 insertions(+), 62 deletions(-)
 create mode 100644 Documentation/ABI/testing/procfs-smaps_rollup

diff --git a/Documentation/ABI/testing/procfs-smaps_rollup 
b/Documentation/ABI/testing/procfs-smaps_rollup
new file mode 100644
index ..8c24138a7279
--- /dev/null
+++ b/Documentation/ABI/testing/procfs-smaps_rollup
@@ -0,0 +1,34 @@
+What:  /proc/pid/smaps_rollup
+Date:  August 2017
+Contact:   Daniel Colascione 
+Description:
+   This file provides pre-summed memory information for a
+   process.  The format is identical to /proc/pid/smaps,
+   except instead of an entry for each VMA in a process,
+   smaps_rollup has a single entry (tagged "[rollup]")
+   for which each field is the sum of the corresponding
+   fields from all the maps in /proc/pid/smaps.
+   For more details, see the procfs man page.
+
+   Typical output looks like this:
+
+   0010-ff709000 ---p  00:00 0  [rollup]
+   Rss: 884 kB
+   Pss: 385 kB
+   Shared_Clean:696 kB
+   Shared_Dirty:  0 kB
+   Private_Clean:   120 kB
+   Private_Dirty:68 kB
+   Referenced:  884 kB
+   Anonymous:68 kB
+   LazyFree:  0 kB
+   AnonHugePages: 0 kB
+   ShmemPmdMapped:0 kB
+   Shared_Hugetlb:0 kB
+   Private_Hugetlb:   0 kB
+   Swap:  0 kB
+   SwapPss:   0 kB
+   Locked:  385 kB
+
+
+   
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 719c2e943ea1..a9587b9cace5 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2930,6 +2930,7 @@ static const struct pid_entry tgid_base_stuff[] = {
 #ifdef 

Re: [PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts

[Philip Prindeville]

> On Jul 21, 2017, at 12:48 PM, Lennart Sorensen  
> wrote:
> 
> On Fri, Jul 21, 2017 at 11:36:27AM -0700, Benjamin Poirier wrote:
>> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
>> adapter (when operating in msix mode) raises the Other interrupt to signal
>> Receiver Overrun.
>> 
>> This is a double problem because 1) at the moment e1000_msix_other()
>> assumes that it is only called in case of Link Status Change and 2) if the
>> condition persists, the interrupt is repeatedly raised again in quick
>> succession.
>> 
>> Ideally we would configure the Other interrupt to not be raised in case of
>> receiver overrun but this doesn't seem possible on this adapter. Instead,
>> we handle the first part of the problem by reverting to the practice of
>> reading ICR in the other interrupt handler, like before commit 16ecba59bc33
>> ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
>> 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME
>> from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
>> anymore. We handle the second part of the problem by not re-enabling the
>> Other interrupt right away when there is overrun. Instead, we wait until
>> traffic subsides, napi polling mode is exited and interrupts are
>> re-enabled.
>> 
>> Reported-by: Lennart Sorensen 
>> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
>> Signed-off-by: Benjamin Poirier 
> 
> Any chance of this fix hitting -stable?  After all adapter reset under
> load is not nice.
> 


I tried this patch sequence and I’m seeing a 2% drop in throughput.  CPU 
utilization at softIRQ is also about 8% higher.  The previous single patch that 
went out to fix this problem had better performance.

This is on an Atom D525 with an 82574L and running 2 GB streams across a pair 
of interfaces with iperf3.

-Philip

Re: [PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts

[Philip Prindeville]

> On Jul 21, 2017, at 12:48 PM, Lennart Sorensen  
> wrote:
> 
> On Fri, Jul 21, 2017 at 11:36:27AM -0700, Benjamin Poirier wrote:
>> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
>> adapter (when operating in msix mode) raises the Other interrupt to signal
>> Receiver Overrun.
>> 
>> This is a double problem because 1) at the moment e1000_msix_other()
>> assumes that it is only called in case of Link Status Change and 2) if the
>> condition persists, the interrupt is repeatedly raised again in quick
>> succession.
>> 
>> Ideally we would configure the Other interrupt to not be raised in case of
>> receiver overrun but this doesn't seem possible on this adapter. Instead,
>> we handle the first part of the problem by reverting to the practice of
>> reading ICR in the other interrupt handler, like before commit 16ecba59bc33
>> ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
>> 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME
>> from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
>> anymore. We handle the second part of the problem by not re-enabling the
>> Other interrupt right away when there is overrun. Instead, we wait until
>> traffic subsides, napi polling mode is exited and interrupts are
>> re-enabled.
>> 
>> Reported-by: Lennart Sorensen 
>> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
>> Signed-off-by: Benjamin Poirier 
> 
> Any chance of this fix hitting -stable?  After all adapter reset under
> load is not nice.
> 


I tried this patch sequence and I’m seeing a 2% drop in throughput.  CPU 
utilization at softIRQ is also about 8% higher.  The previous single patch that 
went out to fix this problem had better performance.

This is on an Atom D525 with an 82574L and running 2 GB streams across a pair 
of interfaces with iperf3.

-Philip

Re: [PATCH 4.4 00/15] 4.4.82-stable review

[Shuah Khan]

On 08/11/2017 04:02 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.82 release.
> There are 15 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 13 22:02:10 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.82-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 00/15] 4.4.82-stable review

[Shuah Khan]

On 08/11/2017 04:02 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.82 release.
> There are 15 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 13 22:02:10 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.82-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/16] 4.9.43-stable review

[Shuah Khan]

On 08/11/2017 04:01 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.43 release.
> There are 16 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 13 22:01:23 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.43-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/16] 4.9.43-stable review

[Shuah Khan]

On 08/11/2017 04:01 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.43 release.
> There are 16 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 13 22:01:23 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.43-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.12 00/17] 4.12.7-stable review

[Shuah Khan]

On 08/11/2017 04:01 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.12.7 release.
> There are 17 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 13 22:00:26 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.12.7-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.12.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted ob my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.12 00/17] 4.12.7-stable review

[Shuah Khan]

On 08/11/2017 04:01 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.12.7 release.
> There are 17 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 13 22:00:26 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.12.7-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.12.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted ob my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 3.18 0/9] 3.18.65-stable review

[Shuah Khan]

On 08/11/2017 04:02 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.65 release.
> There are 9 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 13 22:02:38 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.65-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 3.18 0/9] 3.18.65-stable review

[Shuah Khan]

On 08/11/2017 04:02 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.65 release.
> There are 9 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 13 22:02:38 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.65-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[PATCH] drm/gma500: fix potential NULL pointer dereference dereference

[Gustavo A. R. Silva]

NULL check at line 528: if (!sender || !data_out || !len_out) {, implies
that pointer _sender_ might be NULL.

Move pointer _sender_ dereference after NULL check in order to avoid a
potential NULL pointer dereference.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
index 1616af2..c50534c 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -520,7 +520,7 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
u8 *data, u16 len, u32 *data_out, u16 len_out, bool hs)
 {
unsigned long flags;
-   struct drm_device *dev = sender->dev;
+   struct drm_device *dev;
int i;
u32 gen_data_reg;
int retry = MDFLD_DSI_READ_MAX_COUNT;
@@ -530,6 +530,8 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
return -EINVAL;
}
 
+   dev = sender->dev;
+
/**
 * do reading.
 * 0) send out generic read request
-- 
2.5.0

[PATCH] drm/gma500: fix potential NULL pointer dereference dereference

[Gustavo A. R. Silva]

NULL check at line 528: if (!sender || !data_out || !len_out) {, implies
that pointer _sender_ might be NULL.

Move pointer _sender_ dereference after NULL check in order to avoid a
potential NULL pointer dereference.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
index 1616af2..c50534c 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -520,7 +520,7 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
u8 *data, u16 len, u32 *data_out, u16 len_out, bool hs)
 {
unsigned long flags;
-   struct drm_device *dev = sender->dev;
+   struct drm_device *dev;
int i;
u32 gen_data_reg;
int retry = MDFLD_DSI_READ_MAX_COUNT;
@@ -530,6 +530,8 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
return -EINVAL;
}
 
+   dev = sender->dev;
+
/**
 * do reading.
 * 0) send out generic read request
-- 
2.5.0

[PATCH v3 1/2] ata: mediatek: add support for MediaTek SATA controller

[Ryder Lee]

This adds support the AHCI-compliant Serial ATA controller present
on MediaTek SoCs.

Signed-off-by: Ryder Lee 
---
 drivers/ata/Kconfig|  10 +++
 drivers/ata/Makefile   |   1 +
 drivers/ata/ahci_mtk.c | 196 +
 3 files changed, 207 insertions(+)
 create mode 100644 drivers/ata/ahci_mtk.c

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 363fc53..488c937 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -153,6 +153,16 @@ config AHCI_CEVA
 
  If unsure, say N.
 
+config AHCI_MTK
+   tristate "MediaTek AHCI SATA support"
+   depends on ARCH_MEDIATEK
+   select MFD_SYSCON
+   help
+ This option enables support for the MediaTek SoC's
+ onboard AHCI SATA controller.
+
+ If unsure, say N.
+
 config AHCI_MVEBU
tristate "Marvell EBU AHCI SATA support"
depends on ARCH_MVEBU
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index a26ef5a..ff9cd2e 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AHCI_CEVA)   += ahci_ceva.o 
libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_DA850)   += ahci_da850.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_DM816)   += ahci_dm816.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_IMX) += ahci_imx.o libahci.o libahci_platform.o
+obj-$(CONFIG_AHCI_MTK) += ahci_mtk.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_MVEBU)   += ahci_mvebu.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_OCTEON)  += ahci_octeon.o
 obj-$(CONFIG_AHCI_SUNXI)   += ahci_sunxi.o libahci.o libahci_platform.o
diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
new file mode 100644
index 000..80854f7
--- /dev/null
+++ b/drivers/ata/ahci_mtk.c
@@ -0,0 +1,196 @@
+/*
+ * MeidaTek AHCI SATA driver
+ *
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Ryder Lee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ahci.h"
+
+#define DRV_NAME   "ahci"
+
+#define SYS_CFG0x14
+#define SYS_CFG_SATA_MSK   GENMASK(31, 30)
+#define SYS_CFG_SATA_ENBIT(31)
+
+struct mtk_ahci_plat {
+   struct regmap *mode;
+   struct reset_control *axi_rst;
+   struct reset_control *sw_rst;
+   struct reset_control *reg_rst;
+};
+
+static const struct ata_port_info ahci_port_info = {
+   .flags  = AHCI_FLAG_COMMON,
+   .pio_mask   = ATA_PIO4,
+   .udma_mask  = ATA_UDMA6,
+   .port_ops   = _platform_ops,
+};
+
+static struct scsi_host_template ahci_platform_sht = {
+   AHCI_SHT(DRV_NAME),
+};
+
+static int mtk_ahci_platform_resets(struct ahci_host_priv *hpriv,
+   struct device *dev)
+{
+   struct mtk_ahci_plat *plat = hpriv->plat_data;
+   int err;
+
+   /* reset AXI bus and PHY part */
+   plat->axi_rst = devm_reset_control_get_optional_exclusive(dev, "axi");
+   if (PTR_ERR(plat->axi_rst) == -EPROBE_DEFER)
+   return PTR_ERR(plat->axi_rst);
+
+   plat->sw_rst = devm_reset_control_get_optional_exclusive(dev, "sw");
+   if (PTR_ERR(plat->sw_rst) == -EPROBE_DEFER)
+   return PTR_ERR(plat->sw_rst);
+
+   plat->reg_rst = devm_reset_control_get_optional_exclusive(dev, "reg");
+   if (PTR_ERR(plat->reg_rst) == -EPROBE_DEFER)
+   return PTR_ERR(plat->reg_rst);
+
+   err = reset_control_assert(plat->axi_rst);
+   if (err) {
+   dev_err(dev, "failed to assert AXI bus\n");
+   return err;
+   }
+
+   err = reset_control_assert(plat->sw_rst);
+   if (err) {
+   dev_err(dev, "failed to assert PHY digital part\n");
+   return err;
+   }
+
+   err = reset_control_assert(plat->reg_rst);
+   if (err) {
+   dev_err(dev, "failed to assert PHY register part\n");
+   return err;
+   }
+
+   err = reset_control_deassert(plat->reg_rst);
+   if (err) {
+   dev_err(dev, "failed to deassert PHY register part\n");
+   return err;
+   }
+
+   err = reset_control_deassert(plat->sw_rst);
+   if (err) {
+   dev_err(dev, "failed to deassert PHY digital part\n");
+   return err;
+   }
+
+   err = reset_control_deassert(plat->axi_rst);
+   if (err) {
+   dev_err(dev, 

[PATCH v3 1/2] ata: mediatek: add support for MediaTek SATA controller

[Ryder Lee]

This adds support the AHCI-compliant Serial ATA controller present
on MediaTek SoCs.

Signed-off-by: Ryder Lee 
---
 drivers/ata/Kconfig|  10 +++
 drivers/ata/Makefile   |   1 +
 drivers/ata/ahci_mtk.c | 196 +
 3 files changed, 207 insertions(+)
 create mode 100644 drivers/ata/ahci_mtk.c

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 363fc53..488c937 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -153,6 +153,16 @@ config AHCI_CEVA
 
  If unsure, say N.
 
+config AHCI_MTK
+   tristate "MediaTek AHCI SATA support"
+   depends on ARCH_MEDIATEK
+   select MFD_SYSCON
+   help
+ This option enables support for the MediaTek SoC's
+ onboard AHCI SATA controller.
+
+ If unsure, say N.
+
 config AHCI_MVEBU
tristate "Marvell EBU AHCI SATA support"
depends on ARCH_MVEBU
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index a26ef5a..ff9cd2e 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AHCI_CEVA)   += ahci_ceva.o 
libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_DA850)   += ahci_da850.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_DM816)   += ahci_dm816.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_IMX) += ahci_imx.o libahci.o libahci_platform.o
+obj-$(CONFIG_AHCI_MTK) += ahci_mtk.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_MVEBU)   += ahci_mvebu.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_OCTEON)  += ahci_octeon.o
 obj-$(CONFIG_AHCI_SUNXI)   += ahci_sunxi.o libahci.o libahci_platform.o
diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
new file mode 100644
index 000..80854f7
--- /dev/null
+++ b/drivers/ata/ahci_mtk.c
@@ -0,0 +1,196 @@
+/*
+ * MeidaTek AHCI SATA driver
+ *
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Ryder Lee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ahci.h"
+
+#define DRV_NAME   "ahci"
+
+#define SYS_CFG0x14
+#define SYS_CFG_SATA_MSK   GENMASK(31, 30)
+#define SYS_CFG_SATA_ENBIT(31)
+
+struct mtk_ahci_plat {
+   struct regmap *mode;
+   struct reset_control *axi_rst;
+   struct reset_control *sw_rst;
+   struct reset_control *reg_rst;
+};
+
+static const struct ata_port_info ahci_port_info = {
+   .flags  = AHCI_FLAG_COMMON,
+   .pio_mask   = ATA_PIO4,
+   .udma_mask  = ATA_UDMA6,
+   .port_ops   = _platform_ops,
+};
+
+static struct scsi_host_template ahci_platform_sht = {
+   AHCI_SHT(DRV_NAME),
+};
+
+static int mtk_ahci_platform_resets(struct ahci_host_priv *hpriv,
+   struct device *dev)
+{
+   struct mtk_ahci_plat *plat = hpriv->plat_data;
+   int err;
+
+   /* reset AXI bus and PHY part */
+   plat->axi_rst = devm_reset_control_get_optional_exclusive(dev, "axi");
+   if (PTR_ERR(plat->axi_rst) == -EPROBE_DEFER)
+   return PTR_ERR(plat->axi_rst);
+
+   plat->sw_rst = devm_reset_control_get_optional_exclusive(dev, "sw");
+   if (PTR_ERR(plat->sw_rst) == -EPROBE_DEFER)
+   return PTR_ERR(plat->sw_rst);
+
+   plat->reg_rst = devm_reset_control_get_optional_exclusive(dev, "reg");
+   if (PTR_ERR(plat->reg_rst) == -EPROBE_DEFER)
+   return PTR_ERR(plat->reg_rst);
+
+   err = reset_control_assert(plat->axi_rst);
+   if (err) {
+   dev_err(dev, "failed to assert AXI bus\n");
+   return err;
+   }
+
+   err = reset_control_assert(plat->sw_rst);
+   if (err) {
+   dev_err(dev, "failed to assert PHY digital part\n");
+   return err;
+   }
+
+   err = reset_control_assert(plat->reg_rst);
+   if (err) {
+   dev_err(dev, "failed to assert PHY register part\n");
+   return err;
+   }
+
+   err = reset_control_deassert(plat->reg_rst);
+   if (err) {
+   dev_err(dev, "failed to deassert PHY register part\n");
+   return err;
+   }
+
+   err = reset_control_deassert(plat->sw_rst);
+   if (err) {
+   dev_err(dev, "failed to deassert PHY digital part\n");
+   return err;
+   }
+
+   err = reset_control_deassert(plat->axi_rst);
+   if (err) {
+   dev_err(dev, "failed to deassert AXI bus\n");
+   

[PATCH v3 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller

[Ryder Lee]

Add DT bindings for the onboard SATA controller present on the MediaTek
SoCs.

Signed-off-by: Ryder Lee 
---
 Documentation/devicetree/bindings/ata/ahci-mtk.txt | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt

diff --git a/Documentation/devicetree/bindings/ata/ahci-mtk.txt 
b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
new file mode 100644
index 000..96c8d22
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
@@ -0,0 +1,51 @@
+MediaTek Serial ATA controller
+
+Required properties:
+ - compatible : Must be "mediatek,soc-model-ahci", "mediatek,mtk-ahci".
+When using "mediatek,mtk-ahci" compatible strings, you
+need SoC specific ones in addition, one of:
+- "mediatek,mt7622-ahci"
+ - reg: Physical base addresses and length of register sets.
+ - interrupts : Interrupt associated with the SATA device.
+ - interrupt-names : Associated name must be: "hostc".
+ - clocks : A list of phandle and clock specifier pairs, one for each
+entry in clock-names.
+ - clock-names: Associated names must be: "ahb", "axi", "asic", "rbc", 
"pm".
+ - phys   : A phandle and PHY specifier pair for the PHY port.
+ - phy-names  : Associated name must be: "sata-phy".
+ - ports-implemented : See ./ahci-platform.txt for details.
+
+Optional properties:
+ - power-domains   : A phandle and power domain specifier pair to the power
+domain which is responsible for collapsing and restoring
+power to the peripheral.
+ - resets : Must contain an entry for each entry in reset-names.
+See ../reset/reset.txt for details.
+ - reset-names: Associated names must be: "axi", "sw", "reg".
+ - mediatek,phy-mode : A phandle to the system controller, used to enable
+  SATA function.
+
+Example:
+
+   sata: sata@1a20 {
+   compatible = "mediatek,mt7622-ahci",
+"mediatek,mtk-ahci";
+   reg = <0 0x1a20 0 0x1100>;
+   interrupts = ;
+   interrupt-names = "hostc";
+   clocks = < CLK_SATA_AHB_EN>,
+< CLK_SATA_AXI_EN>,
+< CLK_SATA_ASIC_EN>,
+< CLK_SATA_RBC_EN>,
+< CLK_SATA_PM_EN>;
+   clock-names = "ahb", "axi", "asic", "rbc", "pm";
+   phys = < PHY_TYPE_SATA>;
+   phy-names = "sata-phy";
+   ports-implemented = <0x1>;
+   power-domains = < MT7622_POWER_DOMAIN_HIF0>;
+   resets = < MT7622_SATA_AXI_BUS_RST>,
+< MT7622_SATA_PHY_SW_RST>,
+< MT7622_SATA_PHY_REG_RST>;
+   reset-names = "axi", "sw", "reg";
+   mediatek,phy-mode = <>;
+   };
-- 
1.9.1

[PATCH v3 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller

[Ryder Lee]

Add DT bindings for the onboard SATA controller present on the MediaTek
SoCs.

Signed-off-by: Ryder Lee 
---
 Documentation/devicetree/bindings/ata/ahci-mtk.txt | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt

diff --git a/Documentation/devicetree/bindings/ata/ahci-mtk.txt 
b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
new file mode 100644
index 000..96c8d22
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
@@ -0,0 +1,51 @@
+MediaTek Serial ATA controller
+
+Required properties:
+ - compatible : Must be "mediatek,soc-model-ahci", "mediatek,mtk-ahci".
+When using "mediatek,mtk-ahci" compatible strings, you
+need SoC specific ones in addition, one of:
+- "mediatek,mt7622-ahci"
+ - reg: Physical base addresses and length of register sets.
+ - interrupts : Interrupt associated with the SATA device.
+ - interrupt-names : Associated name must be: "hostc".
+ - clocks : A list of phandle and clock specifier pairs, one for each
+entry in clock-names.
+ - clock-names: Associated names must be: "ahb", "axi", "asic", "rbc", 
"pm".
+ - phys   : A phandle and PHY specifier pair for the PHY port.
+ - phy-names  : Associated name must be: "sata-phy".
+ - ports-implemented : See ./ahci-platform.txt for details.
+
+Optional properties:
+ - power-domains   : A phandle and power domain specifier pair to the power
+domain which is responsible for collapsing and restoring
+power to the peripheral.
+ - resets : Must contain an entry for each entry in reset-names.
+See ../reset/reset.txt for details.
+ - reset-names: Associated names must be: "axi", "sw", "reg".
+ - mediatek,phy-mode : A phandle to the system controller, used to enable
+  SATA function.
+
+Example:
+
+   sata: sata@1a20 {
+   compatible = "mediatek,mt7622-ahci",
+"mediatek,mtk-ahci";
+   reg = <0 0x1a20 0 0x1100>;
+   interrupts = ;
+   interrupt-names = "hostc";
+   clocks = < CLK_SATA_AHB_EN>,
+< CLK_SATA_AXI_EN>,
+< CLK_SATA_ASIC_EN>,
+< CLK_SATA_RBC_EN>,
+< CLK_SATA_PM_EN>;
+   clock-names = "ahb", "axi", "asic", "rbc", "pm";
+   phys = < PHY_TYPE_SATA>;
+   phy-names = "sata-phy";
+   ports-implemented = <0x1>;
+   power-domains = < MT7622_POWER_DOMAIN_HIF0>;
+   resets = < MT7622_SATA_AXI_BUS_RST>,
+< MT7622_SATA_PHY_SW_RST>,
+< MT7622_SATA_PHY_REG_RST>;
+   reset-names = "axi", "sw", "reg";
+   mediatek,phy-mode = <>;
+   };
-- 
1.9.1

[PATCH v3 0/2] Add support for MediaTek AHCI SATA

[Ryder Lee]

Hi,

This patch series add support for AHCI compatible SATA controller, and it is
compliant with the ahci 1.3 and sata 3.0 specification. This driver is slightly
different than ahci_platform.c (e.g., reset control, subsystem setting).

changes since v3:
- update binding text: fix a typo and modify compatible strings.

changes since v2:
- according to Commit a53e35db70d1 ("reset: Ensure drivers are explicit when 
requesting reset lines").
  replace devm_reset_control_get_optional() by 
devm_reset_control_get_optional_exclusive().

changes since v1:
- update binding text: add missing "specifier pairs" descriptions.
- fix kbuild test warning: fix the error handling.

Ryder Lee (2):
  ata: mediatek: add support for MediaTek SATA controller
  dt-bindings: ata: add DT bindings for MediaTek SATA controller

 Documentation/devicetree/bindings/ata/ahci-mtk.txt |  51 ++
 drivers/ata/Kconfig|  10 ++
 drivers/ata/Makefile   |   1 +
 drivers/ata/ahci_mtk.c | 196 +
 4 files changed, 258 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt
 create mode 100644 drivers/ata/ahci_mtk.c

-- 
1.9.1

[PATCH v3 0/2] Add support for MediaTek AHCI SATA

[Ryder Lee]

Hi,

This patch series add support for AHCI compatible SATA controller, and it is
compliant with the ahci 1.3 and sata 3.0 specification. This driver is slightly
different than ahci_platform.c (e.g., reset control, subsystem setting).

changes since v3:
- update binding text: fix a typo and modify compatible strings.

changes since v2:
- according to Commit a53e35db70d1 ("reset: Ensure drivers are explicit when 
requesting reset lines").
  replace devm_reset_control_get_optional() by 
devm_reset_control_get_optional_exclusive().

changes since v1:
- update binding text: add missing "specifier pairs" descriptions.
- fix kbuild test warning: fix the error handling.

Ryder Lee (2):
  ata: mediatek: add support for MediaTek SATA controller
  dt-bindings: ata: add DT bindings for MediaTek SATA controller

 Documentation/devicetree/bindings/ata/ahci-mtk.txt |  51 ++
 drivers/ata/Kconfig|  10 ++
 drivers/ata/Makefile   |   1 +
 drivers/ata/ahci_mtk.c | 196 +
 4 files changed, 258 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt
 create mode 100644 drivers/ata/ahci_mtk.c

-- 
1.9.1

Re: [PATCH] PCI: mediatek: add msi support for mt2712 and mt7622

[Ryder Lee]

Hi Honghui,

On Fri, 2017-08-11 at 20:27 +0800, honghui.zh...@mediatek.com wrote:
...
> +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> +{
> + u32 val;
> +
> + val = lower_32_bits((u64)(port->base + PCIE_MSI_VECTOR));
> + writel(val, port->base + PCIE_IMSI_ADDR);
> +
> + val = readl(port->base + PCIE_INT_MASK);
> + val &= ~MSI_MASK;
> + writel(val, port->base + PCIE_INT_MASK);
> +}
> +
>  static int mtk_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
>irq_hw_number_t hwirq)
>  {
> @@ -460,6 +574,18 @@ static int mtk_pcie_init_irq_domain(struct mtk_pcie_port 
> *port,
>   return PTR_ERR(port->irq_domain);
>   }
>  
> + /* Setup MSI */
> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> + port->msi_domain = irq_domain_add_linear(node, MTK_MSI_IRQS_NUM,
> +  _domain_ops,
> +  _pcie_msi_chip);
> + if (!port->msi_domain) {
> + dev_err(dev, "Failed to get a MSI IRQ domain\n");
> + return PTR_ERR(port->msi_domain);

Just return -ENOMEM. PTR_ERR(NULL) will cause a static checker warning.

> + }
> + mtk_pcie_enable_msi(port);
> + }
> +
>   return 0;
>  }

Ryder

Re: [PATCH] PCI: mediatek: add msi support for mt2712 and mt7622

[Ryder Lee]

Hi Honghui,

On Fri, 2017-08-11 at 20:27 +0800, honghui.zh...@mediatek.com wrote:
...
> +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> +{
> + u32 val;
> +
> + val = lower_32_bits((u64)(port->base + PCIE_MSI_VECTOR));
> + writel(val, port->base + PCIE_IMSI_ADDR);
> +
> + val = readl(port->base + PCIE_INT_MASK);
> + val &= ~MSI_MASK;
> + writel(val, port->base + PCIE_INT_MASK);
> +}
> +
>  static int mtk_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
>irq_hw_number_t hwirq)
>  {
> @@ -460,6 +574,18 @@ static int mtk_pcie_init_irq_domain(struct mtk_pcie_port 
> *port,
>   return PTR_ERR(port->irq_domain);
>   }
>  
> + /* Setup MSI */
> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> + port->msi_domain = irq_domain_add_linear(node, MTK_MSI_IRQS_NUM,
> +  _domain_ops,
> +  _pcie_msi_chip);
> + if (!port->msi_domain) {
> + dev_err(dev, "Failed to get a MSI IRQ domain\n");
> + return PTR_ERR(port->msi_domain);

Just return -ENOMEM. PTR_ERR(NULL) will cause a static checker warning.

> + }
> + mtk_pcie_enable_msi(port);
> + }
> +
>   return 0;
>  }

Ryder

Re: [PATCH] ASoC: hdmi-codec: Use different name for playback streams

[jeffy]

Hi Brian,

Thanks for noting.

On 08/12/2017 12:59 AM, Brian Norris wrote:

Hi Jeffy,

You need to be more careful about the addressee's of your patches. No
one on To/CC is a maintainer or a sufficiently-targeted mailing list. I
doubt any of the maintainers will read your patch. (I've added
alsa-devel for you, but given my understanding of at least Mark's
patchwork workflow -- and of general patch etiquette -- it's important
the patch is actually sent there in the first place.)

Probably worth resending.

Ok, will do that.

I was using patman to send it, not sure why it didn't work correctly 
that time...

Re: [PATCH] ASoC: hdmi-codec: Use different name for playback streams

[jeffy]

Hi Brian,

Thanks for noting.

On 08/12/2017 12:59 AM, Brian Norris wrote:

Hi Jeffy,

You need to be more careful about the addressee's of your patches. No
one on To/CC is a maintainer or a sufficiently-targeted mailing list. I
doubt any of the maintainers will read your patch. (I've added
alsa-devel for you, but given my understanding of at least Mark's
patchwork workflow -- and of general patch etiquette -- it's important
the patch is actually sent there in the first place.)

Probably worth resending.

Ok, will do that.

I was using patman to send it, not sure why it didn't work correctly 
that time...

[PATCH -tip v2 2/2] kprobes/x86: Remove addressof operators

[Masami Hiramatsu]

Since commit 54a7d50b9205 ("x86: mark kprobe templates as
character arrays, not single characters") changes
optprobe_template_* to arrays, we can remove addressof
operators from those symbols.

Signed-off-by: Masami Hiramatsu 
---
 arch/x86/include/asm/kprobes.h |4 ++--
 arch/x86/kernel/kprobes/opt.c  |8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kprobes.h b/arch/x86/include/asm/kprobes.h
index 6cf65437b5e5..9f2e3102e0bb 100644
--- a/arch/x86/include/asm/kprobes.h
+++ b/arch/x86/include/asm/kprobes.h
@@ -58,8 +58,8 @@ extern __visible kprobe_opcode_t optprobe_template_call[];
 extern __visible kprobe_opcode_t optprobe_template_end[];
 #define MAX_OPTIMIZED_LENGTH (MAX_INSN_SIZE + RELATIVE_ADDR_SIZE)
 #define MAX_OPTINSN_SIZE   \
-   (((unsigned long)_template_end -   \
- (unsigned long)_template_entry) +\
+   (((unsigned long)optprobe_template_end -\
+ (unsigned long)optprobe_template_entry) + \
 MAX_OPTIMIZED_LENGTH + RELATIVEJUMP_SIZE)
 
 extern const int kretprobe_blacklist_size;
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 86b9a883b712..d85fac42b512 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -142,11 +142,11 @@ void optprobe_template_func(void);
 STACK_FRAME_NON_STANDARD(optprobe_template_func);
 
 #define TMPL_MOVE_IDX \
-   ((long)_template_val - (long)_template_entry)
+   ((long)optprobe_template_val - (long)optprobe_template_entry)
 #define TMPL_CALL_IDX \
-   ((long)_template_call - (long)_template_entry)
+   ((long)optprobe_template_call - (long)optprobe_template_entry)
 #define TMPL_END_IDX \
-   ((long)_template_end - (long)_template_entry)
+   ((long)optprobe_template_end - (long)optprobe_template_entry)
 
 #define INT3_SIZE sizeof(kprobe_opcode_t)
 
@@ -377,7 +377,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe 
*op,
op->optinsn.size = ret;
 
/* Copy arch-dep-instance from template */
-   memcpy(buf, _template_entry, TMPL_END_IDX);
+   memcpy(buf, optprobe_template_entry, TMPL_END_IDX);
 
/* Set probe information */
synthesize_set_arg1(buf + TMPL_MOVE_IDX, (unsigned long)op);

[PATCH -tip v2 2/2] kprobes/x86: Remove addressof operators

[Masami Hiramatsu]

Since commit 54a7d50b9205 ("x86: mark kprobe templates as
character arrays, not single characters") changes
optprobe_template_* to arrays, we can remove addressof
operators from those symbols.

Signed-off-by: Masami Hiramatsu 
---
 arch/x86/include/asm/kprobes.h |4 ++--
 arch/x86/kernel/kprobes/opt.c  |8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kprobes.h b/arch/x86/include/asm/kprobes.h
index 6cf65437b5e5..9f2e3102e0bb 100644
--- a/arch/x86/include/asm/kprobes.h
+++ b/arch/x86/include/asm/kprobes.h
@@ -58,8 +58,8 @@ extern __visible kprobe_opcode_t optprobe_template_call[];
 extern __visible kprobe_opcode_t optprobe_template_end[];
 #define MAX_OPTIMIZED_LENGTH (MAX_INSN_SIZE + RELATIVE_ADDR_SIZE)
 #define MAX_OPTINSN_SIZE   \
-   (((unsigned long)_template_end -   \
- (unsigned long)_template_entry) +\
+   (((unsigned long)optprobe_template_end -\
+ (unsigned long)optprobe_template_entry) + \
 MAX_OPTIMIZED_LENGTH + RELATIVEJUMP_SIZE)
 
 extern const int kretprobe_blacklist_size;
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 86b9a883b712..d85fac42b512 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -142,11 +142,11 @@ void optprobe_template_func(void);
 STACK_FRAME_NON_STANDARD(optprobe_template_func);
 
 #define TMPL_MOVE_IDX \
-   ((long)_template_val - (long)_template_entry)
+   ((long)optprobe_template_val - (long)optprobe_template_entry)
 #define TMPL_CALL_IDX \
-   ((long)_template_call - (long)_template_entry)
+   ((long)optprobe_template_call - (long)optprobe_template_entry)
 #define TMPL_END_IDX \
-   ((long)_template_end - (long)_template_entry)
+   ((long)optprobe_template_end - (long)optprobe_template_entry)
 
 #define INT3_SIZE sizeof(kprobe_opcode_t)
 
@@ -377,7 +377,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe 
*op,
op->optinsn.size = ret;
 
/* Copy arch-dep-instance from template */
-   memcpy(buf, _template_entry, TMPL_END_IDX);
+   memcpy(buf, optprobe_template_entry, TMPL_END_IDX);
 
/* Set probe information */
synthesize_set_arg1(buf + TMPL_MOVE_IDX, (unsigned long)op);

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[Wei Wang]

> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch  (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.
>

Great. Thanks.

> Do you still want feedback on the previous changes?

If this patch is good, then I don't really need the previous feedback.

Thanks.
Wei


On Fri, Aug 11, 2017 at 5:31 PM, John Stultz  wrote:
> On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang  wrote:
>>> If after Cong's fix, the issue still happens, could you help try the
>>> patch attached and collect all logs when you try the reproduce the
>>> issue? It would be great to have logs for both success case and the
>>> failure case.
>>>
>>> Thanks so much for your help.
>>>
>>
>> I think we have a potential fix for this issue.
>> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
>> possible that rt6->dst.dev points to loopback device while
>> rt6->rt6i_idev->dev points to a real device.
>> When the real device goes down, the current fib6 clean up code only
>> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
>> That leaves unreleased refcnt on the real device if rt6->dst.dev
>> points to loopback dev.
>>
>> The attached potential fix is tested by Martin and made sure it fixes his 
>> issue.
>>
>> John,
>> It will be great if you can also give it a try and see if it fixes the
>> issue on your side before I submit an official patch.
>
> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch  (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.
>
> Do you still want feedback on the previous changes?
>
> thanks
> -john

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[Wei Wang]

> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch  (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.
>

Great. Thanks.

> Do you still want feedback on the previous changes?

If this patch is good, then I don't really need the previous feedback.

Thanks.
Wei


On Fri, Aug 11, 2017 at 5:31 PM, John Stultz  wrote:
> On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang  wrote:
>>> If after Cong's fix, the issue still happens, could you help try the
>>> patch attached and collect all logs when you try the reproduce the
>>> issue? It would be great to have logs for both success case and the
>>> failure case.
>>>
>>> Thanks so much for your help.
>>>
>>
>> I think we have a potential fix for this issue.
>> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
>> possible that rt6->dst.dev points to loopback device while
>> rt6->rt6i_idev->dev points to a real device.
>> When the real device goes down, the current fib6 clean up code only
>> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
>> That leaves unreleased refcnt on the real device if rt6->dst.dev
>> points to loopback dev.
>>
>> The attached potential fix is tested by Martin and made sure it fixes his 
>> issue.
>>
>> John,
>> It will be great if you can also give it a try and see if it fixes the
>> issue on your side before I submit an official patch.
>
> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch  (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.
>
> Do you still want feedback on the previous changes?
>
> thanks
> -john

[PATCH -tip v2 1/2] kprobes/x86: Don't forget to set memory back to RO on failure

[Masami Hiramatsu]

Do not forget to set kprobes insn buffer memory back
to RO on failure path. Without this fix, if there is
an unexpected error on copying instructions, kprobes
insn buffer kept RW, which can allow unexpected modifying
instruction buffer.

Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Masami Hiramatsu 
---
  Changes in v2:
   - Use a helper variable instead of using p->ainsn.insn directly.
---
 arch/x86/kernel/kprobes/core.c |   15 +--
 arch/x86/kernel/kprobes/opt.c  |1 +
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index f0153714ddac..5d8194b9a068 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -428,15 +428,18 @@ void free_insn_page(void *page)
 
 static int arch_copy_kprobe(struct kprobe *p)
 {
+   kprobe_opcode_t *buf = p->ainsn.insn;
struct insn insn;
int len;
 
-   set_memory_rw((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+   set_memory_rw((unsigned long)buf & PAGE_MASK, 1);
 
/* Copy an instruction with recovering if other optprobe modifies it.*/
-   len = __copy_instruction(p->ainsn.insn, p->addr, );
-   if (!len)
+   len = __copy_instruction(buf, p->addr, );
+   if (!len) {
+   set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
return -EINVAL;
+   }
 
/*
 * __copy_instruction can modify the displacement of the instruction,
@@ -444,13 +447,13 @@ static int arch_copy_kprobe(struct kprobe *p)
 */
prepare_boost(p, );
 
-   set_memory_ro((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+   set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
 
/* Check whether the instruction modifies Interrupt Flag or not */
-   p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);
+   p->ainsn.if_modifier = is_IF_modifier(buf);
 
/* Also, displacement change doesn't affect the first byte */
-   p->opcode = p->ainsn.insn[0];
+   p->opcode = buf[0];
 
return 0;
 }
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 4f98aad38237..86b9a883b712 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -371,6 +371,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe 
*op,
ret = copy_optimized_instructions(buf + TMPL_END_IDX, op->kp.addr);
if (ret < 0) {
__arch_remove_optimized_kprobe(op, 0);
+   set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
return ret;
}
op->optinsn.size = ret;

[PATCH -tip v2 1/2] kprobes/x86: Don't forget to set memory back to RO on failure

[Masami Hiramatsu]

Do not forget to set kprobes insn buffer memory back
to RO on failure path. Without this fix, if there is
an unexpected error on copying instructions, kprobes
insn buffer kept RW, which can allow unexpected modifying
instruction buffer.

Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Masami Hiramatsu 
---
  Changes in v2:
   - Use a helper variable instead of using p->ainsn.insn directly.
---
 arch/x86/kernel/kprobes/core.c |   15 +--
 arch/x86/kernel/kprobes/opt.c  |1 +
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index f0153714ddac..5d8194b9a068 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -428,15 +428,18 @@ void free_insn_page(void *page)
 
 static int arch_copy_kprobe(struct kprobe *p)
 {
+   kprobe_opcode_t *buf = p->ainsn.insn;
struct insn insn;
int len;
 
-   set_memory_rw((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+   set_memory_rw((unsigned long)buf & PAGE_MASK, 1);
 
/* Copy an instruction with recovering if other optprobe modifies it.*/
-   len = __copy_instruction(p->ainsn.insn, p->addr, );
-   if (!len)
+   len = __copy_instruction(buf, p->addr, );
+   if (!len) {
+   set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
return -EINVAL;
+   }
 
/*
 * __copy_instruction can modify the displacement of the instruction,
@@ -444,13 +447,13 @@ static int arch_copy_kprobe(struct kprobe *p)
 */
prepare_boost(p, );
 
-   set_memory_ro((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+   set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
 
/* Check whether the instruction modifies Interrupt Flag or not */
-   p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);
+   p->ainsn.if_modifier = is_IF_modifier(buf);
 
/* Also, displacement change doesn't affect the first byte */
-   p->opcode = p->ainsn.insn[0];
+   p->opcode = buf[0];
 
return 0;
 }
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 4f98aad38237..86b9a883b712 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -371,6 +371,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe 
*op,
ret = copy_optimized_instructions(buf + TMPL_END_IDX, op->kp.addr);
if (ret < 0) {
__arch_remove_optimized_kprobe(op, 0);
+   set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
return ret;
}
op->optinsn.size = ret;

[PATCH -tip v2 0/2] kprobes/x86: RO text code bugfix and cleanup

[Masami Hiramatsu]

Hi,

This series fixes a kprobe-x86 bug related to RO text and
cleans up addressof operators.

The first one is an obvious bug that misses to set memory
RO when the function fails. And the second one is just a
cleanup patch to remove addressof operators ("&") since
it is meaningless anymore.

V2 has just a following update:
 - [1/2] Use a helper variable instead of using p->ainsn.insn
   directly.

Thanks,

---

Masami Hiramatsu (2):
  kprobes/x86: Don't forget to set memory back to RO on failure
  kprobes/x86: Remove addressof operators


 arch/x86/include/asm/kprobes.h |4 ++--
 arch/x86/kernel/kprobes/core.c |   15 +--
 arch/x86/kernel/kprobes/opt.c  |9 +
 3 files changed, 16 insertions(+), 12 deletions(-)

--
Masami Hiramatsu 

[PATCH -tip v2 0/2] kprobes/x86: RO text code bugfix and cleanup

[Masami Hiramatsu]

Hi,

This series fixes a kprobe-x86 bug related to RO text and
cleans up addressof operators.

The first one is an obvious bug that misses to set memory
RO when the function fails. And the second one is just a
cleanup patch to remove addressof operators ("&") since
it is meaningless anymore.

V2 has just a following update:
 - [1/2] Use a helper variable instead of using p->ainsn.insn
   directly.

Thanks,

---

Masami Hiramatsu (2):
  kprobes/x86: Don't forget to set memory back to RO on failure
  kprobes/x86: Remove addressof operators


 arch/x86/include/asm/kprobes.h |4 ++--
 arch/x86/kernel/kprobes/core.c |   15 +--
 arch/x86/kernel/kprobes/opt.c  |9 +
 3 files changed, 16 insertions(+), 12 deletions(-)

--
Masami Hiramatsu 

[RESENT PATCH] ASoC: hdmi-codec: Use different name for playback streams

[Jeffy Chen]

Currently the hdmi i2s playback stream and hdmi spdif playback stream
are using the same name. So when they are enabled at the same time,
kernel will print this warning:

[2.201835] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: Failed to
create Playback debugfs file

Assign different names to them to avoid that.

Signed-off-by: Jeffy Chen 
---

 sound/soc/codecs/hdmi-codec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 509ab51..a2af440 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -696,7 +696,7 @@ static struct snd_soc_dai_driver hdmi_i2s_dai = {
.name = "i2s-hifi",
.id = DAI_ID_I2S,
.playback = {
-   .stream_name = "Playback",
+   .stream_name = "I2S Playback",
.channels_min = 2,
.channels_max = 8,
.rates = HDMI_RATES,
@@ -711,7 +711,7 @@ static const struct snd_soc_dai_driver hdmi_spdif_dai = {
.name = "spdif-hifi",
.id = DAI_ID_SPDIF,
.playback = {
-   .stream_name = "Playback",
+   .stream_name = "SPDIF Playback",
.channels_min = 2,
.channels_max = 2,
.rates = HDMI_RATES,
-- 
2.1.4

[RESENT PATCH] ASoC: hdmi-codec: Use different name for playback streams

[Jeffy Chen]

Currently the hdmi i2s playback stream and hdmi spdif playback stream
are using the same name. So when they are enabled at the same time,
kernel will print this warning:

[2.201835] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: Failed to
create Playback debugfs file

Assign different names to them to avoid that.

Signed-off-by: Jeffy Chen 
---

 sound/soc/codecs/hdmi-codec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 509ab51..a2af440 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -696,7 +696,7 @@ static struct snd_soc_dai_driver hdmi_i2s_dai = {
.name = "i2s-hifi",
.id = DAI_ID_I2S,
.playback = {
-   .stream_name = "Playback",
+   .stream_name = "I2S Playback",
.channels_min = 2,
.channels_max = 8,
.rates = HDMI_RATES,
@@ -711,7 +711,7 @@ static const struct snd_soc_dai_driver hdmi_spdif_dai = {
.name = "spdif-hifi",
.id = DAI_ID_SPDIF,
.playback = {
-   .stream_name = "Playback",
+   .stream_name = "SPDIF Playback",
.channels_min = 2,
.channels_max = 2,
.rates = HDMI_RATES,
-- 
2.1.4

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[John Stultz]

On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang  wrote:
>> If after Cong's fix, the issue still happens, could you help try the
>> patch attached and collect all logs when you try the reproduce the
>> issue? It would be great to have logs for both success case and the
>> failure case.
>>
>> Thanks so much for your help.
>>
>
> I think we have a potential fix for this issue.
> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
> possible that rt6->dst.dev points to loopback device while
> rt6->rt6i_idev->dev points to a real device.
> When the real device goes down, the current fib6 clean up code only
> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
> That leaves unreleased refcnt on the real device if rt6->dst.dev
> points to loopback dev.
>
> The attached potential fix is tested by Martin and made sure it fixes his 
> issue.
>
> John,
> It will be great if you can also give it a try and see if it fixes the
> issue on your side before I submit an official patch.

So yes, sorry I haven't been able to get back quicker on the other
patches sent, was mucking about in other work.

So yea, this patch  (potential fix for unregister_netdevice()) seems
to avoid the issue.

I'm going to do some further testing, but its looking good so far.

Do you still want feedback on the previous changes?

thanks
-john

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[John Stultz]

On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang  wrote:
>> If after Cong's fix, the issue still happens, could you help try the
>> patch attached and collect all logs when you try the reproduce the
>> issue? It would be great to have logs for both success case and the
>> failure case.
>>
>> Thanks so much for your help.
>>
>
> I think we have a potential fix for this issue.
> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
> possible that rt6->dst.dev points to loopback device while
> rt6->rt6i_idev->dev points to a real device.
> When the real device goes down, the current fib6 clean up code only
> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
> That leaves unreleased refcnt on the real device if rt6->dst.dev
> points to loopback dev.
>
> The attached potential fix is tested by Martin and made sure it fixes his 
> issue.
>
> John,
> It will be great if you can also give it a try and see if it fixes the
> issue on your side before I submit an official patch.

So yes, sorry I haven't been able to get back quicker on the other
patches sent, was mucking about in other work.

So yea, this patch  (potential fix for unregister_netdevice()) seems
to avoid the issue.

I'm going to do some further testing, but its looking good so far.

Do you still want feedback on the previous changes?

thanks
-john