Re: [PATCH 0/3] sched: Fix wakeup preemption regression

[Mike Galbraith]

On Tue, 2016-05-10 at 19:43 +0200, Peter Zijlstra wrote:

> Mike, Pavan, could you guys please confirm?

Plugging the series into master.today, all seems peachy on my end.

-Mike

Re: [PATCH 0/3] sched: Fix wakeup preemption regression

[Mike Galbraith]

On Tue, 2016-05-10 at 19:43 +0200, Peter Zijlstra wrote:

> Mike, Pavan, could you guys please confirm?

Plugging the series into master.today, all seems peachy on my end.

-Mike

[PATCH 6/8] ARM: dts: AM437X-SK-EVM: Remove redundant regulator compatibles

[Keerthy]

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am437x-sk-evm.dts | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
b/arch/arm/boot/dts/am437x-sk-evm.dts
index d82dd6e..1b404fd 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -428,7 +428,6 @@
#interrupt-cells = <2>;
 
dcdc1: regulator-dcdc1 {
-   compatible = "ti,tps65218-dcdc1";
/* VDD_CORE limits min of OPP50 and max of OPP100 */
regulator-name = "vdd_core";
regulator-min-microvolt = <912000>;
@@ -438,7 +437,6 @@
};
 
dcdc2: regulator-dcdc2 {
-   compatible = "ti,tps65218-dcdc2";
/* VDD_MPU limits min of OPP50 and max of OPP_NITRO */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <912000>;
@@ -448,7 +446,6 @@
};
 
dcdc3: regulator-dcdc3 {
-   compatible = "ti,tps65218-dcdc3";
regulator-name = "vdds_ddr";
regulator-min-microvolt = <150>;
regulator-max-microvolt = <150>;
@@ -457,7 +454,6 @@
};
 
dcdc4: regulator-dcdc4 {
-   compatible = "ti,tps65218-dcdc4";
regulator-name = "v3_3d";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
@@ -466,7 +462,6 @@
};
 
ldo1: regulator-ldo1 {
-   compatible = "ti,tps65218-ldo1";
regulator-name = "v1_8d";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
-- 
1.9.1

[PATCH 8/8] ARM: dts: AM43X-EPOS-EVM: Remove redundant regulator compatibles

[Keerthy]

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index d5dd720..4599d23 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -421,7 +421,6 @@
#interrupt-cells = <2>;
 
dcdc1: regulator-dcdc1 {
-   compatible = "ti,tps65218-dcdc1";
regulator-name = "vdd_core";
regulator-min-microvolt = <912000>;
regulator-max-microvolt = <1144000>;
@@ -430,7 +429,6 @@
};
 
dcdc2: regulator-dcdc2 {
-   compatible = "ti,tps65218-dcdc2";
regulator-name = "vdd_mpu";
regulator-min-microvolt = <912000>;
regulator-max-microvolt = <1378000>;
@@ -439,7 +437,6 @@
};
 
dcdc3: regulator-dcdc3 {
-   compatible = "ti,tps65218-dcdc3";
regulator-name = "vdcdc3";
regulator-min-microvolt = <150>;
regulator-max-microvolt = <150>;
@@ -448,7 +445,6 @@
};
 
dcdc4: regulator-dcdc4 {
-   compatible = "ti,tps65218-dcdc4";
regulator-name = "vdcdc4";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
@@ -457,21 +453,18 @@
};
 
dcdc5: regulator-dcdc5 {
-   compatible = "ti,tps65218-dcdc5";
regulator-name = "v1_0bat";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
};
 
dcdc6: regulator-dcdc6 {
-   compatible = "ti,tps65218-dcdc6";
regulator-name = "v1_8bat";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
};
 
ldo1: regulator-ldo1 {
-   compatible = "ti,tps65218-ldo1";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-boot-on;
-- 
1.9.1

[PATCH 6/8] ARM: dts: AM437X-SK-EVM: Remove redundant regulator compatibles

[Keerthy]

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am437x-sk-evm.dts | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
b/arch/arm/boot/dts/am437x-sk-evm.dts
index d82dd6e..1b404fd 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -428,7 +428,6 @@
#interrupt-cells = <2>;
 
dcdc1: regulator-dcdc1 {
-   compatible = "ti,tps65218-dcdc1";
/* VDD_CORE limits min of OPP50 and max of OPP100 */
regulator-name = "vdd_core";
regulator-min-microvolt = <912000>;
@@ -438,7 +437,6 @@
};
 
dcdc2: regulator-dcdc2 {
-   compatible = "ti,tps65218-dcdc2";
/* VDD_MPU limits min of OPP50 and max of OPP_NITRO */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <912000>;
@@ -448,7 +446,6 @@
};
 
dcdc3: regulator-dcdc3 {
-   compatible = "ti,tps65218-dcdc3";
regulator-name = "vdds_ddr";
regulator-min-microvolt = <150>;
regulator-max-microvolt = <150>;
@@ -457,7 +454,6 @@
};
 
dcdc4: regulator-dcdc4 {
-   compatible = "ti,tps65218-dcdc4";
regulator-name = "v3_3d";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
@@ -466,7 +462,6 @@
};
 
ldo1: regulator-ldo1 {
-   compatible = "ti,tps65218-ldo1";
regulator-name = "v1_8d";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
-- 
1.9.1

[PATCH 8/8] ARM: dts: AM43X-EPOS-EVM: Remove redundant regulator compatibles

[Keerthy]

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index d5dd720..4599d23 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -421,7 +421,6 @@
#interrupt-cells = <2>;
 
dcdc1: regulator-dcdc1 {
-   compatible = "ti,tps65218-dcdc1";
regulator-name = "vdd_core";
regulator-min-microvolt = <912000>;
regulator-max-microvolt = <1144000>;
@@ -430,7 +429,6 @@
};
 
dcdc2: regulator-dcdc2 {
-   compatible = "ti,tps65218-dcdc2";
regulator-name = "vdd_mpu";
regulator-min-microvolt = <912000>;
regulator-max-microvolt = <1378000>;
@@ -439,7 +437,6 @@
};
 
dcdc3: regulator-dcdc3 {
-   compatible = "ti,tps65218-dcdc3";
regulator-name = "vdcdc3";
regulator-min-microvolt = <150>;
regulator-max-microvolt = <150>;
@@ -448,7 +445,6 @@
};
 
dcdc4: regulator-dcdc4 {
-   compatible = "ti,tps65218-dcdc4";
regulator-name = "vdcdc4";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
@@ -457,21 +453,18 @@
};
 
dcdc5: regulator-dcdc5 {
-   compatible = "ti,tps65218-dcdc5";
regulator-name = "v1_0bat";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
};
 
dcdc6: regulator-dcdc6 {
-   compatible = "ti,tps65218-dcdc6";
regulator-name = "v1_8bat";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
};
 
ldo1: regulator-ldo1 {
-   compatible = "ti,tps65218-ldo1";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-boot-on;
-- 
1.9.1

[PATCH 0/8] regulator: tps65218: Clean ups

[Keerthy]

The series cleans up mainly the regulator driver and implements
the device tree parsing using the regulator framework. Removes
all the redundant compatibles for the individual regulators.

One of the patch removes redundant read wrapper and makes
use of regmap_read wherever necessary.

The series is checked for all the regulator registrations on
am437x-gp-evm and am437x-sk-evm.

Keerthy (8):
  mfd: tps65218: Remove redundant read wrapper
  Documentation: regulator: tps65218: Updates according to changes with
parsing
  mfd: tps65218: Use mfd_add_devices instead of of_platform_populate
  regulator: tps65218: Remove all the compatibles
  ARM: dts: AM437X-GP-EVM: Remove redundant regulator compatibles
  ARM: dts: AM437X-SK-EVM: Remove redundant regulator compatibles
  ARM: dts: AM437X-CM-T43: Remove redundant regulator compatibles
  ARM: dts: AM43X-EPOS-EVM: Remove redundant regulator compatibles

 .../devicetree/bindings/regulator/tps65218.txt |  88 +++---
 arch/arm/boot/dts/am437x-cm-t43.dts|   6 -
 arch/arm/boot/dts/am437x-gp-evm.dts|   6 -
 arch/arm/boot/dts/am437x-sk-evm.dts|   5 -
 arch/arm/boot/dts/am43x-epos-evm.dts   |   7 --
 drivers/mfd/tps65218.c |  24 ++--
 drivers/regulator/tps65218-regulator.c | 134 -
 include/linux/mfd/tps65218.h   |   2 -
 8 files changed, 127 insertions(+), 145 deletions(-)

-- 
1.9.1

[PATCH 3/8] mfd: tps65218: Use mfd_add_devices instead of of_platform_populate

[Keerthy]

mfd_add_devices enables parsing device tree nodes without compatibles
for child nodes. Replace of_platform_populate with mfd_add_devices.

Signed-off-by: Keerthy 
---
 drivers/mfd/tps65218.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index f20a531..b8b3a58 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -33,6 +33,10 @@
 
 #define TPS65218_PASSWORD_REGS_UNLOCK   0x7D
 
+static const struct mfd_cell tps65218_cells[] = {
+   { .name = "tps65218-regulator", },
+};
+
 /**
  * tps65218_reg_write: Write a single tps65218 register.
  *
@@ -236,8 +240,10 @@ static int tps65218_probe(struct i2c_client *client,
if (ret < 0)
return ret;
 
-   ret = of_platform_populate(client->dev.of_node, NULL, NULL,
-  >dev);
+   ret = mfd_add_devices(tps->dev, PLATFORM_DEVID_AUTO, tps65218_cells,
+ ARRAY_SIZE(tps65218_cells), NULL, 0,
+ regmap_irq_get_domain(tps->irq_data));
+
if (ret < 0)
goto err_irq;
 
-- 
1.9.1

[PATCH 5/8] ARM: dts: AM437X-GP-EVM: Remove redundant regulator compatibles

[Keerthy]

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 8889be1..67329e0 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -513,7 +513,6 @@
#interrupt-cells = <2>;
 
dcdc1: regulator-dcdc1 {
-   compatible = "ti,tps65218-dcdc1";
regulator-name = "vdd_core";
regulator-min-microvolt = <912000>;
regulator-max-microvolt = <1144000>;
@@ -522,7 +521,6 @@
};
 
dcdc2: regulator-dcdc2 {
-   compatible = "ti,tps65218-dcdc2";
regulator-name = "vdd_mpu";
regulator-min-microvolt = <912000>;
regulator-max-microvolt = <1378000>;
@@ -531,7 +529,6 @@
};
 
dcdc3: regulator-dcdc3 {
-   compatible = "ti,tps65218-dcdc3";
regulator-name = "vdcdc3";
regulator-min-microvolt = <150>;
regulator-max-microvolt = <150>;
@@ -539,7 +536,6 @@
regulator-always-on;
};
dcdc5: regulator-dcdc5 {
-   compatible = "ti,tps65218-dcdc5";
regulator-name = "v1_0bat";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
@@ -548,7 +544,6 @@
};
 
dcdc6: regulator-dcdc6 {
-   compatible = "ti,tps65218-dcdc6";
regulator-name = "v1_8bat";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
@@ -557,7 +552,6 @@
};
 
ldo1: regulator-ldo1 {
-   compatible = "ti,tps65218-ldo1";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-boot-on;
-- 
1.9.1

[PATCH 0/8] regulator: tps65218: Clean ups

[Keerthy]

The series cleans up mainly the regulator driver and implements
the device tree parsing using the regulator framework. Removes
all the redundant compatibles for the individual regulators.

One of the patch removes redundant read wrapper and makes
use of regmap_read wherever necessary.

The series is checked for all the regulator registrations on
am437x-gp-evm and am437x-sk-evm.

Keerthy (8):
  mfd: tps65218: Remove redundant read wrapper
  Documentation: regulator: tps65218: Updates according to changes with
parsing
  mfd: tps65218: Use mfd_add_devices instead of of_platform_populate
  regulator: tps65218: Remove all the compatibles
  ARM: dts: AM437X-GP-EVM: Remove redundant regulator compatibles
  ARM: dts: AM437X-SK-EVM: Remove redundant regulator compatibles
  ARM: dts: AM437X-CM-T43: Remove redundant regulator compatibles
  ARM: dts: AM43X-EPOS-EVM: Remove redundant regulator compatibles

 .../devicetree/bindings/regulator/tps65218.txt |  88 +++---
 arch/arm/boot/dts/am437x-cm-t43.dts|   6 -
 arch/arm/boot/dts/am437x-gp-evm.dts|   6 -
 arch/arm/boot/dts/am437x-sk-evm.dts|   5 -
 arch/arm/boot/dts/am43x-epos-evm.dts   |   7 --
 drivers/mfd/tps65218.c |  24 ++--
 drivers/regulator/tps65218-regulator.c | 134 -
 include/linux/mfd/tps65218.h   |   2 -
 8 files changed, 127 insertions(+), 145 deletions(-)

-- 
1.9.1

[PATCH 3/8] mfd: tps65218: Use mfd_add_devices instead of of_platform_populate

[Keerthy]

mfd_add_devices enables parsing device tree nodes without compatibles
for child nodes. Replace of_platform_populate with mfd_add_devices.

Signed-off-by: Keerthy 
---
 drivers/mfd/tps65218.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index f20a531..b8b3a58 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -33,6 +33,10 @@
 
 #define TPS65218_PASSWORD_REGS_UNLOCK   0x7D
 
+static const struct mfd_cell tps65218_cells[] = {
+   { .name = "tps65218-regulator", },
+};
+
 /**
  * tps65218_reg_write: Write a single tps65218 register.
  *
@@ -236,8 +240,10 @@ static int tps65218_probe(struct i2c_client *client,
if (ret < 0)
return ret;
 
-   ret = of_platform_populate(client->dev.of_node, NULL, NULL,
-  >dev);
+   ret = mfd_add_devices(tps->dev, PLATFORM_DEVID_AUTO, tps65218_cells,
+ ARRAY_SIZE(tps65218_cells), NULL, 0,
+ regmap_irq_get_domain(tps->irq_data));
+
if (ret < 0)
goto err_irq;
 
-- 
1.9.1

[PATCH 5/8] ARM: dts: AM437X-GP-EVM: Remove redundant regulator compatibles

[Keerthy]

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 8889be1..67329e0 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -513,7 +513,6 @@
#interrupt-cells = <2>;
 
dcdc1: regulator-dcdc1 {
-   compatible = "ti,tps65218-dcdc1";
regulator-name = "vdd_core";
regulator-min-microvolt = <912000>;
regulator-max-microvolt = <1144000>;
@@ -522,7 +521,6 @@
};
 
dcdc2: regulator-dcdc2 {
-   compatible = "ti,tps65218-dcdc2";
regulator-name = "vdd_mpu";
regulator-min-microvolt = <912000>;
regulator-max-microvolt = <1378000>;
@@ -531,7 +529,6 @@
};
 
dcdc3: regulator-dcdc3 {
-   compatible = "ti,tps65218-dcdc3";
regulator-name = "vdcdc3";
regulator-min-microvolt = <150>;
regulator-max-microvolt = <150>;
@@ -539,7 +536,6 @@
regulator-always-on;
};
dcdc5: regulator-dcdc5 {
-   compatible = "ti,tps65218-dcdc5";
regulator-name = "v1_0bat";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
@@ -548,7 +544,6 @@
};
 
dcdc6: regulator-dcdc6 {
-   compatible = "ti,tps65218-dcdc6";
regulator-name = "v1_8bat";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
@@ -557,7 +552,6 @@
};
 
ldo1: regulator-ldo1 {
-   compatible = "ti,tps65218-ldo1";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-boot-on;
-- 
1.9.1

Re: [PATCH] ARM: dts: exynos: Only Odroid XU3-family boards use DTSI with CPU thermal nodes

[Krzysztof Kozlowski]

On 05/10/2016 09:45 PM, Anand Moon wrote:
> Hi Krzysztof,
> 
> Sorry I am not able to explain my self clearly.
> But I have once gain tested these changes.
> 
> Only could you append with following changes.
> 
> +   cpu_crit0: cpu-crit-0 {
> +   temperature = <12>; /*
> millicelsius */
> +   hysteresis = <5000>; /* millicelsius 
> */
> +   type = "critical";
> +   };
> 
> hysteresis time help to adjust the present and past temperature inputs
> before critical shutdown.

I need more details why you want this patch. What is the point of
hysteresis on critical trip point? When reaching this trip point the
system shutdowns... there is nothing more to do, I think.

Best regards,
Krzysztof

Re: [PATCH] ARM: dts: exynos: Only Odroid XU3-family boards use DTSI with CPU thermal nodes

[Krzysztof Kozlowski]

On 05/10/2016 09:45 PM, Anand Moon wrote:
> Hi Krzysztof,
> 
> Sorry I am not able to explain my self clearly.
> But I have once gain tested these changes.
> 
> Only could you append with following changes.
> 
> +   cpu_crit0: cpu-crit-0 {
> +   temperature = <12>; /*
> millicelsius */
> +   hysteresis = <5000>; /* millicelsius 
> */
> +   type = "critical";
> +   };
> 
> hysteresis time help to adjust the present and past temperature inputs
> before critical shutdown.

I need more details why you want this patch. What is the point of
hysteresis on critical trip point? When reaching this trip point the
system shutdowns... there is nothing more to do, I think.

Best regards,
Krzysztof

Re: [PATCH] x86/extable: ensure entries are swapped completely when sorting

[Ard Biesheuvel]

On 10 May 2016 at 23:07, Mathias Krause  wrote:
> The x86 exception table sorting was changed in commit 29934b0fb8ff
> ("x86/extable: use generic search and sort routines") to use the arch
> independent code in lib/extable.c. However, the patch was mangled
> somehow on its way into the kernel from the last version posted at [1].
> The committed version kind of attempted to incorporate the changes of
> commit 548acf19234d ("x86/mm: Expand the exception table logic to allow
> new handling options") as in _completely_ _ignoring_ the x86 specific
> 'handler' member of struct exception_table_entry. This effectively broke
> the sorting as entries will only partly be swapped now.
>

OK, it appears that Tony's patches grew a 'handler' field fairly late
in their review cycle, and I didn't pick up on that. Apologies.

> Fortunately, the x86 Kconfig selects BUILDTIME_EXTABLE_SORT, so the
> exception table doesn't need to be sorted at runtime. However, in case
> that ever changes, we better not break the exception table sorting just
> because of that.
>

BUILDTIME_EXTABLE_SORT applies to the core image only, but we still
rely on the sorting routines for modules in that case. So I think this
needs to be fixed right away.

> Fix this by providing a swap_ex_entry_fixup() macro that takes care of
> the 'handler' member.
>
> [1] https://lkml.org/lkml/2016/1/27/232
>
> Signed-off-by: Mathias Krause 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Ard Biesheuvel 
> Cc: Borislav Petkov 
> Cc: H. Peter Anvin 
> Cc: Ingo Molnar 
> Cc: Linus Torvalds 
> Cc: Thomas Gleixner 
> Cc: Tony Luck 

Fixes: 29934b0fb8f ("x86/extable: use generic search and sort routines")
Reviewed-by: Ard Biesheuvel 

Thanks,
Ard.

> ---
>  arch/x86/include/asm/uaccess.h |8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index a969ae607be8..b69b7bffb0e0 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -108,6 +108,14 @@ struct exception_table_entry {
>
>  #define ARCH_HAS_RELATIVE_EXTABLE
>
> +#define swap_ex_entry_fixup(a, b, tmp, delta)  \
> +   do {\
> +   (a)->fixup = (b)->fixup + (delta);  \
> +   (b)->fixup = (tmp).fixup - (delta); \
> +   (a)->handler = (b)->handler + (delta);  \
> +   (b)->handler = (tmp).handler - (delta); \
> +   } while (0)
> +
>  extern int fixup_exception(struct pt_regs *regs, int trapnr);
>  extern bool ex_has_fault_handler(unsigned long ip);
>  extern int early_fixup_exception(unsigned long *ip);
> --
> 1.7.10.4
>

Re: [PATCH] x86/extable: ensure entries are swapped completely when sorting

[Ard Biesheuvel]

On 10 May 2016 at 23:07, Mathias Krause  wrote:
> The x86 exception table sorting was changed in commit 29934b0fb8ff
> ("x86/extable: use generic search and sort routines") to use the arch
> independent code in lib/extable.c. However, the patch was mangled
> somehow on its way into the kernel from the last version posted at [1].
> The committed version kind of attempted to incorporate the changes of
> commit 548acf19234d ("x86/mm: Expand the exception table logic to allow
> new handling options") as in _completely_ _ignoring_ the x86 specific
> 'handler' member of struct exception_table_entry. This effectively broke
> the sorting as entries will only partly be swapped now.
>

OK, it appears that Tony's patches grew a 'handler' field fairly late
in their review cycle, and I didn't pick up on that. Apologies.

> Fortunately, the x86 Kconfig selects BUILDTIME_EXTABLE_SORT, so the
> exception table doesn't need to be sorted at runtime. However, in case
> that ever changes, we better not break the exception table sorting just
> because of that.
>

BUILDTIME_EXTABLE_SORT applies to the core image only, but we still
rely on the sorting routines for modules in that case. So I think this
needs to be fixed right away.

> Fix this by providing a swap_ex_entry_fixup() macro that takes care of
> the 'handler' member.
>
> [1] https://lkml.org/lkml/2016/1/27/232
>
> Signed-off-by: Mathias Krause 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Ard Biesheuvel 
> Cc: Borislav Petkov 
> Cc: H. Peter Anvin 
> Cc: Ingo Molnar 
> Cc: Linus Torvalds 
> Cc: Thomas Gleixner 
> Cc: Tony Luck 

Fixes: 29934b0fb8f ("x86/extable: use generic search and sort routines")
Reviewed-by: Ard Biesheuvel 

Thanks,
Ard.

> ---
>  arch/x86/include/asm/uaccess.h |8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index a969ae607be8..b69b7bffb0e0 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -108,6 +108,14 @@ struct exception_table_entry {
>
>  #define ARCH_HAS_RELATIVE_EXTABLE
>
> +#define swap_ex_entry_fixup(a, b, tmp, delta)  \
> +   do {\
> +   (a)->fixup = (b)->fixup + (delta);  \
> +   (b)->fixup = (tmp).fixup - (delta); \
> +   (a)->handler = (b)->handler + (delta);  \
> +   (b)->handler = (tmp).handler - (delta); \
> +   } while (0)
> +
>  extern int fixup_exception(struct pt_regs *regs, int trapnr);
>  extern bool ex_has_fault_handler(unsigned long ip);
>  extern int early_fixup_exception(unsigned long *ip);
> --
> 1.7.10.4
>

[PATCH 1/2] ARM: dts: sun6i: primo81: Drop constraints on dc1sw regulator

[Chen-Yu Tsai]

This is the same issue fixed in commit dcf5341f0150 ("ARM: dts:
sun8i-q8-common: Do not set constraints on dc1sw regulator").
Commit message copied:

dc1sw is an on/off only regulator and as such it cannot have constraints.

This is a limitation of the kernel regulator implementation which resolves
supplies on the first regulator_get(), which is done after applying
constraints, and applying the constrains will fail because it calls
_regulator_get_voltage() and _regulator_do_set_voltage() both of which
will fail on a switch regulator when there is no supply (yet).

This causes registering of all axp22x regulators to fail with the
following errors:

[1.395249] vcc-lcd: failed to get the current voltage(-22)
[1.405131] axp20x-regulator axp20x-regulator: Failed to register dc1sw
[1.412436] axp20x-regulator: probe of axp20x-regulator failed with error -22

This commit removes the constrains on dc1sw / vcc-lcd fixing this problem.
Note that dcdc1 itself is contrained to the exact same values, so this
does not change anything.

Cc: Hans de Goede 
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31s-primo81.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts 
b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
index 68b479b8772c..73c133f5e79c 100644
--- a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -176,8 +176,6 @@
 };
 
 _dc1sw {
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
regulator-name = "vcc-lcd";
 };
 
-- 
2.8.1

[PATCH 1/2] ARM: dts: sun6i: primo81: Drop constraints on dc1sw regulator

[Chen-Yu Tsai]

This is the same issue fixed in commit dcf5341f0150 ("ARM: dts:
sun8i-q8-common: Do not set constraints on dc1sw regulator").
Commit message copied:

dc1sw is an on/off only regulator and as such it cannot have constraints.

This is a limitation of the kernel regulator implementation which resolves
supplies on the first regulator_get(), which is done after applying
constraints, and applying the constrains will fail because it calls
_regulator_get_voltage() and _regulator_do_set_voltage() both of which
will fail on a switch regulator when there is no supply (yet).

This causes registering of all axp22x regulators to fail with the
following errors:

[1.395249] vcc-lcd: failed to get the current voltage(-22)
[1.405131] axp20x-regulator axp20x-regulator: Failed to register dc1sw
[1.412436] axp20x-regulator: probe of axp20x-regulator failed with error -22

This commit removes the constrains on dc1sw / vcc-lcd fixing this problem.
Note that dcdc1 itself is contrained to the exact same values, so this
does not change anything.

Cc: Hans de Goede 
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31s-primo81.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts 
b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
index 68b479b8772c..73c133f5e79c 100644
--- a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -176,8 +176,6 @@
 };
 
 _dc1sw {
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
regulator-name = "vcc-lcd";
 };
 
-- 
2.8.1

[PATCH 0/2] ARM: dts: sun6i: Drop constraints on dc1sw regulator

[Chen-Yu Tsai]

Hi Arnd, Olof,

Here are 2 last minute fixes for 4.6. The 2 patches drop constaints on
the dc1sw regulator for 2 A31s tablets. I checked with Maxime and he said
to send them directly to you.

The issue was first brought up and fixed for A23/A33 Q8 tablets in commit
dcf5341f0150 ("ARM: dts: sun8i-q8-common: Do not set constraints on dc1sw
regulator"). It was brought up again yesterday on IRC, and I realized that
2 sun6i A31s tablet DTS files also had this setting. The setting causes
PMIC regulator registration to fail, and since among other things, mmc
depends on the regulators, the system will likely hang.

There seems to be a fix for this queued up for 4.7: commit 45389c47526d
("regulator: core: Add early supply resolution for regulators") in the
regulator "supply" topic branch. So we should be able to revert these
fixes in 4.7.


Regards
ChenYu


Chen-Yu Tsai (2):
  ARM: dts: sun6i: primo81: Drop constraints on dc1sw regulator
  ARM: dts: sun6i: yones-toptech-bs1078-v2: Drop constraints on dc1sw
regulator

 arch/arm/boot/dts/sun6i-a31s-primo81.dts | 2 --
 arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts | 2 --
 2 files changed, 4 deletions(-)

-- 
2.8.1

[PATCH 0/2] ARM: dts: sun6i: Drop constraints on dc1sw regulator

[Chen-Yu Tsai]

Hi Arnd, Olof,

Here are 2 last minute fixes for 4.6. The 2 patches drop constaints on
the dc1sw regulator for 2 A31s tablets. I checked with Maxime and he said
to send them directly to you.

The issue was first brought up and fixed for A23/A33 Q8 tablets in commit
dcf5341f0150 ("ARM: dts: sun8i-q8-common: Do not set constraints on dc1sw
regulator"). It was brought up again yesterday on IRC, and I realized that
2 sun6i A31s tablet DTS files also had this setting. The setting causes
PMIC regulator registration to fail, and since among other things, mmc
depends on the regulators, the system will likely hang.

There seems to be a fix for this queued up for 4.7: commit 45389c47526d
("regulator: core: Add early supply resolution for regulators") in the
regulator "supply" topic branch. So we should be able to revert these
fixes in 4.7.


Regards
ChenYu


Chen-Yu Tsai (2):
  ARM: dts: sun6i: primo81: Drop constraints on dc1sw regulator
  ARM: dts: sun6i: yones-toptech-bs1078-v2: Drop constraints on dc1sw
regulator

 arch/arm/boot/dts/sun6i-a31s-primo81.dts | 2 --
 arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts | 2 --
 2 files changed, 4 deletions(-)

-- 
2.8.1

[PATCH 2/2] ARM: dts: sun6i: yones-toptech-bs1078-v2: Drop constraints on dc1sw regulator

[Chen-Yu Tsai]

This is the same issue fixed in commit dcf5341f0150 ("ARM: dts:
sun8i-q8-common: Do not set constraints on dc1sw regulator").
Commit message copied:

dc1sw is an on/off only regulator and as such it cannot have constraints.

This is a limitation of the kernel regulator implementation which resolves
supplies on the first regulator_get(), which is done after applying
constraints, and applying the constrains will fail because it calls
_regulator_get_voltage() and _regulator_do_set_voltage() both of which
will fail on a switch regulator when there is no supply (yet).

This causes registering of all axp22x regulators to fail with the
following errors:

[1.395249] vcc-lcd: failed to get the current voltage(-22)
[1.405131] axp20x-regulator axp20x-regulator: Failed to register dc1sw
[1.412436] axp20x-regulator: probe of axp20x-regulator failed with error -22

This commit removes the constrains on dc1sw / vcc-lcd fixing this problem.
Note that dcdc1 itself is contrained to the exact same values, so this
does not change anything.

Cc: Hans de Goede 
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts 
b/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
index 360adfb1e9ca..d6ad6196a768 100644
--- a/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
@@ -135,8 +135,6 @@
 
 _dc1sw {
regulator-name = "vcc-lcd-usb2";
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
 };
 
 _dc5ldo {
-- 
2.8.1

[PATCH 2/2] ARM: dts: sun6i: yones-toptech-bs1078-v2: Drop constraints on dc1sw regulator

[Chen-Yu Tsai]

This is the same issue fixed in commit dcf5341f0150 ("ARM: dts:
sun8i-q8-common: Do not set constraints on dc1sw regulator").
Commit message copied:

dc1sw is an on/off only regulator and as such it cannot have constraints.

This is a limitation of the kernel regulator implementation which resolves
supplies on the first regulator_get(), which is done after applying
constraints, and applying the constrains will fail because it calls
_regulator_get_voltage() and _regulator_do_set_voltage() both of which
will fail on a switch regulator when there is no supply (yet).

This causes registering of all axp22x regulators to fail with the
following errors:

[1.395249] vcc-lcd: failed to get the current voltage(-22)
[1.405131] axp20x-regulator axp20x-regulator: Failed to register dc1sw
[1.412436] axp20x-regulator: probe of axp20x-regulator failed with error -22

This commit removes the constrains on dc1sw / vcc-lcd fixing this problem.
Note that dcdc1 itself is contrained to the exact same values, so this
does not change anything.

Cc: Hans de Goede 
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts 
b/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
index 360adfb1e9ca..d6ad6196a768 100644
--- a/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
@@ -135,8 +135,6 @@
 
 _dc1sw {
regulator-name = "vcc-lcd-usb2";
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
 };
 
 _dc5ldo {
-- 
2.8.1

linux-next: Tree for May 11

[Stephen Rothwell]

Hi all,

Changes since 20160510:

The vfs tree gained a conflict against the overlayfs tree.

The net-next tree gained a conflict against the net tree and lost its
build failure.

The sound-asoc tree gained a build failure for which I applied a fix
patch.

The dt-rh tree gained a conflict against the iommu tree.

Non-merge commits (relative to Linus' tree): 9447
 8262 files changed, 413604 insertions(+), 177795 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c5114626f33b Merge tag 'pci-v4.6-fixes-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging fixes/master (b507146bb6b9 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (44549e8f5eea Linux 4.6-rc7)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move 
{set,get}_domain under config guard)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm 
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (33656a1f2ee5 Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging net/master (84a527a41f38 net: phylib: fix interrupts re-enablement in 
phy_start)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (cbbba30f1ac9 Merge tag 
'iwlwifi-for-kalle-2016-05-04' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if 
dev_alloc_name() fails)
Merging sound-current/for-linus (3231e2053eae ALSA: hda - Fix subwoofer pin on 
ASUS N751 and N551)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as 
device attach failure)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb.current/usb-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (44549e8f5eea Linux 4.6-rc7)
Merging char-misc.current/char-misc-linus (44549e8f5eea Linux 4.6-rc7)
Merging input-current/for-linus (c52c545ead97 Input: twl6040-vibra - fix DT 
node memory management)
Merging crypto-current/master (df27b26f04ed crypto: testmgr - Use kmalloc 
memory for RSA input)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstandin

linux-next: Tree for May 11

[Stephen Rothwell]

Hi all,

Changes since 20160510:

The vfs tree gained a conflict against the overlayfs tree.

The net-next tree gained a conflict against the net tree and lost its
build failure.

The sound-asoc tree gained a build failure for which I applied a fix
patch.

The dt-rh tree gained a conflict against the iommu tree.

Non-merge commits (relative to Linus' tree): 9447
 8262 files changed, 413604 insertions(+), 177795 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c5114626f33b Merge tag 'pci-v4.6-fixes-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging fixes/master (b507146bb6b9 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (44549e8f5eea Linux 4.6-rc7)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move 
{set,get}_domain under config guard)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm 
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (33656a1f2ee5 Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging net/master (84a527a41f38 net: phylib: fix interrupts re-enablement in 
phy_start)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (cbbba30f1ac9 Merge tag 
'iwlwifi-for-kalle-2016-05-04' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if 
dev_alloc_name() fails)
Merging sound-current/for-linus (3231e2053eae ALSA: hda - Fix subwoofer pin on 
ASUS N751 and N551)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as 
device attach failure)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb.current/usb-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (44549e8f5eea Linux 4.6-rc7)
Merging char-misc.current/char-misc-linus (44549e8f5eea Linux 4.6-rc7)
Merging input-current/for-linus (c52c545ead97 Input: twl6040-vibra - fix DT 
node memory management)
Merging crypto-current/master (df27b26f04ed crypto: testmgr - Use kmalloc 
memory for RSA input)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstandin

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

[Wei-Ning Huang]

On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang  wrote:
> On Fri, May 6, 2016 at 12:07 AM, Dan Williams  wrote:
>>
>> On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
>> > Recent new hardware has the ability to switch between tablet mode and
>> > clamshell mode. To optimize WiFi performance, we want to be able to
>> > use
>> > different power table between modes. This patch adds a new netlink
>> > message type and cfg80211_ops function to allow userspace to trigger
>> > a
>> > power mode switch for a given wireless interface.
>> >
>> > Signed-off-by: Wei-Ning Huang 
>> > ---
>> >  include/net/cfg80211.h   | 11 +++
>> >  include/uapi/linux/nl80211.h | 21 +
>> >  net/wireless/nl80211.c   | 16 
>> >  net/wireless/rdev-ops.h  | 22 ++
>> >  net/wireless/trace.h | 20 
>> >  5 files changed, 90 insertions(+)
>> >
>> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> > index 9e1b24c..aa77fa0 100644
>> > --- a/include/net/cfg80211.h
>> > +++ b/include/net/cfg80211.h
>> > @@ -2370,6 +2370,12 @@ struct cfg80211_qos_map {
>> >   * @get_tx_power: store the current TX power into the dbm variable;
>> >   *   return 0 if successful
>> >   *
>> > + * @set_tx_power_mode: set the transmit power mode. Some device have
>> > the ability
>> > + *   to transform between different mode such as clamshell and
>> > tablet mode.
>> > + *   set_tx_power_mode allows setting of different TX power
>> > mode at runtime.
>> > + * @get_tx_power_mode: store the current TX power mode into the mode
>> > variable;
>> > + *   return 0 if successful
>> > + *
>> >   * @set_wds_peer: set the WDS peer for a WDS interface
>> >   *
>> >   * @rfkill_poll: polls the hw rfkill line, use cfg80211 reporting
>> > @@ -2631,6 +2637,11 @@ struct cfg80211_ops {
>> >   int (*get_tx_power)(struct wiphy *wiphy, struct
>> > wireless_dev *wdev,
>> >   int *dbm);
>> >
>> > + int (*set_tx_power_mode)(struct wiphy *wiphy,
>> > +  enum nl80211_tx_power_mode
>> > mode);
>> > + int (*get_tx_power_mode)(struct wiphy *wiphy,
>> > +  enum nl80211_tx_power_mode
>> > *mode);
>> > +
>> >   int (*set_wds_peer)(struct wiphy *wiphy, struct
>> > net_device *dev,
>> >   const u8 *addr);
>> >
>> > diff --git a/include/uapi/linux/nl80211.h
>> > b/include/uapi/linux/nl80211.h
>> > index 5a30a75..9b1888a 100644
>> > --- a/include/uapi/linux/nl80211.h
>> > +++ b/include/uapi/linux/nl80211.h
>> > @@ -1796,6 +1796,9 @@ enum nl80211_commands {
>> >   *   connecting to a PCP, and in %NL80211_CMD_START_AP to start
>> >   *   a PCP instead of AP. Relevant for DMG networks only.
>> >   *
>> > + * @NL80211_ATTR_WIPHY_TX_POWER_MODE: Transmit power mode. See
>> > + *   nl80211_tx_power_mode for possible values.
>> > + *
>> >   * @NUM_NL80211_ATTR: total number of nl80211_attrs available
>> >   * @NL80211_ATTR_MAX: highest attribute number currently defined
>> >   * @__NL80211_ATTR_AFTER_LAST: internal use
>> > @@ -2172,6 +2175,8 @@ enum nl80211_attrs {
>> >
>> >   NL80211_ATTR_PBSS,
>> >
>> > + NL80211_ATTR_WIPHY_TX_POWER_MODE,
>> > +
>> >   /* add attributes here, update the policy in nl80211.c */
>> >
>> >   __NL80211_ATTR_AFTER_LAST,
>> > @@ -3703,6 +3708,22 @@ enum nl80211_tx_power_setting {
>> >  };
>> >
>> >  /**
>> > + * enum nl80211_tx_power_mode - TX power mode setting
>> > + * @NL80211_TX_POWER_LOW: general low TX power mode
>> > + * @NL80211_TX_POWER_MEDIUM: general medium TX power mode
>> > + * @NL80211_TX_POWER_HIGH: general high TX power mode
>> > + * @NL80211_TX_POWER_CLAMSHELL: clamshell mode TX power mode
>> > + * @NL80211_TX_POWER_TABLET: tablet mode TX power mode
>> > + */
>> > +enum nl80211_tx_power_mode {
>> > + NL80211_TX_POWER_LOW,
>> > + NL80211_TX_POWER_MEDIUM,
>> > + NL80211_TX_POWER_HIGH,
>> > + NL80211_TX_POWER_CLAMSHELL,
>> > + NL80211_TX_POWER_TABLET,
>>
>
>> "clamshell" and "tablet" probably mean many different things to many
>> different people with respect to whether or not they should do anything
>> with power saving or wifi.  I feel like a more generic interface is
>> needed here.
> We could probably drop those two CLAMSHELL and TABLET constant or
> describing what they mean
> in more detail?
>
>>
>> Could this be already done by:
>> @NL80211_ATTR_WIPHY_TX_POWER_SETTING = NL80211_TX_POWER_LIMITED
>> @NL80211_ATTR_WIPHY_TX_POWER_LEVEL = 
>>
>> and then the device would be able to change its TX power as it saw fit
>> up to that limit set by your application which figures out whether it's
>> in clamshell or tablet mode?
>
> We usually want different power settings in different band/channel.
> For example, we can have three different power settings
> in 2.4Ghz, channels 36-64 & channels 100+ on 

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

[Wei-Ning Huang]

On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang  wrote:
> On Fri, May 6, 2016 at 12:07 AM, Dan Williams  wrote:
>>
>> On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
>> > Recent new hardware has the ability to switch between tablet mode and
>> > clamshell mode. To optimize WiFi performance, we want to be able to
>> > use
>> > different power table between modes. This patch adds a new netlink
>> > message type and cfg80211_ops function to allow userspace to trigger
>> > a
>> > power mode switch for a given wireless interface.
>> >
>> > Signed-off-by: Wei-Ning Huang 
>> > ---
>> >  include/net/cfg80211.h   | 11 +++
>> >  include/uapi/linux/nl80211.h | 21 +
>> >  net/wireless/nl80211.c   | 16 
>> >  net/wireless/rdev-ops.h  | 22 ++
>> >  net/wireless/trace.h | 20 
>> >  5 files changed, 90 insertions(+)
>> >
>> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> > index 9e1b24c..aa77fa0 100644
>> > --- a/include/net/cfg80211.h
>> > +++ b/include/net/cfg80211.h
>> > @@ -2370,6 +2370,12 @@ struct cfg80211_qos_map {
>> >   * @get_tx_power: store the current TX power into the dbm variable;
>> >   *   return 0 if successful
>> >   *
>> > + * @set_tx_power_mode: set the transmit power mode. Some device have
>> > the ability
>> > + *   to transform between different mode such as clamshell and
>> > tablet mode.
>> > + *   set_tx_power_mode allows setting of different TX power
>> > mode at runtime.
>> > + * @get_tx_power_mode: store the current TX power mode into the mode
>> > variable;
>> > + *   return 0 if successful
>> > + *
>> >   * @set_wds_peer: set the WDS peer for a WDS interface
>> >   *
>> >   * @rfkill_poll: polls the hw rfkill line, use cfg80211 reporting
>> > @@ -2631,6 +2637,11 @@ struct cfg80211_ops {
>> >   int (*get_tx_power)(struct wiphy *wiphy, struct
>> > wireless_dev *wdev,
>> >   int *dbm);
>> >
>> > + int (*set_tx_power_mode)(struct wiphy *wiphy,
>> > +  enum nl80211_tx_power_mode
>> > mode);
>> > + int (*get_tx_power_mode)(struct wiphy *wiphy,
>> > +  enum nl80211_tx_power_mode
>> > *mode);
>> > +
>> >   int (*set_wds_peer)(struct wiphy *wiphy, struct
>> > net_device *dev,
>> >   const u8 *addr);
>> >
>> > diff --git a/include/uapi/linux/nl80211.h
>> > b/include/uapi/linux/nl80211.h
>> > index 5a30a75..9b1888a 100644
>> > --- a/include/uapi/linux/nl80211.h
>> > +++ b/include/uapi/linux/nl80211.h
>> > @@ -1796,6 +1796,9 @@ enum nl80211_commands {
>> >   *   connecting to a PCP, and in %NL80211_CMD_START_AP to start
>> >   *   a PCP instead of AP. Relevant for DMG networks only.
>> >   *
>> > + * @NL80211_ATTR_WIPHY_TX_POWER_MODE: Transmit power mode. See
>> > + *   nl80211_tx_power_mode for possible values.
>> > + *
>> >   * @NUM_NL80211_ATTR: total number of nl80211_attrs available
>> >   * @NL80211_ATTR_MAX: highest attribute number currently defined
>> >   * @__NL80211_ATTR_AFTER_LAST: internal use
>> > @@ -2172,6 +2175,8 @@ enum nl80211_attrs {
>> >
>> >   NL80211_ATTR_PBSS,
>> >
>> > + NL80211_ATTR_WIPHY_TX_POWER_MODE,
>> > +
>> >   /* add attributes here, update the policy in nl80211.c */
>> >
>> >   __NL80211_ATTR_AFTER_LAST,
>> > @@ -3703,6 +3708,22 @@ enum nl80211_tx_power_setting {
>> >  };
>> >
>> >  /**
>> > + * enum nl80211_tx_power_mode - TX power mode setting
>> > + * @NL80211_TX_POWER_LOW: general low TX power mode
>> > + * @NL80211_TX_POWER_MEDIUM: general medium TX power mode
>> > + * @NL80211_TX_POWER_HIGH: general high TX power mode
>> > + * @NL80211_TX_POWER_CLAMSHELL: clamshell mode TX power mode
>> > + * @NL80211_TX_POWER_TABLET: tablet mode TX power mode
>> > + */
>> > +enum nl80211_tx_power_mode {
>> > + NL80211_TX_POWER_LOW,
>> > + NL80211_TX_POWER_MEDIUM,
>> > + NL80211_TX_POWER_HIGH,
>> > + NL80211_TX_POWER_CLAMSHELL,
>> > + NL80211_TX_POWER_TABLET,
>>
>
>> "clamshell" and "tablet" probably mean many different things to many
>> different people with respect to whether or not they should do anything
>> with power saving or wifi.  I feel like a more generic interface is
>> needed here.
> We could probably drop those two CLAMSHELL and TABLET constant or
> describing what they mean
> in more detail?
>
>>
>> Could this be already done by:
>> @NL80211_ATTR_WIPHY_TX_POWER_SETTING = NL80211_TX_POWER_LIMITED
>> @NL80211_ATTR_WIPHY_TX_POWER_LEVEL = 
>>
>> and then the device would be able to change its TX power as it saw fit
>> up to that limit set by your application which figures out whether it's
>> in clamshell or tablet mode?
>
> We usually want different power settings in different band/channel.
> For example, we can have three different power settings
> in 2.4Ghz, channels 36-64 & channels 100+ on 5Ghz. In this case, we
> can not simply set a fixed number to 

Re: [PATCH 1/3] intel_pstate: Clarify average performance computation

[Srinivas Pandruvada]

On Tue, 2016-05-10 at 22:57 +0200, Rafael J. Wysocki wrote:
> > > > 

[...]

> ---
> From: Rafael J. Wysocki 
> Subject: [PATCH] intel_pstate: Clarify average performance
> computation
> 
> The core_pct_busy field of struct sample actually contains the
> average performace during the last sampling period (in percent)
> and not the utilization of the core as suggested by its name
> which is confusing.
> 
> For this reason, change the name of that field to core_avg_perf
> and rename the function that computes its value accordingly.
> 
> Also notice that storing this value as percentage requires a costly
> integer multiplication to be carried out in a hot path, so instead
> store it as an "extended fixed point" value with more fraction bits
> and update the code using it accordingly (it is better to change the
> name of the field along with its meaning in one go than to make those
> two changes separately, as that would likely lead to more
> confusion).
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/intel_pstate.c |   31 +++---
> -
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -49,6 +49,9 @@
>  #define int_tofp(X) ((int64_t)(X) << FRAC_BITS)
>  #define fp_toint(X) ((X) >> FRAC_BITS)
>  
> +#define EXT_BITS 6
> +#define EXT_FRAC_BITS (EXT_BITS + FRAC_BITS)
> +
>  static inline int32_t mul_fp(int32_t x, int32_t y)
>  {
>   return ((int64_t)x * (int64_t)y) >> FRAC_BITS;
> @@ -72,10 +75,10 @@ static inline int ceiling_fp(int32_t x)
>  
>  /**
>   * struct sample -   Store performance sample
> - * @core_pct_busy:   Ratio of APERF/MPERF in percent, which is
> actual
> + * @core_avg_perf:   Ratio of APERF/MPERF which is the actual
> average
>   *   performance during last sample period
>   * @busy_scaled: Scaled busy value which is used to calculate
> next
> - *   P state. This can be different than
> core_pct_busy
> + *   P state. This can be different than
> core_avg_perf
>   *   to account for cpu idle period
>   * @aperf:   Difference of actual performance frequency
> clock count
>   *   read from APERF MSR between last and
> current sample
> @@ -90,8 +93,8 @@ static inline int ceiling_fp(int32_t x)
>   * data for choosing next P State.
>   */
>  struct sample {
> - int32_t core_pct_busy;
>   int32_t busy_scaled;
> + u64 core_avg_perf;
>   u64 aperf;
>   u64 mperf;
>   u64 tsc;
> @@ -1147,15 +1150,12 @@ static void intel_pstate_get_cpu_pstates
>   intel_pstate_set_min_pstate(cpu);
>  }
>  
> -static inline void intel_pstate_calc_busy(struct cpudata *cpu)
> +static inline void intel_pstate_calc_avg_perf(struct cpudata *cpu)
>  {
>   struct sample *sample = >sample;
> - int64_t core_pct;
> -
> - core_pct = sample->aperf * int_tofp(100);
> - core_pct = div64_u64(core_pct, sample->mperf);
>  
> - sample->core_pct_busy = (int32_t)core_pct;
> + sample->core_avg_perf = div64_u64(sample->aperf <<
> EXT_FRAC_BITS,
> +   sample->mperf);
>  }
>  
>  static inline bool intel_pstate_sample(struct cpudata *cpu, u64
> time)
> @@ -1198,9 +1198,8 @@ static inline bool intel_pstate_sample(s
>  
>  static inline int32_t get_avg_frequency(struct cpudata *cpu)
>  {
> - return fp_toint(mul_fp(cpu->sample.core_pct_busy,
> -    int_tofp(cpu-
> >pstate.max_pstate_physical *
> - cpu->pstate.scaling
> / 100)));
> + return (cpu->sample.core_avg_perf * cpu-
> >pstate.max_pstate_physical *
> + cpu->pstate.scaling) >> EXT_FRAC_BITS;

This breaks frequency display. Needs cast
return ((u64)cpu->sample.core_avg_perf * cpu->
pstate.max_pstate_physical * cpu->pstate.scaling) >>
EXT_FRAC_BITS;

Otherwise results are very close with the version without this change.

Thanks,
Srinivas

Re: [PATCH 1/3] intel_pstate: Clarify average performance computation

[Srinivas Pandruvada]

On Tue, 2016-05-10 at 22:57 +0200, Rafael J. Wysocki wrote:
> > > > 

[...]

> ---
> From: Rafael J. Wysocki 
> Subject: [PATCH] intel_pstate: Clarify average performance
> computation
> 
> The core_pct_busy field of struct sample actually contains the
> average performace during the last sampling period (in percent)
> and not the utilization of the core as suggested by its name
> which is confusing.
> 
> For this reason, change the name of that field to core_avg_perf
> and rename the function that computes its value accordingly.
> 
> Also notice that storing this value as percentage requires a costly
> integer multiplication to be carried out in a hot path, so instead
> store it as an "extended fixed point" value with more fraction bits
> and update the code using it accordingly (it is better to change the
> name of the field along with its meaning in one go than to make those
> two changes separately, as that would likely lead to more
> confusion).
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/intel_pstate.c |   31 +++---
> -
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -49,6 +49,9 @@
>  #define int_tofp(X) ((int64_t)(X) << FRAC_BITS)
>  #define fp_toint(X) ((X) >> FRAC_BITS)
>  
> +#define EXT_BITS 6
> +#define EXT_FRAC_BITS (EXT_BITS + FRAC_BITS)
> +
>  static inline int32_t mul_fp(int32_t x, int32_t y)
>  {
>   return ((int64_t)x * (int64_t)y) >> FRAC_BITS;
> @@ -72,10 +75,10 @@ static inline int ceiling_fp(int32_t x)
>  
>  /**
>   * struct sample -   Store performance sample
> - * @core_pct_busy:   Ratio of APERF/MPERF in percent, which is
> actual
> + * @core_avg_perf:   Ratio of APERF/MPERF which is the actual
> average
>   *   performance during last sample period
>   * @busy_scaled: Scaled busy value which is used to calculate
> next
> - *   P state. This can be different than
> core_pct_busy
> + *   P state. This can be different than
> core_avg_perf
>   *   to account for cpu idle period
>   * @aperf:   Difference of actual performance frequency
> clock count
>   *   read from APERF MSR between last and
> current sample
> @@ -90,8 +93,8 @@ static inline int ceiling_fp(int32_t x)
>   * data for choosing next P State.
>   */
>  struct sample {
> - int32_t core_pct_busy;
>   int32_t busy_scaled;
> + u64 core_avg_perf;
>   u64 aperf;
>   u64 mperf;
>   u64 tsc;
> @@ -1147,15 +1150,12 @@ static void intel_pstate_get_cpu_pstates
>   intel_pstate_set_min_pstate(cpu);
>  }
>  
> -static inline void intel_pstate_calc_busy(struct cpudata *cpu)
> +static inline void intel_pstate_calc_avg_perf(struct cpudata *cpu)
>  {
>   struct sample *sample = >sample;
> - int64_t core_pct;
> -
> - core_pct = sample->aperf * int_tofp(100);
> - core_pct = div64_u64(core_pct, sample->mperf);
>  
> - sample->core_pct_busy = (int32_t)core_pct;
> + sample->core_avg_perf = div64_u64(sample->aperf <<
> EXT_FRAC_BITS,
> +   sample->mperf);
>  }
>  
>  static inline bool intel_pstate_sample(struct cpudata *cpu, u64
> time)
> @@ -1198,9 +1198,8 @@ static inline bool intel_pstate_sample(s
>  
>  static inline int32_t get_avg_frequency(struct cpudata *cpu)
>  {
> - return fp_toint(mul_fp(cpu->sample.core_pct_busy,
> -    int_tofp(cpu-
> >pstate.max_pstate_physical *
> - cpu->pstate.scaling
> / 100)));
> + return (cpu->sample.core_avg_perf * cpu-
> >pstate.max_pstate_physical *
> + cpu->pstate.scaling) >> EXT_FRAC_BITS;

This breaks frequency display. Needs cast
return ((u64)cpu->sample.core_avg_perf * cpu->
pstate.max_pstate_physical * cpu->pstate.scaling) >>
EXT_FRAC_BITS;

Otherwise results are very close with the version without this change.

Thanks,
Srinivas

Re: [RFC][PATCH 5/7] sched: Rewrite select_idle_siblings()

[Yuyang Du]

On Mon, May 09, 2016 at 12:48:12PM +0200, Peter Zijlstra wrote:
> +/*
> + * Scan the LLC domain for idle CPUs; this is dynamically regulated by
> + * comparing the average scan cost (tracked in sd->avg_scan_cost) against the

   tracked in this_sd->avg_scan_cost

> + * average idle time for this rq (as found in rq->avg_idle).
> + */
> +static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, 
> int target)
> +{
> + struct sched_domain *this_sd = rcu_dereference(*this_cpu_ptr(_llc));
> + u64 avg_idle = this_rq()->avg_idle;
> + u64 avg_cost = this_sd->avg_scan_cost;
> + u64 time, cost;
> + s64 delta;
> + int cpu, wrap;
> +
> + /*
> +  * Due to large variance we need a large fuzz factor; hackbench in
> +  * particularly is sensitive here.
> +  */
> + if ((avg_idle / 512) < avg_cost)
> + return -1;
> +
> + time = local_clock();
> +
> + for_each_cpu_wrap(cpu, sched_domain_span(sd), target, wrap) {
> + if (!cpumask_test_cpu(cpu, tsk_cpus_allowed(p)))
> + continue;
> + if (idle_cpu(cpu))
> + break;
> + }
> +
> + time = local_clock() - time;
> + cost = this_sd->avg_scan_cost;
> + delta = (s64)(time - cost) / 8;
> + this_sd->avg_scan_cost += delta;
> +
> + return cpu;
> +}

[snip]

> +
> + i = select_idle_core(p, sd, target);
> + if ((unsigned)i < nr_cpumask_bits)
> + return i;
> +
> + i = select_idle_cpu(p, sd, target);
> + if ((unsigned)i < nr_cpumask_bits)
> + return i;
> +
> + i = select_idle_smt(p, sd, target);
> + if ((unsigned)i < nr_cpumask_bits)
> + return i;

First, on smt, these three scans have a lot of overlap, but it also has an
effect of opportunistic-spinning if it was intended, which is good. Anyway,
maybe you should write something about it, and why only consider cost for cpu,
not core.

Then, I am still considering combining them a bit, like the following patch.
And if you want, more might be combined.

P.S., The idle_smt_cpu may not be the first idle, but one more i++ can make
it.

---

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 25bd5b0..648a15c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5281,7 +5281,7 @@ unlock:
 static int select_idle_core(struct task_struct *p, struct sched_domain *sd, 
int target)
 {
struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
-   int core, cpu, wrap;
+   int core, cpu, wrap, i = 0, idle_smt_cpu = -1;
 
if (!static_branch_likely(_smt_present))
return -1;
@@ -5298,8 +5298,14 @@ static int select_idle_core(struct task_struct *p, 
struct sched_domain *sd, int
cpumask_clear_cpu(cpu, cpus);
if (!idle_cpu(cpu))
idle = false;
+   /*
+* First smt must be target's smt, and any cpu here is 
allowed
+*/
+   else if (i == 0)
+   idle_smt_cpu = cpu;
}
 
+   i++;
if (idle)
return core;
}

Re: [RFC][PATCH 5/7] sched: Rewrite select_idle_siblings()

[Yuyang Du]

On Mon, May 09, 2016 at 12:48:12PM +0200, Peter Zijlstra wrote:
> +/*
> + * Scan the LLC domain for idle CPUs; this is dynamically regulated by
> + * comparing the average scan cost (tracked in sd->avg_scan_cost) against the

   tracked in this_sd->avg_scan_cost

> + * average idle time for this rq (as found in rq->avg_idle).
> + */
> +static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, 
> int target)
> +{
> + struct sched_domain *this_sd = rcu_dereference(*this_cpu_ptr(_llc));
> + u64 avg_idle = this_rq()->avg_idle;
> + u64 avg_cost = this_sd->avg_scan_cost;
> + u64 time, cost;
> + s64 delta;
> + int cpu, wrap;
> +
> + /*
> +  * Due to large variance we need a large fuzz factor; hackbench in
> +  * particularly is sensitive here.
> +  */
> + if ((avg_idle / 512) < avg_cost)
> + return -1;
> +
> + time = local_clock();
> +
> + for_each_cpu_wrap(cpu, sched_domain_span(sd), target, wrap) {
> + if (!cpumask_test_cpu(cpu, tsk_cpus_allowed(p)))
> + continue;
> + if (idle_cpu(cpu))
> + break;
> + }
> +
> + time = local_clock() - time;
> + cost = this_sd->avg_scan_cost;
> + delta = (s64)(time - cost) / 8;
> + this_sd->avg_scan_cost += delta;
> +
> + return cpu;
> +}

[snip]

> +
> + i = select_idle_core(p, sd, target);
> + if ((unsigned)i < nr_cpumask_bits)
> + return i;
> +
> + i = select_idle_cpu(p, sd, target);
> + if ((unsigned)i < nr_cpumask_bits)
> + return i;
> +
> + i = select_idle_smt(p, sd, target);
> + if ((unsigned)i < nr_cpumask_bits)
> + return i;

First, on smt, these three scans have a lot of overlap, but it also has an
effect of opportunistic-spinning if it was intended, which is good. Anyway,
maybe you should write something about it, and why only consider cost for cpu,
not core.

Then, I am still considering combining them a bit, like the following patch.
And if you want, more might be combined.

P.S., The idle_smt_cpu may not be the first idle, but one more i++ can make
it.

---

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 25bd5b0..648a15c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5281,7 +5281,7 @@ unlock:
 static int select_idle_core(struct task_struct *p, struct sched_domain *sd, 
int target)
 {
struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
-   int core, cpu, wrap;
+   int core, cpu, wrap, i = 0, idle_smt_cpu = -1;
 
if (!static_branch_likely(_smt_present))
return -1;
@@ -5298,8 +5298,14 @@ static int select_idle_core(struct task_struct *p, 
struct sched_domain *sd, int
cpumask_clear_cpu(cpu, cpus);
if (!idle_cpu(cpu))
idle = false;
+   /*
+* First smt must be target's smt, and any cpu here is 
allowed
+*/
+   else if (i == 0)
+   idle_smt_cpu = cpu;
}
 
+   i++;
if (idle)
return core;
}

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

[Hoan Tran]

Hi Ashwin,

Thanks for your review !

On Tue, May 10, 2016 at 5:00 AM, Ashwin Chaugule
 wrote:
> Hello,
>
> On 6 May 2016 at 14:38, Hoan Tran  wrote:
>> From: hotran 
>>
>> ACPI 6.1 has a PCC HW-Reduced Communication Subspace Type 2 intended for
>> use on HW-Reduce ACPI Platform, which requires read-modify-write sequence
>> to acknowledge doorbell interrupt. This patch provides the implementation
>> for the Communication Subspace Type 2.
>>
>> This patch depends on patch [1] which supports PCC subspace type 2 header
>> [1] https://lkml.org/lkml/2016/5/5/14
>>  - [PATCH v2 03/13] ACPICA: ACPI 6.1: Support for new PCCT subtable
>>
>> v2
>>  * Remove changes inside "actbl3.h". This file is taken care by ACPICA.
>>  * Parse both subspace type 1 and subspace type 2
>>  * Remove unnecessary variable initialization
>>  * ISR returns IRQ_NONE in case of error
>>
>> v1
>>  * Initial
>>
>> Signed-off-by: Hoan Tran 
>> ---
>>  drivers/mailbox/pcc.c | 395 
>> +-
>>  1 file changed, 296 insertions(+), 99 deletions(-)
>>
>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>> index 043828d..58c9a67 100644
>> --- a/drivers/mailbox/pcc.c
>> +++ b/drivers/mailbox/pcc.c
>> @@ -59,6 +59,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -68,27 +69,179 @@
>>  #include "mailbox.h"
>>
>>  #define MAX_PCC_SUBSPACES  256
>> +#define MBOX_IRQ_NAME  "pcc-mbox"
>>
>> -static struct mbox_chan *pcc_mbox_channels;
>> +/**
>> + * PCC mailbox channel information
>> + *
>> + * @chan:  Pointer to mailbox communication channel
>> + * @pcc_doorbell_vaddr: PCC doorbell register address
>> + * @pcc_doorbell_ack_vaddr: PCC doorbell ack register address
>> + * @irq:   Interrupt number of the channel
>> + */
>> +struct pcc_mbox_chan {
>> +   struct mbox_chan*chan;
>> +   void __iomem*pcc_doorbell_vaddr;
>> +   void __iomem*pcc_doorbell_ack_vaddr;
>> +   int irq;
>> +};
>>
>> -/* Array of cached virtual address for doorbell registers */
>> -static void __iomem **pcc_doorbell_vaddr;
>> +/**
>> + * PCC mailbox controller data
>> + *
>> + * @mb_ctrl:   Representation of the communication channel controller
>> + * @mbox_chan: Array of PCC mailbox channels of the controller
>> + * @chans: Array of mailbox communication channels
>> + */
>> +struct pcc_mbox {
>> +   struct mbox_controller  mbox_ctrl;
>> +   struct pcc_mbox_chan*mbox_chans;
>> +   struct mbox_chan*chans;
>> +};
>> +
>> +static struct pcc_mbox pcc_mbox_ctx = {};
>
> Im missing the idea behind creating this structure. Are you
> registering multiple controllers somewhere?
No, I just want to use a structure to store all global variables into
>
>
> [...]
>
>>
>> @@ -357,24 +534,44 @@ static int __init acpi_pcc_probe(void)
>> pcct_entry = (struct acpi_subtable_header *) (
>> (unsigned long) pcct_tbl + sizeof(struct acpi_table_pcct));
>>
>> +   acpi_pcct_tbl = (struct acpi_table_pcct *) pcct_tbl;
>> +   if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL)
>> +   pcc_mbox_ctx.mbox_ctrl.txdone_irq = true;
>> +
>> for (i = 0; i < count; i++) {
>> struct acpi_generic_address *db_reg;
>> struct acpi_pcct_hw_reduced *pcct_ss;
>> -   pcc_mbox_channels[i].con_priv = pcct_entry;
>> +
>> +   pcc_mbox_ctx.chans[i].con_priv = pcct_entry;
>> +   pcc_mbox_ctx.chans[i].mbox = _mbox_ctx.mbox_ctrl;
>> +
>> +   pcct_ss = (struct acpi_pcct_hw_reduced *) pcct_entry;
>> +
>> +   pcc_mbox_ctx.mbox_chans[i].chan = _mbox_ctx.chans[i];
>> +   if (pcc_mbox_ctx.mbox_ctrl.txdone_irq) {
>> +   rc = 
>> pcc_parse_subspace_irq(_mbox_ctx.mbox_chans[i],
>> +   pcct_ss);
>> +   if (rc < 0)
>> +   return rc;
>> +   }
>
> I think we should parse the remaining entries and register them if
> they are sane. Some other PCC clients can then continue to function.
I think, it could be an error of PCCT table and need to be returned.
>
>>
>> /* If doorbell is in system memory cache the virt address */
>> pcct_ss = (struct acpi_pcct_hw_reduced *)pcct_entry;
>> db_reg = _ss->doorbell_register;
>> -   if (db_reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY)
>> -   pcc_doorbell_vaddr[i] = 
>> acpi_os_ioremap(db_reg->address,
>> +   if (db_reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
>> +   pcc_mbox_ctx.mbox_chans[i].pcc_doorbell_vaddr =
>> +   acpi_os_ioremap(db_reg->address,
>>  

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

[Hoan Tran]

Hi Ashwin,

Thanks for your review !

On Tue, May 10, 2016 at 5:00 AM, Ashwin Chaugule
 wrote:
> Hello,
>
> On 6 May 2016 at 14:38, Hoan Tran  wrote:
>> From: hotran 
>>
>> ACPI 6.1 has a PCC HW-Reduced Communication Subspace Type 2 intended for
>> use on HW-Reduce ACPI Platform, which requires read-modify-write sequence
>> to acknowledge doorbell interrupt. This patch provides the implementation
>> for the Communication Subspace Type 2.
>>
>> This patch depends on patch [1] which supports PCC subspace type 2 header
>> [1] https://lkml.org/lkml/2016/5/5/14
>>  - [PATCH v2 03/13] ACPICA: ACPI 6.1: Support for new PCCT subtable
>>
>> v2
>>  * Remove changes inside "actbl3.h". This file is taken care by ACPICA.
>>  * Parse both subspace type 1 and subspace type 2
>>  * Remove unnecessary variable initialization
>>  * ISR returns IRQ_NONE in case of error
>>
>> v1
>>  * Initial
>>
>> Signed-off-by: Hoan Tran 
>> ---
>>  drivers/mailbox/pcc.c | 395 
>> +-
>>  1 file changed, 296 insertions(+), 99 deletions(-)
>>
>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>> index 043828d..58c9a67 100644
>> --- a/drivers/mailbox/pcc.c
>> +++ b/drivers/mailbox/pcc.c
>> @@ -59,6 +59,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -68,27 +69,179 @@
>>  #include "mailbox.h"
>>
>>  #define MAX_PCC_SUBSPACES  256
>> +#define MBOX_IRQ_NAME  "pcc-mbox"
>>
>> -static struct mbox_chan *pcc_mbox_channels;
>> +/**
>> + * PCC mailbox channel information
>> + *
>> + * @chan:  Pointer to mailbox communication channel
>> + * @pcc_doorbell_vaddr: PCC doorbell register address
>> + * @pcc_doorbell_ack_vaddr: PCC doorbell ack register address
>> + * @irq:   Interrupt number of the channel
>> + */
>> +struct pcc_mbox_chan {
>> +   struct mbox_chan*chan;
>> +   void __iomem*pcc_doorbell_vaddr;
>> +   void __iomem*pcc_doorbell_ack_vaddr;
>> +   int irq;
>> +};
>>
>> -/* Array of cached virtual address for doorbell registers */
>> -static void __iomem **pcc_doorbell_vaddr;
>> +/**
>> + * PCC mailbox controller data
>> + *
>> + * @mb_ctrl:   Representation of the communication channel controller
>> + * @mbox_chan: Array of PCC mailbox channels of the controller
>> + * @chans: Array of mailbox communication channels
>> + */
>> +struct pcc_mbox {
>> +   struct mbox_controller  mbox_ctrl;
>> +   struct pcc_mbox_chan*mbox_chans;
>> +   struct mbox_chan*chans;
>> +};
>> +
>> +static struct pcc_mbox pcc_mbox_ctx = {};
>
> Im missing the idea behind creating this structure. Are you
> registering multiple controllers somewhere?
No, I just want to use a structure to store all global variables into
>
>
> [...]
>
>>
>> @@ -357,24 +534,44 @@ static int __init acpi_pcc_probe(void)
>> pcct_entry = (struct acpi_subtable_header *) (
>> (unsigned long) pcct_tbl + sizeof(struct acpi_table_pcct));
>>
>> +   acpi_pcct_tbl = (struct acpi_table_pcct *) pcct_tbl;
>> +   if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL)
>> +   pcc_mbox_ctx.mbox_ctrl.txdone_irq = true;
>> +
>> for (i = 0; i < count; i++) {
>> struct acpi_generic_address *db_reg;
>> struct acpi_pcct_hw_reduced *pcct_ss;
>> -   pcc_mbox_channels[i].con_priv = pcct_entry;
>> +
>> +   pcc_mbox_ctx.chans[i].con_priv = pcct_entry;
>> +   pcc_mbox_ctx.chans[i].mbox = _mbox_ctx.mbox_ctrl;
>> +
>> +   pcct_ss = (struct acpi_pcct_hw_reduced *) pcct_entry;
>> +
>> +   pcc_mbox_ctx.mbox_chans[i].chan = _mbox_ctx.chans[i];
>> +   if (pcc_mbox_ctx.mbox_ctrl.txdone_irq) {
>> +   rc = 
>> pcc_parse_subspace_irq(_mbox_ctx.mbox_chans[i],
>> +   pcct_ss);
>> +   if (rc < 0)
>> +   return rc;
>> +   }
>
> I think we should parse the remaining entries and register them if
> they are sane. Some other PCC clients can then continue to function.
I think, it could be an error of PCCT table and need to be returned.
>
>>
>> /* If doorbell is in system memory cache the virt address */
>> pcct_ss = (struct acpi_pcct_hw_reduced *)pcct_entry;
>> db_reg = _ss->doorbell_register;
>> -   if (db_reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY)
>> -   pcc_doorbell_vaddr[i] = 
>> acpi_os_ioremap(db_reg->address,
>> +   if (db_reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
>> +   pcc_mbox_ctx.mbox_chans[i].pcc_doorbell_vaddr =
>> +   acpi_os_ioremap(db_reg->address,
>> db_reg->bit_width/8);
>> +   }
>> +
>>   

Re: [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues

[Borislav Petkov]

On Tue, May 10, 2016 at 04:29:52PM -0700, Yu-cheng Yu wrote:
> XSAVES is a kernel-mode instruction. It offers a compacted format and
> memory-write optimization. These patches fix issues in the first
> implementation.
> 
> Changes since Version 5:

Please, for the future, do send your patchset roughly only once a week -
you just sent v5 a day or two ago without giving proper time to people
(me?) to review them all. Consult Documentation/SubmittingPatches if
there are doubts.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: sched: tweak select_idle_sibling to look for idle threads

[Mike Galbraith]

On Wed, 2016-05-11 at 03:16 +0800, Yuyang Du wrote:
> On Tue, May 10, 2016 at 05:26:05PM +0200, Mike Galbraith wrote:
> > On Tue, 2016-05-10 at 09:49 +0200, Mike Galbraith wrote:
> > 
> > >  Only whacking
> > > cfs_rq_runnable_load_avg() with a rock makes schbench -m  -t
> > >  -a work well.  'Course a rock in its gearbox also
> > > rendered load balancing fairly busted for the general case :)
> > 
> > Smaller rock doesn't injure heavy tbench, but more importantly, still
> > demonstrates the issue when you want full spread.
> > 
> > schbench -m4 -t38 -a
> > 
> > cputime 3 threads 38 p99 177
> > cputime 3 threads 39 p99 10160
> > 
> > LB_TIP_AVG_HIGH
> > cputime 3 threads 38 p99 193
> > cputime 3 threads 39 p99 184
> > cputime 3 threads 40 p99 203
> > cputime 3 threads 41 p99 202
> > cputime 3 threads 42 p99 205
> > cputime 3 threads 43 p99 218
> > cputime 3 threads 44 p99 237
> > cputime 3 threads 45 p99 245
> > cputime 3 threads 46 p99 262
> > cputime 3 threads 47 p99 296
> > cputime 3 threads 48 p99 3308
> > 
> > 47*4+4=nr_cpus yay
>  
> yay... and haha, "a perfect world"...

Yup.. for this load.

> > ---
> >  kernel/sched/fair.c |3 +++
> >  kernel/sched/features.h |1 +
> >  2 files changed, 4 insertions(+)
> > 
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -3027,6 +3027,9 @@ void remove_entity_load_avg(struct sched
> >  
> >  static inline unsigned long cfs_rq_runnable_load_avg(struct cfs_rq *cfs_rq)
> >  {
> > +> >> > if (sched_feat(LB_TIP_AVG_HIGH) && cfs_rq->load.weight > 
> > cfs_rq->runnable_load_avg*2)
> > +> >> > > > return cfs_rq->runnable_load_avg + min_t(unsigned 
> > long, NICE_0_LOAD,
> > +> >> > > > > > > > > > > > > >  
> > cfs_rq->load.weight/2);
> >  > >> > return cfs_rq->runnable_load_avg;
> >  }
>   
> cfs_rq->runnable_load_avg is for sure no greater than (in this case much less
> than, maybe 1/2 of) load.weight, whereas load_avg is not necessarily a rock
> in gearbox that only impedes speed up, but also speed down.

Yeah, just like everything else, it'll cuts both ways (why you can't
win the sched game).  If I can believe tbench, at tasks=cpus, reducing
lag increased utilization and reduced latency a wee bit, as did the
reserve thing once a booboo got fixed up.  Makes sense, robbing Peter
to pay Paul should work out better for Paul.

NO_LB_TIP_AVG_HIGH
Throughput 27132.9 MB/sec  96 clients  96 procs  max_latency=7.656 ms
Throughput 28464.1 MB/sec  96 clients  96 procs  max_latency=9.905 ms
Throughput 25369.8 MB/sec  96 clients  96 procs  max_latency=7.192 ms
Throughput 25670.3 MB/sec  96 clients  96 procs  max_latency=5.874 ms
Throughput 29309.3 MB/sec  96 clients  96 procs  max_latency=1.331 ms
avg27189   1.000 6.391   1.000

NO_LB_TIP_AVG_HIGH IDLE_RESERVE
Throughput 24437.5 MB/sec  96 clients  96 procs  max_latency=1.837 ms
Throughput 29464.7 MB/sec  96 clients  96 procs  max_latency=1.594 ms
Throughput 28023.6 MB/sec  96 clients  96 procs  max_latency=1.494 ms
Throughput 28299.0 MB/sec  96 clients  96 procs  max_latency=10.404 ms
Throughput 29072.1 MB/sec  96 clients  96 procs  max_latency=5.575 ms
avg27859   1.024 4.180   0.654

LB_TIP_AVG_HIGH NO_IDLE_RESERVE
Throughput 29068.1 MB/sec  96 clients  96 procs  max_latency=5.599 ms
Throughput 26435.6 MB/sec  96 clients  96 procs  max_latency=3.703 ms
Throughput 23930.0 MB/sec  96 clients  96 procs  max_latency=7.742 ms
Throughput 29464.2 MB/sec  96 clients  96 procs  max_latency=1.549 ms
Throughput 24250.9 MB/sec  96 clients  96 procs  max_latency=1.518 ms
avg26629   0.979 4.022   0.629

LB_TIP_AVG_HIGH IDLE_RESERVE
Throughput 30340.1 MB/sec  96 clients  96 procs  max_latency=1.465 ms
Throughput 29042.9 MB/sec  96 clients  96 procs  max_latency=4.515 ms
Throughput 26718.7 MB/sec  96 clients  96 procs  max_latency=1.822 ms
Throughput 28694.4 MB/sec  96 clients  96 procs  max_latency=1.503 ms
Throughput 28918.2 MB/sec  96 clients  96 procs  max_latency=7.599 ms
avg28742   1.057 3.380   0.528

> But I really don't know the load references in select_task_rq() should be
> what kind. So maybe the real issue is a mix of them, i.e., conflated balancing
> and just wanting an idle cpu. ?

Depends on the goal.  For both, load lagging reality means the high
frequency component is squelched, meaning less migration cost, but also
higher latency due to stacking.  It's a tradeoff where Chris' latency
is everything" benchmark, and _maybe_ the real world load it's based
upon is on Peter's end of the rob Peter to pay Paul transaction.  The
benchmark says it definitely is, the real world load may have already
been fixed up by the select_idle_sibling() rewrite.

-Mike

Re: [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues

[Borislav Petkov]

On Tue, May 10, 2016 at 04:29:52PM -0700, Yu-cheng Yu wrote:
> XSAVES is a kernel-mode instruction. It offers a compacted format and
> memory-write optimization. These patches fix issues in the first
> implementation.
> 
> Changes since Version 5:

Please, for the future, do send your patchset roughly only once a week -
you just sent v5 a day or two ago without giving proper time to people
(me?) to review them all. Consult Documentation/SubmittingPatches if
there are doubts.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: sched: tweak select_idle_sibling to look for idle threads

[Mike Galbraith]

On Wed, 2016-05-11 at 03:16 +0800, Yuyang Du wrote:
> On Tue, May 10, 2016 at 05:26:05PM +0200, Mike Galbraith wrote:
> > On Tue, 2016-05-10 at 09:49 +0200, Mike Galbraith wrote:
> > 
> > >  Only whacking
> > > cfs_rq_runnable_load_avg() with a rock makes schbench -m  -t
> > >  -a work well.  'Course a rock in its gearbox also
> > > rendered load balancing fairly busted for the general case :)
> > 
> > Smaller rock doesn't injure heavy tbench, but more importantly, still
> > demonstrates the issue when you want full spread.
> > 
> > schbench -m4 -t38 -a
> > 
> > cputime 3 threads 38 p99 177
> > cputime 3 threads 39 p99 10160
> > 
> > LB_TIP_AVG_HIGH
> > cputime 3 threads 38 p99 193
> > cputime 3 threads 39 p99 184
> > cputime 3 threads 40 p99 203
> > cputime 3 threads 41 p99 202
> > cputime 3 threads 42 p99 205
> > cputime 3 threads 43 p99 218
> > cputime 3 threads 44 p99 237
> > cputime 3 threads 45 p99 245
> > cputime 3 threads 46 p99 262
> > cputime 3 threads 47 p99 296
> > cputime 3 threads 48 p99 3308
> > 
> > 47*4+4=nr_cpus yay
>  
> yay... and haha, "a perfect world"...

Yup.. for this load.

> > ---
> >  kernel/sched/fair.c |3 +++
> >  kernel/sched/features.h |1 +
> >  2 files changed, 4 insertions(+)
> > 
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -3027,6 +3027,9 @@ void remove_entity_load_avg(struct sched
> >  
> >  static inline unsigned long cfs_rq_runnable_load_avg(struct cfs_rq *cfs_rq)
> >  {
> > +> >> > if (sched_feat(LB_TIP_AVG_HIGH) && cfs_rq->load.weight > 
> > cfs_rq->runnable_load_avg*2)
> > +> >> > > > return cfs_rq->runnable_load_avg + min_t(unsigned 
> > long, NICE_0_LOAD,
> > +> >> > > > > > > > > > > > > >  
> > cfs_rq->load.weight/2);
> >  > >> > return cfs_rq->runnable_load_avg;
> >  }
>   
> cfs_rq->runnable_load_avg is for sure no greater than (in this case much less
> than, maybe 1/2 of) load.weight, whereas load_avg is not necessarily a rock
> in gearbox that only impedes speed up, but also speed down.

Yeah, just like everything else, it'll cuts both ways (why you can't
win the sched game).  If I can believe tbench, at tasks=cpus, reducing
lag increased utilization and reduced latency a wee bit, as did the
reserve thing once a booboo got fixed up.  Makes sense, robbing Peter
to pay Paul should work out better for Paul.

NO_LB_TIP_AVG_HIGH
Throughput 27132.9 MB/sec  96 clients  96 procs  max_latency=7.656 ms
Throughput 28464.1 MB/sec  96 clients  96 procs  max_latency=9.905 ms
Throughput 25369.8 MB/sec  96 clients  96 procs  max_latency=7.192 ms
Throughput 25670.3 MB/sec  96 clients  96 procs  max_latency=5.874 ms
Throughput 29309.3 MB/sec  96 clients  96 procs  max_latency=1.331 ms
avg27189   1.000 6.391   1.000

NO_LB_TIP_AVG_HIGH IDLE_RESERVE
Throughput 24437.5 MB/sec  96 clients  96 procs  max_latency=1.837 ms
Throughput 29464.7 MB/sec  96 clients  96 procs  max_latency=1.594 ms
Throughput 28023.6 MB/sec  96 clients  96 procs  max_latency=1.494 ms
Throughput 28299.0 MB/sec  96 clients  96 procs  max_latency=10.404 ms
Throughput 29072.1 MB/sec  96 clients  96 procs  max_latency=5.575 ms
avg27859   1.024 4.180   0.654

LB_TIP_AVG_HIGH NO_IDLE_RESERVE
Throughput 29068.1 MB/sec  96 clients  96 procs  max_latency=5.599 ms
Throughput 26435.6 MB/sec  96 clients  96 procs  max_latency=3.703 ms
Throughput 23930.0 MB/sec  96 clients  96 procs  max_latency=7.742 ms
Throughput 29464.2 MB/sec  96 clients  96 procs  max_latency=1.549 ms
Throughput 24250.9 MB/sec  96 clients  96 procs  max_latency=1.518 ms
avg26629   0.979 4.022   0.629

LB_TIP_AVG_HIGH IDLE_RESERVE
Throughput 30340.1 MB/sec  96 clients  96 procs  max_latency=1.465 ms
Throughput 29042.9 MB/sec  96 clients  96 procs  max_latency=4.515 ms
Throughput 26718.7 MB/sec  96 clients  96 procs  max_latency=1.822 ms
Throughput 28694.4 MB/sec  96 clients  96 procs  max_latency=1.503 ms
Throughput 28918.2 MB/sec  96 clients  96 procs  max_latency=7.599 ms
avg28742   1.057 3.380   0.528

> But I really don't know the load references in select_task_rq() should be
> what kind. So maybe the real issue is a mix of them, i.e., conflated balancing
> and just wanting an idle cpu. ?

Depends on the goal.  For both, load lagging reality means the high
frequency component is squelched, meaning less migration cost, but also
higher latency due to stacking.  It's a tradeoff where Chris' latency
is everything" benchmark, and _maybe_ the real world load it's based
upon is on Peter's end of the rob Peter to pay Paul transaction.  The
benchmark says it definitely is, the real world load may have already
been fixed up by the select_idle_sibling() rewrite.

-Mike

Re: [PATCH] Staging: wlan-ng: fix comments style

[Kroah-Hartman]

On Tue, May 10, 2016 at 09:05:15PM -0400, YU Bo wrote:
> Hi Greg,
> On Mon, May 09, 2016 at 02:26:13PM +0200, Kroah-Hartman wrote:
> > On Sun, May 08, 2016 at 10:45:16AM -0400, YU Bo wrote:
> > > The patch fixed warning reported by checkpatch.pl: Block comments use a
> > > trailing */ on a separate line.
> > > 
> > > Signed-off-by: YU Bo 
> > > ---
> > >  drivers/staging/wlan-ng/prism2mgmt.h |4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > Patch doesn't apply to my tree, what branch did you make this against?
> Thanks for your reply.
> I made two branches on your tree:little,greg.
> Each time i went into a branch and type:
> git fetch origin && git rebase origin/staging-testing

Ok, good, that is the correct branch, I guess we just got out of sync
here, sorry about that.  Try to rebase and resend.

thanks,

greg k-h

Re: [PATCH] Staging: wlan-ng: fix comments style

[Kroah-Hartman]

On Tue, May 10, 2016 at 09:05:15PM -0400, YU Bo wrote:
> Hi Greg,
> On Mon, May 09, 2016 at 02:26:13PM +0200, Kroah-Hartman wrote:
> > On Sun, May 08, 2016 at 10:45:16AM -0400, YU Bo wrote:
> > > The patch fixed warning reported by checkpatch.pl: Block comments use a
> > > trailing */ on a separate line.
> > > 
> > > Signed-off-by: YU Bo 
> > > ---
> > >  drivers/staging/wlan-ng/prism2mgmt.h |4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > Patch doesn't apply to my tree, what branch did you make this against?
> Thanks for your reply.
> I made two branches on your tree:little,greg.
> Each time i went into a branch and type:
> git fetch origin && git rebase origin/staging-testing

Ok, good, that is the correct branch, I guess we just got out of sync
here, sorry about that.  Try to rebase and resend.

thanks,

greg k-h

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

[Borislav Petkov]

On Tue, May 10, 2016 at 03:30:48PM -0700, H. Peter Anvin wrote:
> I didn't mean inline assembly.

How does that matter?

The problem is having as less insn bytes as possible and the minimal
size we can do is issuing POPCNT everywhere which is 4 or 5 bytes. The
alternatives then replace that with a CALL which is also 5 bytes.

The way I did it now, it adds 22K more to allyesconfig vmlinux due to
the static_cpu_has doubled alternatives sections and the JMPs. The
thunks will keep those 5 bytes *and* get rid of the calling convention
without the growth.

Or?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

[Borislav Petkov]

On Tue, May 10, 2016 at 03:30:48PM -0700, H. Peter Anvin wrote:
> I didn't mean inline assembly.

How does that matter?

The problem is having as less insn bytes as possible and the minimal
size we can do is issuing POPCNT everywhere which is 4 or 5 bytes. The
alternatives then replace that with a CALL which is also 5 bytes.

The way I did it now, it adds 22K more to allyesconfig vmlinux due to
the static_cpu_has doubled alternatives sections and the JMPs. The
thunks will keep those 5 bytes *and* get rid of the calling convention
without the growth.

Or?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH v8 8/8] i2c: rk3x: support fast-mode plus for rk3399

[David Wu]

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- None

 drivers/i2c/busses/i2c-rk3x.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 25ed1ad..0ba25ee 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -126,6 +126,17 @@ static const struct i2c_spec_values fast_mode_spec = {
.min_hold_buffer_ns = 1300,
 };
 
+static const struct i2c_spec_values fast_mode_plus_spec = {
+   .min_hold_start_ns = 260,
+   .min_low_ns = 500,
+   .min_high_ns = 260,
+   .min_setup_start_ns = 260,
+   .max_data_hold_ns = 400,
+   .min_data_setup_ns = 50,
+   .min_setup_stop_ns = 260,
+   .min_hold_buffer_ns = 500,
+};
+
 /**
  * struct rk3x_i2c_calced_timings:
  * @div_low: Divider output for low
@@ -531,8 +542,10 @@ static const struct i2c_spec_values 
*rk3x_i2c_get_spec(unsigned int speed)
 {
if (speed <= 10)
return _mode_spec;
-   else
+   else if (speed <= 40)
return _mode_spec;
+   else
+   return _mode_plus_spec;
 }
 
 /**
@@ -743,9 +756,9 @@ static int rk3x_i2c_v1_calc_timings(unsigned long clk_rate,
const struct i2c_spec_values *spec;
int ret = 0;
 
-   /* Support standard-mode and fast-mode */
-   if (WARN_ON(t->bus_freq_hz > 40))
-   t->bus_freq_hz = 40;
+   /* Support standard-mode, fast-mode and fast-mode plus */
+   if (WARN_ON(t->bus_freq_hz > 100))
+   t->bus_freq_hz = 100;
 
/* prevent scl_rate_khz from becoming 0 */
if (WARN_ON(t->bus_freq_hz < 1000))
-- 
1.9.1

[PATCH v8 8/8] i2c: rk3x: support fast-mode plus for rk3399

[David Wu]

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- None

 drivers/i2c/busses/i2c-rk3x.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 25ed1ad..0ba25ee 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -126,6 +126,17 @@ static const struct i2c_spec_values fast_mode_spec = {
.min_hold_buffer_ns = 1300,
 };
 
+static const struct i2c_spec_values fast_mode_plus_spec = {
+   .min_hold_start_ns = 260,
+   .min_low_ns = 500,
+   .min_high_ns = 260,
+   .min_setup_start_ns = 260,
+   .max_data_hold_ns = 400,
+   .min_data_setup_ns = 50,
+   .min_setup_stop_ns = 260,
+   .min_hold_buffer_ns = 500,
+};
+
 /**
  * struct rk3x_i2c_calced_timings:
  * @div_low: Divider output for low
@@ -531,8 +542,10 @@ static const struct i2c_spec_values 
*rk3x_i2c_get_spec(unsigned int speed)
 {
if (speed <= 10)
return _mode_spec;
-   else
+   else if (speed <= 40)
return _mode_spec;
+   else
+   return _mode_plus_spec;
 }
 
 /**
@@ -743,9 +756,9 @@ static int rk3x_i2c_v1_calc_timings(unsigned long clk_rate,
const struct i2c_spec_values *spec;
int ret = 0;
 
-   /* Support standard-mode and fast-mode */
-   if (WARN_ON(t->bus_freq_hz > 40))
-   t->bus_freq_hz = 40;
+   /* Support standard-mode, fast-mode and fast-mode plus */
+   if (WARN_ON(t->bus_freq_hz > 100))
+   t->bus_freq_hz = 100;
 
/* prevent scl_rate_khz from becoming 0 */
if (WARN_ON(t->bus_freq_hz < 1000))
-- 
1.9.1

[PATCH v8 6/8] dt-bindings: i2c: rk3x: add support for rk3399

[David Wu]

The bus clock and function clock are separated at rk3399,
and others use one clock as the bus clock and function clock.

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- remove error description.

 Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt 
b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
index 0b4a85f..5429301 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
@@ -6,10 +6,20 @@ RK3xxx SoCs.
 Required properties :
 
  - reg : Offset and length of the register set for the device
- - compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c",
-   "rockchip,rk3228-i2c" or "rockchip,rk3288-i2c".
+ - compatible: should be one of the following:
+   - "rockchip,rk3066-i2c": for rk3066
+   - "rockchip,rk3188-i2c": for rk3188
+   - "rockchip,rk3228-i2c": for rk3228
+   - "rockchip,rk3288-i2c": for rk3288
+   - "rockchip,rk3399-i2c": for rk3399
  - interrupts : interrupt number
- - clocks : parent clock
+ - clocks: See ../clock/clock-bindings.txt
+   - For older hardware (rk3066, rk3188, rk3228, rk3288):
+ - There is one clock that's used both to derive the functional clock
+   for the device and as the bus clock.
+   - For newer hardware (rk3399): specified by name
+ - "i2c": REQUIRED. This is used to derive the functional clock.
+ - "pclk": REQUIRED. This is the bus clock.
 
 Required on RK3066, RK3188 :
 
-- 
1.9.1

[PATCH v8 6/8] dt-bindings: i2c: rk3x: add support for rk3399

[David Wu]

The bus clock and function clock are separated at rk3399,
and others use one clock as the bus clock and function clock.

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- remove error description.

 Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt 
b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
index 0b4a85f..5429301 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
@@ -6,10 +6,20 @@ RK3xxx SoCs.
 Required properties :
 
  - reg : Offset and length of the register set for the device
- - compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c",
-   "rockchip,rk3228-i2c" or "rockchip,rk3288-i2c".
+ - compatible: should be one of the following:
+   - "rockchip,rk3066-i2c": for rk3066
+   - "rockchip,rk3188-i2c": for rk3188
+   - "rockchip,rk3228-i2c": for rk3228
+   - "rockchip,rk3288-i2c": for rk3288
+   - "rockchip,rk3399-i2c": for rk3399
  - interrupts : interrupt number
- - clocks : parent clock
+ - clocks: See ../clock/clock-bindings.txt
+   - For older hardware (rk3066, rk3188, rk3228, rk3288):
+ - There is one clock that's used both to derive the functional clock
+   for the device and as the bus clock.
+   - For newer hardware (rk3399): specified by name
+ - "i2c": REQUIRED. This is used to derive the functional clock.
+ - "pclk": REQUIRED. This is the bus clock.
 
 Required on RK3066, RK3188 :
 
-- 
1.9.1

[PATCH v8 7/8] i2c: rk3x: add i2c support for rk3399 soc

[David Wu]

- new method to caculate i2c timings for rk3399:
  There was an timing issue about "repeated start" time at the I2C
  controller of version0, controller appears to drop SDA at .875x (7/8)
  programmed clk high. On version 1 of the controller, the rule(.875x)
  isn't enough to meet tSU;STA
  requirements on 100k's Standard-mode. To resolve this issue,
  sda_update_config, start_setup_config and stop_setup_config for I2C
  timing information are added, new rules are designed to calculate
  the timing information at new v1.
- pclk and function clk are separated at rk3399

Signed-off-by: David Wu 
---
Changes in v8:
- update tuning in RKI2C_CON register by doing a read-modify-write (Doug)
- new method to use pclk and clk (Doug)

Changes in v7:
- transform into a 9 series patches (Doug)
- drop highspeed with mastercode, and support fast-mode plus (Doug)

 drivers/i2c/busses/i2c-rk3x.c | 289 +++---
 1 file changed, 270 insertions(+), 19 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 9791797..25ed1ad 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -58,6 +58,12 @@ enum {
 #define REG_CON_LASTACK   BIT(5) /* 1: send NACK after last received byte */
 #define REG_CON_ACTACKBIT(6) /* 1: stop if NACK is received */
 
+#define REG_CON_TUNING_MASK GENMASK(15, 8)
+
+#define REG_CON_SDA_CFG(cfg) ((cfg) << 8)
+#define REG_CON_STA_CFG(cfg) ((cfg) << 12)
+#define REG_CON_STO_CFG(cfg) ((cfg) << 14)
+
 /* REG_MRXADDR bits */
 #define REG_MRXADDR_VALID(x) BIT(24 + (x)) /* [x*8+7:x*8] of MRX[R]ADDR valid 
*/
 
@@ -77,40 +83,62 @@ enum {
 
 /**
  * struct i2c_spec_values:
+ * @min_hold_start_ns: min hold time (repeated) START condition
  * @min_low_ns: min LOW period of the SCL clock
  * @min_high_ns: min HIGH period of the SCL cloc
  * @min_setup_start_ns: min set-up time for a repeated START conditio
  * @max_data_hold_ns: max data hold time
+ * @min_data_setup_ns: min data set-up time
+ * @min_setup_stop_ns: min set-up time for STOP condition
+ * @min_hold_buffer_ns: min bus free time between a STOP and
+ * START condition
  */
 struct i2c_spec_values {
+   unsigned long min_hold_start_ns;
unsigned long min_low_ns;
unsigned long min_high_ns;
unsigned long min_setup_start_ns;
unsigned long max_data_hold_ns;
+   unsigned long min_data_setup_ns;
+   unsigned long min_setup_stop_ns;
+   unsigned long min_hold_buffer_ns;
 };
 
 static const struct i2c_spec_values standard_mode_spec = {
+   .min_hold_start_ns = 4000,
.min_low_ns = 4700,
.min_high_ns = 4000,
.min_setup_start_ns = 4700,
.max_data_hold_ns = 3450,
+   .min_data_setup_ns = 250,
+   .min_setup_stop_ns = 4000,
+   .min_hold_buffer_ns = 4700,
 };
 
 static const struct i2c_spec_values fast_mode_spec = {
+   .min_hold_start_ns = 600,
.min_low_ns = 1300,
.min_high_ns = 600,
.min_setup_start_ns = 600,
.max_data_hold_ns = 900,
+   .min_data_setup_ns = 100,
+   .min_setup_stop_ns = 600,
+   .min_hold_buffer_ns = 1300,
 };
 
 /**
  * struct rk3x_i2c_calced_timings:
  * @div_low: Divider output for low
  * @div_high: Divider output for high
+ * @tuning: Used to adjust setup/hold data time,
+ * setup/hold start time and setup stop time for
+ * v1's calc_timings, the tuning should all be 0
+ * for old hardware anyone using v0's calc_timings.
  */
 struct rk3x_i2c_calced_timings {
unsigned long div_low;
unsigned long div_high;
+   unsigned int tuning;
 };
 
 enum rk3x_i2c_state {
@@ -123,9 +151,12 @@ enum rk3x_i2c_state {
 
 /**
  * @grf_offset: offset inside the grf regmap for setting the i2c type
+ * @calc_timings: Callback function for i2c timing information calculated
  */
 struct rk3x_i2c_soc_data {
int grf_offset;
+   int (*calc_timings)(unsigned long, struct i2c_timings *,
+   struct rk3x_i2c_calced_timings *);
 };
 
 /**
@@ -134,7 +165,8 @@ struct rk3x_i2c_soc_data {
  * @dev: device for this controller
  * @soc_data: related soc data struct
  * @regs: virtual memory area
- * @clk: clock of i2c bus
+ * @clk: function clk for rk3399 or function & Bus clks for others
+ * @pclk: Bus clk for rk3399
  * @clk_rate_nb: i2c clk rate change notify
  * @t: I2C known timing information
  * @lock: spinlock for the i2c bus
@@ -156,6 +188,7 @@ struct rk3x_i2c {
/* Hardware resources */
void __iomem *regs;
struct clk *clk;
+   struct clk *pclk;
struct notifier_block clk_rate_nb;
 
/* Settings */
@@ -200,12 +233,12 @@ static inline void rk3x_i2c_clean_ipd(struct rk3x_i2c 
*i2c)
  */
 static void rk3x_i2c_start(struct rk3x_i2c *i2c)
 {
-   u32 val;
+   u32 val = i2c_readl(i2c, REG_CON) & REG_CON_TUNING_MASK;
 
i2c_writel(i2c, REG_INT_START, REG_IEN);
 
/* enable adapter with correct 

[PATCH v8 7/8] i2c: rk3x: add i2c support for rk3399 soc

[David Wu]

- new method to caculate i2c timings for rk3399:
  There was an timing issue about "repeated start" time at the I2C
  controller of version0, controller appears to drop SDA at .875x (7/8)
  programmed clk high. On version 1 of the controller, the rule(.875x)
  isn't enough to meet tSU;STA
  requirements on 100k's Standard-mode. To resolve this issue,
  sda_update_config, start_setup_config and stop_setup_config for I2C
  timing information are added, new rules are designed to calculate
  the timing information at new v1.
- pclk and function clk are separated at rk3399

Signed-off-by: David Wu 
---
Changes in v8:
- update tuning in RKI2C_CON register by doing a read-modify-write (Doug)
- new method to use pclk and clk (Doug)

Changes in v7:
- transform into a 9 series patches (Doug)
- drop highspeed with mastercode, and support fast-mode plus (Doug)

 drivers/i2c/busses/i2c-rk3x.c | 289 +++---
 1 file changed, 270 insertions(+), 19 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 9791797..25ed1ad 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -58,6 +58,12 @@ enum {
 #define REG_CON_LASTACK   BIT(5) /* 1: send NACK after last received byte */
 #define REG_CON_ACTACKBIT(6) /* 1: stop if NACK is received */
 
+#define REG_CON_TUNING_MASK GENMASK(15, 8)
+
+#define REG_CON_SDA_CFG(cfg) ((cfg) << 8)
+#define REG_CON_STA_CFG(cfg) ((cfg) << 12)
+#define REG_CON_STO_CFG(cfg) ((cfg) << 14)
+
 /* REG_MRXADDR bits */
 #define REG_MRXADDR_VALID(x) BIT(24 + (x)) /* [x*8+7:x*8] of MRX[R]ADDR valid 
*/
 
@@ -77,40 +83,62 @@ enum {
 
 /**
  * struct i2c_spec_values:
+ * @min_hold_start_ns: min hold time (repeated) START condition
  * @min_low_ns: min LOW period of the SCL clock
  * @min_high_ns: min HIGH period of the SCL cloc
  * @min_setup_start_ns: min set-up time for a repeated START conditio
  * @max_data_hold_ns: max data hold time
+ * @min_data_setup_ns: min data set-up time
+ * @min_setup_stop_ns: min set-up time for STOP condition
+ * @min_hold_buffer_ns: min bus free time between a STOP and
+ * START condition
  */
 struct i2c_spec_values {
+   unsigned long min_hold_start_ns;
unsigned long min_low_ns;
unsigned long min_high_ns;
unsigned long min_setup_start_ns;
unsigned long max_data_hold_ns;
+   unsigned long min_data_setup_ns;
+   unsigned long min_setup_stop_ns;
+   unsigned long min_hold_buffer_ns;
 };
 
 static const struct i2c_spec_values standard_mode_spec = {
+   .min_hold_start_ns = 4000,
.min_low_ns = 4700,
.min_high_ns = 4000,
.min_setup_start_ns = 4700,
.max_data_hold_ns = 3450,
+   .min_data_setup_ns = 250,
+   .min_setup_stop_ns = 4000,
+   .min_hold_buffer_ns = 4700,
 };
 
 static const struct i2c_spec_values fast_mode_spec = {
+   .min_hold_start_ns = 600,
.min_low_ns = 1300,
.min_high_ns = 600,
.min_setup_start_ns = 600,
.max_data_hold_ns = 900,
+   .min_data_setup_ns = 100,
+   .min_setup_stop_ns = 600,
+   .min_hold_buffer_ns = 1300,
 };
 
 /**
  * struct rk3x_i2c_calced_timings:
  * @div_low: Divider output for low
  * @div_high: Divider output for high
+ * @tuning: Used to adjust setup/hold data time,
+ * setup/hold start time and setup stop time for
+ * v1's calc_timings, the tuning should all be 0
+ * for old hardware anyone using v0's calc_timings.
  */
 struct rk3x_i2c_calced_timings {
unsigned long div_low;
unsigned long div_high;
+   unsigned int tuning;
 };
 
 enum rk3x_i2c_state {
@@ -123,9 +151,12 @@ enum rk3x_i2c_state {
 
 /**
  * @grf_offset: offset inside the grf regmap for setting the i2c type
+ * @calc_timings: Callback function for i2c timing information calculated
  */
 struct rk3x_i2c_soc_data {
int grf_offset;
+   int (*calc_timings)(unsigned long, struct i2c_timings *,
+   struct rk3x_i2c_calced_timings *);
 };
 
 /**
@@ -134,7 +165,8 @@ struct rk3x_i2c_soc_data {
  * @dev: device for this controller
  * @soc_data: related soc data struct
  * @regs: virtual memory area
- * @clk: clock of i2c bus
+ * @clk: function clk for rk3399 or function & Bus clks for others
+ * @pclk: Bus clk for rk3399
  * @clk_rate_nb: i2c clk rate change notify
  * @t: I2C known timing information
  * @lock: spinlock for the i2c bus
@@ -156,6 +188,7 @@ struct rk3x_i2c {
/* Hardware resources */
void __iomem *regs;
struct clk *clk;
+   struct clk *pclk;
struct notifier_block clk_rate_nb;
 
/* Settings */
@@ -200,12 +233,12 @@ static inline void rk3x_i2c_clean_ipd(struct rk3x_i2c 
*i2c)
  */
 static void rk3x_i2c_start(struct rk3x_i2c *i2c)
 {
-   u32 val;
+   u32 val = i2c_readl(i2c, REG_CON) & REG_CON_TUNING_MASK;
 
i2c_writel(i2c, REG_INT_START, REG_IEN);
 
/* enable adapter with correct mode, send START condition 

[PATCH v8 5/8] i2c: rk3x: Move spec timing data to "static const" structs

[David Wu]

The i2c timing specs are really just constant data.  There's no reason
to write code to init them, so move them out to structures.  This not
only is a cleaner solution but it will reduce code duplication when we
introduce a new variant of rk3x_i2c_calc_divs() in a future patch.

Signed-off-by: David Wu 
Suggested-by: Douglas Anderson 
Reviewed-by: Douglas Anderson 
---
Changes in v8:
- add commit description.
- remove the spec values that were not needed, then
  introduce the additional values in the rk3399 patch. 

 drivers/i2c/busses/i2c-rk3x.c | 83 ---
 1 file changed, 55 insertions(+), 28 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index d7a871f..9791797 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -76,6 +76,34 @@ enum {
 #define DEFAULT_SCL_RATE  (100 * 1000) /* Hz */
 
 /**
+ * struct i2c_spec_values:
+ * @min_low_ns: min LOW period of the SCL clock
+ * @min_high_ns: min HIGH period of the SCL cloc
+ * @min_setup_start_ns: min set-up time for a repeated START conditio
+ * @max_data_hold_ns: max data hold time
+ */
+struct i2c_spec_values {
+   unsigned long min_low_ns;
+   unsigned long min_high_ns;
+   unsigned long min_setup_start_ns;
+   unsigned long max_data_hold_ns;
+};
+
+static const struct i2c_spec_values standard_mode_spec = {
+   .min_low_ns = 4700,
+   .min_high_ns = 4000,
+   .min_setup_start_ns = 4700,
+   .max_data_hold_ns = 3450,
+};
+
+static const struct i2c_spec_values fast_mode_spec = {
+   .min_low_ns = 1300,
+   .min_high_ns = 600,
+   .min_setup_start_ns = 600,
+   .max_data_hold_ns = 900,
+};
+
+/**
  * struct rk3x_i2c_calced_timings:
  * @div_low: Divider output for low
  * @div_high: Divider output for high
@@ -460,6 +488,21 @@ out:
 }
 
 /**
+ * Get timing values of I2C specification
+ *
+ * @speed: Desired SCL frequency
+ *
+ * Returns: Matched i2c spec values.
+ */
+static const struct i2c_spec_values *rk3x_i2c_get_spec(unsigned int speed)
+{
+   if (speed <= 10)
+   return _mode_spec;
+   else
+   return _mode_spec;
+}
+
+/**
  * Calculate divider values for desired SCL frequency
  *
  * @clk_rate: I2C input clock rate
@@ -474,10 +517,6 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
  struct i2c_timings *t,
  struct rk3x_i2c_calced_timings *t_calc)
 {
-   unsigned long spec_min_low_ns, spec_min_high_ns;
-   unsigned long spec_setup_start, spec_max_data_hold_ns;
-   unsigned long data_hold_buffer_ns;
-
unsigned long min_low_ns, min_high_ns;
unsigned long max_low_ns, min_total_ns;
 
@@ -489,6 +528,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
unsigned long min_div_for_hold, min_total_div;
unsigned long extra_div, extra_low_div, ideal_low_div;
 
+   unsigned long data_hold_buffer_ns = 50;
+   const struct i2c_spec_values *spec;
int ret = 0;
 
/* Only support standard-mode and fast-mode */
@@ -511,22 +552,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 *   This is because the i2c host on Rockchip holds the data line
 *   for half the low time.
 */
-   if (t->bus_freq_hz <= 10) {
-   /* Standard-mode */
-   spec_min_low_ns = 4700;
-   spec_setup_start = 4700;
-   spec_min_high_ns = 4000;
-   spec_max_data_hold_ns = 3450;
-   data_hold_buffer_ns = 50;
-   } else {
-   /* Fast-mode */
-   spec_min_low_ns = 1300;
-   spec_setup_start = 600;
-   spec_min_high_ns = 600;
-   spec_max_data_hold_ns = 900;
-   data_hold_buffer_ns = 50;
-   }
-   min_high_ns = t->scl_rise_ns + spec_min_high_ns;
+   spec = rk3x_i2c_get_spec(t->bus_freq_hz);
+   min_high_ns = t->scl_rise_ns + spec->min_high_ns;
 
/*
 * Timings for repeated start:
@@ -536,14 +563,14 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 * We need to account for those rules in picking our "high" time so
 * we meet tSU;STA and tHD;STA times.
 */
-   min_high_ns = max(min_high_ns,
-   DIV_ROUND_UP((t->scl_rise_ns + spec_setup_start) * 1000, 875));
-   min_high_ns = max(min_high_ns,
-   DIV_ROUND_UP((t->scl_rise_ns + spec_setup_start +
- t->sda_fall_ns + spec_min_high_ns), 2));
-
-   min_low_ns = t->scl_fall_ns + spec_min_low_ns;
-   max_low_ns = spec_max_data_hold_ns * 2 - data_hold_buffer_ns;
+   min_high_ns = max(min_high_ns, DIV_ROUND_UP(
+   (t->scl_rise_ns + spec->min_setup_start_ns) * 1000, 875));
+   min_high_ns = max(min_high_ns, DIV_ROUND_UP(
+   

[PATCH v8 5/8] i2c: rk3x: Move spec timing data to "static const" structs

[David Wu]

The i2c timing specs are really just constant data.  There's no reason
to write code to init them, so move them out to structures.  This not
only is a cleaner solution but it will reduce code duplication when we
introduce a new variant of rk3x_i2c_calc_divs() in a future patch.

Signed-off-by: David Wu 
Suggested-by: Douglas Anderson 
Reviewed-by: Douglas Anderson 
---
Changes in v8:
- add commit description.
- remove the spec values that were not needed, then
  introduce the additional values in the rk3399 patch. 

 drivers/i2c/busses/i2c-rk3x.c | 83 ---
 1 file changed, 55 insertions(+), 28 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index d7a871f..9791797 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -76,6 +76,34 @@ enum {
 #define DEFAULT_SCL_RATE  (100 * 1000) /* Hz */
 
 /**
+ * struct i2c_spec_values:
+ * @min_low_ns: min LOW period of the SCL clock
+ * @min_high_ns: min HIGH period of the SCL cloc
+ * @min_setup_start_ns: min set-up time for a repeated START conditio
+ * @max_data_hold_ns: max data hold time
+ */
+struct i2c_spec_values {
+   unsigned long min_low_ns;
+   unsigned long min_high_ns;
+   unsigned long min_setup_start_ns;
+   unsigned long max_data_hold_ns;
+};
+
+static const struct i2c_spec_values standard_mode_spec = {
+   .min_low_ns = 4700,
+   .min_high_ns = 4000,
+   .min_setup_start_ns = 4700,
+   .max_data_hold_ns = 3450,
+};
+
+static const struct i2c_spec_values fast_mode_spec = {
+   .min_low_ns = 1300,
+   .min_high_ns = 600,
+   .min_setup_start_ns = 600,
+   .max_data_hold_ns = 900,
+};
+
+/**
  * struct rk3x_i2c_calced_timings:
  * @div_low: Divider output for low
  * @div_high: Divider output for high
@@ -460,6 +488,21 @@ out:
 }
 
 /**
+ * Get timing values of I2C specification
+ *
+ * @speed: Desired SCL frequency
+ *
+ * Returns: Matched i2c spec values.
+ */
+static const struct i2c_spec_values *rk3x_i2c_get_spec(unsigned int speed)
+{
+   if (speed <= 10)
+   return _mode_spec;
+   else
+   return _mode_spec;
+}
+
+/**
  * Calculate divider values for desired SCL frequency
  *
  * @clk_rate: I2C input clock rate
@@ -474,10 +517,6 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
  struct i2c_timings *t,
  struct rk3x_i2c_calced_timings *t_calc)
 {
-   unsigned long spec_min_low_ns, spec_min_high_ns;
-   unsigned long spec_setup_start, spec_max_data_hold_ns;
-   unsigned long data_hold_buffer_ns;
-
unsigned long min_low_ns, min_high_ns;
unsigned long max_low_ns, min_total_ns;
 
@@ -489,6 +528,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
unsigned long min_div_for_hold, min_total_div;
unsigned long extra_div, extra_low_div, ideal_low_div;
 
+   unsigned long data_hold_buffer_ns = 50;
+   const struct i2c_spec_values *spec;
int ret = 0;
 
/* Only support standard-mode and fast-mode */
@@ -511,22 +552,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 *   This is because the i2c host on Rockchip holds the data line
 *   for half the low time.
 */
-   if (t->bus_freq_hz <= 10) {
-   /* Standard-mode */
-   spec_min_low_ns = 4700;
-   spec_setup_start = 4700;
-   spec_min_high_ns = 4000;
-   spec_max_data_hold_ns = 3450;
-   data_hold_buffer_ns = 50;
-   } else {
-   /* Fast-mode */
-   spec_min_low_ns = 1300;
-   spec_setup_start = 600;
-   spec_min_high_ns = 600;
-   spec_max_data_hold_ns = 900;
-   data_hold_buffer_ns = 50;
-   }
-   min_high_ns = t->scl_rise_ns + spec_min_high_ns;
+   spec = rk3x_i2c_get_spec(t->bus_freq_hz);
+   min_high_ns = t->scl_rise_ns + spec->min_high_ns;
 
/*
 * Timings for repeated start:
@@ -536,14 +563,14 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 * We need to account for those rules in picking our "high" time so
 * we meet tSU;STA and tHD;STA times.
 */
-   min_high_ns = max(min_high_ns,
-   DIV_ROUND_UP((t->scl_rise_ns + spec_setup_start) * 1000, 875));
-   min_high_ns = max(min_high_ns,
-   DIV_ROUND_UP((t->scl_rise_ns + spec_setup_start +
- t->sda_fall_ns + spec_min_high_ns), 2));
-
-   min_low_ns = t->scl_fall_ns + spec_min_low_ns;
-   max_low_ns = spec_max_data_hold_ns * 2 - data_hold_buffer_ns;
+   min_high_ns = max(min_high_ns, DIV_ROUND_UP(
+   (t->scl_rise_ns + spec->min_setup_start_ns) * 1000, 875));
+   min_high_ns = max(min_high_ns, DIV_ROUND_UP(
+   (t->scl_rise_ns + spec->min_setup_start_ns + t->sda_fall_ns +
+ 

Re: [GIT PULL] overlayfs fixes for 4.6-rc7

[Al Viro]

On Wed, May 11, 2016 at 01:23:42AM +0200, Miklos Szeredi wrote:
> Hi Al,
> 
> Hopefully this addresses your concerns.  I couldn't find a better name for
> lookup_hash(), after all it's just that.
> 
> Please pull:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git 
> overlayfs-linus
> 
> ---
> Miklos Szeredi (4):
>   vfs: add vfs_select_inode() helper

B0rken - for one thing, you've lost file->f_path = *path in vfs_open(), for
another this thing belongs in dcache.h as static inline.  Fixed, pushed
as vfs.git#ovl-fixes, merged into #for-linus.

If you have any objections against the current state of that branch, please
yell.

Re: [GIT PULL] overlayfs fixes for 4.6-rc7

[Al Viro]

On Wed, May 11, 2016 at 01:23:42AM +0200, Miklos Szeredi wrote:
> Hi Al,
> 
> Hopefully this addresses your concerns.  I couldn't find a better name for
> lookup_hash(), after all it's just that.
> 
> Please pull:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git 
> overlayfs-linus
> 
> ---
> Miklos Szeredi (4):
>   vfs: add vfs_select_inode() helper

B0rken - for one thing, you've lost file->f_path = *path in vfs_open(), for
another this thing belongs in dcache.h as static inline.  Fixed, pushed
as vfs.git#ovl-fixes, merged into #for-linus.

If you have any objections against the current state of that branch, please
yell.

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

[Hoan Tran]

Hi Alexey,

On Tue, May 10, 2016 at 3:34 AM, Alexey Klimov  wrote:
> On Mon, May 09, 2016 at 10:38:24AM -0700, Hoan Tran wrote:
>> Hi Alexey,
>>
>> On Mon, May 9, 2016 at 2:43 AM, Alexey Klimov  wrote:
>> > Hi Hoan,
>> >
>> > On Fri, May 06, 2016 at 11:38:34AM -0700, Hoan Tran wrote:
>> >> From: hotran 
>> >>
>> >> ACPI 6.1 has a PCC HW-Reduced Communication Subspace Type 2 intended for
>> >> use on HW-Reduce ACPI Platform, which requires read-modify-write sequence
>> >> to acknowledge doorbell interrupt. This patch provides the implementation
>> >> for the Communication Subspace Type 2.
>> >>
>> >> This patch depends on patch [1] which supports PCC subspace type 2 header
>> >> [1] https://lkml.org/lkml/2016/5/5/14
>> >>  - [PATCH v2 03/13] ACPICA: ACPI 6.1: Support for new PCCT subtable
>> >
>> > So you finally decided to use separate structure declaration for type 2. 
>> > Good.
>> >
>> >> v2
>> >>  * Remove changes inside "actbl3.h". This file is taken care by ACPICA.
>> >>  * Parse both subspace type 1 and subspace type 2
>> >>  * Remove unnecessary variable initialization
>> >>  * ISR returns IRQ_NONE in case of error
>> >>
>> >> v1
>> >>  * Initial
>> >>
>> >> Signed-off-by: Hoan Tran 
>> >> ---
>> >>  drivers/mailbox/pcc.c | 395 
>> >> +-
>> >>  1 file changed, 296 insertions(+), 99 deletions(-)
>> >>
>> >> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>> >> index 043828d..58c9a67 100644
>> >> --- a/drivers/mailbox/pcc.c
>> >> +++ b/drivers/mailbox/pcc.c
>> >> @@ -59,6 +59,7 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >
>> > [...]
>> >
>> >> @@ -307,6 +440,43 @@ static int parse_pcc_subspace(struct 
>> >> acpi_subtable_header *header,
>> >>  }
>> >>
>> >>  /**
>> >> + * pcc_parse_subspace_irq - Parse the PCC IRQ and PCC ACK register
>> >> + *   There should be one entry per PCC client.
>> >> + * @mbox_chans: Pointer to the PCC mailbox channel data
>> >> + * @pcct_ss: Pointer to the ACPI subtable header under the PCCT.
>> >> + *
>> >> + * Return: 0 for Success, else errno.
>> >> + *
>> >> + * This gets called for each entry in the PCC table.
>> >> + */
>> >> +static int pcc_parse_subspace_irq(struct pcc_mbox_chan *mbox_chans,
>> >> + struct acpi_pcct_hw_reduced *pcct_ss)
>> >> +{
>> >> + mbox_chans->irq = pcc_map_interrupt(pcct_ss->doorbell_interrupt,
>> >> + (u32)pcct_ss->flags);
>> >> + if (mbox_chans->irq <= 0) {
>> >> + pr_err("PCC GSI %d not registered\n",
>> >> +pcct_ss->doorbell_interrupt);
>> >> + return -EINVAL;
>> >> + }
>> >> +
>> >> + if (pcct_ss->header.type
>> >> + == ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2) {
>> >> + struct acpi_pcct_hw_reduced_type2 *pcct2_ss = (void 
>> >> *)pcct_ss;
>> >> +
>> >> + mbox_chans->pcc_doorbell_ack_vaddr = acpi_os_ioremap(
>> >> + pcct2_ss->doorbell_ack_register.address,
>> >> + pcct2_ss->doorbell_ack_register.bit_width / 
>> >> 8);
>> >> + if (!mbox_chans->pcc_doorbell_ack_vaddr) {
>> >> + pr_err("Failed to ioremap PCC ACK register\n");
>> >> + return -ENOMEM;
>> >> + }
>> >> + }
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> +/**
>> >>   * acpi_pcc_probe - Parse the ACPI tree for the PCCT.
>> >>   *
>> >>   * Return: 0 for Success, else errno.
>> >> @@ -316,7 +486,8 @@ static int __init acpi_pcc_probe(void)
>> >>   acpi_size pcct_tbl_header_size;
>> >>   struct acpi_table_header *pcct_tbl;
>> >>   struct acpi_subtable_header *pcct_entry;
>> >> - int count, i;
>> >> + struct acpi_table_pcct *acpi_pcct_tbl;
>> >> + int count, i, rc;
>> >>   acpi_status status = AE_OK;
>> >>
>> >>   /* Search for PCCT */
>> >> @@ -334,22 +505,28 @@ static int __init acpi_pcc_probe(void)
>> >>   ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE,
>> >>   parse_pcc_subspace, MAX_PCC_SUBSPACES);
>> >>
>> >> + count += acpi_table_parse_entries(ACPI_SIG_PCCT,
>> >> + sizeof(struct acpi_table_pcct),
>> >> + ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2,
>> >> + parse_pcc_subspace, MAX_PCC_SUBSPACES);
>> >> +
>> >>   if (count <= 0) {
>> >>   pr_err("Error parsing PCC subspaces from PCCT\n");
>> >>   return -EINVAL;
>> >>   }
>> >
>> > Looks like after first call to acpi_table_parse_entries() you may have 
>> > negative
>> > number in count. And then you add counted number of type 2 subtables to 
>> > count variable.
>> >
>> > I am not aware how pedantic this all should be but you may have more than 
>> > MAX_PCC_SUBSPACES
>> > subspaces or don't probe any subspaces at all with such approach. Or other 

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

[Hoan Tran]

Hi Alexey,

On Tue, May 10, 2016 at 3:34 AM, Alexey Klimov  wrote:
> On Mon, May 09, 2016 at 10:38:24AM -0700, Hoan Tran wrote:
>> Hi Alexey,
>>
>> On Mon, May 9, 2016 at 2:43 AM, Alexey Klimov  wrote:
>> > Hi Hoan,
>> >
>> > On Fri, May 06, 2016 at 11:38:34AM -0700, Hoan Tran wrote:
>> >> From: hotran 
>> >>
>> >> ACPI 6.1 has a PCC HW-Reduced Communication Subspace Type 2 intended for
>> >> use on HW-Reduce ACPI Platform, which requires read-modify-write sequence
>> >> to acknowledge doorbell interrupt. This patch provides the implementation
>> >> for the Communication Subspace Type 2.
>> >>
>> >> This patch depends on patch [1] which supports PCC subspace type 2 header
>> >> [1] https://lkml.org/lkml/2016/5/5/14
>> >>  - [PATCH v2 03/13] ACPICA: ACPI 6.1: Support for new PCCT subtable
>> >
>> > So you finally decided to use separate structure declaration for type 2. 
>> > Good.
>> >
>> >> v2
>> >>  * Remove changes inside "actbl3.h". This file is taken care by ACPICA.
>> >>  * Parse both subspace type 1 and subspace type 2
>> >>  * Remove unnecessary variable initialization
>> >>  * ISR returns IRQ_NONE in case of error
>> >>
>> >> v1
>> >>  * Initial
>> >>
>> >> Signed-off-by: Hoan Tran 
>> >> ---
>> >>  drivers/mailbox/pcc.c | 395 
>> >> +-
>> >>  1 file changed, 296 insertions(+), 99 deletions(-)
>> >>
>> >> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>> >> index 043828d..58c9a67 100644
>> >> --- a/drivers/mailbox/pcc.c
>> >> +++ b/drivers/mailbox/pcc.c
>> >> @@ -59,6 +59,7 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >
>> > [...]
>> >
>> >> @@ -307,6 +440,43 @@ static int parse_pcc_subspace(struct 
>> >> acpi_subtable_header *header,
>> >>  }
>> >>
>> >>  /**
>> >> + * pcc_parse_subspace_irq - Parse the PCC IRQ and PCC ACK register
>> >> + *   There should be one entry per PCC client.
>> >> + * @mbox_chans: Pointer to the PCC mailbox channel data
>> >> + * @pcct_ss: Pointer to the ACPI subtable header under the PCCT.
>> >> + *
>> >> + * Return: 0 for Success, else errno.
>> >> + *
>> >> + * This gets called for each entry in the PCC table.
>> >> + */
>> >> +static int pcc_parse_subspace_irq(struct pcc_mbox_chan *mbox_chans,
>> >> + struct acpi_pcct_hw_reduced *pcct_ss)
>> >> +{
>> >> + mbox_chans->irq = pcc_map_interrupt(pcct_ss->doorbell_interrupt,
>> >> + (u32)pcct_ss->flags);
>> >> + if (mbox_chans->irq <= 0) {
>> >> + pr_err("PCC GSI %d not registered\n",
>> >> +pcct_ss->doorbell_interrupt);
>> >> + return -EINVAL;
>> >> + }
>> >> +
>> >> + if (pcct_ss->header.type
>> >> + == ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2) {
>> >> + struct acpi_pcct_hw_reduced_type2 *pcct2_ss = (void 
>> >> *)pcct_ss;
>> >> +
>> >> + mbox_chans->pcc_doorbell_ack_vaddr = acpi_os_ioremap(
>> >> + pcct2_ss->doorbell_ack_register.address,
>> >> + pcct2_ss->doorbell_ack_register.bit_width / 
>> >> 8);
>> >> + if (!mbox_chans->pcc_doorbell_ack_vaddr) {
>> >> + pr_err("Failed to ioremap PCC ACK register\n");
>> >> + return -ENOMEM;
>> >> + }
>> >> + }
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> +/**
>> >>   * acpi_pcc_probe - Parse the ACPI tree for the PCCT.
>> >>   *
>> >>   * Return: 0 for Success, else errno.
>> >> @@ -316,7 +486,8 @@ static int __init acpi_pcc_probe(void)
>> >>   acpi_size pcct_tbl_header_size;
>> >>   struct acpi_table_header *pcct_tbl;
>> >>   struct acpi_subtable_header *pcct_entry;
>> >> - int count, i;
>> >> + struct acpi_table_pcct *acpi_pcct_tbl;
>> >> + int count, i, rc;
>> >>   acpi_status status = AE_OK;
>> >>
>> >>   /* Search for PCCT */
>> >> @@ -334,22 +505,28 @@ static int __init acpi_pcc_probe(void)
>> >>   ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE,
>> >>   parse_pcc_subspace, MAX_PCC_SUBSPACES);
>> >>
>> >> + count += acpi_table_parse_entries(ACPI_SIG_PCCT,
>> >> + sizeof(struct acpi_table_pcct),
>> >> + ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2,
>> >> + parse_pcc_subspace, MAX_PCC_SUBSPACES);
>> >> +
>> >>   if (count <= 0) {
>> >>   pr_err("Error parsing PCC subspaces from PCCT\n");
>> >>   return -EINVAL;
>> >>   }
>> >
>> > Looks like after first call to acpi_table_parse_entries() you may have 
>> > negative
>> > number in count. And then you add counted number of type 2 subtables to 
>> > count variable.
>> >
>> > I am not aware how pedantic this all should be but you may have more than 
>> > MAX_PCC_SUBSPACES
>> > subspaces or don't probe any subspaces at all with such approach. Or other 
>> > side effects.
>> I should check the "count" at first call 

[PATCH v8 0/8] add i2c driver supported for rk3399

[David Wu]

There are three points differert from others:
 - new method to caculate i2c timings for rk3399
 - pclk and function clk are separated at rk3399
 - add fast-plus mode supported for rk3399

David Wu (8):
  i2c: rk3x: add documentation to fields in "struct rk3x_i2c"
  i2c: rk3x: use struct "rk3x_i2c_calced_timings"
  i2c: rk3x: Remove redundant rk3x_i2c_clean_ipd()
  i2c: rk3x: Change SoC data to not use array
  i2c: rk3x: Move spec timing data to "static const" structs
  dt-bindings: i2c: rk3x: add support for rk3399
  i2c: rk3x: add i2c support for rk3399 soc
  i2c: rk3x: support fast-mode plus for rk3399

 Documentation/devicetree/bindings/i2c/i2c-rk3x.txt |  16 +-
 drivers/i2c/busses/i2c-rk3x.c  | 493 +
 2 files changed, 430 insertions(+), 79 deletions(-)

-- 
1.9.1

[PATCH v8 0/8] add i2c driver supported for rk3399

[David Wu]

There are three points differert from others:
 - new method to caculate i2c timings for rk3399
 - pclk and function clk are separated at rk3399
 - add fast-plus mode supported for rk3399

David Wu (8):
  i2c: rk3x: add documentation to fields in "struct rk3x_i2c"
  i2c: rk3x: use struct "rk3x_i2c_calced_timings"
  i2c: rk3x: Remove redundant rk3x_i2c_clean_ipd()
  i2c: rk3x: Change SoC data to not use array
  i2c: rk3x: Move spec timing data to "static const" structs
  dt-bindings: i2c: rk3x: add support for rk3399
  i2c: rk3x: add i2c support for rk3399 soc
  i2c: rk3x: support fast-mode plus for rk3399

 Documentation/devicetree/bindings/i2c/i2c-rk3x.txt |  16 +-
 drivers/i2c/busses/i2c-rk3x.c  | 493 +
 2 files changed, 430 insertions(+), 79 deletions(-)

-- 
1.9.1

[PATCH v8 4/8] i2c: rk3x: Change SoC data to not use array

[David Wu]

Specifying the i2c SoC data in an array provides very little benefit and
gets unwieldly / confusing as the array grows since the next bit of code
needs to refer to elements in the array by their raw integral index.

Let's just create a single 'static const' structure for each SoC so that
we can refer to these structures by ID.

Signed-off-by: David Wu 
Reviewed-by: Heiko Stuebner 
Suggested-by: Douglas Anderson 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- add commit description.

 drivers/i2c/busses/i2c-rk3x.c | 38 ++
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 9eeb4e5..d7a871f 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -864,17 +864,39 @@ static const struct i2c_algorithm rk3x_i2c_algorithm = {
.functionality  = rk3x_i2c_func,
 };
 
-static struct rk3x_i2c_soc_data soc_data[3] = {
-   { .grf_offset = 0x154 }, /* rk3066 */
-   { .grf_offset = 0x0a4 }, /* rk3188 */
-   { .grf_offset = -1 },/* no I2C switching needed */
+static const struct rk3x_i2c_soc_data rk3066_soc_data = {
+   .grf_offset = 0x154,
+};
+
+static const struct rk3x_i2c_soc_data rk3188_soc_data = {
+   .grf_offset = 0x0a4,
+};
+
+static const struct rk3x_i2c_soc_data rk3228_soc_data = {
+   .grf_offset = -1,
+};
+
+static const struct rk3x_i2c_soc_data rk3288_soc_data = {
+   .grf_offset = -1,
 };
 
 static const struct of_device_id rk3x_i2c_match[] = {
-   { .compatible = "rockchip,rk3066-i2c", .data = (void *)_data[0] },
-   { .compatible = "rockchip,rk3188-i2c", .data = (void *)_data[1] },
-   { .compatible = "rockchip,rk3228-i2c", .data = (void *)_data[2] },
-   { .compatible = "rockchip,rk3288-i2c", .data = (void *)_data[2] },
+   {
+   .compatible = "rockchip,rk3066-i2c",
+   .data = (void *)_soc_data
+   },
+   {
+   .compatible = "rockchip,rk3188-i2c",
+   .data = (void *)_soc_data
+   },
+   {
+   .compatible = "rockchip,rk3228-i2c",
+   .data = (void *)_soc_data
+   },
+   {
+   .compatible = "rockchip,rk3288-i2c",
+   .data = (void *)_soc_data
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, rk3x_i2c_match);
-- 
1.9.1

[PATCH v8 4/8] i2c: rk3x: Change SoC data to not use array

[David Wu]

Specifying the i2c SoC data in an array provides very little benefit and
gets unwieldly / confusing as the array grows since the next bit of code
needs to refer to elements in the array by their raw integral index.

Let's just create a single 'static const' structure for each SoC so that
we can refer to these structures by ID.

Signed-off-by: David Wu 
Reviewed-by: Heiko Stuebner 
Suggested-by: Douglas Anderson 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- add commit description.

 drivers/i2c/busses/i2c-rk3x.c | 38 ++
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 9eeb4e5..d7a871f 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -864,17 +864,39 @@ static const struct i2c_algorithm rk3x_i2c_algorithm = {
.functionality  = rk3x_i2c_func,
 };
 
-static struct rk3x_i2c_soc_data soc_data[3] = {
-   { .grf_offset = 0x154 }, /* rk3066 */
-   { .grf_offset = 0x0a4 }, /* rk3188 */
-   { .grf_offset = -1 },/* no I2C switching needed */
+static const struct rk3x_i2c_soc_data rk3066_soc_data = {
+   .grf_offset = 0x154,
+};
+
+static const struct rk3x_i2c_soc_data rk3188_soc_data = {
+   .grf_offset = 0x0a4,
+};
+
+static const struct rk3x_i2c_soc_data rk3228_soc_data = {
+   .grf_offset = -1,
+};
+
+static const struct rk3x_i2c_soc_data rk3288_soc_data = {
+   .grf_offset = -1,
 };
 
 static const struct of_device_id rk3x_i2c_match[] = {
-   { .compatible = "rockchip,rk3066-i2c", .data = (void *)_data[0] },
-   { .compatible = "rockchip,rk3188-i2c", .data = (void *)_data[1] },
-   { .compatible = "rockchip,rk3228-i2c", .data = (void *)_data[2] },
-   { .compatible = "rockchip,rk3288-i2c", .data = (void *)_data[2] },
+   {
+   .compatible = "rockchip,rk3066-i2c",
+   .data = (void *)_soc_data
+   },
+   {
+   .compatible = "rockchip,rk3188-i2c",
+   .data = (void *)_soc_data
+   },
+   {
+   .compatible = "rockchip,rk3228-i2c",
+   .data = (void *)_soc_data
+   },
+   {
+   .compatible = "rockchip,rk3288-i2c",
+   .data = (void *)_soc_data
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, rk3x_i2c_match);
-- 
1.9.1

[PATCH v8 1/8] i2c: rk3x: add documentation to fields in "struct rk3x_i2c"

[David Wu]

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- none

 drivers/i2c/busses/i2c-rk3x.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 80bed02..7e45d51 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -90,6 +90,26 @@ struct rk3x_i2c_soc_data {
int grf_offset;
 };
 
+/**
+ * struct rk3x_i2c - private data of the controller
+ * @adap: corresponding I2C adapter
+ * @dev: device for this controller
+ * @soc_data: related soc data struct
+ * @regs: virtual memory area
+ * @clk: clock of i2c bus
+ * @clk_rate_nb: i2c clk rate change notify
+ * @t: I2C known timing information
+ * @lock: spinlock for the i2c bus
+ * @wait: the waitqueue to wait for i2c transfer
+ * @busy: the condition for the event to wait for
+ * @msg: current i2c message
+ * @addr: addr of i2c slave device
+ * @mode: mode of i2c transfer
+ * @is_last_msg: flag determines whether it is the last msg in this transfer
+ * @state: state of i2c transfer
+ * @processed: byte length which has been send or received
+ * @error: error code for i2c transfer
+ */
 struct rk3x_i2c {
struct i2c_adapter adap;
struct device *dev;
@@ -116,7 +136,7 @@ struct rk3x_i2c {
 
/* I2C state machine */
enum rk3x_i2c_state state;
-   unsigned int processed; /* sent/received bytes */
+   unsigned int processed;
int error;
 };
 
-- 
1.9.1

[PATCH v8 1/8] i2c: rk3x: add documentation to fields in "struct rk3x_i2c"

[David Wu]

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- none

 drivers/i2c/busses/i2c-rk3x.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 80bed02..7e45d51 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -90,6 +90,26 @@ struct rk3x_i2c_soc_data {
int grf_offset;
 };
 
+/**
+ * struct rk3x_i2c - private data of the controller
+ * @adap: corresponding I2C adapter
+ * @dev: device for this controller
+ * @soc_data: related soc data struct
+ * @regs: virtual memory area
+ * @clk: clock of i2c bus
+ * @clk_rate_nb: i2c clk rate change notify
+ * @t: I2C known timing information
+ * @lock: spinlock for the i2c bus
+ * @wait: the waitqueue to wait for i2c transfer
+ * @busy: the condition for the event to wait for
+ * @msg: current i2c message
+ * @addr: addr of i2c slave device
+ * @mode: mode of i2c transfer
+ * @is_last_msg: flag determines whether it is the last msg in this transfer
+ * @state: state of i2c transfer
+ * @processed: byte length which has been send or received
+ * @error: error code for i2c transfer
+ */
 struct rk3x_i2c {
struct i2c_adapter adap;
struct device *dev;
@@ -116,7 +136,7 @@ struct rk3x_i2c {
 
/* I2C state machine */
enum rk3x_i2c_state state;
-   unsigned int processed; /* sent/received bytes */
+   unsigned int processed;
int error;
 };
 
-- 
1.9.1

[PATCH v8 3/8] i2c: rk3x: Remove redundant rk3x_i2c_clean_ipd()

[David Wu]

Call rk3x_i2c_setup() before rk3x_i2c_start()
and the last thing in setup was to clean the IPD,
so no reason to do it at the beginning of start.

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- none

 drivers/i2c/busses/i2c-rk3x.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 1e2677a..9eeb4e5 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -174,7 +174,6 @@ static void rk3x_i2c_start(struct rk3x_i2c *i2c)
 {
u32 val;
 
-   rk3x_i2c_clean_ipd(i2c);
i2c_writel(i2c, REG_INT_START, REG_IEN);
 
/* enable adapter with correct mode, send START condition */
-- 
1.9.1

[PATCH v8 2/8] i2c: rk3x: use struct "rk3x_i2c_calced_timings"

[David Wu]

The "div_high" and "div_low" values are always used together.  Group them
into a structure to make it easier to pass them both around.  This
structure also provides a place for future calculated timings.

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- add commit description.

 drivers/i2c/busses/i2c-rk3x.c | 55 +--
 1 file changed, 32 insertions(+), 23 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 7e45d51..1e2677a 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -75,6 +75,16 @@ enum {
 #define WAIT_TIMEOUT  1000 /* ms */
 #define DEFAULT_SCL_RATE  (100 * 1000) /* Hz */
 
+/**
+ * struct rk3x_i2c_calced_timings:
+ * @div_low: Divider output for low
+ * @div_high: Divider output for high
+ */
+struct rk3x_i2c_calced_timings {
+   unsigned long div_low;
+   unsigned long div_high;
+};
+
 enum rk3x_i2c_state {
STATE_IDLE,
STATE_START,
@@ -454,9 +464,8 @@ out:
  * Calculate divider values for desired SCL frequency
  *
  * @clk_rate: I2C input clock rate
- * @t: Known I2C timing information.
- * @div_low: Divider output for low
- * @div_high: Divider output for high
+ * @t: Known I2C timing information
+ * @t_calc: Caculated rk3x private timings that would be written into regs
  *
  * Returns: 0 on success, -EINVAL if the goal SCL rate is too slow. In that 
case
  * a best-effort divider value is returned in divs. If the target rate is
@@ -464,8 +473,7 @@ out:
  */
 static int rk3x_i2c_calc_divs(unsigned long clk_rate,
  struct i2c_timings *t,
- unsigned long *div_low,
- unsigned long *div_high)
+ struct rk3x_i2c_calced_timings *t_calc)
 {
unsigned long spec_min_low_ns, spec_min_high_ns;
unsigned long spec_setup_start, spec_max_data_hold_ns;
@@ -572,8 +580,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 * Time needed to meet hold requirements is important.
 * Just use that.
 */
-   *div_low = min_low_div;
-   *div_high = min_high_div;
+   t_calc->div_low = min_low_div;
+   t_calc->div_high = min_high_div;
} else {
/*
 * We've got to distribute some time among the low and high
@@ -602,25 +610,25 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 
/* Give low the "ideal" and give high whatever extra is left */
extra_low_div = ideal_low_div - min_low_div;
-   *div_low = ideal_low_div;
-   *div_high = min_high_div + (extra_div - extra_low_div);
+   t_calc->div_low = ideal_low_div;
+   t_calc->div_high = min_high_div + (extra_div - extra_low_div);
}
 
/*
 * Adjust to the fact that the hardware has an implicit "+1".
 * NOTE: Above calculations always produce div_low > 0 and div_high > 0.
 */
-   *div_low = *div_low - 1;
-   *div_high = *div_high - 1;
+   t_calc->div_low--;
+   t_calc->div_high--;
 
/* Maximum divider supported by hw is 0x */
-   if (*div_low > 0x) {
-   *div_low = 0x;
+   if (t_calc->div_low > 0x) {
+   t_calc->div_low = 0x;
ret = -EINVAL;
}
 
-   if (*div_high > 0x) {
-   *div_high = 0x;
+   if (t_calc->div_high > 0x) {
+   t_calc->div_high = 0x;
ret = -EINVAL;
}
 
@@ -630,19 +638,21 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 static void rk3x_i2c_adapt_div(struct rk3x_i2c *i2c, unsigned long clk_rate)
 {
struct i2c_timings *t = >t;
-   unsigned long div_low, div_high;
+   struct rk3x_i2c_calced_timings calc;
u64 t_low_ns, t_high_ns;
int ret;
 
-   ret = rk3x_i2c_calc_divs(clk_rate, t, _low, _high);
+   ret = rk3x_i2c_calc_divs(clk_rate, t, );
WARN_ONCE(ret != 0, "Could not reach SCL freq %u", t->bus_freq_hz);
 
clk_enable(i2c->clk);
-   i2c_writel(i2c, (div_high << 16) | (div_low & 0x), REG_CLKDIV);
+   i2c_writel(i2c, (calc.div_high << 16) | (calc.div_low & 0x),
+  REG_CLKDIV);
clk_disable(i2c->clk);
 
-   t_low_ns = div_u64(((u64)div_low + 1) * 8 * 10, clk_rate);
-   t_high_ns = div_u64(((u64)div_high + 1) * 8 * 10, clk_rate);
+   t_low_ns = div_u64(((u64)calc.div_low + 1) * 8 * 10, clk_rate);
+   t_high_ns = div_u64(((u64)calc.div_high + 1) * 8 * 10,
+   clk_rate);
dev_dbg(i2c->dev,
"CLK %lukhz, Req %uns, Act low %lluns high %lluns\n",
clk_rate / 1000,
@@ -672,12 +682,11 @@ static int 

[PATCH v8 3/8] i2c: rk3x: Remove redundant rk3x_i2c_clean_ipd()

[David Wu]

Call rk3x_i2c_setup() before rk3x_i2c_start()
and the last thing in setup was to clean the IPD,
so no reason to do it at the beginning of start.

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- none

 drivers/i2c/busses/i2c-rk3x.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 1e2677a..9eeb4e5 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -174,7 +174,6 @@ static void rk3x_i2c_start(struct rk3x_i2c *i2c)
 {
u32 val;
 
-   rk3x_i2c_clean_ipd(i2c);
i2c_writel(i2c, REG_INT_START, REG_IEN);
 
/* enable adapter with correct mode, send START condition */
-- 
1.9.1

[PATCH v8 2/8] i2c: rk3x: use struct "rk3x_i2c_calced_timings"

[David Wu]

The "div_high" and "div_low" values are always used together.  Group them
into a structure to make it easier to pass them both around.  This
structure also provides a place for future calculated timings.

Signed-off-by: David Wu 
Reviewed-by: Douglas Anderson 
---
Change in v8:
- add commit description.

 drivers/i2c/busses/i2c-rk3x.c | 55 +--
 1 file changed, 32 insertions(+), 23 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 7e45d51..1e2677a 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -75,6 +75,16 @@ enum {
 #define WAIT_TIMEOUT  1000 /* ms */
 #define DEFAULT_SCL_RATE  (100 * 1000) /* Hz */
 
+/**
+ * struct rk3x_i2c_calced_timings:
+ * @div_low: Divider output for low
+ * @div_high: Divider output for high
+ */
+struct rk3x_i2c_calced_timings {
+   unsigned long div_low;
+   unsigned long div_high;
+};
+
 enum rk3x_i2c_state {
STATE_IDLE,
STATE_START,
@@ -454,9 +464,8 @@ out:
  * Calculate divider values for desired SCL frequency
  *
  * @clk_rate: I2C input clock rate
- * @t: Known I2C timing information.
- * @div_low: Divider output for low
- * @div_high: Divider output for high
+ * @t: Known I2C timing information
+ * @t_calc: Caculated rk3x private timings that would be written into regs
  *
  * Returns: 0 on success, -EINVAL if the goal SCL rate is too slow. In that 
case
  * a best-effort divider value is returned in divs. If the target rate is
@@ -464,8 +473,7 @@ out:
  */
 static int rk3x_i2c_calc_divs(unsigned long clk_rate,
  struct i2c_timings *t,
- unsigned long *div_low,
- unsigned long *div_high)
+ struct rk3x_i2c_calced_timings *t_calc)
 {
unsigned long spec_min_low_ns, spec_min_high_ns;
unsigned long spec_setup_start, spec_max_data_hold_ns;
@@ -572,8 +580,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 * Time needed to meet hold requirements is important.
 * Just use that.
 */
-   *div_low = min_low_div;
-   *div_high = min_high_div;
+   t_calc->div_low = min_low_div;
+   t_calc->div_high = min_high_div;
} else {
/*
 * We've got to distribute some time among the low and high
@@ -602,25 +610,25 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 
/* Give low the "ideal" and give high whatever extra is left */
extra_low_div = ideal_low_div - min_low_div;
-   *div_low = ideal_low_div;
-   *div_high = min_high_div + (extra_div - extra_low_div);
+   t_calc->div_low = ideal_low_div;
+   t_calc->div_high = min_high_div + (extra_div - extra_low_div);
}
 
/*
 * Adjust to the fact that the hardware has an implicit "+1".
 * NOTE: Above calculations always produce div_low > 0 and div_high > 0.
 */
-   *div_low = *div_low - 1;
-   *div_high = *div_high - 1;
+   t_calc->div_low--;
+   t_calc->div_high--;
 
/* Maximum divider supported by hw is 0x */
-   if (*div_low > 0x) {
-   *div_low = 0x;
+   if (t_calc->div_low > 0x) {
+   t_calc->div_low = 0x;
ret = -EINVAL;
}
 
-   if (*div_high > 0x) {
-   *div_high = 0x;
+   if (t_calc->div_high > 0x) {
+   t_calc->div_high = 0x;
ret = -EINVAL;
}
 
@@ -630,19 +638,21 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
 static void rk3x_i2c_adapt_div(struct rk3x_i2c *i2c, unsigned long clk_rate)
 {
struct i2c_timings *t = >t;
-   unsigned long div_low, div_high;
+   struct rk3x_i2c_calced_timings calc;
u64 t_low_ns, t_high_ns;
int ret;
 
-   ret = rk3x_i2c_calc_divs(clk_rate, t, _low, _high);
+   ret = rk3x_i2c_calc_divs(clk_rate, t, );
WARN_ONCE(ret != 0, "Could not reach SCL freq %u", t->bus_freq_hz);
 
clk_enable(i2c->clk);
-   i2c_writel(i2c, (div_high << 16) | (div_low & 0x), REG_CLKDIV);
+   i2c_writel(i2c, (calc.div_high << 16) | (calc.div_low & 0x),
+  REG_CLKDIV);
clk_disable(i2c->clk);
 
-   t_low_ns = div_u64(((u64)div_low + 1) * 8 * 10, clk_rate);
-   t_high_ns = div_u64(((u64)div_high + 1) * 8 * 10, clk_rate);
+   t_low_ns = div_u64(((u64)calc.div_low + 1) * 8 * 10, clk_rate);
+   t_high_ns = div_u64(((u64)calc.div_high + 1) * 8 * 10,
+   clk_rate);
dev_dbg(i2c->dev,
"CLK %lukhz, Req %uns, Act low %lluns high %lluns\n",
clk_rate / 1000,
@@ -672,12 +682,11 @@ static int rk3x_i2c_clk_notifier_cb(struct notifier_block 
*nb, 

Re: [PATCH v2] pinctrl: rockchip: fix pull setting error for rk3399

[Doug Anderson]

Caesar,

On Tue, May 10, 2016 at 8:39 PM, Caesar Wang  wrote:
> From: David Wu 
>
> This patch fixes the pinctrl pull bias setting, since the pull up/down
> setting is the contrary for gpio0(just the gpio0a and gpio0b) and
> gpio2(just the gpio2c and gpio2d).
>
> From the TRM said, the gpio0a pull polarity setting:
> gpio0a_p
> GPIO0A PE/PS programmation section, every
> GPIO bit corresponding to 2bits[PS:PE]
> 2'b00: Z(Normal operation);
> 2'b11: weak 1(pull-up);
> 2'b01: weak 0(pull-down);
> 2'b10: Z(Normal operation);
>
> Then, the other gpios setting as the following:
> gpio1a_p (e.g.: gpio1, gpio2a, gpio2b, gpio3...)
> GPIO1A PU/PD programmation section, every
> GPIO bit corresponding to 2bits
> 2'b00: Z(Normal operation);
> 2'b01: weak 1(pull-up);
> 2'b10: weak 0(pull-down);
> 2'b11: Z(Normal operation);
>
> For example,(rk3399evb board)
> sdmmc_cd --->gpio0_a7
> localhost / # io -r -4 0xff320040
> ff320040: 4d5f
> In general,the value should be 0xcd5f since the pin has been set
> in the dts.
>
> Signed-off-by: David Wu 
> Signed-off-by: Caesar Wang 
> Cc: Linus Walleij 
> Cc: Heiko Stuebner 
> Cc: linux-g...@vger.kernel.org
> ---
>
> Changes in v2:
> - As Doug commnets on https://patchwork.kernel.org/patch/9056961/
> - update the commit for gpio2.
> - change the print error messgae.
>
>  drivers/pinctrl/pinctrl-rockchip.c | 179 
> ++---
>  1 file changed, 127 insertions(+), 52 deletions(-)

Reviewed-by: Douglas Anderson 

Re: [PATCH v2] pinctrl: rockchip: fix pull setting error for rk3399

[Doug Anderson]

Caesar,

On Tue, May 10, 2016 at 8:39 PM, Caesar Wang  wrote:
> From: David Wu 
>
> This patch fixes the pinctrl pull bias setting, since the pull up/down
> setting is the contrary for gpio0(just the gpio0a and gpio0b) and
> gpio2(just the gpio2c and gpio2d).
>
> From the TRM said, the gpio0a pull polarity setting:
> gpio0a_p
> GPIO0A PE/PS programmation section, every
> GPIO bit corresponding to 2bits[PS:PE]
> 2'b00: Z(Normal operation);
> 2'b11: weak 1(pull-up);
> 2'b01: weak 0(pull-down);
> 2'b10: Z(Normal operation);
>
> Then, the other gpios setting as the following:
> gpio1a_p (e.g.: gpio1, gpio2a, gpio2b, gpio3...)
> GPIO1A PU/PD programmation section, every
> GPIO bit corresponding to 2bits
> 2'b00: Z(Normal operation);
> 2'b01: weak 1(pull-up);
> 2'b10: weak 0(pull-down);
> 2'b11: Z(Normal operation);
>
> For example,(rk3399evb board)
> sdmmc_cd --->gpio0_a7
> localhost / # io -r -4 0xff320040
> ff320040: 4d5f
> In general,the value should be 0xcd5f since the pin has been set
> in the dts.
>
> Signed-off-by: David Wu 
> Signed-off-by: Caesar Wang 
> Cc: Linus Walleij 
> Cc: Heiko Stuebner 
> Cc: linux-g...@vger.kernel.org
> ---
>
> Changes in v2:
> - As Doug commnets on https://patchwork.kernel.org/patch/9056961/
> - update the commit for gpio2.
> - change the print error messgae.
>
>  drivers/pinctrl/pinctrl-rockchip.c | 179 
> ++---
>  1 file changed, 127 insertions(+), 52 deletions(-)

Reviewed-by: Douglas Anderson 

Re: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if TIMINCA is zero

[Mark D Rustad]

Jarod Wilson  wrote:


On Fri, May 06, 2016 at 11:43:17PM +, Rustad, Mark D wrote:

Denys Vlasenko  wrote:


Users report that under VMWare, er32(TIMINCA) returns zero.
This causes division by zero at init time as follows:

==>incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
   for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS; i++) {
   /* latch SYSTIMH on read of SYSTIML */
   systim_next = (cycle_t)er32(SYSTIML);
   systim_next |= (cycle_t)er32(SYSTIMH) << 32;

   time_delta = systim_next - systim;
   temp = time_delta;
>  rem = do_div(temp, incvalue);

This change makes kernel survive this, and users report that
NIC does work after this change.

Since on real hardware incvalue is never zero, this should not affect
real hardware use case.

...
I seem to recall that this was rejected before because it really is  
VMWare's

bug and, if they fix it, any existing VMs that use this will just work.
Changing the driver will only fix it for vms that install a new driver. I
don't object to doing it, it just seems like not the most effective  
place to

address the issue.


You could also have people who never update VMWare, for whom a kernel
work-around would be better. I think it'd be best to address it both at
the driver level and the emulated hardware level, to improve things for
the most possible users. Those who update neither hypervisor or
kernel/driver, well, they reap what they sow.


That is a sound argument for doing both. I would expect that there are more  
frozen VM images than host environments, but I can certainly imagine that  
some choose to freeze their host. Of course if everything is frozen there  
is no point at all. :-)


I am on an extended vacation, and don't work on e1000e anyway, so I will  
quit my kibitzing here.


--
Mark Rustad, mrus...@gmail.com


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if TIMINCA is zero

[Mark D Rustad]

Jarod Wilson  wrote:


On Fri, May 06, 2016 at 11:43:17PM +, Rustad, Mark D wrote:

Denys Vlasenko  wrote:


Users report that under VMWare, er32(TIMINCA) returns zero.
This causes division by zero at init time as follows:

==>incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
   for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS; i++) {
   /* latch SYSTIMH on read of SYSTIML */
   systim_next = (cycle_t)er32(SYSTIML);
   systim_next |= (cycle_t)er32(SYSTIMH) << 32;

   time_delta = systim_next - systim;
   temp = time_delta;
>  rem = do_div(temp, incvalue);

This change makes kernel survive this, and users report that
NIC does work after this change.

Since on real hardware incvalue is never zero, this should not affect
real hardware use case.

...
I seem to recall that this was rejected before because it really is  
VMWare's

bug and, if they fix it, any existing VMs that use this will just work.
Changing the driver will only fix it for vms that install a new driver. I
don't object to doing it, it just seems like not the most effective  
place to

address the issue.


You could also have people who never update VMWare, for whom a kernel
work-around would be better. I think it'd be best to address it both at
the driver level and the emulated hardware level, to improve things for
the most possible users. Those who update neither hypervisor or
kernel/driver, well, they reap what they sow.


That is a sound argument for doing both. I would expect that there are more  
frozen VM images than host environments, but I can certainly imagine that  
some choose to freeze their host. Of course if everything is frozen there  
is no point at all. :-)


I am on an extended vacation, and don't work on e1000e anyway, so I will  
quit my kibitzing here.


--
Mark Rustad, mrus...@gmail.com


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH 6/6] mpt3sas: Used "synchronize_irq()"API to synchronize timed-out IO & TMs

[Sreekanth Reddy]

On Tue, May 10, 2016 at 6:41 PM, Tomas Henzl  wrote:
> On 6.5.2016 10:59, Chaitra P B wrote:
>> Replaced mpt3sas_base_flush_reply_queues()with
>> mpt3sas_base_sync_reply_irqs(),as mpt3sas_base_flush_reply_queues()
>> skips over reply queues that are currently busy (i.e. being handled
>> by interrupt processing in another core). If a reply queue is busy,
>> then call to synchronize_irq()in mpt3sas_base_sync_reply_irqs()make
>> sures the other core has finished flushing the queue and completed
>> any calls to the mid-layer scsi_done() routine.
>>
>> Signed-off-by: Chaitra P B 
>> ---
>>  drivers/scsi/mpt3sas/mpt3sas_base.c  | 15 +++
>>  drivers/scsi/mpt3sas/mpt3sas_base.h  |  3 ++-
>>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |  4 +++-
>>  3 files changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
>> b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> index 4e9142f..fd9002d 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> @@ -1103,18 +1103,16 @@ _base_is_controller_msix_enabled(struct 
>> MPT3SAS_ADAPTER *ioc)
>>  }
>>
>>  /**
>> - * mpt3sas_base_flush_reply_queues - flushing the MSIX reply queues
>> + * mpt3sas_base_sync_reply_irqs - flush pending MSIX interrupts
>>   * @ioc: per adapter object
>> - * Context: ISR conext
>> + * Context: non ISR conext
>>   *
>> - * Called when a Task Management request has completed. We want
>> - * to flush the other reply queues so all the outstanding IO has been
>> - * completed back to OS before we process the TM completetion.
>> + * Called when a Task Management request has completed.
>>   *
>>   * Return nothing.
>>   */
>>  void
>> -mpt3sas_base_flush_reply_queues(struct MPT3SAS_ADAPTER *ioc)
>> +mpt3sas_base_sync_reply_irqs(struct MPT3SAS_ADAPTER *ioc)
>>  {
>>   struct adapter_reply_queue *reply_q;
>>
>> @@ -1125,12 +1123,13 @@ mpt3sas_base_flush_reply_queues(struct 
>> MPT3SAS_ADAPTER *ioc)
>>   return;
>>
>>   list_for_each_entry(reply_q, >reply_queue_list, list) {
>> - if (ioc->shost_recovery)
>> + if (ioc->shost_recovery || ioc->remove_host ||
>> + ioc->pci_error_recovery)
>
> Hi Chaitra,
> how is this change + (ioc->remove_host || ioc->pci_error_recovery)
> related to the subject?

[Sreekanth] These changes are actually not related to this subject, but these
sanity checks were missing previously.

>
>>   return;
>>   /* TMs are on msix_index == 0 */
>>   if (reply_q->msix_index == 0)
>>   continue;
>> - _base_interrupt(reply_q->vector, (void *)reply_q);
>> + synchronize_irq(reply_q->vector);
>>   }
>
> One thing I don't understand - what if an interrupt comes after
> the synchronize_irq has finished ?

[Sreekanth] Tomas, we are calling this function
'mpt3sas_base_flush_reply_queues()'
only after we got the reply for the TM. Also our firmware will send
reply for the TM only after
it sends reply for the all terminated IOs (due to this TM). So by this
time firmware has already
raised interrupts for all the terminated IOs before it raising
interrupt for TM. So we won't get
any interrupts (which we are interested) after synchronize_irq.

Thanks,
Sreekanth
>
> Thanks,
> Tomas
>
>>  }
>>
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
>> b/drivers/scsi/mpt3sas/mpt3sas_base.h
>> index e1befba..1a614d7 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
>> @@ -1236,7 +1236,8 @@ void *mpt3sas_base_get_msg_frame(struct 
>> MPT3SAS_ADAPTER *ioc, u16 smid);
>>  void *mpt3sas_base_get_sense_buffer(struct MPT3SAS_ADAPTER *ioc, u16 smid);
>>  __le32 mpt3sas_base_get_sense_buffer_dma(struct MPT3SAS_ADAPTER *ioc,
>>   u16 smid);
>> -void mpt3sas_base_flush_reply_queues(struct MPT3SAS_ADAPTER *ioc);
>> +
>> +void mpt3sas_base_sync_reply_irqs(struct MPT3SAS_ADAPTER *ioc);
>>
>>  /* hi-priority queue */
>>  u16 mpt3sas_base_get_smid_hpr(struct MPT3SAS_ADAPTER *ioc, u8 cb_idx);
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
>> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> index abd8717..928214f 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> @@ -2126,7 +2126,6 @@ _scsih_tm_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, 
>> u8 msix_index, u32 reply)
>>   return 1;
>>   if (ioc->tm_cmds.smid != smid)
>>   return 1;
>> - mpt3sas_base_flush_reply_queues(ioc);
>>   ioc->tm_cmds.status |= MPT3_CMD_COMPLETE;
>>   mpi_reply =  mpt3sas_base_get_reply_virt_addr(ioc, reply);
>>   if (mpi_reply) {
>> @@ -2311,6 +2310,9 @@ mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, 
>> u16 handle, uint channel,
>>   }
>>   }
>>
>> + /* sync IRQs in case those were busy during flush. */
>> + mpt3sas_base_sync_reply_irqs(ioc);

Re: [PATCH 6/6] mpt3sas: Used "synchronize_irq()"API to synchronize timed-out IO & TMs

[Sreekanth Reddy]

On Tue, May 10, 2016 at 6:41 PM, Tomas Henzl  wrote:
> On 6.5.2016 10:59, Chaitra P B wrote:
>> Replaced mpt3sas_base_flush_reply_queues()with
>> mpt3sas_base_sync_reply_irqs(),as mpt3sas_base_flush_reply_queues()
>> skips over reply queues that are currently busy (i.e. being handled
>> by interrupt processing in another core). If a reply queue is busy,
>> then call to synchronize_irq()in mpt3sas_base_sync_reply_irqs()make
>> sures the other core has finished flushing the queue and completed
>> any calls to the mid-layer scsi_done() routine.
>>
>> Signed-off-by: Chaitra P B 
>> ---
>>  drivers/scsi/mpt3sas/mpt3sas_base.c  | 15 +++
>>  drivers/scsi/mpt3sas/mpt3sas_base.h  |  3 ++-
>>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |  4 +++-
>>  3 files changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
>> b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> index 4e9142f..fd9002d 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> @@ -1103,18 +1103,16 @@ _base_is_controller_msix_enabled(struct 
>> MPT3SAS_ADAPTER *ioc)
>>  }
>>
>>  /**
>> - * mpt3sas_base_flush_reply_queues - flushing the MSIX reply queues
>> + * mpt3sas_base_sync_reply_irqs - flush pending MSIX interrupts
>>   * @ioc: per adapter object
>> - * Context: ISR conext
>> + * Context: non ISR conext
>>   *
>> - * Called when a Task Management request has completed. We want
>> - * to flush the other reply queues so all the outstanding IO has been
>> - * completed back to OS before we process the TM completetion.
>> + * Called when a Task Management request has completed.
>>   *
>>   * Return nothing.
>>   */
>>  void
>> -mpt3sas_base_flush_reply_queues(struct MPT3SAS_ADAPTER *ioc)
>> +mpt3sas_base_sync_reply_irqs(struct MPT3SAS_ADAPTER *ioc)
>>  {
>>   struct adapter_reply_queue *reply_q;
>>
>> @@ -1125,12 +1123,13 @@ mpt3sas_base_flush_reply_queues(struct 
>> MPT3SAS_ADAPTER *ioc)
>>   return;
>>
>>   list_for_each_entry(reply_q, >reply_queue_list, list) {
>> - if (ioc->shost_recovery)
>> + if (ioc->shost_recovery || ioc->remove_host ||
>> + ioc->pci_error_recovery)
>
> Hi Chaitra,
> how is this change + (ioc->remove_host || ioc->pci_error_recovery)
> related to the subject?

[Sreekanth] These changes are actually not related to this subject, but these
sanity checks were missing previously.

>
>>   return;
>>   /* TMs are on msix_index == 0 */
>>   if (reply_q->msix_index == 0)
>>   continue;
>> - _base_interrupt(reply_q->vector, (void *)reply_q);
>> + synchronize_irq(reply_q->vector);
>>   }
>
> One thing I don't understand - what if an interrupt comes after
> the synchronize_irq has finished ?

[Sreekanth] Tomas, we are calling this function
'mpt3sas_base_flush_reply_queues()'
only after we got the reply for the TM. Also our firmware will send
reply for the TM only after
it sends reply for the all terminated IOs (due to this TM). So by this
time firmware has already
raised interrupts for all the terminated IOs before it raising
interrupt for TM. So we won't get
any interrupts (which we are interested) after synchronize_irq.

Thanks,
Sreekanth
>
> Thanks,
> Tomas
>
>>  }
>>
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
>> b/drivers/scsi/mpt3sas/mpt3sas_base.h
>> index e1befba..1a614d7 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
>> @@ -1236,7 +1236,8 @@ void *mpt3sas_base_get_msg_frame(struct 
>> MPT3SAS_ADAPTER *ioc, u16 smid);
>>  void *mpt3sas_base_get_sense_buffer(struct MPT3SAS_ADAPTER *ioc, u16 smid);
>>  __le32 mpt3sas_base_get_sense_buffer_dma(struct MPT3SAS_ADAPTER *ioc,
>>   u16 smid);
>> -void mpt3sas_base_flush_reply_queues(struct MPT3SAS_ADAPTER *ioc);
>> +
>> +void mpt3sas_base_sync_reply_irqs(struct MPT3SAS_ADAPTER *ioc);
>>
>>  /* hi-priority queue */
>>  u16 mpt3sas_base_get_smid_hpr(struct MPT3SAS_ADAPTER *ioc, u8 cb_idx);
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
>> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> index abd8717..928214f 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> @@ -2126,7 +2126,6 @@ _scsih_tm_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, 
>> u8 msix_index, u32 reply)
>>   return 1;
>>   if (ioc->tm_cmds.smid != smid)
>>   return 1;
>> - mpt3sas_base_flush_reply_queues(ioc);
>>   ioc->tm_cmds.status |= MPT3_CMD_COMPLETE;
>>   mpi_reply =  mpt3sas_base_get_reply_virt_addr(ioc, reply);
>>   if (mpi_reply) {
>> @@ -2311,6 +2310,9 @@ mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, 
>> u16 handle, uint channel,
>>   }
>>   }
>>
>> + /* sync IRQs in case those were busy during flush. */
>> + mpt3sas_base_sync_reply_irqs(ioc);
>> +
>>   if (ioc->tm_cmds.status & 

Re: [PATCH 2/2] dt-bindings: rockchip-dw-mshc: add rockchip,default-drv-phase

[Doug Anderson]

Hi,

On Tue, May 10, 2016 at 7:50 PM, Shawn Lin  wrote:
>>> maybe. But I think 180(downside) is the better.
>
>
> NAK my previous comments here. Downside is better for SRD, but won't
> work for DDR mode. When running in DDR mode, we should use 90 instead.
>
> So let me elaborate a bit more here.
> For DDR mode, one single clk cycle should sending two data bits outside
> to the devices. We need a hold time for both. If 180 is used, the first
> bit occurs around the downside area, which won't be sampled by devices
> on the upside.  So on the upside, the devices will see a zero bit if you
> actually send a one-bit, which makes the devices  generate CRC finally.
>
>
> For this above, 180 for all SDR mode is ok, but 90 should be deployed
> for DDR mode. So simply checking the timing to hardcode it should be
> fine.

OK, I sent out a patch for 180 always.  I can send v2 to use 90 for
DDR modes tomorrow.  ...or feel free to post that yourself if you
want.

We want 90 for all DDR modes?  So MMC_TIMING_UHS_DDR50,
MMC_TIMING_MMC_DDR52, MMC_TIMING_MMC_HS400? (not that we support HS400
in dw_mmc on Rockchip).

-Doug

Re: [PATCH 2/2] dt-bindings: rockchip-dw-mshc: add rockchip,default-drv-phase

[Doug Anderson]

Hi,

On Tue, May 10, 2016 at 7:50 PM, Shawn Lin  wrote:
>>> maybe. But I think 180(downside) is the better.
>
>
> NAK my previous comments here. Downside is better for SRD, but won't
> work for DDR mode. When running in DDR mode, we should use 90 instead.
>
> So let me elaborate a bit more here.
> For DDR mode, one single clk cycle should sending two data bits outside
> to the devices. We need a hold time for both. If 180 is used, the first
> bit occurs around the downside area, which won't be sampled by devices
> on the upside.  So on the upside, the devices will see a zero bit if you
> actually send a one-bit, which makes the devices  generate CRC finally.
>
>
> For this above, 180 for all SDR mode is ok, but 90 should be deployed
> for DDR mode. So simply checking the timing to hardcode it should be
> fine.

OK, I sent out a patch for 180 always.  I can send v2 to use 90 for
DDR modes tomorrow.  ...or feel free to post that yourself if you
want.

We want 90 for all DDR modes?  So MMC_TIMING_UHS_DDR50,
MMC_TIMING_MMC_DDR52, MMC_TIMING_MMC_HS400? (not that we support HS400
in dw_mmc on Rockchip).

-Doug

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

[James Bottomley]

On Wed, 2016-05-11 at 01:53 +0100, Al Viro wrote:
> On Tue, May 10, 2016 at 04:36:56PM -0700, James Bottomley wrote:
> > +static int shiftfs_rename2(struct inode *olddir, struct dentry
> > *old,
> > +  struct inode *newdir, struct dentry
> > *new,
> > +  unsigned int flags)
> > +{
> > +   struct dentry *rodd = olddir->i_private, *rndd = newdir
> > ->i_private,
> > +   *realold = old->d_inode->i_private,
> > +   *realnew = new->d_inode->i_private;
> > +   struct inode *realolddir = rodd->d_inode, *realnewdir =
> > rndd->d_inode;
> > +   const struct inode_operations *iop = realolddir->i_op;
> > +   int err;
> > +   const struct cred *oldcred, *newcred;
> > +
> > +   oldcred = shiftfs_new_creds(, old->d_sb);
> > +   err = iop->rename2(realolddir, realold, realnewdir,
> > realnew, flags);
> > +   shiftfs_old_creds(oldcred, );
> 
> ... and you've just violated all locking rules for ->rename2().

Yes, sorry, somehow I missed that when I converted everything else to
the vfs_ functions.

> > +static struct dentry *shiftfs_lookup(struct inode *dir, struct
> > dentry *dentry,
> > +unsigned int flags)
> > +{
> > +   struct dentry *real = dir->i_private, *new;
> > +   struct inode *reali = real->d_inode, *newi;
> > +   const struct cred *oldcred, *newcred;
> > +
> > +   /* note: violation of usual fs rules here: dentries are
> > never
> > +* added with d_add.  This is because we want no dentry
> > cache
> > +* for shiftfs.  All lookups proceed through the dentry
> > cache
> > +* of the underlying filesystem, meaning we always see any
> > +* changes in the underlying */
> 
> Bloody wonderful.  So
>   * we lose caching the negative lookups

We do?  They should be cached in the underlying layer's dcache. If
that's not enough, I can hash them, but I was trying to avoid doubling
the dcache size.

>   * we've got buggered hardlinks (different inodes for those)

Yes, had a note to do the lookup, but forgot.

>   * it has never, ever been tried on -next (would do rather nasty
> things on that d_instantiate())

So this is just a proof of concept; I figured it was best to do it
against current rather than have people who wanted to try it pull in
your tree.  I can respin it after the merge window closes.

> 
> > +
> > +   kfree(sfc);
> > +
> > +   return err;
> > +}
> 
> > +   file->f_op = >fop;
> 
> Lovely - now try that with underlying fs something built modular.
> 
> Or try to use it on top of something with non-trivial
> dentry_operations
> (hell, on top of itself, for starters).

So if I add the missing fops_get/put, you're happy with the way this
hijacks f_op and f_inode?

James

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

[James Bottomley]

On Wed, 2016-05-11 at 01:53 +0100, Al Viro wrote:
> On Tue, May 10, 2016 at 04:36:56PM -0700, James Bottomley wrote:
> > +static int shiftfs_rename2(struct inode *olddir, struct dentry
> > *old,
> > +  struct inode *newdir, struct dentry
> > *new,
> > +  unsigned int flags)
> > +{
> > +   struct dentry *rodd = olddir->i_private, *rndd = newdir
> > ->i_private,
> > +   *realold = old->d_inode->i_private,
> > +   *realnew = new->d_inode->i_private;
> > +   struct inode *realolddir = rodd->d_inode, *realnewdir =
> > rndd->d_inode;
> > +   const struct inode_operations *iop = realolddir->i_op;
> > +   int err;
> > +   const struct cred *oldcred, *newcred;
> > +
> > +   oldcred = shiftfs_new_creds(, old->d_sb);
> > +   err = iop->rename2(realolddir, realold, realnewdir,
> > realnew, flags);
> > +   shiftfs_old_creds(oldcred, );
> 
> ... and you've just violated all locking rules for ->rename2().

Yes, sorry, somehow I missed that when I converted everything else to
the vfs_ functions.

> > +static struct dentry *shiftfs_lookup(struct inode *dir, struct
> > dentry *dentry,
> > +unsigned int flags)
> > +{
> > +   struct dentry *real = dir->i_private, *new;
> > +   struct inode *reali = real->d_inode, *newi;
> > +   const struct cred *oldcred, *newcred;
> > +
> > +   /* note: violation of usual fs rules here: dentries are
> > never
> > +* added with d_add.  This is because we want no dentry
> > cache
> > +* for shiftfs.  All lookups proceed through the dentry
> > cache
> > +* of the underlying filesystem, meaning we always see any
> > +* changes in the underlying */
> 
> Bloody wonderful.  So
>   * we lose caching the negative lookups

We do?  They should be cached in the underlying layer's dcache. If
that's not enough, I can hash them, but I was trying to avoid doubling
the dcache size.

>   * we've got buggered hardlinks (different inodes for those)

Yes, had a note to do the lookup, but forgot.

>   * it has never, ever been tried on -next (would do rather nasty
> things on that d_instantiate())

So this is just a proof of concept; I figured it was best to do it
against current rather than have people who wanted to try it pull in
your tree.  I can respin it after the merge window closes.

> 
> > +
> > +   kfree(sfc);
> > +
> > +   return err;
> > +}
> 
> > +   file->f_op = >fop;
> 
> Lovely - now try that with underlying fs something built modular.
> 
> Or try to use it on top of something with non-trivial
> dentry_operations
> (hell, on top of itself, for starters).

So if I add the missing fops_get/put, you're happy with the way this
hijacks f_op and f_inode?

James

RE: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

[Rajesh Bhagat]

> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Wednesday, May 04, 2016 1:28 PM
> To: Rajesh Bhagat ; linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; gre...@linuxfoundation.org; Yang-Leo Li
> ; Sriram Dash ; Rajesh Bhagat
> 
> Subject: Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops 
> from DT
> 
> 
> Hi,
> 
> Rajesh Bhagat  writes:
> > On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly
> > set to be able to do DMA allocations, so use the of_dma_configure()
> > helper to populate the dma properties and assign an appropriate dma_ops.
> >
> > Signed-off-by: Rajesh Bhagat 
> > Reviewed-by: Yang-Leo Li 

Hi,

> 
> Cool, nxp is also using dwc3 :-) C'mon Rajesh, send us a glue layer :)
> 

I would surely be sending the glue layer soon :)

> > diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c index
> > c679f63..4d5b783 100644
> > --- a/drivers/usb/dwc3/host.c
> > +++ b/drivers/usb/dwc3/host.c
> > @@ -17,6 +17,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "core.h"
> >
> > @@ -32,6 +33,9 @@ int dwc3_host_init(struct dwc3 *dwc)
> > return -ENOMEM;
> > }
> >
> > +   if (IS_ENABLED(CONFIG_OF) && dwc->dev->of_node)
> > +   of_dma_configure(>dev, dwc->dev->of_node);
> 
> okay, so we have a long discussion about this going on. You can catch up with 
> it
> starting here:
> 
> http://marc.info/?i=1461612094-30939-1-git-send-email-grygorii.stras...@ti.com
> 
> At least for now, this patch will be applied. We need to have a better 
> solution for this,
> one that helps not only DT platforms.
> 

Thanks for information. 

> --
> balbi

RE: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

[Rajesh Bhagat]

> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Wednesday, May 04, 2016 1:28 PM
> To: Rajesh Bhagat ; linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; gre...@linuxfoundation.org; Yang-Leo Li
> ; Sriram Dash ; Rajesh Bhagat
> 
> Subject: Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops 
> from DT
> 
> 
> Hi,
> 
> Rajesh Bhagat  writes:
> > On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly
> > set to be able to do DMA allocations, so use the of_dma_configure()
> > helper to populate the dma properties and assign an appropriate dma_ops.
> >
> > Signed-off-by: Rajesh Bhagat 
> > Reviewed-by: Yang-Leo Li 

Hi,

> 
> Cool, nxp is also using dwc3 :-) C'mon Rajesh, send us a glue layer :)
> 

I would surely be sending the glue layer soon :)

> > diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c index
> > c679f63..4d5b783 100644
> > --- a/drivers/usb/dwc3/host.c
> > +++ b/drivers/usb/dwc3/host.c
> > @@ -17,6 +17,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "core.h"
> >
> > @@ -32,6 +33,9 @@ int dwc3_host_init(struct dwc3 *dwc)
> > return -ENOMEM;
> > }
> >
> > +   if (IS_ENABLED(CONFIG_OF) && dwc->dev->of_node)
> > +   of_dma_configure(>dev, dwc->dev->of_node);
> 
> okay, so we have a long discussion about this going on. You can catch up with 
> it
> starting here:
> 
> http://marc.info/?i=1461612094-30939-1-git-send-email-grygorii.stras...@ti.com
> 
> At least for now, this patch will be applied. We need to have a better 
> solution for this,
> one that helps not only DT platforms.
> 

Thanks for information. 

> --
> balbi

[PATCH v2] pinctrl: rockchip: fix pull setting error for rk3399

[Caesar Wang]

From: David Wu 

This patch fixes the pinctrl pull bias setting, since the pull up/down
setting is the contrary for gpio0(just the gpio0a and gpio0b) and
gpio2(just the gpio2c and gpio2d).

>From the TRM said, the gpio0a pull polarity setting:
gpio0a_p
GPIO0A PE/PS programmation section, every
GPIO bit corresponding to 2bits[PS:PE]
2'b00: Z(Normal operation);
2'b11: weak 1(pull-up);
2'b01: weak 0(pull-down);
2'b10: Z(Normal operation);

Then, the other gpios setting as the following:
gpio1a_p (e.g.: gpio1, gpio2a, gpio2b, gpio3...)
GPIO1A PU/PD programmation section, every
GPIO bit corresponding to 2bits
2'b00: Z(Normal operation);
2'b01: weak 1(pull-up);
2'b10: weak 0(pull-down);
2'b11: Z(Normal operation);

For example,(rk3399evb board)
sdmmc_cd --->gpio0_a7
localhost / # io -r -4 0xff320040
ff320040: 4d5f
In general,the value should be 0xcd5f since the pin has been set
in the dts.

Signed-off-by: David Wu 
Signed-off-by: Caesar Wang 
Cc: Linus Walleij 
Cc: Heiko Stuebner 
Cc: linux-g...@vger.kernel.org
---

Changes in v2:
- As Doug commnets on https://patchwork.kernel.org/patch/9056961/
- update the commit for gpio2.
- change the print error messgae.

 drivers/pinctrl/pinctrl-rockchip.c | 179 ++---
 1 file changed, 127 insertions(+), 52 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 596b869..a91026e 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -99,6 +99,15 @@ enum rockchip_pin_drv_type {
 };
 
 /**
+ * enum type index corresponding to rockchip_pull_list arrays index.
+ */
+enum rockchip_pin_pull_type {
+   PULL_TYPE_IO_DEFAULT = 0,
+   PULL_TYPE_IO_1V8_ONLY,
+   PULL_TYPE_MAX
+};
+
+/**
  * @drv_type: drive strength variant using rockchip_perpin_drv_type
  * @offset: if initialized to -1 it will be autocalculated, by specifying
  * an initial offset value the relevant source offset can be reset
@@ -123,6 +132,7 @@ struct rockchip_drv {
  * @bank_num: number of the bank, to account for holes
  * @iomux: array describing the 4 iomux sources of the bank
  * @drv: array describing the 4 drive strength sources of the bank
+ * @pull_type: array describing the 4 pull type sources of the bank
  * @valid: are all necessary informations present
  * @of_node: dt node of this bank
  * @drvdata: common pinctrl basedata
@@ -143,6 +153,7 @@ struct rockchip_pin_bank {
u8  bank_num;
struct rockchip_iomux   iomux[4];
struct rockchip_drv drv[4];
+   enum rockchip_pin_pull_type pull_type[4];
boolvalid;
struct device_node  *of_node;
struct rockchip_pinctrl *drvdata;
@@ -198,6 +209,31 @@ struct rockchip_pin_bank {
},  \
}
 
+#define PIN_BANK_DRV_FLAGS_PULL_FLAGS(id, pins, label, drv0, drv1, \
+ drv2, drv3, pull0, pull1, \
+ pull2, pull3) \
+   {   \
+   .bank_num   = id,   \
+   .nr_pins= pins, \
+   .name   = label,\
+   .iomux  = { \
+   { .offset = -1 },   \
+   { .offset = -1 },   \
+   { .offset = -1 },   \
+   { .offset = -1 },   \
+   },  \
+   .drv= { \
+   { .drv_type = drv0, .offset = -1 }, \
+   { .drv_type = drv1, .offset = -1 }, \
+   { .drv_type = drv2, .offset = -1 }, \
+   { .drv_type = drv3, .offset = -1 }, \
+   },  \
+   .pull_type[0] = pull0,  \
+   .pull_type[1] = pull1,  \
+   .pull_type[2] = pull2,  \
+   .pull_type[3] = pull3,  \
+   }
+
 #define PIN_BANK_IOMUX_DRV_FLAGS_OFFSET(id, pins, label, iom0, iom1,   \
iom2, iom3, drv0, drv1, drv2,   \
drv3, offset0, offset1, \
@@ 

[PATCH v2] pinctrl: rockchip: fix pull setting error for rk3399

[Caesar Wang]

From: David Wu 

This patch fixes the pinctrl pull bias setting, since the pull up/down
setting is the contrary for gpio0(just the gpio0a and gpio0b) and
gpio2(just the gpio2c and gpio2d).

>From the TRM said, the gpio0a pull polarity setting:
gpio0a_p
GPIO0A PE/PS programmation section, every
GPIO bit corresponding to 2bits[PS:PE]
2'b00: Z(Normal operation);
2'b11: weak 1(pull-up);
2'b01: weak 0(pull-down);
2'b10: Z(Normal operation);

Then, the other gpios setting as the following:
gpio1a_p (e.g.: gpio1, gpio2a, gpio2b, gpio3...)
GPIO1A PU/PD programmation section, every
GPIO bit corresponding to 2bits
2'b00: Z(Normal operation);
2'b01: weak 1(pull-up);
2'b10: weak 0(pull-down);
2'b11: Z(Normal operation);

For example,(rk3399evb board)
sdmmc_cd --->gpio0_a7
localhost / # io -r -4 0xff320040
ff320040: 4d5f
In general,the value should be 0xcd5f since the pin has been set
in the dts.

Signed-off-by: David Wu 
Signed-off-by: Caesar Wang 
Cc: Linus Walleij 
Cc: Heiko Stuebner 
Cc: linux-g...@vger.kernel.org
---

Changes in v2:
- As Doug commnets on https://patchwork.kernel.org/patch/9056961/
- update the commit for gpio2.
- change the print error messgae.

 drivers/pinctrl/pinctrl-rockchip.c | 179 ++---
 1 file changed, 127 insertions(+), 52 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 596b869..a91026e 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -99,6 +99,15 @@ enum rockchip_pin_drv_type {
 };
 
 /**
+ * enum type index corresponding to rockchip_pull_list arrays index.
+ */
+enum rockchip_pin_pull_type {
+   PULL_TYPE_IO_DEFAULT = 0,
+   PULL_TYPE_IO_1V8_ONLY,
+   PULL_TYPE_MAX
+};
+
+/**
  * @drv_type: drive strength variant using rockchip_perpin_drv_type
  * @offset: if initialized to -1 it will be autocalculated, by specifying
  * an initial offset value the relevant source offset can be reset
@@ -123,6 +132,7 @@ struct rockchip_drv {
  * @bank_num: number of the bank, to account for holes
  * @iomux: array describing the 4 iomux sources of the bank
  * @drv: array describing the 4 drive strength sources of the bank
+ * @pull_type: array describing the 4 pull type sources of the bank
  * @valid: are all necessary informations present
  * @of_node: dt node of this bank
  * @drvdata: common pinctrl basedata
@@ -143,6 +153,7 @@ struct rockchip_pin_bank {
u8  bank_num;
struct rockchip_iomux   iomux[4];
struct rockchip_drv drv[4];
+   enum rockchip_pin_pull_type pull_type[4];
boolvalid;
struct device_node  *of_node;
struct rockchip_pinctrl *drvdata;
@@ -198,6 +209,31 @@ struct rockchip_pin_bank {
},  \
}
 
+#define PIN_BANK_DRV_FLAGS_PULL_FLAGS(id, pins, label, drv0, drv1, \
+ drv2, drv3, pull0, pull1, \
+ pull2, pull3) \
+   {   \
+   .bank_num   = id,   \
+   .nr_pins= pins, \
+   .name   = label,\
+   .iomux  = { \
+   { .offset = -1 },   \
+   { .offset = -1 },   \
+   { .offset = -1 },   \
+   { .offset = -1 },   \
+   },  \
+   .drv= { \
+   { .drv_type = drv0, .offset = -1 }, \
+   { .drv_type = drv1, .offset = -1 }, \
+   { .drv_type = drv2, .offset = -1 }, \
+   { .drv_type = drv3, .offset = -1 }, \
+   },  \
+   .pull_type[0] = pull0,  \
+   .pull_type[1] = pull1,  \
+   .pull_type[2] = pull2,  \
+   .pull_type[3] = pull3,  \
+   }
+
 #define PIN_BANK_IOMUX_DRV_FLAGS_OFFSET(id, pins, label, iom0, iom1,   \
iom2, iom3, drv0, drv1, drv2,   \
drv3, offset0, offset1, \
@@ -220,6 +256,34 @@ struct rockchip_pin_bank {
},

Re: [RFC 2/2] perf/core: change errno for sampling event not supported in hardware

[Vince Weaver]

On Mon, 9 May 2016, Vineet Gupta wrote:

> On Monday 09 May 2016 07:24 PM, Vince Weaver wrote:
> > On Mon, 9 May 2016, Vineet Gupta wrote:
> > 
> >> This allows userspace to identify this case specifically from the
> >> catch all error msg it prints currently.
> >>
> >> This is an ABI change
> > 
> > An ABI change which will probably break things.
> 
> 
> Right thats what I feared. But hold on, I don't think we need to change the 
> ABI to
> achieve what we want. Gosh why did I even take that path.
> 
> Currently the errno switch case in perf_evsel__open_strerror() in doesn't 
> handle
> ENOTSUPP. So how about we add that - augmented with the same sample_period !0
> check to barf for lack of sampling support.
> 
> Do you see anything wrong with that ?

no, but it would be nice if one of the actual maintainers would chime in 
with an opinion.

In any case if ENOTSUPP is being returned to userspace I should update the 
perf_event manpage to reflect that.

Vince

Re: [RFC 2/2] perf/core: change errno for sampling event not supported in hardware

[Vince Weaver]

On Mon, 9 May 2016, Vineet Gupta wrote:

> On Monday 09 May 2016 07:24 PM, Vince Weaver wrote:
> > On Mon, 9 May 2016, Vineet Gupta wrote:
> > 
> >> This allows userspace to identify this case specifically from the
> >> catch all error msg it prints currently.
> >>
> >> This is an ABI change
> > 
> > An ABI change which will probably break things.
> 
> 
> Right thats what I feared. But hold on, I don't think we need to change the 
> ABI to
> achieve what we want. Gosh why did I even take that path.
> 
> Currently the errno switch case in perf_evsel__open_strerror() in doesn't 
> handle
> ENOTSUPP. So how about we add that - augmented with the same sample_period !0
> check to barf for lack of sampling support.
> 
> Do you see anything wrong with that ?

no, but it would be nice if one of the actual maintainers would chime in 
with an opinion.

In any case if ENOTSUPP is being returned to userspace I should update the 
perf_event manpage to reflect that.

Vince

Re: linux-next: build failure after merge of the sound-asoc tree

[Vinod Koul]

On Wed, May 11, 2016 at 11:07:02AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> sound/soc/intel/boards/bxt_rt298.c:257:3: error: unknown field 'be_id' 
> specified in initializer
>.be_id = 0,
>^
> sound/soc/intel/boards/bxt_rt298.c:274:3: error: unknown field 'be_id' 
> specified in initializer
>.be_id = 1,
>^
> sound/soc/intel/boards/bxt_rt298.c:274:12: warning: initialization makes 
> pointer from integer without a cast [-Wint-conversion]
>.be_id = 1,
> ^
> sound/soc/intel/boards/bxt_rt298.c:274:12: note: (near initialization for 
> 'broxton_rt298_dais[7].stream_name')
> sound/soc/intel/boards/bxt_rt298.c:285:3: error: unknown field 'be_id' 
> specified in initializer
>.be_id = 3,
>^
> sound/soc/intel/boards/bxt_rt298.c:285:12: warning: initialization makes 
> pointer from integer without a cast [-Wint-conversion]
>.be_id = 3,
> ^
> sound/soc/intel/boards/bxt_rt298.c:285:12: note: (near initialization for 
> 'broxton_rt298_dais[8].stream_name')
> sound/soc/intel/boards/bxt_rt298.c:296:3: error: unknown field 'be_id' 
> specified in initializer 
>.be_id = 4,
>^
> sound/soc/intel/boards/bxt_rt298.c:296:12: warning: initialization makes 
> pointer from integer without a cast [-Wint-conversion]
>.be_id = 4,
> ^
> sound/soc/intel/boards/bxt_rt298.c:296:12: note: (near initialization for 
> 'broxton_rt298_dais[9].stream_name')
> sound/soc/intel/boards/bxt_rt298.c:307:3: error: unknown field 'be_id' 
> specified in initializer 
>.be_id = 5,
>^
> sound/soc/intel/boards/bxt_rt298.c:307:12: warning: initialization makes 
> pointer from integer without a cast [-Wint-conversion]
>.be_id = 5,
> ^
> 
> Caused by commit
> 
>   76016322ec56 ("ASoC: Intel: Add Broxton-P machine driver")
> 
> interacting with commit
> 
>   2f0ad49104cb ("ASoC: Change DAI link's be_id to a generic id")

My bad, patch was generated against topic/intel of Mark's tree and I should
have checked the -next branch as well

> 
> I applied the following fix patch that should have happened in the
> merge commit
> 
>   8554363b9f0f ("Merge remote-tracking branches 'asoc/topic/dai-link', 
> 'asoc/topic/davinci', 'asoc/topic/dwc' and 'asoc/topic/es8328' into 
> asoc-next")
> 
> From: Stephen Rothwell 
> Date: Wed, 11 May 2016 11:03:25 +1000
> Subject: [PATCH] ASoC: Intel: fix up for DAI link's be_id change
> 
> Signed-off-by: Stephen Rothwell 

Acked-by: Vinod Koul 

I guess Mark you will merge this as well?


> ---
>  sound/soc/intel/boards/bxt_rt298.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/sound/soc/intel/boards/bxt_rt298.c 
> b/sound/soc/intel/boards/bxt_rt298.c
> index 1b845ff779f3..f4787515c0ed 100644
> --- a/sound/soc/intel/boards/bxt_rt298.c
> +++ b/sound/soc/intel/boards/bxt_rt298.c
> @@ -254,7 +254,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   {
>   /* SSP5 - Codec */
>   .name = "SSP5-Codec",
> - .be_id = 0,
> + .id = 0,
>   .cpu_dai_name = "SSP5 Pin",
>   .platform_name = ":00:0e.0",
>   .no_pcm = 1,
> @@ -271,7 +271,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   },
>   {
>   .name = "dmic01",
> - .be_id = 1,
> + .id = 1,
>   .cpu_dai_name = "DMIC01 Pin",
>   .codec_name = "dmic-codec",
>   .codec_dai_name = "dmic-hifi",
> @@ -282,7 +282,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   },
>   {
>   .name = "iDisp1",
> - .be_id = 3,
> + .id = 3,
>   .cpu_dai_name = "iDisp1 Pin",
>   .codec_name = "ehdaudio0D2",
>   .codec_dai_name = "intel-hdmi-hifi1",
> @@ -293,7 +293,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   },
>   {
>   .name = "iDisp2",
> - .be_id = 4,
> + .id = 4,
>   .cpu_dai_name = "iDisp2 Pin",
>   .codec_name = "ehdaudio0D2",
>   .codec_dai_name = "intel-hdmi-hifi2",
> @@ -304,7 +304,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   },
>   {
>   .name = "iDisp3",
> - .be_id = 5,
> + .id = 5,
>   .cpu_dai_name = "iDisp3 Pin",
>   .codec_name = "ehdaudio0D2",
>   .codec_dai_name = "intel-hdmi-hifi3",
> -- 
> 2.7.0
> 
> -- 
> Cheers,
> Stephen Rothwell

Thanks
-- 
~Vinod

Re: linux-next: build failure after merge of the sound-asoc tree

[Vinod Koul]

On Wed, May 11, 2016 at 11:07:02AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> sound/soc/intel/boards/bxt_rt298.c:257:3: error: unknown field 'be_id' 
> specified in initializer
>.be_id = 0,
>^
> sound/soc/intel/boards/bxt_rt298.c:274:3: error: unknown field 'be_id' 
> specified in initializer
>.be_id = 1,
>^
> sound/soc/intel/boards/bxt_rt298.c:274:12: warning: initialization makes 
> pointer from integer without a cast [-Wint-conversion]
>.be_id = 1,
> ^
> sound/soc/intel/boards/bxt_rt298.c:274:12: note: (near initialization for 
> 'broxton_rt298_dais[7].stream_name')
> sound/soc/intel/boards/bxt_rt298.c:285:3: error: unknown field 'be_id' 
> specified in initializer
>.be_id = 3,
>^
> sound/soc/intel/boards/bxt_rt298.c:285:12: warning: initialization makes 
> pointer from integer without a cast [-Wint-conversion]
>.be_id = 3,
> ^
> sound/soc/intel/boards/bxt_rt298.c:285:12: note: (near initialization for 
> 'broxton_rt298_dais[8].stream_name')
> sound/soc/intel/boards/bxt_rt298.c:296:3: error: unknown field 'be_id' 
> specified in initializer 
>.be_id = 4,
>^
> sound/soc/intel/boards/bxt_rt298.c:296:12: warning: initialization makes 
> pointer from integer without a cast [-Wint-conversion]
>.be_id = 4,
> ^
> sound/soc/intel/boards/bxt_rt298.c:296:12: note: (near initialization for 
> 'broxton_rt298_dais[9].stream_name')
> sound/soc/intel/boards/bxt_rt298.c:307:3: error: unknown field 'be_id' 
> specified in initializer 
>.be_id = 5,
>^
> sound/soc/intel/boards/bxt_rt298.c:307:12: warning: initialization makes 
> pointer from integer without a cast [-Wint-conversion]
>.be_id = 5,
> ^
> 
> Caused by commit
> 
>   76016322ec56 ("ASoC: Intel: Add Broxton-P machine driver")
> 
> interacting with commit
> 
>   2f0ad49104cb ("ASoC: Change DAI link's be_id to a generic id")

My bad, patch was generated against topic/intel of Mark's tree and I should
have checked the -next branch as well

> 
> I applied the following fix patch that should have happened in the
> merge commit
> 
>   8554363b9f0f ("Merge remote-tracking branches 'asoc/topic/dai-link', 
> 'asoc/topic/davinci', 'asoc/topic/dwc' and 'asoc/topic/es8328' into 
> asoc-next")
> 
> From: Stephen Rothwell 
> Date: Wed, 11 May 2016 11:03:25 +1000
> Subject: [PATCH] ASoC: Intel: fix up for DAI link's be_id change
> 
> Signed-off-by: Stephen Rothwell 

Acked-by: Vinod Koul 

I guess Mark you will merge this as well?


> ---
>  sound/soc/intel/boards/bxt_rt298.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/sound/soc/intel/boards/bxt_rt298.c 
> b/sound/soc/intel/boards/bxt_rt298.c
> index 1b845ff779f3..f4787515c0ed 100644
> --- a/sound/soc/intel/boards/bxt_rt298.c
> +++ b/sound/soc/intel/boards/bxt_rt298.c
> @@ -254,7 +254,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   {
>   /* SSP5 - Codec */
>   .name = "SSP5-Codec",
> - .be_id = 0,
> + .id = 0,
>   .cpu_dai_name = "SSP5 Pin",
>   .platform_name = ":00:0e.0",
>   .no_pcm = 1,
> @@ -271,7 +271,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   },
>   {
>   .name = "dmic01",
> - .be_id = 1,
> + .id = 1,
>   .cpu_dai_name = "DMIC01 Pin",
>   .codec_name = "dmic-codec",
>   .codec_dai_name = "dmic-hifi",
> @@ -282,7 +282,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   },
>   {
>   .name = "iDisp1",
> - .be_id = 3,
> + .id = 3,
>   .cpu_dai_name = "iDisp1 Pin",
>   .codec_name = "ehdaudio0D2",
>   .codec_dai_name = "intel-hdmi-hifi1",
> @@ -293,7 +293,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   },
>   {
>   .name = "iDisp2",
> - .be_id = 4,
> + .id = 4,
>   .cpu_dai_name = "iDisp2 Pin",
>   .codec_name = "ehdaudio0D2",
>   .codec_dai_name = "intel-hdmi-hifi2",
> @@ -304,7 +304,7 @@ static struct snd_soc_dai_link broxton_rt298_dais[] = {
>   },
>   {
>   .name = "iDisp3",
> - .be_id = 5,
> + .id = 5,
>   .cpu_dai_name = "iDisp3 Pin",
>   .codec_name = "ehdaudio0D2",
>   .codec_dai_name = "intel-hdmi-hifi3",
> -- 
> 2.7.0
> 
> -- 
> Cheers,
> Stephen Rothwell

Thanks
-- 
~Vinod

Re: [PATCH] dma: rcar-dmac: use list_add() on rcar_dmac_desc_put()

[Kuninori Morimoto]

Hi Laurent, Vinod,

> > > From: Kuninori Morimoto 
> > > 
> > > Current rcar_dmac_desc_put() is using list_add_tail() in order to
> > > push used descriptor to list of free descriptors, and next DMA transfer
> > > try to reuse it from this list. But because it is using *_tail(),
> > > this reuse effect can't be obtained without using all of them.
> > > For a longer-term solution, we should allocate hardware descriptors
> > > using GFP_KERNEL instead of GFP_NOWAIT, but it is difficult today.
> > > This patch uses list_add() instead of list_add_tail() for short-term
> > > solution.
> > 
> > So how does reuse case help by not moving the descriptor to tail.
> > 
> > Also you are not reusing descriptor, you are reusing a descriptor memory,
> > these are two different things.
> > 
> > Lastly how does this help? Something doesn't seem right
> 
> For each descriptor, in addition to the memory used by the descriptors 
> structure itself, the driver allocates a list of chunks as well as a buffer 
> for hardware descriptors. Descriptors themselves are preallocated, and 
> allocation of the chunks and buffer is performed the first time the 
> descriptor 
> is used. The memory isn't freed when the transfer is completed, as the chunks 
> and buffer will be needed again when the descriptor is reused internally, so 
> the driver keeps the memory around.
> 
> If only a few descriptors are used concurrently, the current list_add_tail() 
> implementation will result in all preallocated descriptors being used before 
> going back to the first one, and will thus allocate chunks and a buffer for 
> all preallocated descriptors. Using list_add() will put the complete 
> descriptor at the head of the list of available descriptors, so the next 
> transfer will be more likely to reuse a descriptor that already has 
> associated 
> memory instead of one that has never been used before.

Laurent, thank you for your help
Vinod, does above clear for you ?

[PATCH v2 0/4] perf script: fix duplicate symbols in db-export

[Chris Phlipot]

Changes since v1:
 - fixed scripts/checkpatch.pl errors

This patch set contains 3 fixes for duplicate symbol creation in the
db-export implementation and one new symbol API required for the fixes.

commit 9c7b37cd63d0 ("perf symbols: Fix handling of zero-length symbols.")
already removed the majority of duplicates, but these fixes take care of
the remaining corner cases.

each patch (except for the 1st, which is a dependency for patch 2) reduces
the number of duplicate symbols exported. When all patches are applied,
my test workload has no more duplicate symbols being exported.

Tests ran:

$perf record --call-graph=dwarf stress -c 2 -t 20
$perf script -s scripts/python/export-to-postgresql.py test all callchains
$psql test

To show the effect of the changes we run the following query before/after
the changes on a database created using the export-to-postgresql.py script
with callchains enabled. If this query returns any value greater than 1,
then it means that there are duplicates present. 


In the test workload, at least one symbol occurs 299 times before applying
the fixes:

  test=# select count(*) as cnt from symbols group by 
sym_start,sym_end,dso_id order by cnt desc limit 1;
   cnt 
  -
   299
  (1 row)

After applying the fixes no symbol occurs more than once:

  test=# select count(*) as cnt from symbols group by
sym_start,sym_end,dso_id order by cnt desc limit 1;
   cnt 
  -
 1
  (1 row)

Chris Phlipot (4):
  perf symbols: add dso__insert_symbol function
  perf script: fix symbol insertion behavior in db-export
  perf script: fix callchain addresses in db-export
  perf script: fix export of callchains with recursion in db-export

 tools/perf/util/db-export.c | 12 ++--
 tools/perf/util/symbol.c| 12 
 tools/perf/util/symbol.h|  3 +++
 3 files changed, 21 insertions(+), 6 deletions(-)

-- 
2.7.4

Re: [PATCH] dma: rcar-dmac: use list_add() on rcar_dmac_desc_put()

[Kuninori Morimoto]

Hi Laurent, Vinod,

> > > From: Kuninori Morimoto 
> > > 
> > > Current rcar_dmac_desc_put() is using list_add_tail() in order to
> > > push used descriptor to list of free descriptors, and next DMA transfer
> > > try to reuse it from this list. But because it is using *_tail(),
> > > this reuse effect can't be obtained without using all of them.
> > > For a longer-term solution, we should allocate hardware descriptors
> > > using GFP_KERNEL instead of GFP_NOWAIT, but it is difficult today.
> > > This patch uses list_add() instead of list_add_tail() for short-term
> > > solution.
> > 
> > So how does reuse case help by not moving the descriptor to tail.
> > 
> > Also you are not reusing descriptor, you are reusing a descriptor memory,
> > these are two different things.
> > 
> > Lastly how does this help? Something doesn't seem right
> 
> For each descriptor, in addition to the memory used by the descriptors 
> structure itself, the driver allocates a list of chunks as well as a buffer 
> for hardware descriptors. Descriptors themselves are preallocated, and 
> allocation of the chunks and buffer is performed the first time the 
> descriptor 
> is used. The memory isn't freed when the transfer is completed, as the chunks 
> and buffer will be needed again when the descriptor is reused internally, so 
> the driver keeps the memory around.
> 
> If only a few descriptors are used concurrently, the current list_add_tail() 
> implementation will result in all preallocated descriptors being used before 
> going back to the first one, and will thus allocate chunks and a buffer for 
> all preallocated descriptors. Using list_add() will put the complete 
> descriptor at the head of the list of available descriptors, so the next 
> transfer will be more likely to reuse a descriptor that already has 
> associated 
> memory instead of one that has never been used before.

Laurent, thank you for your help
Vinod, does above clear for you ?

[PATCH v2 0/4] perf script: fix duplicate symbols in db-export

[Chris Phlipot]

Changes since v1:
 - fixed scripts/checkpatch.pl errors

This patch set contains 3 fixes for duplicate symbol creation in the
db-export implementation and one new symbol API required for the fixes.

commit 9c7b37cd63d0 ("perf symbols: Fix handling of zero-length symbols.")
already removed the majority of duplicates, but these fixes take care of
the remaining corner cases.

each patch (except for the 1st, which is a dependency for patch 2) reduces
the number of duplicate symbols exported. When all patches are applied,
my test workload has no more duplicate symbols being exported.

Tests ran:

$perf record --call-graph=dwarf stress -c 2 -t 20
$perf script -s scripts/python/export-to-postgresql.py test all callchains
$psql test

To show the effect of the changes we run the following query before/after
the changes on a database created using the export-to-postgresql.py script
with callchains enabled. If this query returns any value greater than 1,
then it means that there are duplicates present. 


In the test workload, at least one symbol occurs 299 times before applying
the fixes:

  test=# select count(*) as cnt from symbols group by 
sym_start,sym_end,dso_id order by cnt desc limit 1;
   cnt 
  -
   299
  (1 row)

After applying the fixes no symbol occurs more than once:

  test=# select count(*) as cnt from symbols group by
sym_start,sym_end,dso_id order by cnt desc limit 1;
   cnt 
  -
 1
  (1 row)

Chris Phlipot (4):
  perf symbols: add dso__insert_symbol function
  perf script: fix symbol insertion behavior in db-export
  perf script: fix callchain addresses in db-export
  perf script: fix export of callchains with recursion in db-export

 tools/perf/util/db-export.c | 12 ++--
 tools/perf/util/symbol.c| 12 
 tools/perf/util/symbol.h|  3 +++
 3 files changed, 21 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH v2 3/4] perf script: fix callchain addresses in db-export

[Chris Phlipot]

Remove the call to map_ip, because it has already been called when
assembling the callchain. Calling it a second time can result in incorrect
addresses being used. This can have effects such as duplicate symbols
being created and exported.

Signed-off-by: Chris Phlipot 
---
 tools/perf/util/db-export.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/tools/perf/util/db-export.c b/tools/perf/util/db-export.c
index 2ef1f69..8ca4186 100644
--- a/tools/perf/util/db-export.c
+++ b/tools/perf/util/db-export.c
@@ -324,10 +324,7 @@ static struct call_path *call_path_from_sample(struct 
db_export *dbe,
al.sym = node->sym;
al.map = node->map;
al.machine = machine;
-   if (al.map)
-   al.addr = al.map->map_ip(al.map, node->ip);
-   else
-   al.addr = node->ip;
+   al.addr = node->ip;
 
db_ids_from_al(dbe, , _db_id, _db_id, );
 
-- 
2.7.4

[PATCH v2 3/4] perf script: fix callchain addresses in db-export

[Chris Phlipot]

Remove the call to map_ip, because it has already been called when
assembling the callchain. Calling it a second time can result in incorrect
addresses being used. This can have effects such as duplicate symbols
being created and exported.

Signed-off-by: Chris Phlipot 
---
 tools/perf/util/db-export.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/tools/perf/util/db-export.c b/tools/perf/util/db-export.c
index 2ef1f69..8ca4186 100644
--- a/tools/perf/util/db-export.c
+++ b/tools/perf/util/db-export.c
@@ -324,10 +324,7 @@ static struct call_path *call_path_from_sample(struct 
db_export *dbe,
al.sym = node->sym;
al.map = node->map;
al.machine = machine;
-   if (al.map)
-   al.addr = al.map->map_ip(al.map, node->ip);
-   else
-   al.addr = node->ip;
+   al.addr = node->ip;
 
db_ids_from_al(dbe, , _db_id, _db_id, );
 
-- 
2.7.4

[PATCH v2 2/4] perf script: fix symbol insertion behavior in db-export

[Chris Phlipot]

Use the dso__insert_symbol function instead of symbols__insert in order to
properly update the dso symbol cache.

If the cache is not updated, then duplicate symbols can be unintentionally
created, inserted, and exported.

This change prevents duplicate symbols from being exported due to
dso__find_symbol using a stale symbol cache.

Signed-off-by: Chris Phlipot 
---
 tools/perf/util/db-export.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/db-export.c b/tools/perf/util/db-export.c
index f8e3057..2ef1f69 100644
--- a/tools/perf/util/db-export.c
+++ b/tools/perf/util/db-export.c
@@ -260,8 +260,7 @@ static int db_ids_from_al(struct db_export *dbe, struct 
addr_location *al,
if (!al->sym) {
al->sym = symbol__new(al->addr, 0, 0, "unknown");
if (al->sym)
-   symbols__insert(>symbols[al->map->type],
-   al->sym);
+   dso__insert_symbol(dso, al->map->type, al->sym);
}
 
if (al->sym) {
-- 
2.7.4

[PATCH v2 4/4] perf script: fix export of callchains with recursion in db-export

[Chris Phlipot]

When an IP with an unresolved symbol occurs in the callchain more than
once (ie. recursion), then duplicate symbols can be created because
the callchain nodes are never updated after they are first created.

To fix this issue we call dso__find_symbol whenever we encounter a NULL
symbol, in case we already added a symbol at that IP since we started
traversing the callchain.

This change prevents duplicate symbols from being exported when duplicate
IPs are present in the callchain.

Signed-off-by: Chris Phlipot 
---
 tools/perf/util/db-export.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/util/db-export.c b/tools/perf/util/db-export.c
index 8ca4186..8d96c80 100644
--- a/tools/perf/util/db-export.c
+++ b/tools/perf/util/db-export.c
@@ -326,6 +326,10 @@ static struct call_path *call_path_from_sample(struct 
db_export *dbe,
al.machine = machine;
al.addr = node->ip;
 
+   if (al.map && !al.sym)
+   al.sym = dso__find_symbol(al.map->dso, MAP__FUNCTION,
+ al.addr);
+
db_ids_from_al(dbe, , _db_id, _db_id, );
 
/* add node to the call path tree if it doesn't exist */
-- 
2.7.4

[PATCH v2 2/4] perf script: fix symbol insertion behavior in db-export

[Chris Phlipot]

Use the dso__insert_symbol function instead of symbols__insert in order to
properly update the dso symbol cache.

If the cache is not updated, then duplicate symbols can be unintentionally
created, inserted, and exported.

This change prevents duplicate symbols from being exported due to
dso__find_symbol using a stale symbol cache.

Signed-off-by: Chris Phlipot 
---
 tools/perf/util/db-export.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/db-export.c b/tools/perf/util/db-export.c
index f8e3057..2ef1f69 100644
--- a/tools/perf/util/db-export.c
+++ b/tools/perf/util/db-export.c
@@ -260,8 +260,7 @@ static int db_ids_from_al(struct db_export *dbe, struct 
addr_location *al,
if (!al->sym) {
al->sym = symbol__new(al->addr, 0, 0, "unknown");
if (al->sym)
-   symbols__insert(>symbols[al->map->type],
-   al->sym);
+   dso__insert_symbol(dso, al->map->type, al->sym);
}
 
if (al->sym) {
-- 
2.7.4

[PATCH v2 4/4] perf script: fix export of callchains with recursion in db-export

[Chris Phlipot]

When an IP with an unresolved symbol occurs in the callchain more than
once (ie. recursion), then duplicate symbols can be created because
the callchain nodes are never updated after they are first created.

To fix this issue we call dso__find_symbol whenever we encounter a NULL
symbol, in case we already added a symbol at that IP since we started
traversing the callchain.

This change prevents duplicate symbols from being exported when duplicate
IPs are present in the callchain.

Signed-off-by: Chris Phlipot 
---
 tools/perf/util/db-export.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/util/db-export.c b/tools/perf/util/db-export.c
index 8ca4186..8d96c80 100644
--- a/tools/perf/util/db-export.c
+++ b/tools/perf/util/db-export.c
@@ -326,6 +326,10 @@ static struct call_path *call_path_from_sample(struct 
db_export *dbe,
al.machine = machine;
al.addr = node->ip;
 
+   if (al.map && !al.sym)
+   al.sym = dso__find_symbol(al.map->dso, MAP__FUNCTION,
+ al.addr);
+
db_ids_from_al(dbe, , _db_id, _db_id, );
 
/* add node to the call path tree if it doesn't exist */
-- 
2.7.4

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

[Scott Wood]

On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -Original Message-
> > > From: Arnd Bergmann [mailto:a...@arndb.de]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-...@lists.ozlabs.org
> > > Cc: Yangbo Lu; linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux-...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> > > foundation.org; net...@vger.kernel.org; Mark Rutland;
> > > ulf.hans...@linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > > R1.0-R2.0
> > > 
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > > > even compile on !PPC. It is things like this that prevent sharing the
> > > > driver.
> > 
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM...  The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
> 
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
> 
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
> 
> Finding out the version of the SoC does not look like this case.

I'm open to new ways of abstracting this, but can that please be discussed
after these patches are merged?  This patchset is fixing a problem, the
existing abstraction is unappealing and not widely adopted, a new abstraction
is not ready, and we're only touching code for our hardware.

Oh, and the existing abstraction isn't even "existing".  I don't see any
examples where soc_device is being used like this -- or even any way for a
driver (the one consuming the information, not the soc "driver") to get a
reference to the soc_device that's been registered short of searching for the
device object by name -- and you're asking for new functionality in
drivers/base/soc.c.

> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> > 
> > What specific problem is there with COMPILE_TEST?
> 
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.

Please keep in mind that this is a Freescale-specific driver... it's not as if
we're attaching this dependency to common SDHCI code.

> 
> > > > Dealing with Si revs is a common problem. We should have a
> > > > common solution. There is soc_device for this purpose.
> > > 
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> > 
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number. 
> 
> You already need to encode it as a string to register the soc_device,

No we don't, because we don't already register a soc_device on arm64 or ppc
(and it looks like whatever does get registered on at least some relevant
arm32 chips is not particularly useful).

> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.

"just"

And what would the glob look like?

I'd rather not write kernel code as if it were a shell/Perl script.

> > And when would it get registered on arm64, which doesn't have
> > platform code?
> 
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.

That's too late for some places where we need 

[PATCH v2 1/4] perf symbols: add dso__insert_symbol function

[Chris Phlipot]

The current method for inserting symbols is to use the symbols__insert
function. However symbols__insert does not update the dso symbol cache.
This causes problems in the following scenario:

1. symbol not found at ip using dso__find_symbol

2. symbol inserted at ip using the existing symbols__insert function

3. symbol still not found at ip using dso__find_symbol because cache isn't
updated. This is undesired behavior.

The undesired behavior in (3) is addressed by creating a new function,
dso__insert_symbol to both insert the symbol and update the symbol cache
if necessary.

If dso__insert_symbol is used in (2) instead of symbols__insert, then the
undesired behavior in (3) is avoided.

Signed-off-by: Chris Phlipot 
---
 tools/perf/util/symbol.c | 12 
 tools/perf/util/symbol.h |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 2946295..21af8e8 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -413,6 +413,18 @@ void dso__reset_find_symbol_cache(struct dso *dso)
}
 }
 
+void dso__insert_symbol(struct dso *dso, enum map_type type, struct symbol 
*sym)
+{
+   symbols__insert(>symbols[type], sym);
+
+   /* update the symbol cache if necessary */
+   if (dso->last_find_result[type].addr >= sym->start &&
+   (dso->last_find_result[type].addr < sym->end ||
+   sym->start == sym->end)) {
+   dso->last_find_result[type].symbol = sym;
+   }
+}
+
 struct symbol *dso__find_symbol(struct dso *dso,
enum map_type type, u64 addr)
 {
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 07211c2..2b5e4ed 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -246,6 +246,9 @@ int __dso__load_kallsyms(struct dso *dso, const char 
*filename, struct map *map,
 int dso__load_kallsyms(struct dso *dso, const char *filename, struct map *map,
   symbol_filter_t filter);
 
+void dso__insert_symbol(struct dso *dso, enum map_type type,
+   struct symbol *sym);
+
 struct symbol *dso__find_symbol(struct dso *dso, enum map_type type,
u64 addr);
 struct symbol *dso__find_symbol_by_name(struct dso *dso, enum map_type type,
-- 
2.7.4

[PATCH v2 1/4] perf symbols: add dso__insert_symbol function

[Chris Phlipot]

The current method for inserting symbols is to use the symbols__insert
function. However symbols__insert does not update the dso symbol cache.
This causes problems in the following scenario:

1. symbol not found at ip using dso__find_symbol

2. symbol inserted at ip using the existing symbols__insert function

3. symbol still not found at ip using dso__find_symbol because cache isn't
updated. This is undesired behavior.

The undesired behavior in (3) is addressed by creating a new function,
dso__insert_symbol to both insert the symbol and update the symbol cache
if necessary.

If dso__insert_symbol is used in (2) instead of symbols__insert, then the
undesired behavior in (3) is avoided.

Signed-off-by: Chris Phlipot 
---
 tools/perf/util/symbol.c | 12 
 tools/perf/util/symbol.h |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 2946295..21af8e8 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -413,6 +413,18 @@ void dso__reset_find_symbol_cache(struct dso *dso)
}
 }
 
+void dso__insert_symbol(struct dso *dso, enum map_type type, struct symbol 
*sym)
+{
+   symbols__insert(>symbols[type], sym);
+
+   /* update the symbol cache if necessary */
+   if (dso->last_find_result[type].addr >= sym->start &&
+   (dso->last_find_result[type].addr < sym->end ||
+   sym->start == sym->end)) {
+   dso->last_find_result[type].symbol = sym;
+   }
+}
+
 struct symbol *dso__find_symbol(struct dso *dso,
enum map_type type, u64 addr)
 {
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 07211c2..2b5e4ed 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -246,6 +246,9 @@ int __dso__load_kallsyms(struct dso *dso, const char 
*filename, struct map *map,
 int dso__load_kallsyms(struct dso *dso, const char *filename, struct map *map,
   symbol_filter_t filter);
 
+void dso__insert_symbol(struct dso *dso, enum map_type type,
+   struct symbol *sym);
+
 struct symbol *dso__find_symbol(struct dso *dso, enum map_type type,
u64 addr);
 struct symbol *dso__find_symbol_by_name(struct dso *dso, enum map_type type,
-- 
2.7.4

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

[Scott Wood]

On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -Original Message-
> > > From: Arnd Bergmann [mailto:a...@arndb.de]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-...@lists.ozlabs.org
> > > Cc: Yangbo Lu; linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux-...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> > > foundation.org; net...@vger.kernel.org; Mark Rutland;
> > > ulf.hans...@linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > > R1.0-R2.0
> > > 
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > > > even compile on !PPC. It is things like this that prevent sharing the
> > > > driver.
> > 
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM...  The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
> 
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
> 
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
> 
> Finding out the version of the SoC does not look like this case.

I'm open to new ways of abstracting this, but can that please be discussed
after these patches are merged?  This patchset is fixing a problem, the
existing abstraction is unappealing and not widely adopted, a new abstraction
is not ready, and we're only touching code for our hardware.

Oh, and the existing abstraction isn't even "existing".  I don't see any
examples where soc_device is being used like this -- or even any way for a
driver (the one consuming the information, not the soc "driver") to get a
reference to the soc_device that's been registered short of searching for the
device object by name -- and you're asking for new functionality in
drivers/base/soc.c.

> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> > 
> > What specific problem is there with COMPILE_TEST?
> 
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.

Please keep in mind that this is a Freescale-specific driver... it's not as if
we're attaching this dependency to common SDHCI code.

> 
> > > > Dealing with Si revs is a common problem. We should have a
> > > > common solution. There is soc_device for this purpose.
> > > 
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> > 
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number. 
> 
> You already need to encode it as a string to register the soc_device,

No we don't, because we don't already register a soc_device on arm64 or ppc
(and it looks like whatever does get registered on at least some relevant
arm32 chips is not particularly useful).

> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.

"just"

And what would the glob look like?

I'd rather not write kernel code as if it were a shell/Perl script.

> > And when would it get registered on arm64, which doesn't have
> > platform code?
> 
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.

That's too late for some places where we need 

Re: [PATCH v2 5/5] vf610-soc: Add Vybrid SoC device tree binding documentation

[Rob Herring]

On Mon, May 9, 2016 at 8:13 PM, Stefan Agner  wrote:
> On 2016-05-09 15:58, Rob Herring wrote:
>> On Mon, May 9, 2016 at 1:25 PM, Stefan Agner  wrote:
>>> On 2016-05-09 10:14, Rob Herring wrote:
 On Thu, May 5, 2016 at 3:27 AM,   wrote:
> Hello Rob,
>
> On 16-05-03 21:30:26, Rob Herring wrote:
>> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
>> > Add device tree binding documentation for Vybrid SoC.

[...]

> Basically being a standalone platform driver, there was need of a 
> compatible
> property to bind on. Introducing a separate device tree node for it's sake
> didn't seem appropriate so the alteration to SoC node's compatible.

 Ah, so you are designing a node around the needs of a Linux specific
 driver. Don't do that. DT describes the h/w and this node is not a h/w
 block.

 Create a platform device based on a matching SOC compatible string
 instead and make your driver find the information it needs directly
 from the relevant nodes like the ROM node.
>>>
>>> That reads like my words a year ago:
>>> https://lkml.org/lkml/2015/5/22/408
>>>
>>> Initially pretty much everything was hard-coded in the driver.
>>>
>>> Arnd then pushed to use more descriptive in the device tree.
>>>
>>> Of course, we should not end up making up relations which are not there
>>> in hardware. We need to find the right balance.
>>>
>>> Here is my suggestion:
>>> 1. Add "fsl,vf610-soc-bus" as compatible string to the soc node, use it
>>> to bind the "soc bus driver" as a platform driver located in driver/soc/
>>
>> I'm not convinced this is a h/w block. This keeps coming up and I
>> think this is a kernel problem, not a DT problem. Let's face it that
>> there are drivers at the SOC level which don't fit into a DT node.
>> They may be the exception, but they are a common exception. My
>> proposal for how to deal with these cases is here[1].
>
> Probably "fsl,vf610-soc" would be better than "fsl,vf610-soc-bus".

But the node in question is just the bus part of the SoC. Things like
cpus are not included.

> But the SoC is definitely a h/w block! Despite all the individual
> silicon in there, I can even touch the SoC ;-)

Can't argue with that...

> But yeah, I understand what you are saying... We model it as a
> container, and do not attribute any specific thing directly to it. But
> aren't there other containers where we bind to? Is it wrong to bind a
> driver to a container, if that driver implements issues concerning that
> level..?

It is supposed to be a bus, not just a container. However, we probably
don't generally fully and accurately model the buses in SoCs so DT
ends up being just a container frequently. If the bus is more than
simple-bus, then it should have some resource that needs to be
controlled to enable the bus.

>
> The two drivers under drivers/soc/ which implement the SoC bus API and
> both use a compatible string on a container level (e.g.
> arm,realview-pb11mp-soc in arch/arm/boot/dts/arm-realview-pb11mp.dts).

I'm not sure Realview and Integrator are models to follow. They are a
bit unique in their h/w design.

>
>>
>> I also think drivers/soc is a mess because it is randomly used or not.
>> IMO, using it should not be at the whim of whomever does SOC support.
>
> Are you talking about random drivers under drivers/soc/ or the ones
> which implement the SoC bus API? I think that is not the same...

The SoC bus API.

> If SoC bus, agreed, it is a mess. Not only its adoption is sparse, the
> specification is also interpreted differently across different SoC's,
> which I brought up in the past:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333765.html
>
> But it exports really useful information to user space, and that has
> real value in practice.

Yes, but the information exported has nothing really to do with a bus.
The "bus" part of it is more sub-classing platform_bus_type for all
platform devices on an SOC. That container may or may not directly
correspond to the bus structure of the SOC as defined in DT. I guess
it is the mixing of really 2 independent things that I don't like and
has made its use sparse. We should perhaps mandate using the bus (for
what I described) and make the information part separate and be able
to populate it from any driver (e.g. an SoC syscon driver which reads
the SOC revision).

Rob

Re: [PATCH v2 5/5] vf610-soc: Add Vybrid SoC device tree binding documentation

[Rob Herring]

On Mon, May 9, 2016 at 8:13 PM, Stefan Agner  wrote:
> On 2016-05-09 15:58, Rob Herring wrote:
>> On Mon, May 9, 2016 at 1:25 PM, Stefan Agner  wrote:
>>> On 2016-05-09 10:14, Rob Herring wrote:
 On Thu, May 5, 2016 at 3:27 AM,   wrote:
> Hello Rob,
>
> On 16-05-03 21:30:26, Rob Herring wrote:
>> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
>> > Add device tree binding documentation for Vybrid SoC.

[...]

> Basically being a standalone platform driver, there was need of a 
> compatible
> property to bind on. Introducing a separate device tree node for it's sake
> didn't seem appropriate so the alteration to SoC node's compatible.

 Ah, so you are designing a node around the needs of a Linux specific
 driver. Don't do that. DT describes the h/w and this node is not a h/w
 block.

 Create a platform device based on a matching SOC compatible string
 instead and make your driver find the information it needs directly
 from the relevant nodes like the ROM node.
>>>
>>> That reads like my words a year ago:
>>> https://lkml.org/lkml/2015/5/22/408
>>>
>>> Initially pretty much everything was hard-coded in the driver.
>>>
>>> Arnd then pushed to use more descriptive in the device tree.
>>>
>>> Of course, we should not end up making up relations which are not there
>>> in hardware. We need to find the right balance.
>>>
>>> Here is my suggestion:
>>> 1. Add "fsl,vf610-soc-bus" as compatible string to the soc node, use it
>>> to bind the "soc bus driver" as a platform driver located in driver/soc/
>>
>> I'm not convinced this is a h/w block. This keeps coming up and I
>> think this is a kernel problem, not a DT problem. Let's face it that
>> there are drivers at the SOC level which don't fit into a DT node.
>> They may be the exception, but they are a common exception. My
>> proposal for how to deal with these cases is here[1].
>
> Probably "fsl,vf610-soc" would be better than "fsl,vf610-soc-bus".

But the node in question is just the bus part of the SoC. Things like
cpus are not included.

> But the SoC is definitely a h/w block! Despite all the individual
> silicon in there, I can even touch the SoC ;-)

Can't argue with that...

> But yeah, I understand what you are saying... We model it as a
> container, and do not attribute any specific thing directly to it. But
> aren't there other containers where we bind to? Is it wrong to bind a
> driver to a container, if that driver implements issues concerning that
> level..?

It is supposed to be a bus, not just a container. However, we probably
don't generally fully and accurately model the buses in SoCs so DT
ends up being just a container frequently. If the bus is more than
simple-bus, then it should have some resource that needs to be
controlled to enable the bus.

>
> The two drivers under drivers/soc/ which implement the SoC bus API and
> both use a compatible string on a container level (e.g.
> arm,realview-pb11mp-soc in arch/arm/boot/dts/arm-realview-pb11mp.dts).

I'm not sure Realview and Integrator are models to follow. They are a
bit unique in their h/w design.

>
>>
>> I also think drivers/soc is a mess because it is randomly used or not.
>> IMO, using it should not be at the whim of whomever does SOC support.
>
> Are you talking about random drivers under drivers/soc/ or the ones
> which implement the SoC bus API? I think that is not the same...

The SoC bus API.

> If SoC bus, agreed, it is a mess. Not only its adoption is sparse, the
> specification is also interpreted differently across different SoC's,
> which I brought up in the past:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333765.html
>
> But it exports really useful information to user space, and that has
> real value in practice.

Yes, but the information exported has nothing really to do with a bus.
The "bus" part of it is more sub-classing platform_bus_type for all
platform devices on an SOC. That container may or may not directly
correspond to the bus structure of the SOC as defined in DT. I guess
it is the mixing of really 2 independent things that I don't like and
has made its use sparse. We should perhaps mandate using the bus (for
what I described) and make the information part separate and be able
to populate it from any driver (e.g. an SoC syscon driver which reads
the SOC revision).

Rob

Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

[Guenter Roeck]

Heikki,

On 05/06/2016 01:08 AM, Heikki Krogerus wrote:

Hi,


[ ... ]


I don't have not made any new code for the class driver yet, but I'm
attempting to prepare v2 next week.


Would it make sense to send feedback about v1 now, or should I wait for v2 ?

Thanks,
Guenter

Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

[Guenter Roeck]

Heikki,

On 05/06/2016 01:08 AM, Heikki Krogerus wrote:

Hi,


[ ... ]


I don't have not made any new code for the class driver yet, but I'm
attempting to prepare v2 next week.


Would it make sense to send feedback about v1 now, or should I wait for v2 ?

Thanks,
Guenter

Re: [PATCH 1/6] f2fs: support in batch multi blocks preallocation

[Chao Yu]

On 2016/5/11 10:32, Jaegeuk Kim wrote:
> On Wed, May 11, 2016 at 10:22:05AM +0800, Chao Yu wrote:
>> On 2016/5/11 5:41, Jaegeuk Kim wrote:
>>> +
>>> +   f2fs_wait_on_page_writeback(dn->node_page, NODE, true);
>>> +
>>> +   for (; count > 0; dn->ofs_in_node++) {
>>> +   block_t blkaddr =
>>> +   datablock_addr(dn->node_page, dn->ofs_in_node);
>>> +   if (blkaddr == NULL_ADDR) {
>>> +   dn->data_blkaddr = NEW_ADDR;
>>> +   __set_data_blkaddr(dn);
>>> +   count--;
>>> +   }
>>> +   }
>>
>> Should let ofs_in_node increase to offset where blkaddr = NULL_ADDR in
>> ENOSPC case or increase to end_offset in normal case, right?
> 
> hehe, I could get some errors on this patch. :)
> Finally, I've made a patch which passes xfstests and fsstress.
> Could you find the latest ones?

OK, I will check them.
Thanks for your rework. :)

Thanks,

> 
> http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git/log/?h=dev-test
> 
>>
>> Thanks,
> .
> 

Re: [PATCH 1/6] f2fs: support in batch multi blocks preallocation

[Chao Yu]

On 2016/5/11 10:32, Jaegeuk Kim wrote:
> On Wed, May 11, 2016 at 10:22:05AM +0800, Chao Yu wrote:
>> On 2016/5/11 5:41, Jaegeuk Kim wrote:
>>> +
>>> +   f2fs_wait_on_page_writeback(dn->node_page, NODE, true);
>>> +
>>> +   for (; count > 0; dn->ofs_in_node++) {
>>> +   block_t blkaddr =
>>> +   datablock_addr(dn->node_page, dn->ofs_in_node);
>>> +   if (blkaddr == NULL_ADDR) {
>>> +   dn->data_blkaddr = NEW_ADDR;
>>> +   __set_data_blkaddr(dn);
>>> +   count--;
>>> +   }
>>> +   }
>>
>> Should let ofs_in_node increase to offset where blkaddr = NULL_ADDR in
>> ENOSPC case or increase to end_offset in normal case, right?
> 
> hehe, I could get some errors on this patch. :)
> Finally, I've made a patch which passes xfstests and fsstress.
> Could you find the latest ones?

OK, I will check them.
Thanks for your rework. :)

Thanks,

> 
> http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git/log/?h=dev-test
> 
>>
>> Thanks,
> .
>