[PATCH 05/31] Add blackfin-specific parity functions

[zhaoxiu.zeng]

From: Zeng Zhaoxiu 

Signed-off-by: Zeng Zhaoxiu 
---
 arch/blackfin/include/asm/bitops.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/blackfin/include/asm/bitops.h 
b/arch/blackfin/include/asm/bitops.h
index b298b65..81b078a 100644
--- a/arch/blackfin/include/asm/bitops.h
+++ b/arch/blackfin/include/asm/bitops.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -137,4 +138,34 @@ static inline unsigned int __arch_hweight8(unsigned int w)
return __arch_hweight32(w & 0xff);
 }
 
+/*
+ * parityN: returns the parity of a N-bit word,
+ * i.e. the number of 1-bits in x modulo 2.
+ */
+
+static inline unsigned int __arch_parity32(unsigned int w)
+{
+   return __arch_hweight32(w) & 1;
+}
+
+static inline unsigned int __arch_parity64(__u64 w)
+{
+   return __arch_parity32((unsigned int)(w >> 32) ^ (unsigned int)w);
+}
+
+static inline unsigned int __arch_parity16(unsigned int w)
+{
+   return __arch_parity32(w & 0x);
+}
+
+static inline unsigned int __arch_parity8(unsigned int w)
+{
+   return __arch_parity32(w & 0xff);
+}
+
+static inline unsigned int __arch_parity4(unsigned int w)
+{
+   return __arch_parity32(w & 0xf);
+}
+
 #endif /* _BLACKFIN_BITOPS_H */
-- 
2.5.5

[PATCH 05/31] Add blackfin-specific parity functions

[zhaoxiu.zeng]

From: Zeng Zhaoxiu 

Signed-off-by: Zeng Zhaoxiu 
---
 arch/blackfin/include/asm/bitops.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/blackfin/include/asm/bitops.h 
b/arch/blackfin/include/asm/bitops.h
index b298b65..81b078a 100644
--- a/arch/blackfin/include/asm/bitops.h
+++ b/arch/blackfin/include/asm/bitops.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -137,4 +138,34 @@ static inline unsigned int __arch_hweight8(unsigned int w)
return __arch_hweight32(w & 0xff);
 }
 
+/*
+ * parityN: returns the parity of a N-bit word,
+ * i.e. the number of 1-bits in x modulo 2.
+ */
+
+static inline unsigned int __arch_parity32(unsigned int w)
+{
+   return __arch_hweight32(w) & 1;
+}
+
+static inline unsigned int __arch_parity64(__u64 w)
+{
+   return __arch_parity32((unsigned int)(w >> 32) ^ (unsigned int)w);
+}
+
+static inline unsigned int __arch_parity16(unsigned int w)
+{
+   return __arch_parity32(w & 0x);
+}
+
+static inline unsigned int __arch_parity8(unsigned int w)
+{
+   return __arch_parity32(w & 0xff);
+}
+
+static inline unsigned int __arch_parity4(unsigned int w)
+{
+   return __arch_parity32(w & 0xf);
+}
+
 #endif /* _BLACKFIN_BITOPS_H */
-- 
2.5.5

Re: [PATCH 10/12] ARM: dts: dragonboard-600c: Add on board leds support

[Bjorn Andersson]

On Wed 23 Mar 12:48 PDT 2016, Srinivas Kandagatla wrote:

> This patch adds support to 4 user leds, wlan and bt led on board.
> 
> Signed-off-by: Srinivas Kandagatla 

I'm not fond of the overly complicated names; and I think it should at
least be shortened to "db600c:...".

Tested this on my DB600c, seems to work, except the WiFi/BT triggers,
see comments below.

> + leds {
> + pinctrl-names = "default";
> + pinctrl-0 = <_leds>, <_leds>;
> +
> + compatible = "gpio-leds";
> +
> + led@1 {
> + label = "dragonboard-600c:green:user1";
> + gpios = <_pinmux 3 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> +
> + led@2 {
> + label = "dragonboard-600c:green:user2";
> + gpios = <_pinmux 7 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc0";
> + default-state = "off";
> + };
> +
> + led@3 {
> + label = "dragonboard-600c:green:user3";
> + gpios = <_pinmux 10 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc1";
> + default-state = "off";
> + };
> +
> + led@4 {
> + label = "apq8016-sbc:green:user4";
> + gpios = <_pinmux 11 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "none";
> + default-state = "off";
> + };
> +
> + led@5 {
> + label = "dragonboard-600c:yellow:wlan";
> + gpios = <_mpps 7 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "wlan";

This should either be "phy0rx", "phy0tx", "phy0assoc" or "phy0radio". TX
does not seem to work, so this should be debugged; "assoc" is probably
the one that makes most sense.

> + default-state = "off";
> + };
> +
> + led@6 {
> + label = "dragonboard-600c:blue:bt";
> + gpios = <_mpps 8 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "bt";

This should be "hci0-power".

> + default-state = "off";
> + };
> + };
> +

Regards,
Bjorn

Re: [PATCH 10/12] ARM: dts: dragonboard-600c: Add on board leds support

[Bjorn Andersson]

On Wed 23 Mar 12:48 PDT 2016, Srinivas Kandagatla wrote:

> This patch adds support to 4 user leds, wlan and bt led on board.
> 
> Signed-off-by: Srinivas Kandagatla 

I'm not fond of the overly complicated names; and I think it should at
least be shortened to "db600c:...".

Tested this on my DB600c, seems to work, except the WiFi/BT triggers,
see comments below.

> + leds {
> + pinctrl-names = "default";
> + pinctrl-0 = <_leds>, <_leds>;
> +
> + compatible = "gpio-leds";
> +
> + led@1 {
> + label = "dragonboard-600c:green:user1";
> + gpios = <_pinmux 3 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> +
> + led@2 {
> + label = "dragonboard-600c:green:user2";
> + gpios = <_pinmux 7 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc0";
> + default-state = "off";
> + };
> +
> + led@3 {
> + label = "dragonboard-600c:green:user3";
> + gpios = <_pinmux 10 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc1";
> + default-state = "off";
> + };
> +
> + led@4 {
> + label = "apq8016-sbc:green:user4";
> + gpios = <_pinmux 11 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "none";
> + default-state = "off";
> + };
> +
> + led@5 {
> + label = "dragonboard-600c:yellow:wlan";
> + gpios = <_mpps 7 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "wlan";

This should either be "phy0rx", "phy0tx", "phy0assoc" or "phy0radio". TX
does not seem to work, so this should be debugged; "assoc" is probably
the one that makes most sense.

> + default-state = "off";
> + };
> +
> + led@6 {
> + label = "dragonboard-600c:blue:bt";
> + gpios = <_mpps 8 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "bt";

This should be "hci0-power".

> + default-state = "off";
> + };
> + };
> +

Regards,
Bjorn

Re: [PATCH] drivers : Remove unnecessary void pointer conversions

[Joe Perches]

On Sat, 2016-03-26 at 20:42 -0700, Bhaskar Jupudi wrote:
> Explicit void pointer conversion is unnecessary
> because the conversions to and from a void pointer
> are always implicit in 'C'. Changed two instances 
> of such conversions.

Your patch subject is incorrect, this is for fman
not all of drivers/

If you do one file, you should do them all.

$ git grep -E "\*\s*\)\s*of_get_property" drivers/net/ethernet/freescale/
drivers/net/ethernet/freescale/fman/fman.c: u32_prop = (const u32 
*)of_get_property(fm_node, "cell-index", );
drivers/net/ethernet/freescale/fman/fman.c: u32_prop = (const u32 
*)of_get_property(fm_node,
drivers/net/ethernet/freescale/fman/fman_port.c:u32_prop = (const u32 
*)of_get_property(port_node, "cell-index", );
drivers/net/ethernet/freescale/fman/fman_port.c:u32_prop = 
(const u32 *)of_get_property(port_node,
drivers/net/ethernet/freescale/fman/fman_port.c:u32_prop = 
(const u32 *)of_get_property(port_node,
drivers/net/ethernet/freescale/fman/mac.c:  char_prop = (const char 
*)of_get_property(mac_node,

>  drivers/net/ethernet/freescale/fman/fman.c | 4 ++--

Re: [PATCH] drivers : Remove unnecessary void pointer conversions

[Joe Perches]

On Sat, 2016-03-26 at 20:42 -0700, Bhaskar Jupudi wrote:
> Explicit void pointer conversion is unnecessary
> because the conversions to and from a void pointer
> are always implicit in 'C'. Changed two instances 
> of such conversions.

Your patch subject is incorrect, this is for fman
not all of drivers/

If you do one file, you should do them all.

$ git grep -E "\*\s*\)\s*of_get_property" drivers/net/ethernet/freescale/
drivers/net/ethernet/freescale/fman/fman.c: u32_prop = (const u32 
*)of_get_property(fm_node, "cell-index", );
drivers/net/ethernet/freescale/fman/fman.c: u32_prop = (const u32 
*)of_get_property(fm_node,
drivers/net/ethernet/freescale/fman/fman_port.c:u32_prop = (const u32 
*)of_get_property(port_node, "cell-index", );
drivers/net/ethernet/freescale/fman/fman_port.c:u32_prop = 
(const u32 *)of_get_property(port_node,
drivers/net/ethernet/freescale/fman/fman_port.c:u32_prop = 
(const u32 *)of_get_property(port_node,
drivers/net/ethernet/freescale/fman/mac.c:  char_prop = (const char 
*)of_get_property(mac_node,

>  drivers/net/ethernet/freescale/fman/fman.c | 4 ++--

[PATCH 04/31] Add avr32-specific parity functions

[zhaoxiu.zeng]

From: Zeng Zhaoxiu 

Signed-off-by: Zeng Zhaoxiu 
---
 arch/avr32/include/asm/bitops.h | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/avr32/include/asm/bitops.h b/arch/avr32/include/asm/bitops.h
index 910d537..80d7005 100644
--- a/arch/avr32/include/asm/bitops.h
+++ b/arch/avr32/include/asm/bitops.h
@@ -300,6 +300,38 @@ static inline int ffs(unsigned long word)
 #include 
 #include 
 
+static inline unsigned int __arch_parity4(unsigned int w)
+{
+   w ^= w >> 2;
+   w ^= w >> 1;
+   return w & 1;
+}
+
+static inline unsigned int __arch_parity8(unsigned int w)
+{
+   w ^= w >> 4;
+   return __arch_parity4(w);
+}
+
+static inline unsigned int __arch_parity16(unsigned int w)
+{
+   w ^= w >> 8;
+   return __arch_parity8(w);
+}
+
+static inline unsigned int __arch_parity32(unsigned int w)
+{
+   w ^= w >> 16;
+   return __arch_parity16(w);
+}
+
+static inline unsigned int __arch_parity64(__u64 w)
+{
+   return __arch_parity32((unsigned int)(w >> 32) ^ (unsigned int)w);
+}
+
+#include 
+
 extern unsigned long find_next_zero_bit_le(const void *addr,
unsigned long size, unsigned long offset);
 #define find_next_zero_bit_le find_next_zero_bit_le
-- 
2.5.5

[PATCH 04/31] Add avr32-specific parity functions

[zhaoxiu.zeng]

From: Zeng Zhaoxiu 

Signed-off-by: Zeng Zhaoxiu 
---
 arch/avr32/include/asm/bitops.h | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/avr32/include/asm/bitops.h b/arch/avr32/include/asm/bitops.h
index 910d537..80d7005 100644
--- a/arch/avr32/include/asm/bitops.h
+++ b/arch/avr32/include/asm/bitops.h
@@ -300,6 +300,38 @@ static inline int ffs(unsigned long word)
 #include 
 #include 
 
+static inline unsigned int __arch_parity4(unsigned int w)
+{
+   w ^= w >> 2;
+   w ^= w >> 1;
+   return w & 1;
+}
+
+static inline unsigned int __arch_parity8(unsigned int w)
+{
+   w ^= w >> 4;
+   return __arch_parity4(w);
+}
+
+static inline unsigned int __arch_parity16(unsigned int w)
+{
+   w ^= w >> 8;
+   return __arch_parity8(w);
+}
+
+static inline unsigned int __arch_parity32(unsigned int w)
+{
+   w ^= w >> 16;
+   return __arch_parity16(w);
+}
+
+static inline unsigned int __arch_parity64(__u64 w)
+{
+   return __arch_parity32((unsigned int)(w >> 32) ^ (unsigned int)w);
+}
+
+#include 
+
 extern unsigned long find_next_zero_bit_le(const void *addr,
unsigned long size, unsigned long offset);
 #define find_next_zero_bit_le find_next_zero_bit_le
-- 
2.5.5

[PATCH 03/31] Add alpha-specific parity functions

[zhaoxiu.zeng]

From: Zeng Zhaoxiu 

Signed-off-by: Zeng Zhaoxiu 
---
 arch/alpha/include/asm/bitops.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/alpha/include/asm/bitops.h b/arch/alpha/include/asm/bitops.h
index 4bdfbd4..95a43fa 100644
--- a/arch/alpha/include/asm/bitops.h
+++ b/arch/alpha/include/asm/bitops.h
@@ -421,11 +421,38 @@ static inline unsigned int __arch_hweight8(unsigned int w)
 {
return __arch_hweight64(w & 0xff);
 }
+
+static inline unsigned int __arch_parity64(unsigned long w)
+{
+   return (unsigned int)__kernel_ctpop(w) & 1;
+}
+
+static inline unsigned int __arch_parity32(unsigned int w)
+{
+   return __arch_parity64(w);
+}
+
+static inline unsigned int __arch_parity16(unsigned int w)
+{
+   return __arch_parity64(w & 0x);
+}
+
+static inline unsigned int __arch_parity8(unsigned int w)
+{
+   return __arch_parity64(w & 0xff);
+}
+
+static inline unsigned int __arch_parity4(unsigned int w)
+{
+   return __arch_parity64(w & 0xf);
+}
 #else
 #include 
+#include 
 #endif
 
 #include 
+#include 
 
 #endif /* __KERNEL__ */
 
-- 
2.5.5

[PATCH 03/31] Add alpha-specific parity functions

[zhaoxiu.zeng]

From: Zeng Zhaoxiu 

Signed-off-by: Zeng Zhaoxiu 
---
 arch/alpha/include/asm/bitops.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/alpha/include/asm/bitops.h b/arch/alpha/include/asm/bitops.h
index 4bdfbd4..95a43fa 100644
--- a/arch/alpha/include/asm/bitops.h
+++ b/arch/alpha/include/asm/bitops.h
@@ -421,11 +421,38 @@ static inline unsigned int __arch_hweight8(unsigned int w)
 {
return __arch_hweight64(w & 0xff);
 }
+
+static inline unsigned int __arch_parity64(unsigned long w)
+{
+   return (unsigned int)__kernel_ctpop(w) & 1;
+}
+
+static inline unsigned int __arch_parity32(unsigned int w)
+{
+   return __arch_parity64(w);
+}
+
+static inline unsigned int __arch_parity16(unsigned int w)
+{
+   return __arch_parity64(w & 0x);
+}
+
+static inline unsigned int __arch_parity8(unsigned int w)
+{
+   return __arch_parity64(w & 0xff);
+}
+
+static inline unsigned int __arch_parity4(unsigned int w)
+{
+   return __arch_parity64(w & 0xf);
+}
 #else
 #include 
+#include 
 #endif
 
 #include 
+#include 
 
 #endif /* __KERNEL__ */
 
-- 
2.5.5

[PATCH 02/31] Include generic parity.h in some architectures' bitops.h

[zhaoxiu.zeng]

From: Zeng Zhaoxiu 

Use the generic version.

Signed-off-by: Zeng Zhaoxiu 
---
 arch/arc/include/asm/bitops.h  | 1 +
 arch/arm/include/asm/bitops.h  | 1 +
 arch/arm64/include/asm/bitops.h| 1 +
 arch/c6x/include/asm/bitops.h  | 1 +
 arch/cris/include/asm/bitops.h | 1 +
 arch/frv/include/asm/bitops.h  | 1 +
 arch/h8300/include/asm/bitops.h| 1 +
 arch/hexagon/include/asm/bitops.h  | 1 +
 arch/m32r/include/asm/bitops.h | 1 +
 arch/m68k/include/asm/bitops.h | 1 +
 arch/metag/include/asm/bitops.h| 1 +
 arch/mn10300/include/asm/bitops.h  | 1 +
 arch/openrisc/include/asm/bitops.h | 1 +
 arch/parisc/include/asm/bitops.h   | 1 +
 arch/s390/include/asm/bitops.h | 1 +
 arch/sh/include/asm/bitops.h   | 1 +
 arch/xtensa/include/asm/bitops.h   | 1 +
 17 files changed, 17 insertions(+)

diff --git a/arch/arc/include/asm/bitops.h b/arch/arc/include/asm/bitops.h
index 0352fb8..7967e47 100644
--- a/arch/arc/include/asm/bitops.h
+++ b/arch/arc/include/asm/bitops.h
@@ -370,6 +370,7 @@ static inline __attribute__ ((const)) int __ffs(unsigned 
long x)
 #define ffz(x) __ffs(~(x))
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index e943e6c..99f28a6 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -313,6 +313,7 @@ static inline unsigned long __ffs(unsigned long x)
 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef __ARMEB__
diff --git a/arch/arm64/include/asm/bitops.h b/arch/arm64/include/asm/bitops.h
index 9c19594..eac4965 100644
--- a/arch/arm64/include/asm/bitops.h
+++ b/arch/arm64/include/asm/bitops.h
@@ -44,6 +44,7 @@ extern int test_and_change_bit(int nr, volatile unsigned long 
*p);
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/arch/c6x/include/asm/bitops.h b/arch/c6x/include/asm/bitops.h
index f0ab012..94eb0d1 100644
--- a/arch/c6x/include/asm/bitops.h
+++ b/arch/c6x/include/asm/bitops.h
@@ -87,6 +87,7 @@ static inline int ffs(int x)
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/arch/cris/include/asm/bitops.h b/arch/cris/include/asm/bitops.h
index 8062cb5..06bc246 100644
--- a/arch/cris/include/asm/bitops.h
+++ b/arch/cris/include/asm/bitops.h
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/frv/include/asm/bitops.h b/arch/frv/include/asm/bitops.h
index 0df8e95..f2a7ee8 100644
--- a/arch/frv/include/asm/bitops.h
+++ b/arch/frv/include/asm/bitops.h
@@ -314,6 +314,7 @@ int __ilog2_u64(u64 n)
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/arch/h8300/include/asm/bitops.h b/arch/h8300/include/asm/bitops.h
index 05999ab..e392db2 100644
--- a/arch/h8300/include/asm/bitops.h
+++ b/arch/h8300/include/asm/bitops.h
@@ -172,6 +172,7 @@ static inline unsigned long __ffs(unsigned long word)
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/hexagon/include/asm/bitops.h 
b/arch/hexagon/include/asm/bitops.h
index 5e4a59b..2df614e 100644
--- a/arch/hexagon/include/asm/bitops.h
+++ b/arch/hexagon/include/asm/bitops.h
@@ -290,6 +290,7 @@ static inline unsigned long __fls(unsigned long word)
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/m32r/include/asm/bitops.h b/arch/m32r/include/asm/bitops.h
index 86ba2b4..e3cf46b 100644
--- a/arch/m32r/include/asm/bitops.h
+++ b/arch/m32r/include/asm/bitops.h
@@ -259,6 +259,7 @@ static __inline__ int test_and_change_bit(int nr, volatile 
void * addr)
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #endif /* __KERNEL__ */
diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/include/asm/bitops.h
index b4a9b0d..fd673ea 100644
--- a/arch/m68k/include/asm/bitops.h
+++ b/arch/m68k/include/asm/bitops.h
@@ -519,6 +519,7 @@ static inline int __fls(int x)
 #include 
 #include 
 #include 
+#include 
 #include 
 #endif /* __KERNEL__ */
 
diff --git a/arch/metag/include/asm/bitops.h b/arch/metag/include/asm/bitops.h
index 2671134..ad13087 100644
--- a/arch/metag/include/asm/bitops.h
+++ b/arch/metag/include/asm/bitops.h
@@ -118,6 +118,7 @@ static inline int test_and_change_bit(unsigned int bit,
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/mn10300/include/asm/bitops.h 
b/arch/mn10300/include/asm/bitops.h
index fe6f8e2..60761b7 100644
--- a/arch/mn10300/include/asm/bitops.h
+++ b/arch/mn10300/include/asm/bitops.h
@@ -225,6 +225,7 @@ int ffs(int x)
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/openrisc/include/asm/bitops.h 
b/arch/openrisc/include/asm/bitops.h
index 3003cda..8c97642 100644
--- a/arch/openrisc/include/asm/bitops.h
+++ b/arch/openrisc/include/asm/bitops.h
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git 

[PATCH 02/31] Include generic parity.h in some architectures' bitops.h

[zhaoxiu.zeng]

From: Zeng Zhaoxiu 

Use the generic version.

Signed-off-by: Zeng Zhaoxiu 
---
 arch/arc/include/asm/bitops.h  | 1 +
 arch/arm/include/asm/bitops.h  | 1 +
 arch/arm64/include/asm/bitops.h| 1 +
 arch/c6x/include/asm/bitops.h  | 1 +
 arch/cris/include/asm/bitops.h | 1 +
 arch/frv/include/asm/bitops.h  | 1 +
 arch/h8300/include/asm/bitops.h| 1 +
 arch/hexagon/include/asm/bitops.h  | 1 +
 arch/m32r/include/asm/bitops.h | 1 +
 arch/m68k/include/asm/bitops.h | 1 +
 arch/metag/include/asm/bitops.h| 1 +
 arch/mn10300/include/asm/bitops.h  | 1 +
 arch/openrisc/include/asm/bitops.h | 1 +
 arch/parisc/include/asm/bitops.h   | 1 +
 arch/s390/include/asm/bitops.h | 1 +
 arch/sh/include/asm/bitops.h   | 1 +
 arch/xtensa/include/asm/bitops.h   | 1 +
 17 files changed, 17 insertions(+)

diff --git a/arch/arc/include/asm/bitops.h b/arch/arc/include/asm/bitops.h
index 0352fb8..7967e47 100644
--- a/arch/arc/include/asm/bitops.h
+++ b/arch/arc/include/asm/bitops.h
@@ -370,6 +370,7 @@ static inline __attribute__ ((const)) int __ffs(unsigned 
long x)
 #define ffz(x) __ffs(~(x))
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index e943e6c..99f28a6 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -313,6 +313,7 @@ static inline unsigned long __ffs(unsigned long x)
 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef __ARMEB__
diff --git a/arch/arm64/include/asm/bitops.h b/arch/arm64/include/asm/bitops.h
index 9c19594..eac4965 100644
--- a/arch/arm64/include/asm/bitops.h
+++ b/arch/arm64/include/asm/bitops.h
@@ -44,6 +44,7 @@ extern int test_and_change_bit(int nr, volatile unsigned long 
*p);
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/arch/c6x/include/asm/bitops.h b/arch/c6x/include/asm/bitops.h
index f0ab012..94eb0d1 100644
--- a/arch/c6x/include/asm/bitops.h
+++ b/arch/c6x/include/asm/bitops.h
@@ -87,6 +87,7 @@ static inline int ffs(int x)
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/arch/cris/include/asm/bitops.h b/arch/cris/include/asm/bitops.h
index 8062cb5..06bc246 100644
--- a/arch/cris/include/asm/bitops.h
+++ b/arch/cris/include/asm/bitops.h
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/frv/include/asm/bitops.h b/arch/frv/include/asm/bitops.h
index 0df8e95..f2a7ee8 100644
--- a/arch/frv/include/asm/bitops.h
+++ b/arch/frv/include/asm/bitops.h
@@ -314,6 +314,7 @@ int __ilog2_u64(u64 n)
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/arch/h8300/include/asm/bitops.h b/arch/h8300/include/asm/bitops.h
index 05999ab..e392db2 100644
--- a/arch/h8300/include/asm/bitops.h
+++ b/arch/h8300/include/asm/bitops.h
@@ -172,6 +172,7 @@ static inline unsigned long __ffs(unsigned long word)
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/hexagon/include/asm/bitops.h 
b/arch/hexagon/include/asm/bitops.h
index 5e4a59b..2df614e 100644
--- a/arch/hexagon/include/asm/bitops.h
+++ b/arch/hexagon/include/asm/bitops.h
@@ -290,6 +290,7 @@ static inline unsigned long __fls(unsigned long word)
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/m32r/include/asm/bitops.h b/arch/m32r/include/asm/bitops.h
index 86ba2b4..e3cf46b 100644
--- a/arch/m32r/include/asm/bitops.h
+++ b/arch/m32r/include/asm/bitops.h
@@ -259,6 +259,7 @@ static __inline__ int test_and_change_bit(int nr, volatile 
void * addr)
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #endif /* __KERNEL__ */
diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/include/asm/bitops.h
index b4a9b0d..fd673ea 100644
--- a/arch/m68k/include/asm/bitops.h
+++ b/arch/m68k/include/asm/bitops.h
@@ -519,6 +519,7 @@ static inline int __fls(int x)
 #include 
 #include 
 #include 
+#include 
 #include 
 #endif /* __KERNEL__ */
 
diff --git a/arch/metag/include/asm/bitops.h b/arch/metag/include/asm/bitops.h
index 2671134..ad13087 100644
--- a/arch/metag/include/asm/bitops.h
+++ b/arch/metag/include/asm/bitops.h
@@ -118,6 +118,7 @@ static inline int test_and_change_bit(unsigned int bit,
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/mn10300/include/asm/bitops.h 
b/arch/mn10300/include/asm/bitops.h
index fe6f8e2..60761b7 100644
--- a/arch/mn10300/include/asm/bitops.h
+++ b/arch/mn10300/include/asm/bitops.h
@@ -225,6 +225,7 @@ int ffs(int x)
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/openrisc/include/asm/bitops.h 
b/arch/openrisc/include/asm/bitops.h
index 3003cda..8c97642 100644
--- a/arch/openrisc/include/asm/bitops.h
+++ b/arch/openrisc/include/asm/bitops.h
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/arch/parisc/include/asm/bitops.h b/arch/parisc/include/asm/bitops.h

[PATCH] Documentation/IRQ-domain.txt: Document irq_domain_create_{linear, tree}

[Jianyu Zhan]

They have the same functionalities as irq_domain_add_{linear, tree},
except fro accepting different first argument.

Signed-off-by: Jianyu Zhan 
---
v1->v2:
   Fix spelling error.

 Documentation/IRQ-domain.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
index 8d990bd..89dda22 100644
--- a/Documentation/IRQ-domain.txt
+++ b/Documentation/IRQ-domain.txt
@@ -70,6 +70,7 @@ of the reverse map types are described below:
 
  Linear 
 irq_domain_add_linear()
+irq_domain_create_linear()
 
 The linear reverse map maintains a fixed size table indexed by the
 hwirq number.  When a hwirq is mapped, an irq_desc is allocated for
@@ -81,10 +82,16 @@ map are fixed time lookup for IRQ numbers, and irq_descs 
are only
 allocated for in-use IRQs.  The disadvantage is that the table must be
 as large as the largest possible hwirq number.
 
+irq_domain_add_linear() and irq_domain_create_linear() are functionally
+equivalent, except for the first argument is different - the former
+accepts an Open Firmware specific 'struct device_node', while the latter
+accepts a more general abstraction 'struct fwnode_handle'.
+
 The majority of drivers should use the linear map.
 
  Tree 
 irq_domain_add_tree()
+irq_domain_create_tree()
 
 The irq_domain maintains a radix tree map from hwirq numbers to Linux
 IRQs.  When an hwirq is mapped, an irq_desc is allocated and the
@@ -95,6 +102,11 @@ since it doesn't need to allocate a table as large as the 
largest
 hwirq number.  The disadvantage is that hwirq to IRQ number lookup is
 dependent on how many entries are in the table.
 
+irq_domain_add_tree() and irq_domain_create_tree() are functionally
+equivalent, except for the first argument is different - the former
+accepts an Open Firmware specific 'struct device_node', while the latter
+accepts a more general abstraction 'struct fwnode_handle'.
+
 Very few drivers should need this mapping.
 
  No Map ===-
-- 
2.4.3

[PATCH] Documentation/IRQ-domain.txt: Document irq_domain_create_{linear, tree}

[Jianyu Zhan]

They have the same functionalities as irq_domain_add_{linear, tree},
except fro accepting different first argument.

Signed-off-by: Jianyu Zhan 
---
v1->v2:
   Fix spelling error.

 Documentation/IRQ-domain.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
index 8d990bd..89dda22 100644
--- a/Documentation/IRQ-domain.txt
+++ b/Documentation/IRQ-domain.txt
@@ -70,6 +70,7 @@ of the reverse map types are described below:
 
  Linear 
 irq_domain_add_linear()
+irq_domain_create_linear()
 
 The linear reverse map maintains a fixed size table indexed by the
 hwirq number.  When a hwirq is mapped, an irq_desc is allocated for
@@ -81,10 +82,16 @@ map are fixed time lookup for IRQ numbers, and irq_descs 
are only
 allocated for in-use IRQs.  The disadvantage is that the table must be
 as large as the largest possible hwirq number.
 
+irq_domain_add_linear() and irq_domain_create_linear() are functionally
+equivalent, except for the first argument is different - the former
+accepts an Open Firmware specific 'struct device_node', while the latter
+accepts a more general abstraction 'struct fwnode_handle'.
+
 The majority of drivers should use the linear map.
 
  Tree 
 irq_domain_add_tree()
+irq_domain_create_tree()
 
 The irq_domain maintains a radix tree map from hwirq numbers to Linux
 IRQs.  When an hwirq is mapped, an irq_desc is allocated and the
@@ -95,6 +102,11 @@ since it doesn't need to allocate a table as large as the 
largest
 hwirq number.  The disadvantage is that hwirq to IRQ number lookup is
 dependent on how many entries are in the table.
 
+irq_domain_add_tree() and irq_domain_create_tree() are functionally
+equivalent, except for the first argument is different - the former
+accepts an Open Firmware specific 'struct device_node', while the latter
+accepts a more general abstraction 'struct fwnode_handle'.
+
 Very few drivers should need this mapping.
 
  No Map ===-
-- 
2.4.3

drivers/media/i2c/msp3400-kthreads.o: warning: objtool: msp3400c_set_audmode()+0x12ca: function has unreachable instruction

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f55532a0c0b8bb6148f4e07853b876ef73bc69ca
commit: d4883d5d6b146fd65f762c462b2c6d4a327c7d50 objtool: Enable stack metadata 
validation on 64-bit x86
date:   4 weeks ago
config: x86_64-randconfig-r0-03270825 (attached as .config)
reproduce:
git checkout d4883d5d6b146fd65f762c462b2c6d4a327c7d50
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
>> msp3400c_set_audmode()+0x12ca: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12d1: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12db: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12de: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12e2: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12e6: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12e9: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12ec: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12ef: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12f1: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12f7: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12f9: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12ff: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x1304: function has unreachable instruction

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


.config.gz
Description: Binary data

drivers/media/i2c/msp3400-kthreads.o: warning: objtool: msp3400c_set_audmode()+0x12ca: function has unreachable instruction

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f55532a0c0b8bb6148f4e07853b876ef73bc69ca
commit: d4883d5d6b146fd65f762c462b2c6d4a327c7d50 objtool: Enable stack metadata 
validation on 64-bit x86
date:   4 weeks ago
config: x86_64-randconfig-r0-03270825 (attached as .config)
reproduce:
git checkout d4883d5d6b146fd65f762c462b2c6d4a327c7d50
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
>> msp3400c_set_audmode()+0x12ca: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12d1: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12db: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12de: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12e2: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12e6: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12e9: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12ec: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12ef: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12f1: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12f7: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12f9: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x12ff: function has unreachable instruction
   drivers/media/i2c/msp3400-kthreads.o: warning: objtool: 
msp3400c_set_audmode()+0x1304: function has unreachable instruction

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


.config.gz
Description: Binary data

[PATCH] drivers : Remove unnecessary void pointer conversions

[Bhaskar Jupudi]

Explicit void pointer conversion is unnecessary
because the conversions to and from a void pointer
are always implicit in 'C'. Changed two instances 
of such conversions.


Signed-off-by: Bhaskar Jupudi 
---
This patch is based on Kernel Janitors To-Do list

 drivers/net/ethernet/freescale/fman/fman.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman.c 
b/drivers/net/ethernet/freescale/fman/fman.c
index 623aa1c..8719f7b 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2668,7 +2668,7 @@ static struct fman *read_dts_node(struct platform_device 
*of_dev)
 
fm_node = of_node_get(of_dev->dev.of_node);
 
-   u32_prop = (const u32 *)of_get_property(fm_node, "cell-index", );
+   u32_prop = of_get_property(fm_node, "cell-index", );
if (!u32_prop) {
dev_err(_dev->dev, "%s: of_get_property(%s, cell-index) 
failed\n",
__func__, fm_node->full_name);
@@ -2724,7 +2724,7 @@ static struct fman *read_dts_node(struct platform_device 
*of_dev)
/* Rounding to MHz */
fman->dts_params.clk_freq = DIV_ROUND_UP(clk_rate, 100);
 
-   u32_prop = (const u32 *)of_get_property(fm_node,
+   u32_prop = of_get_property(fm_node,
"fsl,qman-channel-range",
);
if (!u32_prop) {
-- 
2.5.0

[PATCH] drivers : Remove unnecessary void pointer conversions

[Bhaskar Jupudi]

Explicit void pointer conversion is unnecessary
because the conversions to and from a void pointer
are always implicit in 'C'. Changed two instances 
of such conversions.


Signed-off-by: Bhaskar Jupudi 
---
This patch is based on Kernel Janitors To-Do list

 drivers/net/ethernet/freescale/fman/fman.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman.c 
b/drivers/net/ethernet/freescale/fman/fman.c
index 623aa1c..8719f7b 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2668,7 +2668,7 @@ static struct fman *read_dts_node(struct platform_device 
*of_dev)
 
fm_node = of_node_get(of_dev->dev.of_node);
 
-   u32_prop = (const u32 *)of_get_property(fm_node, "cell-index", );
+   u32_prop = of_get_property(fm_node, "cell-index", );
if (!u32_prop) {
dev_err(_dev->dev, "%s: of_get_property(%s, cell-index) 
failed\n",
__func__, fm_node->full_name);
@@ -2724,7 +2724,7 @@ static struct fman *read_dts_node(struct platform_device 
*of_dev)
/* Rounding to MHz */
fman->dts_params.clk_freq = DIV_ROUND_UP(clk_rate, 100);
 
-   u32_prop = (const u32 *)of_get_property(fm_node,
+   u32_prop = of_get_property(fm_node,
"fsl,qman-channel-range",
);
if (!u32_prop) {
-- 
2.5.0

Re: [PATCH 01/31] bitops: add parity functions

[zhaoxiu.zeng]

On 2016/3/24 16:38, Denys Vlasenko wrote:
> On 03/24/2016 04:03 AM, Zhaoxiu Zeng wrote:
>> +/*
>> + * Type invariant interface to the compile time constant parity functions.
>> + */
>> +#define PARITY(w)PARITY64((u64)w)
> 
> Can result in incorrect expansion of w. Should be PARITY64((u64)(w))
> 
> .
> 
Thanks. The new version has been fixed.


Signed-off-by: Zeng Zhaoxiu 
---
 include/asm-generic/bitops.h  |  1 +
 include/asm-generic/bitops/arch_parity.h  | 39 +++
 include/asm-generic/bitops/const_parity.h | 36 
 include/asm-generic/bitops/parity.h   |  7 ++
 include/linux/bitops.h|  5 
 5 files changed, 88 insertions(+)
 create mode 100644 include/asm-generic/bitops/arch_parity.h
 create mode 100644 include/asm-generic/bitops/const_parity.h
 create mode 100644 include/asm-generic/bitops/parity.h

diff --git a/include/asm-generic/bitops.h b/include/asm-generic/bitops.h
index dcdcacf..d85722f 100644
--- a/include/asm-generic/bitops.h
+++ b/include/asm-generic/bitops.h
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/include/asm-generic/bitops/arch_parity.h 
b/include/asm-generic/bitops/arch_parity.h
new file mode 100644
index 000..cddc555
--- /dev/null
+++ b/include/asm-generic/bitops/arch_parity.h
@@ -0,0 +1,39 @@
+#ifndef _ASM_GENERIC_BITOPS_ARCH_PARITY_H_
+#define _ASM_GENERIC_BITOPS_ARCH_PARITY_H_
+
+#include 
+
+/*
+ * Refrence to 
'https://graphics.stanford.edu/~seander/bithacks.html#ParityParallel'.
+ */
+
+static inline unsigned int __arch_parity4(unsigned int w)
+{
+   w &= 0xf;
+   return (0x6996 >> w) & 1;
+}
+
+static inline unsigned int __arch_parity8(unsigned int w)
+{
+   w ^= w >> 4;
+   return __arch_parity4(w);
+}
+
+static inline unsigned int __arch_parity16(unsigned int w)
+{
+   w ^= w >> 8;
+   return __arch_parity8(w);
+}
+
+static inline unsigned int __arch_parity32(unsigned int w)
+{
+   w ^= w >> 16;
+   return __arch_parity16(w);
+}
+
+static inline unsigned int __arch_parity64(__u64 w)
+{
+   return __arch_parity32((unsigned int)(w >> 32) ^ (unsigned int)w);
+}
+
+#endif /* _ASM_GENERIC_BITOPS_ARCH_PARITY_H_ */
diff --git a/include/asm-generic/bitops/const_parity.h 
b/include/asm-generic/bitops/const_parity.h
new file mode 100644
index 000..6af7987
--- /dev/null
+++ b/include/asm-generic/bitops/const_parity.h
@@ -0,0 +1,36 @@
+#ifndef _ASM_GENERIC_BITOPS_CONST_PARITY_H_
+#define _ASM_GENERIC_BITOPS_CONST_PARITY_H_
+
+/*
+ * Compile time versions of __arch_parityN()
+ */
+#define __const_parity4(w)   ((0x6996 >> ((w) & 0xf)) & 1)
+#define __const_parity8(w)   (__const_parity4((w) ^ ((w) >> 4)))
+#define __const_parity16(w)  (__const_parity8((w) ^ ((w) >> 8)))
+#define __const_parity32(w)  (__const_parity16((w) ^ ((w) >> 16)))
+#define __const_parity64(w)  (__const_parity32((w) ^ ((w) >> 32)))
+
+/*
+ * Generic interface.
+ */
+#define parity4(w)   (__builtin_constant_p(w) ? __const_parity4(w)  : 
__arch_parity4(w))
+#define parity8(w)   (__builtin_constant_p(w) ? __const_parity8(w)  : 
__arch_parity8(w))
+#define parity16(w)  (__builtin_constant_p(w) ? __const_parity16(w) : 
__arch_parity16(w))
+#define parity32(w)  (__builtin_constant_p(w) ? __const_parity32(w) : 
__arch_parity32(w))
+#define parity64(w)  (__builtin_constant_p(w) ? __const_parity64(w) : 
__arch_parity64(w))
+
+/*
+ * Interface for known constant arguments
+ */
+#define PARITY4(w)   (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity4(w))
+#define PARITY8(w)   (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity8(w))
+#define PARITY16(w)  (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity16(w))
+#define PARITY32(w)  (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity32(w))
+#define PARITY64(w)  (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity64(w))
+
+/*
+ * Type invariant interface to the compile time constant parity functions.
+ */
+#define PARITY(w)PARITY64((u64)(w))
+
+#endif /* _ASM_GENERIC_BITOPS_CONST_PARITY_H_ */
diff --git a/include/asm-generic/bitops/parity.h 
b/include/asm-generic/bitops/parity.h
new file mode 100644
index 000..a91dce7
--- /dev/null
+++ b/include/asm-generic/bitops/parity.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_GENERIC_BITOPS_PARITY_H_
+#define _ASM_GENERIC_BITOPS_PARITY_H_
+
+#include 
+#include 
+
+#endif /* _ASM_GENERIC_BITOPS_PARITY_H_ */
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index defeaac..8952f88 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -80,6 +80,11 @@ static __always_inline unsigned long hweight_long(unsigned 
long w)
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
 }
 
+static __always_inline unsigned int parity_long(unsigned long w)
+{
+   return sizeof(w) == 4 ? parity32(w) : parity64(w);
+}
+
 /**
  * rol64 - rotate a 64-bit value 

Re: [PATCH 01/31] bitops: add parity functions

[zhaoxiu.zeng]

On 2016/3/24 16:38, Denys Vlasenko wrote:
> On 03/24/2016 04:03 AM, Zhaoxiu Zeng wrote:
>> +/*
>> + * Type invariant interface to the compile time constant parity functions.
>> + */
>> +#define PARITY(w)PARITY64((u64)w)
> 
> Can result in incorrect expansion of w. Should be PARITY64((u64)(w))
> 
> .
> 
Thanks. The new version has been fixed.


Signed-off-by: Zeng Zhaoxiu 
---
 include/asm-generic/bitops.h  |  1 +
 include/asm-generic/bitops/arch_parity.h  | 39 +++
 include/asm-generic/bitops/const_parity.h | 36 
 include/asm-generic/bitops/parity.h   |  7 ++
 include/linux/bitops.h|  5 
 5 files changed, 88 insertions(+)
 create mode 100644 include/asm-generic/bitops/arch_parity.h
 create mode 100644 include/asm-generic/bitops/const_parity.h
 create mode 100644 include/asm-generic/bitops/parity.h

diff --git a/include/asm-generic/bitops.h b/include/asm-generic/bitops.h
index dcdcacf..d85722f 100644
--- a/include/asm-generic/bitops.h
+++ b/include/asm-generic/bitops.h
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/include/asm-generic/bitops/arch_parity.h 
b/include/asm-generic/bitops/arch_parity.h
new file mode 100644
index 000..cddc555
--- /dev/null
+++ b/include/asm-generic/bitops/arch_parity.h
@@ -0,0 +1,39 @@
+#ifndef _ASM_GENERIC_BITOPS_ARCH_PARITY_H_
+#define _ASM_GENERIC_BITOPS_ARCH_PARITY_H_
+
+#include 
+
+/*
+ * Refrence to 
'https://graphics.stanford.edu/~seander/bithacks.html#ParityParallel'.
+ */
+
+static inline unsigned int __arch_parity4(unsigned int w)
+{
+   w &= 0xf;
+   return (0x6996 >> w) & 1;
+}
+
+static inline unsigned int __arch_parity8(unsigned int w)
+{
+   w ^= w >> 4;
+   return __arch_parity4(w);
+}
+
+static inline unsigned int __arch_parity16(unsigned int w)
+{
+   w ^= w >> 8;
+   return __arch_parity8(w);
+}
+
+static inline unsigned int __arch_parity32(unsigned int w)
+{
+   w ^= w >> 16;
+   return __arch_parity16(w);
+}
+
+static inline unsigned int __arch_parity64(__u64 w)
+{
+   return __arch_parity32((unsigned int)(w >> 32) ^ (unsigned int)w);
+}
+
+#endif /* _ASM_GENERIC_BITOPS_ARCH_PARITY_H_ */
diff --git a/include/asm-generic/bitops/const_parity.h 
b/include/asm-generic/bitops/const_parity.h
new file mode 100644
index 000..6af7987
--- /dev/null
+++ b/include/asm-generic/bitops/const_parity.h
@@ -0,0 +1,36 @@
+#ifndef _ASM_GENERIC_BITOPS_CONST_PARITY_H_
+#define _ASM_GENERIC_BITOPS_CONST_PARITY_H_
+
+/*
+ * Compile time versions of __arch_parityN()
+ */
+#define __const_parity4(w)   ((0x6996 >> ((w) & 0xf)) & 1)
+#define __const_parity8(w)   (__const_parity4((w) ^ ((w) >> 4)))
+#define __const_parity16(w)  (__const_parity8((w) ^ ((w) >> 8)))
+#define __const_parity32(w)  (__const_parity16((w) ^ ((w) >> 16)))
+#define __const_parity64(w)  (__const_parity32((w) ^ ((w) >> 32)))
+
+/*
+ * Generic interface.
+ */
+#define parity4(w)   (__builtin_constant_p(w) ? __const_parity4(w)  : 
__arch_parity4(w))
+#define parity8(w)   (__builtin_constant_p(w) ? __const_parity8(w)  : 
__arch_parity8(w))
+#define parity16(w)  (__builtin_constant_p(w) ? __const_parity16(w) : 
__arch_parity16(w))
+#define parity32(w)  (__builtin_constant_p(w) ? __const_parity32(w) : 
__arch_parity32(w))
+#define parity64(w)  (__builtin_constant_p(w) ? __const_parity64(w) : 
__arch_parity64(w))
+
+/*
+ * Interface for known constant arguments
+ */
+#define PARITY4(w)   (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity4(w))
+#define PARITY8(w)   (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity8(w))
+#define PARITY16(w)  (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity16(w))
+#define PARITY32(w)  (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity32(w))
+#define PARITY64(w)  (BUILD_BUG_ON_ZERO(!__builtin_constant_p(w)) + 
__const_parity64(w))
+
+/*
+ * Type invariant interface to the compile time constant parity functions.
+ */
+#define PARITY(w)PARITY64((u64)(w))
+
+#endif /* _ASM_GENERIC_BITOPS_CONST_PARITY_H_ */
diff --git a/include/asm-generic/bitops/parity.h 
b/include/asm-generic/bitops/parity.h
new file mode 100644
index 000..a91dce7
--- /dev/null
+++ b/include/asm-generic/bitops/parity.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_GENERIC_BITOPS_PARITY_H_
+#define _ASM_GENERIC_BITOPS_PARITY_H_
+
+#include 
+#include 
+
+#endif /* _ASM_GENERIC_BITOPS_PARITY_H_ */
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index defeaac..8952f88 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -80,6 +80,11 @@ static __always_inline unsigned long hweight_long(unsigned 
long w)
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
 }
 
+static __always_inline unsigned int parity_long(unsigned long w)
+{
+   return sizeof(w) == 4 ? parity32(w) : parity64(w);
+}
+
 /**
  * rol64 - rotate a 64-bit value left
  * @word: value to 

Re: [PATCH net-next 4/7] net: dsa: mv88e6xxx: fix ATU FID access for 6185

[Andrew Lunn]

On Sat, Mar 26, 2016 at 09:59:40PM -0400, Vivien Didelot wrote:
> The 6185 family does not have a ATU FID register. It splits it in the
> ATU Control register and the ATU Operation.

Looking at the reference code, the following devices have a FID
register:
( DEV_88E6097_FAMILY | DEV_88E6165_FAMILY | DEV_88E6351_FAMILY | 
  DEV_88E6352_FAMILY)

If there are 256 databases, it gets split across the two registers.

If there are only 64, it all goes in the ATU operation.

   Andrew

> 
> Add 6185 support for FID (a.k.a. DBNum) in ATU commands.
> 
> Signed-off-by: Vivien Didelot 
> ---
>  drivers/net/dsa/mv88e6xxx.c | 14 ++
>  drivers/net/dsa/mv88e6xxx.h |  2 +-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> index df3f219..4b3c466 100644
> --- a/drivers/net/dsa/mv88e6xxx.c
> +++ b/drivers/net/dsa/mv88e6xxx.c
> @@ -961,6 +961,20 @@ static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 
> fid, u16 cmd)
>   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
>   if (ret < 0)
>   return ret;
> + } else if (mv88e6xxx_6185_family(ds)) {
> + /* ATU DBNum[7:4] are located in ATU Control 15:12 */
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL);
> + if (ret < 0)
> + return ret;
> +
> + ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL,
> +(ret & 0xfff) |
> +((fid << 8) & 0xf000));
> + if (ret < 0)
> + return ret;
> +
> + /* ATU DBNum[3:0] are located in ATU Operation 3:0 */
> + cmd |= fid & 0xf;
>   } else {
>   return -EOPNOTSUPP;
>   }
> diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
> index febab76..94d3cb3 100644
> --- a/drivers/net/dsa/mv88e6xxx.h
> +++ b/drivers/net/dsa/mv88e6xxx.h
> @@ -366,7 +366,7 @@ struct mv88e6xxx_switch_id {
>  };
>  
>  struct mv88e6xxx_atu_entry {
> - u16 fid;
> + u16 fid; /* 8-bit DBNum in 88E6185 family */
>   u8  state;
>   booltrunk;
>   u16 portv_trunkid;
> -- 
> 2.7.4
> 

Re: [PATCH net-next 4/7] net: dsa: mv88e6xxx: fix ATU FID access for 6185

[Andrew Lunn]

On Sat, Mar 26, 2016 at 09:59:40PM -0400, Vivien Didelot wrote:
> The 6185 family does not have a ATU FID register. It splits it in the
> ATU Control register and the ATU Operation.

Looking at the reference code, the following devices have a FID
register:
( DEV_88E6097_FAMILY | DEV_88E6165_FAMILY | DEV_88E6351_FAMILY | 
  DEV_88E6352_FAMILY)

If there are 256 databases, it gets split across the two registers.

If there are only 64, it all goes in the ATU operation.

   Andrew

> 
> Add 6185 support for FID (a.k.a. DBNum) in ATU commands.
> 
> Signed-off-by: Vivien Didelot 
> ---
>  drivers/net/dsa/mv88e6xxx.c | 14 ++
>  drivers/net/dsa/mv88e6xxx.h |  2 +-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> index df3f219..4b3c466 100644
> --- a/drivers/net/dsa/mv88e6xxx.c
> +++ b/drivers/net/dsa/mv88e6xxx.c
> @@ -961,6 +961,20 @@ static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 
> fid, u16 cmd)
>   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
>   if (ret < 0)
>   return ret;
> + } else if (mv88e6xxx_6185_family(ds)) {
> + /* ATU DBNum[7:4] are located in ATU Control 15:12 */
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL);
> + if (ret < 0)
> + return ret;
> +
> + ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL,
> +(ret & 0xfff) |
> +((fid << 8) & 0xf000));
> + if (ret < 0)
> + return ret;
> +
> + /* ATU DBNum[3:0] are located in ATU Operation 3:0 */
> + cmd |= fid & 0xf;
>   } else {
>   return -EOPNOTSUPP;
>   }
> diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
> index febab76..94d3cb3 100644
> --- a/drivers/net/dsa/mv88e6xxx.h
> +++ b/drivers/net/dsa/mv88e6xxx.h
> @@ -366,7 +366,7 @@ struct mv88e6xxx_switch_id {
>  };
>  
>  struct mv88e6xxx_atu_entry {
> - u16 fid;
> + u16 fid; /* 8-bit DBNum in 88E6185 family */
>   u8  state;
>   booltrunk;
>   u16 portv_trunkid;
> -- 
> 2.7.4
> 

Re: [PATCH net-next 2/7] net: dsa: mv88e6xxx: 6185 has only 256 FDBs

[Andrew Lunn]

On Sat, Mar 26, 2016 at 09:59:38PM -0400, Vivien Didelot wrote:
> The 6185 family has only 256 indexable address databases, while the
> others (such as 6352) have 4095. Explicit and use these maximum values
> in the _mv88e6xxx_fid_new function.

Hi Vivien

I've been looking at the Marvell reference code, in particular, the
function gfdbGetAtuAllCount().

The following device have 16 databases.

( DEV_88E6021 | DEV_88E6060 | DEV_88E6063 | \
  DEV_FH_VPN |  DEV_88E6083 |  DEV_88E6183 | DEV_88E6093 | DEV_88E6061 )

The following device have 64 databases.
( DEV_88E6065 )

The following devices have 256 databases
( DEV_88E6095_FAMILY | DEV_88E6185_FAMILY )

And the following devices have 4096
( DEV_88E6097_FAMILY | DEV_88E6165_FAMILY | DEV_88E6\
  351_FAMILY| DEV_88E6352_FAMILY )

  Andrew

Re: [PATCH net-next 2/7] net: dsa: mv88e6xxx: 6185 has only 256 FDBs

[Andrew Lunn]

On Sat, Mar 26, 2016 at 09:59:38PM -0400, Vivien Didelot wrote:
> The 6185 family has only 256 indexable address databases, while the
> others (such as 6352) have 4095. Explicit and use these maximum values
> in the _mv88e6xxx_fid_new function.

Hi Vivien

I've been looking at the Marvell reference code, in particular, the
function gfdbGetAtuAllCount().

The following device have 16 databases.

( DEV_88E6021 | DEV_88E6060 | DEV_88E6063 | \
  DEV_FH_VPN |  DEV_88E6083 |  DEV_88E6183 | DEV_88E6093 | DEV_88E6061 )

The following device have 64 databases.
( DEV_88E6065 )

The following devices have 256 databases
( DEV_88E6095_FAMILY | DEV_88E6185_FAMILY )

And the following devices have 4096
( DEV_88E6097_FAMILY | DEV_88E6165_FAMILY | DEV_88E6\
  351_FAMILY| DEV_88E6352_FAMILY )

  Andrew

fs/xfs/xfs_ondisk.h:86:2: error: call to '__compiletime_assert_86' declared with attribute error: XFS: sizeof(xfs_dir2_data_unused_t) is wrong, expected 6

[kbuild test robot]

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f55532a0c0b8bb6148f4e07853b876ef73bc69ca
commit: ab9d1e4f7b0217948a3b35a64178602ab30ff45d Merge branch 
'xfs-misc-fixes-4.6-3' into for-next
date:   3 weeks ago
config: openrisc-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ab9d1e4f7b0217948a3b35a64178602ab30ff45d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from fs/xfs/xfs_super.c:48:0:
   In function 'xfs_check_ondisk_structs',
   inlined from 'init_xfs_fs' at fs/xfs/xfs_super.c:1862:26:
>> fs/xfs/xfs_ondisk.h:86:2: error: call to '__compiletime_assert_86' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_data_unused_t) is wrong, expected 
>> 6
>> fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3
>> fs/xfs/xfs_ondisk.h:97:2: error: call to '__compiletime_assert_97' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_sf_hdr_t) is wrong, expected 10

vim +/__compiletime_assert_86 +86 fs/xfs/xfs_ondisk.h

30cbc591 Darrick J. Wong 2016-03-09   80
XFS_CHECK_STRUCT_SIZE(xfs_da_blkinfo_t, 12);
30cbc591 Darrick J. Wong 2016-03-09   81
XFS_CHECK_STRUCT_SIZE(xfs_da_intnode_t, 16);
30cbc591 Darrick J. Wong 2016-03-09   82
XFS_CHECK_STRUCT_SIZE(xfs_da_node_entry_t,  8);
30cbc591 Darrick J. Wong 2016-03-09   83
XFS_CHECK_STRUCT_SIZE(xfs_da_node_hdr_t,16);
30cbc591 Darrick J. Wong 2016-03-09   84
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_free_t, 4);
30cbc591 Darrick J. Wong 2016-03-09   85
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  @86
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_unused_t,   6);
30cbc591 Darrick J. Wong 2016-03-09   87
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09   88
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_t,  16);
30cbc591 Darrick J. Wong 2016-03-09   89
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino4_t,  4);
30cbc591 Darrick J. Wong 2016-03-09   90
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino8_t,  8);
30cbc591 Darrick J. Wong 2016-03-09   91
XFS_CHECK_STRUCT_SIZE(xfs_dir2_inou_t,  8);
30cbc591 Darrick J. Wong 2016-03-09   92
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_entry_t,8);
30cbc591 Darrick J. Wong 2016-03-09   93
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09   94
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_t,  16);
30cbc591 Darrick J. Wong 2016-03-09   95
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_tail_t, 4);
30cbc591 Darrick J. Wong 2016-03-09  @96
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_entry_t,  3);
30cbc591 Darrick J. Wong 2016-03-09  @97
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_hdr_t,10);
30cbc591 Darrick J. Wong 2016-03-09   98
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_off_t,2);
30cbc591 Darrick J. Wong 2016-03-09   99  
30cbc591 Darrick J. Wong 2016-03-09  100/* log structures */

:: The code at line 86 was first introduced by commit
:: 30cbc591c34e680e8b5d6d675ea49effe42a0570 xfs: check sizes of XFS on-disk 
structures at compile time

:: TO: Darrick J. Wong 
:: CC: Dave Chinner 

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


.config.gz
Description: Binary data

fs/xfs/xfs_ondisk.h:86:2: error: call to '__compiletime_assert_86' declared with attribute error: XFS: sizeof(xfs_dir2_data_unused_t) is wrong, expected 6

[kbuild test robot]

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f55532a0c0b8bb6148f4e07853b876ef73bc69ca
commit: ab9d1e4f7b0217948a3b35a64178602ab30ff45d Merge branch 
'xfs-misc-fixes-4.6-3' into for-next
date:   3 weeks ago
config: openrisc-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ab9d1e4f7b0217948a3b35a64178602ab30ff45d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from fs/xfs/xfs_super.c:48:0:
   In function 'xfs_check_ondisk_structs',
   inlined from 'init_xfs_fs' at fs/xfs/xfs_super.c:1862:26:
>> fs/xfs/xfs_ondisk.h:86:2: error: call to '__compiletime_assert_86' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_data_unused_t) is wrong, expected 
>> 6
>> fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3
>> fs/xfs/xfs_ondisk.h:97:2: error: call to '__compiletime_assert_97' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_sf_hdr_t) is wrong, expected 10

vim +/__compiletime_assert_86 +86 fs/xfs/xfs_ondisk.h

30cbc591 Darrick J. Wong 2016-03-09   80
XFS_CHECK_STRUCT_SIZE(xfs_da_blkinfo_t, 12);
30cbc591 Darrick J. Wong 2016-03-09   81
XFS_CHECK_STRUCT_SIZE(xfs_da_intnode_t, 16);
30cbc591 Darrick J. Wong 2016-03-09   82
XFS_CHECK_STRUCT_SIZE(xfs_da_node_entry_t,  8);
30cbc591 Darrick J. Wong 2016-03-09   83
XFS_CHECK_STRUCT_SIZE(xfs_da_node_hdr_t,16);
30cbc591 Darrick J. Wong 2016-03-09   84
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_free_t, 4);
30cbc591 Darrick J. Wong 2016-03-09   85
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  @86
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_unused_t,   6);
30cbc591 Darrick J. Wong 2016-03-09   87
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09   88
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_t,  16);
30cbc591 Darrick J. Wong 2016-03-09   89
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino4_t,  4);
30cbc591 Darrick J. Wong 2016-03-09   90
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino8_t,  8);
30cbc591 Darrick J. Wong 2016-03-09   91
XFS_CHECK_STRUCT_SIZE(xfs_dir2_inou_t,  8);
30cbc591 Darrick J. Wong 2016-03-09   92
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_entry_t,8);
30cbc591 Darrick J. Wong 2016-03-09   93
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09   94
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_t,  16);
30cbc591 Darrick J. Wong 2016-03-09   95
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_tail_t, 4);
30cbc591 Darrick J. Wong 2016-03-09  @96
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_entry_t,  3);
30cbc591 Darrick J. Wong 2016-03-09  @97
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_hdr_t,10);
30cbc591 Darrick J. Wong 2016-03-09   98
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_off_t,2);
30cbc591 Darrick J. Wong 2016-03-09   99  
30cbc591 Darrick J. Wong 2016-03-09  100/* log structures */

:: The code at line 86 was first introduced by commit
:: 30cbc591c34e680e8b5d6d675ea49effe42a0570 xfs: check sizes of XFS on-disk 
structures at compile time

:: TO: Darrick J. Wong 
:: CC: Dave Chinner 

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


.config.gz
Description: Binary data

平时最多也就联系了三千家，全球还有十几万客户在哪里？

[Andy-Search*Mailer*Inquiry*Order]

您好:
您还在用ali平台开发外贸客户?
   还在使用展会宣传企业和产品?
 你out了!!!
 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 
 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？
 加QQ1286754208给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。
 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。

平时最多也就联系了三千家，全球还有十几万客户在哪里？

[Andy-Search*Mailer*Inquiry*Order]

您好:
您还在用ali平台开发外贸客户?
   还在使用展会宣传企业和产品?
 你out了!!!
 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 
 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？
 加QQ1286754208给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。
 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。

Re: [PATCH v8 4/4] power: wm831x_power: Support USB charger current limit management

[kbuild test robot]

Hi Baolin,

[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160324]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20160324-204018
config: m68k-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   ERROR: "usb_charger_init" [drivers/usb/gadget/udc/udc-core.ko] undefined!
   ERROR: "usb_charger_plug_by_gadget" [drivers/usb/gadget/udc/udc-core.ko] 
undefined!
   ERROR: "usb_charger_exit" [drivers/usb/gadget/udc/udc-core.ko] undefined!
   ERROR: "usb_charger_set_cur_limit_by_type" 
[drivers/usb/gadget/libcomposite.ko] undefined!
   ERROR: "usb_charger_detect_type" [drivers/usb/gadget/libcomposite.ko] 
undefined!
   ERROR: "usb_charger_set_cur_limit_by_type" 
[drivers/usb/gadget/legacy/gadgetfs.ko] undefined!
   ERROR: "usb_charger_detect_type" [drivers/usb/gadget/legacy/gadgetfs.ko] 
undefined!
>> ERROR: "usb_charger_register_notify" [drivers/power/wm831x_power.ko] 
>> undefined!
>> ERROR: "usb_charger_find_by_name" [drivers/power/wm831x_power.ko] undefined!
>> ERROR: "usb_charger_unregister_notify" [drivers/power/wm831x_power.ko] 
>> undefined!

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


.config.gz
Description: Binary data

Re: [PATCH v8 4/4] power: wm831x_power: Support USB charger current limit management

[kbuild test robot]

Hi Baolin,

[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160324]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20160324-204018
config: m68k-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   ERROR: "usb_charger_init" [drivers/usb/gadget/udc/udc-core.ko] undefined!
   ERROR: "usb_charger_plug_by_gadget" [drivers/usb/gadget/udc/udc-core.ko] 
undefined!
   ERROR: "usb_charger_exit" [drivers/usb/gadget/udc/udc-core.ko] undefined!
   ERROR: "usb_charger_set_cur_limit_by_type" 
[drivers/usb/gadget/libcomposite.ko] undefined!
   ERROR: "usb_charger_detect_type" [drivers/usb/gadget/libcomposite.ko] 
undefined!
   ERROR: "usb_charger_set_cur_limit_by_type" 
[drivers/usb/gadget/legacy/gadgetfs.ko] undefined!
   ERROR: "usb_charger_detect_type" [drivers/usb/gadget/legacy/gadgetfs.ko] 
undefined!
>> ERROR: "usb_charger_register_notify" [drivers/power/wm831x_power.ko] 
>> undefined!
>> ERROR: "usb_charger_find_by_name" [drivers/power/wm831x_power.ko] undefined!
>> ERROR: "usb_charger_unregister_notify" [drivers/power/wm831x_power.ko] 
>> undefined!

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


.config.gz
Description: Binary data

[PATCH net-next 1/7] net: dsa: mv88e6xxx: 6185 port default FID is 8-bit

[Vivien Didelot]

In the 6352 family, FIDs are 12-bit. In the 6185 family, they are 8-bit.

Fix the upper mask, which was overlapping on the port Trunk ID (even
though it is not used yet).

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 10 +++---
 drivers/net/dsa/mv88e6xxx.h |  3 ++-
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index fa086e0..1d9ae48 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1511,9 +1511,13 @@ loadpurge:
 static int _mv88e6xxx_port_fid(struct dsa_switch *ds, int port, u16 *new,
   u16 *old)
 {
+   u16 upper_mask = PORT_CONTROL_1_FID_11_4_MASK;
u16 fid;
int ret;
 
+   if (mv88e6xxx_6185_family(ds))
+   upper_mask = PORT_CONTROL_1_DBNUM_7_4_MASK;
+
/* Port's default FID bits 3:0 are located in reg 0x06, offset 12 */
ret = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_BASE_VLAN);
if (ret < 0)
@@ -1536,11 +1540,11 @@ static int _mv88e6xxx_port_fid(struct dsa_switch *ds, 
int port, u16 *new,
if (ret < 0)
return ret;
 
-   fid |= (ret & PORT_CONTROL_1_FID_11_4_MASK) << 4;
+   fid |= (ret & upper_mask) << 4;
 
if (new) {
-   ret &= ~PORT_CONTROL_1_FID_11_4_MASK;
-   ret |= (*new >> 4) & PORT_CONTROL_1_FID_11_4_MASK;
+   ret &= ~upper_mask;
+   ret |= (*new >> 4) & upper_mask;
 
ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_CONTROL_1,
   ret);
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 9a038ab..febab76 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -133,7 +133,8 @@
 #define PORT_CONTROL_STATE_LEARNING0x02
 #define PORT_CONTROL_STATE_FORWARDING  0x03
 #define PORT_CONTROL_1 0x05
-#define PORT_CONTROL_1_FID_11_4_MASK   (0xff << 0)
+#define PORT_CONTROL_1_DBNUM_7_4_MASK  (0xf << 0)  /* 6185 */
+#define PORT_CONTROL_1_FID_11_4_MASK   (0xff << 0) /* 6352 */
 #define PORT_BASE_VLAN 0x06
 #define PORT_BASE_VLAN_FID_3_0_MASK(0xf << 12)
 #define PORT_DEFAULT_VLAN  0x07
-- 
2.7.4

[PATCH net-next 1/7] net: dsa: mv88e6xxx: 6185 port default FID is 8-bit

[Vivien Didelot]

In the 6352 family, FIDs are 12-bit. In the 6185 family, they are 8-bit.

Fix the upper mask, which was overlapping on the port Trunk ID (even
though it is not used yet).

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 10 +++---
 drivers/net/dsa/mv88e6xxx.h |  3 ++-
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index fa086e0..1d9ae48 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1511,9 +1511,13 @@ loadpurge:
 static int _mv88e6xxx_port_fid(struct dsa_switch *ds, int port, u16 *new,
   u16 *old)
 {
+   u16 upper_mask = PORT_CONTROL_1_FID_11_4_MASK;
u16 fid;
int ret;
 
+   if (mv88e6xxx_6185_family(ds))
+   upper_mask = PORT_CONTROL_1_DBNUM_7_4_MASK;
+
/* Port's default FID bits 3:0 are located in reg 0x06, offset 12 */
ret = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_BASE_VLAN);
if (ret < 0)
@@ -1536,11 +1540,11 @@ static int _mv88e6xxx_port_fid(struct dsa_switch *ds, 
int port, u16 *new,
if (ret < 0)
return ret;
 
-   fid |= (ret & PORT_CONTROL_1_FID_11_4_MASK) << 4;
+   fid |= (ret & upper_mask) << 4;
 
if (new) {
-   ret &= ~PORT_CONTROL_1_FID_11_4_MASK;
-   ret |= (*new >> 4) & PORT_CONTROL_1_FID_11_4_MASK;
+   ret &= ~upper_mask;
+   ret |= (*new >> 4) & upper_mask;
 
ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_CONTROL_1,
   ret);
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 9a038ab..febab76 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -133,7 +133,8 @@
 #define PORT_CONTROL_STATE_LEARNING0x02
 #define PORT_CONTROL_STATE_FORWARDING  0x03
 #define PORT_CONTROL_1 0x05
-#define PORT_CONTROL_1_FID_11_4_MASK   (0xff << 0)
+#define PORT_CONTROL_1_DBNUM_7_4_MASK  (0xf << 0)  /* 6185 */
+#define PORT_CONTROL_1_FID_11_4_MASK   (0xff << 0) /* 6352 */
 #define PORT_BASE_VLAN 0x06
 #define PORT_BASE_VLAN_FID_3_0_MASK(0xf << 12)
 #define PORT_DEFAULT_VLAN  0x07
-- 
2.7.4

[PATCH net-next 3/7] net: dsa: mv88e6xxx: write FID in ATU command

[Vivien Didelot]

Some switch models don't have a separate ATU FID register, but bury it
in the ATU Operation register.

Factorize the write of the FID and opcode in the ATU command function.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 1d9b5dd..df3f219 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -951,10 +951,20 @@ out:
return ret;
 }
 
-static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 cmd)
+static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 fid, u16 cmd)
 {
int ret;
 
+   if (mv88e6xxx_6097_family(ds) || mv88e6xxx_6165_family(ds) ||
+   mv88e6xxx_6351_family(ds) || mv88e6xxx_6352_family(ds)) {
+   /* 88E6352 and similar have their own ATU FID register */
+   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
+   if (ret < 0)
+   return ret;
+   } else {
+   return -EOPNOTSUPP;
+   }
+
ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_OP, cmd);
if (ret < 0)
return ret;
@@ -1001,11 +1011,6 @@ static int _mv88e6xxx_atu_flush_move(struct dsa_switch 
*ds,
return err;
 
if (entry->fid) {
-   err = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID,
-  entry->fid);
-   if (err)
-   return err;
-
op = static_too ? GLOBAL_ATU_OP_FLUSH_MOVE_ALL_DB :
GLOBAL_ATU_OP_FLUSH_MOVE_NON_STATIC_DB;
} else {
@@ -1013,7 +1018,7 @@ static int _mv88e6xxx_atu_flush_move(struct dsa_switch 
*ds,
GLOBAL_ATU_OP_FLUSH_MOVE_NON_STATIC;
}
 
-   return _mv88e6xxx_atu_cmd(ds, op);
+   return _mv88e6xxx_atu_cmd(ds, entry->fid, op);
 }
 
 static int _mv88e6xxx_atu_flush(struct dsa_switch *ds, u16 fid, bool 
static_too)
@@ -1973,11 +1978,7 @@ static int _mv88e6xxx_atu_load(struct dsa_switch *ds,
if (ret < 0)
return ret;
 
-   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, entry->fid);
-   if (ret < 0)
-   return ret;
-
-   return _mv88e6xxx_atu_cmd(ds, GLOBAL_ATU_OP_LOAD_DB);
+   return _mv88e6xxx_atu_cmd(ds, entry->fid, GLOBAL_ATU_OP_LOAD_DB);
 }
 
 static int _mv88e6xxx_port_fdb_load(struct dsa_switch *ds, int port,
@@ -2060,11 +2061,7 @@ static int _mv88e6xxx_atu_getnext(struct dsa_switch *ds, 
u16 fid,
if (ret < 0)
return ret;
 
-   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
-   if (ret < 0)
-   return ret;
-
-   ret = _mv88e6xxx_atu_cmd(ds, GLOBAL_ATU_OP_GET_NEXT_DB);
+   ret = _mv88e6xxx_atu_cmd(ds, fid, GLOBAL_ATU_OP_GET_NEXT_DB);
if (ret < 0)
return ret;
 
-- 
2.7.4

[PATCH net-next 5/7] net: dsa: mv88e6xxx: fix VTU FID access for 6185

[Vivien Didelot]

The 6352 family has an entire register for its 12-bit FID used by the
VTU operations. The 6185 family has no such register. Its 8-bit FID
(called DBNum) is split in the VTU Operation register.

Modify the VTU read and write access to support this switch family.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 20 +++-
 drivers/net/dsa/mv88e6xxx.h |  2 +-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 4b3c466..366fda1 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1355,6 +1355,17 @@ static int _mv88e6xxx_vtu_getnext(struct dsa_switch *ds,
return ret;
 
next.sid = ret & GLOBAL_VTU_SID_MASK;
+   } else if (mv88e6xxx_6185_family(ds)) {
+   /* VTU DBNum[7:4] are located in VTU Operation 11:8, and
+* VTU DBNum[3:0] are located in VTU Operation 3:0
+*/
+   ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL,
+ GLOBAL_VTU_OP);
+   if (ret < 0)
+   return ret;
+
+   next.fid = (ret & 0xf00) >> 4;
+   next.fid |= ret & 0xf;
}
}
 
@@ -1416,6 +1427,7 @@ unlock:
 static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch *ds,
struct mv88e6xxx_vtu_stu_entry *entry)
 {
+   u16 op = GLOBAL_VTU_OP_VTU_LOAD_PURGE;
u16 reg = 0;
int ret;
 
@@ -1442,6 +1454,12 @@ static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch 
*ds,
ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_FID, reg);
if (ret < 0)
return ret;
+   } else if (mv88e6xxx_6185_family(ds)) {
+   /* VTU DBNum[7:4] are located in VTU Operation 11:8, and
+* VTU DBNum[3:0] are located in VTU Operation 3:0
+*/
+   op |= (entry->fid & 0xf0) << 8;
+   op |= entry->fid & 0xf;
}
 
reg = GLOBAL_VTU_VID_VALID;
@@ -1451,7 +1469,7 @@ loadpurge:
if (ret < 0)
return ret;
 
-   return _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_VTU_LOAD_PURGE);
+   return _mv88e6xxx_vtu_cmd(ds, op);
 }
 
 static int _mv88e6xxx_stu_getnext(struct dsa_switch *ds, u8 sid,
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 94d3cb3..b1f1269 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -376,7 +376,7 @@ struct mv88e6xxx_atu_entry {
 struct mv88e6xxx_vtu_stu_entry {
/* VTU only */
u16 vid;
-   u16 fid;
+   u16 fid; /* 8-bit DBNum in 88E6185 family */
 
/* VTU and STU */
u8  sid;
-- 
2.7.4

[PATCH net-next 4/7] net: dsa: mv88e6xxx: fix ATU FID access for 6185

[Vivien Didelot]

The 6185 family does not have a ATU FID register. It splits it in the
ATU Control register and the ATU Operation.

Add 6185 support for FID (a.k.a. DBNum) in ATU commands.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 14 ++
 drivers/net/dsa/mv88e6xxx.h |  2 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index df3f219..4b3c466 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -961,6 +961,20 @@ static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 
fid, u16 cmd)
ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
if (ret < 0)
return ret;
+   } else if (mv88e6xxx_6185_family(ds)) {
+   /* ATU DBNum[7:4] are located in ATU Control 15:12 */
+   ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL);
+   if (ret < 0)
+   return ret;
+
+   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL,
+  (ret & 0xfff) |
+  ((fid << 8) & 0xf000));
+   if (ret < 0)
+   return ret;
+
+   /* ATU DBNum[3:0] are located in ATU Operation 3:0 */
+   cmd |= fid & 0xf;
} else {
return -EOPNOTSUPP;
}
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index febab76..94d3cb3 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -366,7 +366,7 @@ struct mv88e6xxx_switch_id {
 };
 
 struct mv88e6xxx_atu_entry {
-   u16 fid;
+   u16 fid; /* 8-bit DBNum in 88E6185 family */
u8  state;
booltrunk;
u16 portv_trunkid;
-- 
2.7.4

[PATCH net-next 4/7] net: dsa: mv88e6xxx: fix ATU FID access for 6185

[Vivien Didelot]

The 6185 family does not have a ATU FID register. It splits it in the
ATU Control register and the ATU Operation.

Add 6185 support for FID (a.k.a. DBNum) in ATU commands.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 14 ++
 drivers/net/dsa/mv88e6xxx.h |  2 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index df3f219..4b3c466 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -961,6 +961,20 @@ static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 
fid, u16 cmd)
ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
if (ret < 0)
return ret;
+   } else if (mv88e6xxx_6185_family(ds)) {
+   /* ATU DBNum[7:4] are located in ATU Control 15:12 */
+   ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL);
+   if (ret < 0)
+   return ret;
+
+   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL,
+  (ret & 0xfff) |
+  ((fid << 8) & 0xf000));
+   if (ret < 0)
+   return ret;
+
+   /* ATU DBNum[3:0] are located in ATU Operation 3:0 */
+   cmd |= fid & 0xf;
} else {
return -EOPNOTSUPP;
}
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index febab76..94d3cb3 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -366,7 +366,7 @@ struct mv88e6xxx_switch_id {
 };
 
 struct mv88e6xxx_atu_entry {
-   u16 fid;
+   u16 fid; /* 8-bit DBNum in 88E6185 family */
u8  state;
booltrunk;
u16 portv_trunkid;
-- 
2.7.4

[PATCH net-next 3/7] net: dsa: mv88e6xxx: write FID in ATU command

[Vivien Didelot]

Some switch models don't have a separate ATU FID register, but bury it
in the ATU Operation register.

Factorize the write of the FID and opcode in the ATU command function.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 1d9b5dd..df3f219 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -951,10 +951,20 @@ out:
return ret;
 }
 
-static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 cmd)
+static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 fid, u16 cmd)
 {
int ret;
 
+   if (mv88e6xxx_6097_family(ds) || mv88e6xxx_6165_family(ds) ||
+   mv88e6xxx_6351_family(ds) || mv88e6xxx_6352_family(ds)) {
+   /* 88E6352 and similar have their own ATU FID register */
+   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
+   if (ret < 0)
+   return ret;
+   } else {
+   return -EOPNOTSUPP;
+   }
+
ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_OP, cmd);
if (ret < 0)
return ret;
@@ -1001,11 +1011,6 @@ static int _mv88e6xxx_atu_flush_move(struct dsa_switch 
*ds,
return err;
 
if (entry->fid) {
-   err = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID,
-  entry->fid);
-   if (err)
-   return err;
-
op = static_too ? GLOBAL_ATU_OP_FLUSH_MOVE_ALL_DB :
GLOBAL_ATU_OP_FLUSH_MOVE_NON_STATIC_DB;
} else {
@@ -1013,7 +1018,7 @@ static int _mv88e6xxx_atu_flush_move(struct dsa_switch 
*ds,
GLOBAL_ATU_OP_FLUSH_MOVE_NON_STATIC;
}
 
-   return _mv88e6xxx_atu_cmd(ds, op);
+   return _mv88e6xxx_atu_cmd(ds, entry->fid, op);
 }
 
 static int _mv88e6xxx_atu_flush(struct dsa_switch *ds, u16 fid, bool 
static_too)
@@ -1973,11 +1978,7 @@ static int _mv88e6xxx_atu_load(struct dsa_switch *ds,
if (ret < 0)
return ret;
 
-   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, entry->fid);
-   if (ret < 0)
-   return ret;
-
-   return _mv88e6xxx_atu_cmd(ds, GLOBAL_ATU_OP_LOAD_DB);
+   return _mv88e6xxx_atu_cmd(ds, entry->fid, GLOBAL_ATU_OP_LOAD_DB);
 }
 
 static int _mv88e6xxx_port_fdb_load(struct dsa_switch *ds, int port,
@@ -2060,11 +2061,7 @@ static int _mv88e6xxx_atu_getnext(struct dsa_switch *ds, 
u16 fid,
if (ret < 0)
return ret;
 
-   ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
-   if (ret < 0)
-   return ret;
-
-   ret = _mv88e6xxx_atu_cmd(ds, GLOBAL_ATU_OP_GET_NEXT_DB);
+   ret = _mv88e6xxx_atu_cmd(ds, fid, GLOBAL_ATU_OP_GET_NEXT_DB);
if (ret < 0)
return ret;
 
-- 
2.7.4

[PATCH net-next 5/7] net: dsa: mv88e6xxx: fix VTU FID access for 6185

[Vivien Didelot]

The 6352 family has an entire register for its 12-bit FID used by the
VTU operations. The 6185 family has no such register. Its 8-bit FID
(called DBNum) is split in the VTU Operation register.

Modify the VTU read and write access to support this switch family.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 20 +++-
 drivers/net/dsa/mv88e6xxx.h |  2 +-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 4b3c466..366fda1 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1355,6 +1355,17 @@ static int _mv88e6xxx_vtu_getnext(struct dsa_switch *ds,
return ret;
 
next.sid = ret & GLOBAL_VTU_SID_MASK;
+   } else if (mv88e6xxx_6185_family(ds)) {
+   /* VTU DBNum[7:4] are located in VTU Operation 11:8, and
+* VTU DBNum[3:0] are located in VTU Operation 3:0
+*/
+   ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL,
+ GLOBAL_VTU_OP);
+   if (ret < 0)
+   return ret;
+
+   next.fid = (ret & 0xf00) >> 4;
+   next.fid |= ret & 0xf;
}
}
 
@@ -1416,6 +1427,7 @@ unlock:
 static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch *ds,
struct mv88e6xxx_vtu_stu_entry *entry)
 {
+   u16 op = GLOBAL_VTU_OP_VTU_LOAD_PURGE;
u16 reg = 0;
int ret;
 
@@ -1442,6 +1454,12 @@ static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch 
*ds,
ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_FID, reg);
if (ret < 0)
return ret;
+   } else if (mv88e6xxx_6185_family(ds)) {
+   /* VTU DBNum[7:4] are located in VTU Operation 11:8, and
+* VTU DBNum[3:0] are located in VTU Operation 3:0
+*/
+   op |= (entry->fid & 0xf0) << 8;
+   op |= entry->fid & 0xf;
}
 
reg = GLOBAL_VTU_VID_VALID;
@@ -1451,7 +1469,7 @@ loadpurge:
if (ret < 0)
return ret;
 
-   return _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_VTU_LOAD_PURGE);
+   return _mv88e6xxx_vtu_cmd(ds, op);
 }
 
 static int _mv88e6xxx_stu_getnext(struct dsa_switch *ds, u8 sid,
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 94d3cb3..b1f1269 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -376,7 +376,7 @@ struct mv88e6xxx_atu_entry {
 struct mv88e6xxx_vtu_stu_entry {
/* VTU only */
u16 vid;
-   u16 fid;
+   u16 fid; /* 8-bit DBNum in 88E6185 family */
 
/* VTU and STU */
u8  sid;
-- 
2.7.4

[PATCH net-next 2/7] net: dsa: mv88e6xxx: 6185 has only 256 FDBs

[Vivien Didelot]

The 6185 family has only 256 indexable address databases, while the
others (such as 6352) have 4095. Explicit and use these maximum values
in the _mv88e6xxx_fid_new function.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 1d9ae48..1d9b5dd 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1575,8 +1575,12 @@ static int _mv88e6xxx_fid_new(struct dsa_switch *ds, u16 
*fid)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
DECLARE_BITMAP(fid_bitmap, MV88E6XXX_N_FID);
struct mv88e6xxx_vtu_stu_entry vlan;
+   u16 max = 4095;
int i, err;
 
+   if (mv88e6xxx_6185_family(ds))
+   max = 256;
+
bitmap_zero(fid_bitmap, MV88E6XXX_N_FID);
 
/* Set every FID bit used by the (un)bridged ports */
@@ -1608,7 +1612,7 @@ static int _mv88e6xxx_fid_new(struct dsa_switch *ds, u16 
*fid)
 * databases are not needed. Return the next positive available.
 */
*fid = find_next_zero_bit(fid_bitmap, MV88E6XXX_N_FID, 1);
-   if (unlikely(*fid == MV88E6XXX_N_FID))
+   if (unlikely(*fid > max))
return -ENOSPC;
 
/* Clear the database */
-- 
2.7.4

[PATCH net-next 2/7] net: dsa: mv88e6xxx: 6185 has only 256 FDBs

[Vivien Didelot]

The 6185 family has only 256 indexable address databases, while the
others (such as 6352) have 4095. Explicit and use these maximum values
in the _mv88e6xxx_fid_new function.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 1d9ae48..1d9b5dd 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1575,8 +1575,12 @@ static int _mv88e6xxx_fid_new(struct dsa_switch *ds, u16 
*fid)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
DECLARE_BITMAP(fid_bitmap, MV88E6XXX_N_FID);
struct mv88e6xxx_vtu_stu_entry vlan;
+   u16 max = 4095;
int i, err;
 
+   if (mv88e6xxx_6185_family(ds))
+   max = 256;
+
bitmap_zero(fid_bitmap, MV88E6XXX_N_FID);
 
/* Set every FID bit used by the (un)bridged ports */
@@ -1608,7 +1612,7 @@ static int _mv88e6xxx_fid_new(struct dsa_switch *ds, u16 
*fid)
 * databases are not needed. Return the next positive available.
 */
*fid = find_next_zero_bit(fid_bitmap, MV88E6XXX_N_FID, 1);
-   if (unlikely(*fid == MV88E6XXX_N_FID))
+   if (unlikely(*fid > max))
return -ENOSPC;
 
/* Clear the database */
-- 
2.7.4

[PATCH net-next 0/7] net: dsa: mv88e6xxx: HW bridging support for 6185

[Vivien Didelot]

All packets passing through a switch of the 6185 family are currently all
directed to the CPU port. This means that port bridging is software driven.

To enable hardware bridging for this switch family, we need to implement the
port mapping operations, the FDB operations, and optionally the VLAN operations
(for 802.1Q and VLAN filtering aware systems).

However this family only has 256 FDBs indexed by 8-bit identifiers, opposed to
4096 FDBs with 12-bit identifiers for other families such as 6352. It also
doesn't have dedicated FID registers for ATU and VTU operations.

This patchset fixes these differences, and enable hardware bridging for 6185.

Vivien Didelot (7):
  net: dsa: mv88e6xxx: 6185 port default FID is 8-bit
  net: dsa: mv88e6xxx: 6185 has only 256 FDBs
  net: dsa: mv88e6xxx: write FID in ATU command
  net: dsa: mv88e6xxx: fix ATU FID access for 6185
  net: dsa: mv88e6xxx: fix VTU FID access for 6185
  net: dsa: mv88e6xxx: map destination addresses for 6185
  net: dsa: mv88e6131: enable hardware bridging

 drivers/net/dsa/mv88e6131.c | 11 ++
 drivers/net/dsa/mv88e6xxx.c | 84 -
 drivers/net/dsa/mv88e6xxx.h |  7 ++--
 3 files changed, 76 insertions(+), 26 deletions(-)

-- 
2.7.4

[PATCH net-next 6/7] net: dsa: mv88e6xxx: map destination addresses for 6185

[Vivien Didelot]

The 88E6185 switch also has a MapDA bit in its Port Control 2 register.
When this bit is cleared, all frames are sent out to the CPU port.

Set this bit to rely on address databases (ATU) hits and direct frames
out of the correct ports, and thus allow hardware bridging.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 366fda1..35d0ace 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -2413,7 +2413,8 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds, 
int port)
reg = 0;
if (mv88e6xxx_6352_family(ds) || mv88e6xxx_6351_family(ds) ||
mv88e6xxx_6165_family(ds) || mv88e6xxx_6097_family(ds) ||
-   mv88e6xxx_6095_family(ds) || mv88e6xxx_6320_family(ds))
+   mv88e6xxx_6095_family(ds) || mv88e6xxx_6320_family(ds) ||
+   mv88e6xxx_6185_family(ds))
reg = PORT_CONTROL_2_MAP_DA;
 
if (mv88e6xxx_6352_family(ds) || mv88e6xxx_6351_family(ds) ||
-- 
2.7.4

[PATCH net-next 0/7] net: dsa: mv88e6xxx: HW bridging support for 6185

[Vivien Didelot]

All packets passing through a switch of the 6185 family are currently all
directed to the CPU port. This means that port bridging is software driven.

To enable hardware bridging for this switch family, we need to implement the
port mapping operations, the FDB operations, and optionally the VLAN operations
(for 802.1Q and VLAN filtering aware systems).

However this family only has 256 FDBs indexed by 8-bit identifiers, opposed to
4096 FDBs with 12-bit identifiers for other families such as 6352. It also
doesn't have dedicated FID registers for ATU and VTU operations.

This patchset fixes these differences, and enable hardware bridging for 6185.

Vivien Didelot (7):
  net: dsa: mv88e6xxx: 6185 port default FID is 8-bit
  net: dsa: mv88e6xxx: 6185 has only 256 FDBs
  net: dsa: mv88e6xxx: write FID in ATU command
  net: dsa: mv88e6xxx: fix ATU FID access for 6185
  net: dsa: mv88e6xxx: fix VTU FID access for 6185
  net: dsa: mv88e6xxx: map destination addresses for 6185
  net: dsa: mv88e6131: enable hardware bridging

 drivers/net/dsa/mv88e6131.c | 11 ++
 drivers/net/dsa/mv88e6xxx.c | 84 -
 drivers/net/dsa/mv88e6xxx.h |  7 ++--
 3 files changed, 76 insertions(+), 26 deletions(-)

-- 
2.7.4

[PATCH net-next 6/7] net: dsa: mv88e6xxx: map destination addresses for 6185

[Vivien Didelot]

The 88E6185 switch also has a MapDA bit in its Port Control 2 register.
When this bit is cleared, all frames are sent out to the CPU port.

Set this bit to rely on address databases (ATU) hits and direct frames
out of the correct ports, and thus allow hardware bridging.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 366fda1..35d0ace 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -2413,7 +2413,8 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds, 
int port)
reg = 0;
if (mv88e6xxx_6352_family(ds) || mv88e6xxx_6351_family(ds) ||
mv88e6xxx_6165_family(ds) || mv88e6xxx_6097_family(ds) ||
-   mv88e6xxx_6095_family(ds) || mv88e6xxx_6320_family(ds))
+   mv88e6xxx_6095_family(ds) || mv88e6xxx_6320_family(ds) ||
+   mv88e6xxx_6185_family(ds))
reg = PORT_CONTROL_2_MAP_DA;
 
if (mv88e6xxx_6352_family(ds) || mv88e6xxx_6351_family(ds) ||
-- 
2.7.4

[PATCH net-next 7/7] net: dsa: mv88e6131: enable hardware bridging

[Vivien Didelot]

By adding support for bridge operations, FDB operations, and optionally
VLAN operations (for 802.1Q and VLAN filtering aware systems), the
switch bridges ports correctly, the CPU is able to populate the hardware
address databases, and thus hardware bridging becomes functional within
the 88E6185 family of switches.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6131.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index a92ca65..2407028 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -169,6 +169,17 @@ struct dsa_switch_driver mv88e6131_switch_driver = {
.get_ethtool_stats  = mv88e6xxx_get_ethtool_stats,
.get_sset_count = mv88e6xxx_get_sset_count,
.adjust_link= mv88e6xxx_adjust_link,
+   .port_bridge_join   = mv88e6xxx_port_bridge_join,
+   .port_bridge_leave  = mv88e6xxx_port_bridge_leave,
+   .port_vlan_filtering= mv88e6xxx_port_vlan_filtering,
+   .port_vlan_prepare  = mv88e6xxx_port_vlan_prepare,
+   .port_vlan_add  = mv88e6xxx_port_vlan_add,
+   .port_vlan_del  = mv88e6xxx_port_vlan_del,
+   .port_vlan_dump = mv88e6xxx_port_vlan_dump,
+   .port_fdb_prepare   = mv88e6xxx_port_fdb_prepare,
+   .port_fdb_add   = mv88e6xxx_port_fdb_add,
+   .port_fdb_del   = mv88e6xxx_port_fdb_del,
+   .port_fdb_dump  = mv88e6xxx_port_fdb_dump,
 };
 
 MODULE_ALIAS("platform:mv88e6085");
-- 
2.7.4

[PATCH net-next 7/7] net: dsa: mv88e6131: enable hardware bridging

[Vivien Didelot]

By adding support for bridge operations, FDB operations, and optionally
VLAN operations (for 802.1Q and VLAN filtering aware systems), the
switch bridges ports correctly, the CPU is able to populate the hardware
address databases, and thus hardware bridging becomes functional within
the 88E6185 family of switches.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6131.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index a92ca65..2407028 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -169,6 +169,17 @@ struct dsa_switch_driver mv88e6131_switch_driver = {
.get_ethtool_stats  = mv88e6xxx_get_ethtool_stats,
.get_sset_count = mv88e6xxx_get_sset_count,
.adjust_link= mv88e6xxx_adjust_link,
+   .port_bridge_join   = mv88e6xxx_port_bridge_join,
+   .port_bridge_leave  = mv88e6xxx_port_bridge_leave,
+   .port_vlan_filtering= mv88e6xxx_port_vlan_filtering,
+   .port_vlan_prepare  = mv88e6xxx_port_vlan_prepare,
+   .port_vlan_add  = mv88e6xxx_port_vlan_add,
+   .port_vlan_del  = mv88e6xxx_port_vlan_del,
+   .port_vlan_dump = mv88e6xxx_port_vlan_dump,
+   .port_fdb_prepare   = mv88e6xxx_port_fdb_prepare,
+   .port_fdb_add   = mv88e6xxx_port_fdb_add,
+   .port_fdb_del   = mv88e6xxx_port_fdb_del,
+   .port_fdb_dump  = mv88e6xxx_port_fdb_dump,
 };
 
 MODULE_ALIAS("platform:mv88e6085");
-- 
2.7.4

Re: [RESEND PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver

[Marek Vasut]

On 03/26/2016 09:11 AM, Jiancheng Xue wrote:
> Add hisilicon spi-nor flash controller driver
> 
> Signed-off-by: Binquan Peng 
> Signed-off-by: Jiancheng Xue 
> Acked-by: Rob Herring 
> Reviewed-by: Ezequiel Garcia 
> Reviewed-by: Jagan Teki 
> ---
> change log
> v9:
> Fixed issues pointed by Jagan Teki.

It'd be really great if you could list which exact issues you fixed.

> v8:
> Fixed issues pointed by Ezequiel Garcia and Brian Norris.
> Moved dts binding file to mtd directory.
> Changed the compatible string more specific.

[...]

> +/* Hardware register offsets and field definitions */
> +#define FMC_CFG  0x00
> +#define SPI_NOR_ADDR_MODEBIT(10)
> +#define FMC_GLOBAL_CFG   0x04
> +#define FMC_GLOBAL_CFG_WP_ENABLE BIT(6)
> +#define FMC_SPI_TIMING_CFG   0x08
> +#define TIMING_CFG_TCSH(nr)  (((nr) & 0xf) << 8)
> +#define TIMING_CFG_TCSS(nr)  (((nr) & 0xf) << 4)
> +#define TIMING_CFG_TSHSL(nr) ((nr) & 0xf)
> +#define CS_HOLD_TIME 0x6
> +#define CS_SETUP_TIME0x6
> +#define CS_DESELECT_TIME 0xf
> +#define FMC_INT  0x18
> +#define FMC_INT_OP_DONE  BIT(0)
> +#define FMC_INT_CLR  0x20
> +#define FMC_CMD  0x24
> +#define FMC_CMD_CMD1(_cmd)   ((_cmd) & 0xff)

Drop the underscores in the argument names.

> +#define FMC_ADDRL0x2c
> +#define FMC_OP_CFG   0x30
> +#define OP_CFG_FM_CS(_cs)((_cs) << 11)
> +#define OP_CFG_MEM_IF_TYPE(_type)(((_type) & 0x7) << 7)
> +#define OP_CFG_ADDR_NUM(_addr)   (((_addr) & 0x7) << 4)
> +#define OP_CFG_DUMMY_NUM(_dummy) ((_dummy) & 0xf)
> +#define FMC_DATA_NUM 0x38
> +#define FMC_DATA_NUM_CNT(_n) ((_n) & 0x3fff)
> +#define FMC_OP   0x3c
> +#define FMC_OP_DUMMY_EN  BIT(8)
> +#define FMC_OP_CMD1_EN   BIT(7)
> +#define FMC_OP_ADDR_EN   BIT(6)
> +#define FMC_OP_WRITE_DATA_EN BIT(5)
> +#define FMC_OP_READ_DATA_EN  BIT(2)
> +#define FMC_OP_READ_STATUS_ENBIT(1)
> +#define FMC_OP_REG_OP_START  BIT(0)

[...]

> +enum hifmc_iftype {
> + IF_TYPE_STD,
> + IF_TYPE_DUAL,
> + IF_TYPE_DIO,
> + IF_TYPE_QUAD,
> + IF_TYPE_QIO,
> +};
> +
> +struct hifmc_priv {
> + int chipselect;

Can chipselect be set to < 0 values ?

> + u32 clkrate;
> + struct hifmc_host *host;
> +};
> +
> +#define HIFMC_MAX_CHIP_NUM   2

This does not scale very well, use dynamic allocation.

> +struct hifmc_host {
> + struct device *dev;
> + struct mutex lock;
> +
> + void __iomem *regbase;
> + void __iomem *iobase;
> + struct clk *clk;
> + void *buffer;
> + dma_addr_t dma_buffer;
> +
> + struct spi_nor  nor[HIFMC_MAX_CHIP_NUM];
> + struct hifmc_priv priv[HIFMC_MAX_CHIP_NUM];
> + int num_chip;
> +};
> +
> +static inline int wait_op_finish(struct hifmc_host *host)
> +{
> + unsigned int reg;
> +
> + return readl_poll_timeout(host->regbase + FMC_INT, reg,
> + (reg & FMC_INT_OP_DONE), 0, FMC_WAIT_TIMEOUT);
> +}
> +
> +static int get_if_type(enum read_mode flash_read)
> +{
> + enum hifmc_iftype if_type;
> +
> + switch (flash_read) {
> + case SPI_NOR_DUAL:
> + if_type = IF_TYPE_DUAL;
> + break;
> + case SPI_NOR_QUAD:
> + if_type = IF_TYPE_QUAD;
> + break;
> + case SPI_NOR_NORMAL:
> + case SPI_NOR_FAST:
> + default:
> + if_type = IF_TYPE_STD;
> + break;
> + }
> +
> + return if_type;
> +}
> +
> +static void hisi_spi_nor_init(struct hifmc_host *host)
> +{
> + unsigned int reg;

Should be u32 here.

> + reg = TIMING_CFG_TCSH(CS_HOLD_TIME)
> + | TIMING_CFG_TCSS(CS_SETUP_TIME)
> + | TIMING_CFG_TSHSL(CS_DESELECT_TIME);
> + writel(reg, host->regbase + FMC_SPI_TIMING_CFG);
> +}
> +
> +static int hisi_spi_nor_prep(struct spi_nor *nor, enum spi_nor_ops ops)
> +{
> + struct hifmc_priv *priv = nor->priv;
> + struct hifmc_host *host = priv->host;
> + int ret;
> +
> + mutex_lock(>lock);

Why do you need the mutex lock here ? Let me guess -- SPI NOR framework
locks a mutex in struct spi_nor , but that's not enough if you have
multiple SPI NORs on the same bus, because concurrent access to multiple
SPI NOR flashes needs locking on the controller level, right ?

> + ret = clk_set_rate(host->clk, priv->clkrate);
> + if (ret)
> + goto out;
> +
> + ret = clk_prepare_enable(host->clk);
> + if (ret)
> + goto out;
> +
> + return 0;
> +
> +out:
> + mutex_unlock(>lock);
> + return 

Re: [RESEND PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver

[Marek Vasut]

On 03/26/2016 09:11 AM, Jiancheng Xue wrote:
> Add hisilicon spi-nor flash controller driver
> 
> Signed-off-by: Binquan Peng 
> Signed-off-by: Jiancheng Xue 
> Acked-by: Rob Herring 
> Reviewed-by: Ezequiel Garcia 
> Reviewed-by: Jagan Teki 
> ---
> change log
> v9:
> Fixed issues pointed by Jagan Teki.

It'd be really great if you could list which exact issues you fixed.

> v8:
> Fixed issues pointed by Ezequiel Garcia and Brian Norris.
> Moved dts binding file to mtd directory.
> Changed the compatible string more specific.

[...]

> +/* Hardware register offsets and field definitions */
> +#define FMC_CFG  0x00
> +#define SPI_NOR_ADDR_MODEBIT(10)
> +#define FMC_GLOBAL_CFG   0x04
> +#define FMC_GLOBAL_CFG_WP_ENABLE BIT(6)
> +#define FMC_SPI_TIMING_CFG   0x08
> +#define TIMING_CFG_TCSH(nr)  (((nr) & 0xf) << 8)
> +#define TIMING_CFG_TCSS(nr)  (((nr) & 0xf) << 4)
> +#define TIMING_CFG_TSHSL(nr) ((nr) & 0xf)
> +#define CS_HOLD_TIME 0x6
> +#define CS_SETUP_TIME0x6
> +#define CS_DESELECT_TIME 0xf
> +#define FMC_INT  0x18
> +#define FMC_INT_OP_DONE  BIT(0)
> +#define FMC_INT_CLR  0x20
> +#define FMC_CMD  0x24
> +#define FMC_CMD_CMD1(_cmd)   ((_cmd) & 0xff)

Drop the underscores in the argument names.

> +#define FMC_ADDRL0x2c
> +#define FMC_OP_CFG   0x30
> +#define OP_CFG_FM_CS(_cs)((_cs) << 11)
> +#define OP_CFG_MEM_IF_TYPE(_type)(((_type) & 0x7) << 7)
> +#define OP_CFG_ADDR_NUM(_addr)   (((_addr) & 0x7) << 4)
> +#define OP_CFG_DUMMY_NUM(_dummy) ((_dummy) & 0xf)
> +#define FMC_DATA_NUM 0x38
> +#define FMC_DATA_NUM_CNT(_n) ((_n) & 0x3fff)
> +#define FMC_OP   0x3c
> +#define FMC_OP_DUMMY_EN  BIT(8)
> +#define FMC_OP_CMD1_EN   BIT(7)
> +#define FMC_OP_ADDR_EN   BIT(6)
> +#define FMC_OP_WRITE_DATA_EN BIT(5)
> +#define FMC_OP_READ_DATA_EN  BIT(2)
> +#define FMC_OP_READ_STATUS_ENBIT(1)
> +#define FMC_OP_REG_OP_START  BIT(0)

[...]

> +enum hifmc_iftype {
> + IF_TYPE_STD,
> + IF_TYPE_DUAL,
> + IF_TYPE_DIO,
> + IF_TYPE_QUAD,
> + IF_TYPE_QIO,
> +};
> +
> +struct hifmc_priv {
> + int chipselect;

Can chipselect be set to < 0 values ?

> + u32 clkrate;
> + struct hifmc_host *host;
> +};
> +
> +#define HIFMC_MAX_CHIP_NUM   2

This does not scale very well, use dynamic allocation.

> +struct hifmc_host {
> + struct device *dev;
> + struct mutex lock;
> +
> + void __iomem *regbase;
> + void __iomem *iobase;
> + struct clk *clk;
> + void *buffer;
> + dma_addr_t dma_buffer;
> +
> + struct spi_nor  nor[HIFMC_MAX_CHIP_NUM];
> + struct hifmc_priv priv[HIFMC_MAX_CHIP_NUM];
> + int num_chip;
> +};
> +
> +static inline int wait_op_finish(struct hifmc_host *host)
> +{
> + unsigned int reg;
> +
> + return readl_poll_timeout(host->regbase + FMC_INT, reg,
> + (reg & FMC_INT_OP_DONE), 0, FMC_WAIT_TIMEOUT);
> +}
> +
> +static int get_if_type(enum read_mode flash_read)
> +{
> + enum hifmc_iftype if_type;
> +
> + switch (flash_read) {
> + case SPI_NOR_DUAL:
> + if_type = IF_TYPE_DUAL;
> + break;
> + case SPI_NOR_QUAD:
> + if_type = IF_TYPE_QUAD;
> + break;
> + case SPI_NOR_NORMAL:
> + case SPI_NOR_FAST:
> + default:
> + if_type = IF_TYPE_STD;
> + break;
> + }
> +
> + return if_type;
> +}
> +
> +static void hisi_spi_nor_init(struct hifmc_host *host)
> +{
> + unsigned int reg;

Should be u32 here.

> + reg = TIMING_CFG_TCSH(CS_HOLD_TIME)
> + | TIMING_CFG_TCSS(CS_SETUP_TIME)
> + | TIMING_CFG_TSHSL(CS_DESELECT_TIME);
> + writel(reg, host->regbase + FMC_SPI_TIMING_CFG);
> +}
> +
> +static int hisi_spi_nor_prep(struct spi_nor *nor, enum spi_nor_ops ops)
> +{
> + struct hifmc_priv *priv = nor->priv;
> + struct hifmc_host *host = priv->host;
> + int ret;
> +
> + mutex_lock(>lock);

Why do you need the mutex lock here ? Let me guess -- SPI NOR framework
locks a mutex in struct spi_nor , but that's not enough if you have
multiple SPI NORs on the same bus, because concurrent access to multiple
SPI NOR flashes needs locking on the controller level, right ?

> + ret = clk_set_rate(host->clk, priv->clkrate);
> + if (ret)
> + goto out;
> +
> + ret = clk_prepare_enable(host->clk);
> + if (ret)
> + goto out;
> +
> + return 0;
> +
> +out:
> + mutex_unlock(>lock);
> + return ret;
> +}
> +
> +static void hisi_spi_nor_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
> +{
> + struct 

Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data

[Rafael J. Wysocki]

On Sat, Mar 26, 2016 at 3:05 AM, Rafael J. Wysocki  wrote:
> On Sat, Mar 26, 2016 at 2:12 AM, Steve Muckle  wrote:
>> Hi Rafael,
>>
>> On 03/21/2016 06:54 PM, Rafael J. Wysocki wrote:
>> ...
>>> +config CPU_FREQ_GOV_SCHEDUTIL
>>> + tristate "'schedutil' cpufreq policy governor"
>>> + depends on CPU_FREQ
>>> + select CPU_FREQ_GOV_ATTR_SET
>>> + select IRQ_WORK
>>> + help
>>> +   The frequency selection formula used by this governor is analogous
>>> +   to the one used by 'ondemand', but instead of computing CPU load
>>> +   as the "non-idle CPU time" to "total CPU time" ratio, it uses CPU
>>> +   utilization data provided by the scheduler as input.
>>
>> The formula's changed a bit from ondemand - can the formula description
>> in the commit text be repackaged a bit and used here?
>
> Right, I forgot to update this help text.
>
> I'll figure out what to do here.
>
>> ...
>>> +
>>> +static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
>>> + unsigned int next_freq)
>>> +{
>>> + struct cpufreq_policy *policy = sg_policy->policy;
>>> +
>>> + sg_policy->last_freq_update_time = time;
>>> +
>>> + if (policy->fast_switch_enabled) {
>>> + if (next_freq > policy->max)
>>> + next_freq = policy->max;
>>> + else if (next_freq < policy->min)
>>> + next_freq = policy->min;
>>
>> The __cpufreq_driver_target() interface has this capping in it. For
>> uniformity should this be pushed into cpufreq_driver_fast_switch()?
>
> It could, but see below.

It should be doable regardless unless I'm overlooking something.  Will try.

[cut]

>> ...
>>> +static int sugov_limits(struct cpufreq_policy *policy)
>>> +{
>>> + struct sugov_policy *sg_policy = policy->governor_data;
>>> +
>>> + if (!policy->fast_switch_enabled) {
>>> + mutex_lock(_policy->work_lock);
>>> +
>>> + if (policy->max < policy->cur)
>>> + __cpufreq_driver_target(policy, policy->max,
>>> + CPUFREQ_RELATION_H);
>>> + else if (policy->min > policy->cur)
>>> + __cpufreq_driver_target(policy, policy->min,
>>> + CPUFREQ_RELATION_L);
>>> +
>>> + mutex_unlock(_policy->work_lock);
>>> + }
>>
>> Is the expectation that in the fast_switch_enabled case we should
>> re-evaluate soon enough that an explicit fixup is not required here?
>
> Yes, it is.
>
>> I'm worried as to whether that will always be true given the possible
>> criticality of applying frequency limits (thermal for example).
>
> The part of the patch below that you cut actually takes care of that:
>
> sg_policy->need_freq_update = true;
>
> which causes the rate limit to be ignored essentially, so the
> frequency will be changed on the first update from the scheduler.
> Which also is why the min/max check is before the sg_policy->next_freq
> == next_freq check in sugov_update_commit().
>
> I wanted to avoid locking in the fast switch/one CPU per policy case
> which otherwise would be necessary just for the handling of this
> thing.  I'd like to keep it the way it is unless it can be clearly
> demonstrated that it really would lead to problems in practice in a
> real system.

Besides, even if frequency is updated directly from here in the "fast
switch" case, that still doesn't guarantee that it will be updated
immediately, because the task running this code may be preempted and
only scheduled again in the next cycle.  Not to mention the fact that
it may not run on the CPU to be updated, so it would need to use
something like smp_call_function_single() for the update and that
would complicate things even more.

Overall, I don't really think that doing the update directly from here
in the "fast switch" case would improve things much latency-wise and
it would increase complexity and introduce overhead into the fast
path.  So this really is a tradeoff and the current choice is the
right one IMO.

Thanks,
Rafael

Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data

[Rafael J. Wysocki]

On Sat, Mar 26, 2016 at 3:05 AM, Rafael J. Wysocki  wrote:
> On Sat, Mar 26, 2016 at 2:12 AM, Steve Muckle  wrote:
>> Hi Rafael,
>>
>> On 03/21/2016 06:54 PM, Rafael J. Wysocki wrote:
>> ...
>>> +config CPU_FREQ_GOV_SCHEDUTIL
>>> + tristate "'schedutil' cpufreq policy governor"
>>> + depends on CPU_FREQ
>>> + select CPU_FREQ_GOV_ATTR_SET
>>> + select IRQ_WORK
>>> + help
>>> +   The frequency selection formula used by this governor is analogous
>>> +   to the one used by 'ondemand', but instead of computing CPU load
>>> +   as the "non-idle CPU time" to "total CPU time" ratio, it uses CPU
>>> +   utilization data provided by the scheduler as input.
>>
>> The formula's changed a bit from ondemand - can the formula description
>> in the commit text be repackaged a bit and used here?
>
> Right, I forgot to update this help text.
>
> I'll figure out what to do here.
>
>> ...
>>> +
>>> +static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
>>> + unsigned int next_freq)
>>> +{
>>> + struct cpufreq_policy *policy = sg_policy->policy;
>>> +
>>> + sg_policy->last_freq_update_time = time;
>>> +
>>> + if (policy->fast_switch_enabled) {
>>> + if (next_freq > policy->max)
>>> + next_freq = policy->max;
>>> + else if (next_freq < policy->min)
>>> + next_freq = policy->min;
>>
>> The __cpufreq_driver_target() interface has this capping in it. For
>> uniformity should this be pushed into cpufreq_driver_fast_switch()?
>
> It could, but see below.

It should be doable regardless unless I'm overlooking something.  Will try.

[cut]

>> ...
>>> +static int sugov_limits(struct cpufreq_policy *policy)
>>> +{
>>> + struct sugov_policy *sg_policy = policy->governor_data;
>>> +
>>> + if (!policy->fast_switch_enabled) {
>>> + mutex_lock(_policy->work_lock);
>>> +
>>> + if (policy->max < policy->cur)
>>> + __cpufreq_driver_target(policy, policy->max,
>>> + CPUFREQ_RELATION_H);
>>> + else if (policy->min > policy->cur)
>>> + __cpufreq_driver_target(policy, policy->min,
>>> + CPUFREQ_RELATION_L);
>>> +
>>> + mutex_unlock(_policy->work_lock);
>>> + }
>>
>> Is the expectation that in the fast_switch_enabled case we should
>> re-evaluate soon enough that an explicit fixup is not required here?
>
> Yes, it is.
>
>> I'm worried as to whether that will always be true given the possible
>> criticality of applying frequency limits (thermal for example).
>
> The part of the patch below that you cut actually takes care of that:
>
> sg_policy->need_freq_update = true;
>
> which causes the rate limit to be ignored essentially, so the
> frequency will be changed on the first update from the scheduler.
> Which also is why the min/max check is before the sg_policy->next_freq
> == next_freq check in sugov_update_commit().
>
> I wanted to avoid locking in the fast switch/one CPU per policy case
> which otherwise would be necessary just for the handling of this
> thing.  I'd like to keep it the way it is unless it can be clearly
> demonstrated that it really would lead to problems in practice in a
> real system.

Besides, even if frequency is updated directly from here in the "fast
switch" case, that still doesn't guarantee that it will be updated
immediately, because the task running this code may be preempted and
only scheduled again in the next cycle.  Not to mention the fact that
it may not run on the CPU to be updated, so it would need to use
something like smp_call_function_single() for the update and that
would complicate things even more.

Overall, I don't really think that doing the update directly from here
in the "fast switch" case would improve things much latency-wise and
it would increase complexity and introduce overhead into the fast
path.  So this really is a tradeoff and the current choice is the
right one IMO.

Thanks,
Rafael

Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17

[Paul E. McKenney]

On Sat, Mar 26, 2016 at 10:22:57PM +, Mathieu Desnoyers wrote:
> - On Mar 26, 2016, at 2:49 PM, Paul E. McKenney 
> paul...@linux.vnet.ibm.com wrote:
> 
> > On Sat, Mar 26, 2016 at 08:28:16AM -0700, Paul E. McKenney wrote:
> >> On Sat, Mar 26, 2016 at 12:29:31PM +, Mathieu Desnoyers wrote:
> >> > - On Mar 25, 2016, at 5:46 PM, Paul E. McKenney 
> >> > paul...@linux.vnet.ibm.com
> >> > wrote:
> >> > 
> >> > > On Fri, Mar 25, 2016 at 09:24:14PM +, Chatre, Reinette wrote:
> >> > >> Hi  Paul,
> >> > >> 
> >> > >> On 2016-03-23, Paul E. McKenney wrote:
> >> > >> > Please boot with the following parameters:
> >> > >> > 
> >> > >> > rcu_tree.rcu_kick_kthreads ftrace
> >> > >> > trace_event=sched_waking,sched_wakeup,sched_wake_idle_without_ipi
> >> > >> 
> >> > >> With these parameters I expected more details to show up in the 
> >> > >> kernel logs but
> >> > >> cannot find any. Even so, today I left the machine running again and 
> >> > >> when this
> >> > >> happened I think I was able to capture the trace data for the event. 
> >> > >> Please
> >> > >> find attached the trace information for the kernel message below. 
> >> > >> Since the
> >> > >> complete trace file is very big I trimmed it to show the time around 
> >> > >> this event
> >> > >> - hopefully this will contain the information you need. I would also 
> >> > >> like to
> >> > >> provide some additional information. The system on which I see these 
> >> > >> events had
> >> > >> a time that was _very_ wrong. I noticed that this issue occurs when
> >> > >> system-timesynd was one of the tasks calling the functions of 
> >> > >> interest to your
> >> > >> tracing and am wondering if a very out of sync time in process of 
> >> > >> being
> >> > >> corrected could be the cause of this issue? As an experiment I 
> >> > >> ensured the
> >> > >> system time was accurate before leaving the system idle overnight and 
> >> > >> I did not
> >> > >> see the issue the next morning.
> >> > > 
> >> > > Ah!  Yes, a sudden jump in time or a disagreement about the time among
> >> > > different components of the system can definitely cause these symptoms.
> >> > > We have sometimes seen these problems occur when a pair of CPUs have
> >> > > wildly different ideas about what time it is, for example.  Please let
> >> > > me know how it goes.
> >> > > 
> >> > > Also, in your trace, there are no sched_waking events for the 
> >> > > rcu_preempt
> >> > > process that are not immediately followed by sched_wakeup, so your 
> >> > > trace
> >> > > isn't showing the problem that I am seeing.
> >> > 
> >> > This is interesting.
> >> > 
> >> > Perhaps we could try with those commits reverted ?
> >> > 
> >> > commit e3baac47f0e82c4be632f4f97215bb93bf16b342
> >> > Author: Peter Zijlstra 
> >> > Date:   Wed Jun 4 10:31:18 2014 -0700
> >> > 
> >> > sched/idle: Optimize try-to-wake-up IPI
> >> > 
> >> > commit fd99f91aa007ba255aac44fe6cf21c1db398243a
> >> > Author: Peter Zijlstra 
> >> > Date:   Wed Apr 9 15:35:08 2014 +0200
> >> > 
> >> > sched/idle: Avoid spurious wakeup IPIs
> >> > 
> >> > They appeared in 3.16.
> >> 
> >> At this point, I am up for trying pretty much anything.  ;-)
> >> 
> >> Will give it a go.
> > 
> > And those certainly don't revert cleanly!  Would patching the kernel
> > to remove the definition of TIF_POLLING_NRFLAG be useful?  Or, more
> > to the point, is there some other course of action that would be more
> > useful?  At this point, the test times are measured in weeks...
> 
> Indeed, patching the kernel to remove the TIF_POLLING_NRFLAG
> definition would have an effect similar to reverting those two
> commits.
> 
> Since testing takes a while, we could take a more aggressive
> approach towards reproducing a possible race condition: we
> could re-implement the _TIF_POLLING_NRFLAG vs _TIF_NEED_RESCHED
> dance, along with the ttwu pending lock-list queue, within
> a dummy test module, with custom data structures, and
> stress-test the invariants. We could also create a Promela
> model of these ipi-skip optimisations trying to validate
> progress: whenever a wakeup is requested, there should
> always be a scheduling performed, even if no further wakeup
> is encountered.
> 
> Each of the two approaches proposed above might be a significant
> endeavor, and would only validate my specific hunch. So it might
> be a good idea to just let a test run for a few weeks with
> TIF_POLLING_NRFLAG disabled meanwhile.

This makes a lot of sense.  I did some short runs, and nothing broke
too badly.  However, I left some diagnostic stuff in that obscured
the outcome.  I disabled the diagnostic stuff and am running overnight.
I might need to go further and revert some of my diagnostic patches,
but let's see where it is in the morning.

Thanx, Paul

Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17

[Paul E. McKenney]

On Sat, Mar 26, 2016 at 10:22:57PM +, Mathieu Desnoyers wrote:
> - On Mar 26, 2016, at 2:49 PM, Paul E. McKenney 
> paul...@linux.vnet.ibm.com wrote:
> 
> > On Sat, Mar 26, 2016 at 08:28:16AM -0700, Paul E. McKenney wrote:
> >> On Sat, Mar 26, 2016 at 12:29:31PM +, Mathieu Desnoyers wrote:
> >> > - On Mar 25, 2016, at 5:46 PM, Paul E. McKenney 
> >> > paul...@linux.vnet.ibm.com
> >> > wrote:
> >> > 
> >> > > On Fri, Mar 25, 2016 at 09:24:14PM +, Chatre, Reinette wrote:
> >> > >> Hi  Paul,
> >> > >> 
> >> > >> On 2016-03-23, Paul E. McKenney wrote:
> >> > >> > Please boot with the following parameters:
> >> > >> > 
> >> > >> > rcu_tree.rcu_kick_kthreads ftrace
> >> > >> > trace_event=sched_waking,sched_wakeup,sched_wake_idle_without_ipi
> >> > >> 
> >> > >> With these parameters I expected more details to show up in the 
> >> > >> kernel logs but
> >> > >> cannot find any. Even so, today I left the machine running again and 
> >> > >> when this
> >> > >> happened I think I was able to capture the trace data for the event. 
> >> > >> Please
> >> > >> find attached the trace information for the kernel message below. 
> >> > >> Since the
> >> > >> complete trace file is very big I trimmed it to show the time around 
> >> > >> this event
> >> > >> - hopefully this will contain the information you need. I would also 
> >> > >> like to
> >> > >> provide some additional information. The system on which I see these 
> >> > >> events had
> >> > >> a time that was _very_ wrong. I noticed that this issue occurs when
> >> > >> system-timesynd was one of the tasks calling the functions of 
> >> > >> interest to your
> >> > >> tracing and am wondering if a very out of sync time in process of 
> >> > >> being
> >> > >> corrected could be the cause of this issue? As an experiment I 
> >> > >> ensured the
> >> > >> system time was accurate before leaving the system idle overnight and 
> >> > >> I did not
> >> > >> see the issue the next morning.
> >> > > 
> >> > > Ah!  Yes, a sudden jump in time or a disagreement about the time among
> >> > > different components of the system can definitely cause these symptoms.
> >> > > We have sometimes seen these problems occur when a pair of CPUs have
> >> > > wildly different ideas about what time it is, for example.  Please let
> >> > > me know how it goes.
> >> > > 
> >> > > Also, in your trace, there are no sched_waking events for the 
> >> > > rcu_preempt
> >> > > process that are not immediately followed by sched_wakeup, so your 
> >> > > trace
> >> > > isn't showing the problem that I am seeing.
> >> > 
> >> > This is interesting.
> >> > 
> >> > Perhaps we could try with those commits reverted ?
> >> > 
> >> > commit e3baac47f0e82c4be632f4f97215bb93bf16b342
> >> > Author: Peter Zijlstra 
> >> > Date:   Wed Jun 4 10:31:18 2014 -0700
> >> > 
> >> > sched/idle: Optimize try-to-wake-up IPI
> >> > 
> >> > commit fd99f91aa007ba255aac44fe6cf21c1db398243a
> >> > Author: Peter Zijlstra 
> >> > Date:   Wed Apr 9 15:35:08 2014 +0200
> >> > 
> >> > sched/idle: Avoid spurious wakeup IPIs
> >> > 
> >> > They appeared in 3.16.
> >> 
> >> At this point, I am up for trying pretty much anything.  ;-)
> >> 
> >> Will give it a go.
> > 
> > And those certainly don't revert cleanly!  Would patching the kernel
> > to remove the definition of TIF_POLLING_NRFLAG be useful?  Or, more
> > to the point, is there some other course of action that would be more
> > useful?  At this point, the test times are measured in weeks...
> 
> Indeed, patching the kernel to remove the TIF_POLLING_NRFLAG
> definition would have an effect similar to reverting those two
> commits.
> 
> Since testing takes a while, we could take a more aggressive
> approach towards reproducing a possible race condition: we
> could re-implement the _TIF_POLLING_NRFLAG vs _TIF_NEED_RESCHED
> dance, along with the ttwu pending lock-list queue, within
> a dummy test module, with custom data structures, and
> stress-test the invariants. We could also create a Promela
> model of these ipi-skip optimisations trying to validate
> progress: whenever a wakeup is requested, there should
> always be a scheduling performed, even if no further wakeup
> is encountered.
> 
> Each of the two approaches proposed above might be a significant
> endeavor, and would only validate my specific hunch. So it might
> be a good idea to just let a test run for a few weeks with
> TIF_POLLING_NRFLAG disabled meanwhile.

This makes a lot of sense.  I did some short runs, and nothing broke
too badly.  However, I left some diagnostic stuff in that obscured
the outcome.  I disabled the diagnostic stuff and am running overnight.
I might need to go further and revert some of my diagnostic patches,
but let's see where it is in the morning.

Thanx, Paul

Re: [PATCH v8 2/4] gadget: Support for the usb charger framework

[kbuild test robot]

Hi Baolin,

[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160324]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20160324-204018
config: m68k-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

>> ERROR: "usb_charger_init" [drivers/usb/gadget/udc/udc-core.ko] undefined!
>> ERROR: "usb_charger_plug_by_gadget" [drivers/usb/gadget/udc/udc-core.ko] 
>> undefined!
>> ERROR: "usb_charger_exit" [drivers/usb/gadget/udc/udc-core.ko] undefined!
>> ERROR: "usb_charger_set_cur_limit_by_type" 
>> [drivers/usb/gadget/libcomposite.ko] undefined!
>> ERROR: "usb_charger_detect_type" [drivers/usb/gadget/libcomposite.ko] 
>> undefined!
>> ERROR: "usb_charger_set_cur_limit_by_type" 
>> [drivers/usb/gadget/legacy/gadgetfs.ko] undefined!
>> ERROR: "usb_charger_detect_type" [drivers/usb/gadget/legacy/gadgetfs.ko] 
>> undefined!

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


.config.gz
Description: Binary data

Re: [PATCH v8 2/4] gadget: Support for the usb charger framework

[kbuild test robot]

Hi Baolin,

[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160324]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20160324-204018
config: m68k-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

>> ERROR: "usb_charger_init" [drivers/usb/gadget/udc/udc-core.ko] undefined!
>> ERROR: "usb_charger_plug_by_gadget" [drivers/usb/gadget/udc/udc-core.ko] 
>> undefined!
>> ERROR: "usb_charger_exit" [drivers/usb/gadget/udc/udc-core.ko] undefined!
>> ERROR: "usb_charger_set_cur_limit_by_type" 
>> [drivers/usb/gadget/libcomposite.ko] undefined!
>> ERROR: "usb_charger_detect_type" [drivers/usb/gadget/libcomposite.ko] 
>> undefined!
>> ERROR: "usb_charger_set_cur_limit_by_type" 
>> [drivers/usb/gadget/legacy/gadgetfs.ko] undefined!
>> ERROR: "usb_charger_detect_type" [drivers/usb/gadget/legacy/gadgetfs.ko] 
>> undefined!

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


.config.gz
Description: Binary data

Re: [PATCH v6 6/7][Resend] cpufreq: Support for fast frequency switching

[Rafael J. Wysocki]

On Sat, Mar 26, 2016 at 2:46 AM, Rafael J. Wysocki  wrote:
> On Sat, Mar 26, 2016 at 2:12 AM, Steve Muckle  wrote:
>> Hi Rafael,
>>
>> On 03/21/2016 06:53 PM, Rafael J. Wysocki wrote:
>>> Add two new policy flags, fast_switch_possible, to be set by the
>>> cpufreq driver if fast frequency switching can be used for the
>>> given policy and fast_switch_enabled, to be set by the governor
>>> if it is going to use fast frequency switching for the given
>>> policy.  Also add a helper for setting the latter.
>> ...
>>> @@ -740,6 +777,9 @@ static int acpi_cpufreq_cpu_init(struct
>>>   goto err_unreg;
>>>   }
>>>
>>> + policy->fast_switch_possible = !acpi_pstate_strict &&
>>> + !(policy_is_shared(policy) && policy->shared_type != 
>>> CPUFREQ_SHARED_TYPE_ANY);
>>
>> Could the policy->fast_switch_possible flag be avoided by just checking
>> whether a driver has registered the .fast_switch callback?
>
> No, it couldn't.
>
> As in this case, the driver has the ->fast_switch callback, but it
> can't be used for policies that don't satisfy the above condition.  At
> the same time it may be possible to use it for other policies on the
> same system in principle.

In fact, for fast switching to be useful, the driver has to guarantee
that frequency can be updated on any of the policy CPUs (and it
doesn't matter which of them updates the frequency) and that's what
the fast_switch_possible flag is really for.  I guess I should add a
comment to that effect to its definition.

Thanks,
Rafael

Re: [PATCH v6 6/7][Resend] cpufreq: Support for fast frequency switching

[Rafael J. Wysocki]

On Sat, Mar 26, 2016 at 2:46 AM, Rafael J. Wysocki  wrote:
> On Sat, Mar 26, 2016 at 2:12 AM, Steve Muckle  wrote:
>> Hi Rafael,
>>
>> On 03/21/2016 06:53 PM, Rafael J. Wysocki wrote:
>>> Add two new policy flags, fast_switch_possible, to be set by the
>>> cpufreq driver if fast frequency switching can be used for the
>>> given policy and fast_switch_enabled, to be set by the governor
>>> if it is going to use fast frequency switching for the given
>>> policy.  Also add a helper for setting the latter.
>> ...
>>> @@ -740,6 +777,9 @@ static int acpi_cpufreq_cpu_init(struct
>>>   goto err_unreg;
>>>   }
>>>
>>> + policy->fast_switch_possible = !acpi_pstate_strict &&
>>> + !(policy_is_shared(policy) && policy->shared_type != 
>>> CPUFREQ_SHARED_TYPE_ANY);
>>
>> Could the policy->fast_switch_possible flag be avoided by just checking
>> whether a driver has registered the .fast_switch callback?
>
> No, it couldn't.
>
> As in this case, the driver has the ->fast_switch callback, but it
> can't be used for policies that don't satisfy the above condition.  At
> the same time it may be possible to use it for other policies on the
> same system in principle.

In fact, for fast switching to be useful, the driver has to guarantee
that frequency can be updated on any of the policy CPUs (and it
doesn't matter which of them updates the frequency) and that's what
the fast_switch_possible flag is really for.  I guess I should add a
comment to that effect to its definition.

Thanks,
Rafael

[PATCH] drivers/iommu: don't select DEBUG_FS for AMD_IOMMU_STATS

[Paul Gortmaker]

We have at least one big banner telling people that they should
not deploy production kernels with DEBUG options enabled, but
at the same time, we make it hard for people to turn DEBUG_FS
off when we select (vs. depend on) the CONFIG_DEBUG_FS option.

Since we actively discourage people using debug-like features
on any builds that are production oriented (see trace_printk
banner for one example), so a generic sounding option should
not select DEBUG_FS.

Since this is not a system critical option, convert it from a
select to a depend -- this makes it nicer for us old school folk
who edit .config and then run "make oldconfig" as a (bad?) habit.

Cc: Joerg Roedel 
Cc: "Steven Rostedt (Red Hat)" 
Cc: io...@lists.linux-foundation.org
Signed-off-by: Paul Gortmaker 
---
 drivers/iommu/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd1dc39f84ff..959032bdbe12 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -126,8 +126,7 @@ config AMD_IOMMU
 
 config AMD_IOMMU_STATS
bool "Export AMD IOMMU statistics to debugfs"
-   depends on AMD_IOMMU
-   select DEBUG_FS
+   depends on AMD_IOMMU && DEBUG_FS
---help---
  This option enables code in the AMD IOMMU driver to collect various
  statistics about whats happening in the driver and exports that
-- 
2.6.1

[PATCH] drivers/iommu: don't select DEBUG_FS for AMD_IOMMU_STATS

[Paul Gortmaker]

We have at least one big banner telling people that they should
not deploy production kernels with DEBUG options enabled, but
at the same time, we make it hard for people to turn DEBUG_FS
off when we select (vs. depend on) the CONFIG_DEBUG_FS option.

Since we actively discourage people using debug-like features
on any builds that are production oriented (see trace_printk
banner for one example), so a generic sounding option should
not select DEBUG_FS.

Since this is not a system critical option, convert it from a
select to a depend -- this makes it nicer for us old school folk
who edit .config and then run "make oldconfig" as a (bad?) habit.

Cc: Joerg Roedel 
Cc: "Steven Rostedt (Red Hat)" 
Cc: io...@lists.linux-foundation.org
Signed-off-by: Paul Gortmaker 
---
 drivers/iommu/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd1dc39f84ff..959032bdbe12 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -126,8 +126,7 @@ config AMD_IOMMU
 
 config AMD_IOMMU_STATS
bool "Export AMD IOMMU statistics to debugfs"
-   depends on AMD_IOMMU
-   select DEBUG_FS
+   depends on AMD_IOMMU && DEBUG_FS
---help---
  This option enables code in the AMD IOMMU driver to collect various
  statistics about whats happening in the driver and exports that
-- 
2.6.1

Hello

[Miss. Barbara]

Hello My dear.
How are you doing today and how is everything over there together with your 
health? i hope that you are in good condition of health, i want to use this 
opportunity to introduce myself to you. My name is Miss barbara.   so i will 
like you to reply  me  with my contact email address 
(barbara.zak...@hotmail.com) so that i will show you my photo and also tell you 
everything about myself and i will also like to know more about you. thanks for 
your understand and i will be hoping to hear from you soon. Yours barbara.
(barbara.zak...@hotmail.com)

Hello

[Miss. Barbara]

Hello My dear.
How are you doing today and how is everything over there together with your 
health? i hope that you are in good condition of health, i want to use this 
opportunity to introduce myself to you. My name is Miss barbara.   so i will 
like you to reply  me  with my contact email address 
(barbara.zak...@hotmail.com) so that i will show you my photo and also tell you 
everything about myself and i will also like to know more about you. thanks for 
your understand and i will be hoping to hear from you soon. Yours barbara.
(barbara.zak...@hotmail.com)

Problems with commit a770d946371e ("gpio: pxa: add pin control gpio direction and request")

[Guenter Roeck]

Hi,

when trying pxa_defconfig with various pxa270 and pxa255 qemu targets, I 
noticed that the gpio
pin direction is no longer set. Bisect points to commit a770d946371e ("gpio: 
pxa: add pin control
gpio direction and request"). As it turns out, pxa_defconfig does not configure 
PINCTRL. As a result,
pinctrl stub functions are used. Those all return 0 if PINCTRL is not 
configured. This causes the
pxa gpio driver to wrongly assume that pinctrl configured the gpio pin 
direction, and does nothing.

Looking into gpio-mvebu.c, its use of the pinctrl functions is completely 
different. It aborts
on error, not on success, from the pinctrl functions. Given that, I have no 
idea how to resolve
the problem. Having the stub functions return an error might cause the mvebu 
driver (and maybe
others) to fail if there is no pinctrl driver, so that does not seem to be an 
option.

If the idea is to mandate pinctrl for PXA architectures, it should probably be 
enabled for those
architectures. Unless I am missing something, PXA architectures to not select 
PINCTRL, which
suggests that the problem may affect a wide range of systems. Please have a 
look.

Thanks,
Guenter

Problems with commit a770d946371e ("gpio: pxa: add pin control gpio direction and request")

[Guenter Roeck]

Hi,

when trying pxa_defconfig with various pxa270 and pxa255 qemu targets, I 
noticed that the gpio
pin direction is no longer set. Bisect points to commit a770d946371e ("gpio: 
pxa: add pin control
gpio direction and request"). As it turns out, pxa_defconfig does not configure 
PINCTRL. As a result,
pinctrl stub functions are used. Those all return 0 if PINCTRL is not 
configured. This causes the
pxa gpio driver to wrongly assume that pinctrl configured the gpio pin 
direction, and does nothing.

Looking into gpio-mvebu.c, its use of the pinctrl functions is completely 
different. It aborts
on error, not on success, from the pinctrl functions. Given that, I have no 
idea how to resolve
the problem. Having the stub functions return an error might cause the mvebu 
driver (and maybe
others) to fail if there is no pinctrl driver, so that does not seem to be an 
option.

If the idea is to mandate pinctrl for PXA architectures, it should probably be 
enabled for those
architectures. Unless I am missing something, PXA architectures to not select 
PINCTRL, which
suggests that the problem may affect a wide range of systems. Please have a 
look.

Thanks,
Guenter

drivers/infiniband/hw/mlx5/main.c:2357:31: error: 'mlx5_ib_get_vf_config' undeclared

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f55532a0c0b8bb6148f4e07853b876ef73bc69ca
commit: eff901d30e6cebd940072637f112ce4d0090ac12 IB/mlx5: Implement callbacks 
for manipulating VFs
date:   5 days ago
config: x86_64-randconfig-s4-03270750 (attached as .config)
reproduce:
git checkout eff901d30e6cebd940072637f112ce4d0090ac12
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_add':
>> drivers/infiniband/hw/mlx5/main.c:2357:31: error: 'mlx5_ib_get_vf_config' 
>> undeclared (first use in this function)
  dev->ib_dev.get_vf_config = mlx5_ib_get_vf_config;
  ^
   drivers/infiniband/hw/mlx5/main.c:2357:31: note: each undeclared identifier 
is reported only once for each function it appears in
>> drivers/infiniband/hw/mlx5/main.c:2358:35: error: 
>> 'mlx5_ib_set_vf_link_state' undeclared (first use in this function)
  dev->ib_dev.set_vf_link_state = mlx5_ib_set_vf_link_state;
  ^
>> drivers/infiniband/hw/mlx5/main.c:2359:30: error: 'mlx5_ib_get_vf_stats' 
>> undeclared (first use in this function)
  dev->ib_dev.get_vf_stats = mlx5_ib_get_vf_stats;
 ^
>> drivers/infiniband/hw/mlx5/main.c:2360:30: error: 'mlx5_ib_set_vf_guid' 
>> undeclared (first use in this function)
  dev->ib_dev.set_vf_guid  = mlx5_ib_set_vf_guid;
 ^

vim +/mlx5_ib_get_vf_config +2357 drivers/infiniband/hw/mlx5/main.c

  2351  dev->ib_dev.process_mad = mlx5_ib_process_mad;
  2352  dev->ib_dev.alloc_mr= mlx5_ib_alloc_mr;
  2353  dev->ib_dev.map_mr_sg   = mlx5_ib_map_mr_sg;
  2354  dev->ib_dev.check_mr_status = mlx5_ib_check_mr_status;
  2355  dev->ib_dev.get_port_immutable  = mlx5_port_immutable;
  2356  if (mlx5_core_is_pf(mdev)) {
> 2357  dev->ib_dev.get_vf_config   = mlx5_ib_get_vf_config;
> 2358  dev->ib_dev.set_vf_link_state   = 
> mlx5_ib_set_vf_link_state;
> 2359  dev->ib_dev.get_vf_stats= mlx5_ib_get_vf_stats;
> 2360  dev->ib_dev.set_vf_guid = mlx5_ib_set_vf_guid;
  2361  }
  2362  
  2363  mlx5_ib_internal_fill_odp_caps(dev);

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


.config.gz
Description: Binary data

drivers/infiniband/hw/mlx5/main.c:2357:31: error: 'mlx5_ib_get_vf_config' undeclared

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f55532a0c0b8bb6148f4e07853b876ef73bc69ca
commit: eff901d30e6cebd940072637f112ce4d0090ac12 IB/mlx5: Implement callbacks 
for manipulating VFs
date:   5 days ago
config: x86_64-randconfig-s4-03270750 (attached as .config)
reproduce:
git checkout eff901d30e6cebd940072637f112ce4d0090ac12
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_add':
>> drivers/infiniband/hw/mlx5/main.c:2357:31: error: 'mlx5_ib_get_vf_config' 
>> undeclared (first use in this function)
  dev->ib_dev.get_vf_config = mlx5_ib_get_vf_config;
  ^
   drivers/infiniband/hw/mlx5/main.c:2357:31: note: each undeclared identifier 
is reported only once for each function it appears in
>> drivers/infiniband/hw/mlx5/main.c:2358:35: error: 
>> 'mlx5_ib_set_vf_link_state' undeclared (first use in this function)
  dev->ib_dev.set_vf_link_state = mlx5_ib_set_vf_link_state;
  ^
>> drivers/infiniband/hw/mlx5/main.c:2359:30: error: 'mlx5_ib_get_vf_stats' 
>> undeclared (first use in this function)
  dev->ib_dev.get_vf_stats = mlx5_ib_get_vf_stats;
 ^
>> drivers/infiniband/hw/mlx5/main.c:2360:30: error: 'mlx5_ib_set_vf_guid' 
>> undeclared (first use in this function)
  dev->ib_dev.set_vf_guid  = mlx5_ib_set_vf_guid;
 ^

vim +/mlx5_ib_get_vf_config +2357 drivers/infiniband/hw/mlx5/main.c

  2351  dev->ib_dev.process_mad = mlx5_ib_process_mad;
  2352  dev->ib_dev.alloc_mr= mlx5_ib_alloc_mr;
  2353  dev->ib_dev.map_mr_sg   = mlx5_ib_map_mr_sg;
  2354  dev->ib_dev.check_mr_status = mlx5_ib_check_mr_status;
  2355  dev->ib_dev.get_port_immutable  = mlx5_port_immutable;
  2356  if (mlx5_core_is_pf(mdev)) {
> 2357  dev->ib_dev.get_vf_config   = mlx5_ib_get_vf_config;
> 2358  dev->ib_dev.set_vf_link_state   = 
> mlx5_ib_set_vf_link_state;
> 2359  dev->ib_dev.get_vf_stats= mlx5_ib_get_vf_stats;
> 2360  dev->ib_dev.set_vf_guid = mlx5_ib_set_vf_guid;
  2361  }
  2362  
  2363  mlx5_ib_internal_fill_odp_caps(dev);

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


.config.gz
Description: Binary data

Re: [PATCH] intel_menlow: reduce code duplication

[Joe Perches]

On Sat, 2016-03-26 at 22:40 +0100, Rasmus Villemoes wrote:
> aux0_show and aux1_show consists of almost identical code. Pull that
> into a common helper and make them thin wrappers. Similarly for
> _store.

Seems sensible, thanks

> diff --git a/drivers/platform/x86/intel_menlow.c 
> b/drivers/platform/x86/intel_menlow.c
[]
> @@ -306,33 +306,32 @@ static int sensor_set_auxtrip(acpi_handle handle, int 
> index, int value)
>  #define to_intel_menlow_attr(_attr)  \
>   container_of(_attr, struct intel_menlow_attribute, attr)
>  
> -static ssize_t aux0_show(struct device *dev,
> -  struct device_attribute *dev_attr, char *buf)
> +static ssize_t aux_show(struct device *dev, struct device_attribute 
> *dev_attr,
> + char *buf, int idx)
>  {
>   struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
>   unsigned long long value;
>   int result;
>  
> - result = sensor_get_auxtrip(attr->handle, 0, );
> + result = sensor_get_auxtrip(attr->handle, idx, );
>  
>   return result ? result : sprintf(buf, "%lu", 
> DECI_KELVIN_TO_CELSIUS(value));

While not something you've done differently than the
existing code, perhaps this would be more common
without the ternary operator like:

result = sensor_get_auxtrip(attr->handle, idx, );
if (result < 0)
return result;

return sprintf(buf, "%lu", DECI_KELVIN_TO_CELSIUS(value));

Re: [PATCH] intel_menlow: reduce code duplication

[Joe Perches]

On Sat, 2016-03-26 at 22:40 +0100, Rasmus Villemoes wrote:
> aux0_show and aux1_show consists of almost identical code. Pull that
> into a common helper and make them thin wrappers. Similarly for
> _store.

Seems sensible, thanks

> diff --git a/drivers/platform/x86/intel_menlow.c 
> b/drivers/platform/x86/intel_menlow.c
[]
> @@ -306,33 +306,32 @@ static int sensor_set_auxtrip(acpi_handle handle, int 
> index, int value)
>  #define to_intel_menlow_attr(_attr)  \
>   container_of(_attr, struct intel_menlow_attribute, attr)
>  
> -static ssize_t aux0_show(struct device *dev,
> -  struct device_attribute *dev_attr, char *buf)
> +static ssize_t aux_show(struct device *dev, struct device_attribute 
> *dev_attr,
> + char *buf, int idx)
>  {
>   struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
>   unsigned long long value;
>   int result;
>  
> - result = sensor_get_auxtrip(attr->handle, 0, );
> + result = sensor_get_auxtrip(attr->handle, idx, );
>  
>   return result ? result : sprintf(buf, "%lu", 
> DECI_KELVIN_TO_CELSIUS(value));

While not something you've done differently than the
existing code, perhaps this would be more common
without the ternary operator like:

result = sensor_get_auxtrip(attr->handle, idx, );
if (result < 0)
return result;

return sprintf(buf, "%lu", DECI_KELVIN_TO_CELSIUS(value));

Re: [PATCH 2/2] regulator: core: Ensure we are at least in bounds for our constraints

[Bjorn Andersson]

On Thu, Mar 24, 2016 at 12:18 AM, Krzysztof Kozlowski
 wrote:
> On Thu, Mar 24, 2016 at 3:11 PM, Krzysztof Kozlowski
>  wrote:
>> On Tue, Mar 22, 2016 at 6:06 AM, Ivaylo Dimitrov
>>  wrote:
>>> Hi,
>>>
>>> On 21.03.2016 21:18, Mark Brown wrote:

 Currently we only attempt to set the voltage during constraints
 application if an exact voltage is specified.  Extend this so that if
 the currently set voltage for the regualtor is outside the bounds set in
>>>
>>>
>>> regulator
>>>
 constraints we will move the voltage to the nearest constraint, raising
 to the minimum or lowering to the maximum as needed.  This ensures that
 drivers can probe without the hardware being driven out of spec.

 Reported-by: Ivaylo Dimitrov 
 Signed-off-by: Mark Brown 
 ---

 Untested so far, will give it a spin later/tomorrow.

   drivers/regulator/core.c | 32 +---
   1 file changed, 25 insertions(+), 7 deletions(-)

>>>
>>> Patch 1 does not apply cleanly on 4.5-rc5, so I applied it by hand, however,
>>> you may add:
>>>
>>> Tested-by: Ivaylo Dimitrov 
>>
>>
>> Cc: Ulf, mmc
>>
>> I bisected today's next MMC/SD card failure to this patch. Plugging a
>> SD card on Odroid XU3/XU4 (Exynos5422) causes:
>> [   11.759954] mmc1: card never left busy state
>> [   11.762795] mmc1: error -110 whilst initialising SD card
>>

Mark,

I'm facing the same issue on my Qualcomm based boards; my eMMCs fails
to talk to me because I'm not powering them.

The problem in my case comes from the vmmc regulator having min_uV ==
max_uV and patch 1 in this series changes the logic of
of_get_regulation_constraints() to no longer set apply_uV. I.e. we end
up never calling set_voltage(), ever.

When the mmc framework calls regulator_set_load() to change voltage
REGULATOR_CHANGE_VOLTAGE is not set (because min == max) so we will
never call set_voltage().

Before patch 1 apply_uV was set and we did set up the voltage earlier,
so regulator_get_voltage() will return a valid voltage and
regulator_set_voltage() will succeed for the valid voltages (if the
range spans the current setting).


Reinstating the following snippet in of_get_regulation_constraints()
sort this out:
if (constraints->min_uV && constraints->max_uV)
   constraints->apply_uV = true;


I did look at an alternative of having regulator_set_voltage() pass
and call set_voltage() if the requested voltage matches the
constraints, but this does indeed seem to mess things up. So checking
in with you before continuing on that hack.

Regards,
Bjorn

Re: [PATCH 2/2] regulator: core: Ensure we are at least in bounds for our constraints

[Bjorn Andersson]

On Thu, Mar 24, 2016 at 12:18 AM, Krzysztof Kozlowski
 wrote:
> On Thu, Mar 24, 2016 at 3:11 PM, Krzysztof Kozlowski
>  wrote:
>> On Tue, Mar 22, 2016 at 6:06 AM, Ivaylo Dimitrov
>>  wrote:
>>> Hi,
>>>
>>> On 21.03.2016 21:18, Mark Brown wrote:

 Currently we only attempt to set the voltage during constraints
 application if an exact voltage is specified.  Extend this so that if
 the currently set voltage for the regualtor is outside the bounds set in
>>>
>>>
>>> regulator
>>>
 constraints we will move the voltage to the nearest constraint, raising
 to the minimum or lowering to the maximum as needed.  This ensures that
 drivers can probe without the hardware being driven out of spec.

 Reported-by: Ivaylo Dimitrov 
 Signed-off-by: Mark Brown 
 ---

 Untested so far, will give it a spin later/tomorrow.

   drivers/regulator/core.c | 32 +---
   1 file changed, 25 insertions(+), 7 deletions(-)

>>>
>>> Patch 1 does not apply cleanly on 4.5-rc5, so I applied it by hand, however,
>>> you may add:
>>>
>>> Tested-by: Ivaylo Dimitrov 
>>
>>
>> Cc: Ulf, mmc
>>
>> I bisected today's next MMC/SD card failure to this patch. Plugging a
>> SD card on Odroid XU3/XU4 (Exynos5422) causes:
>> [   11.759954] mmc1: card never left busy state
>> [   11.762795] mmc1: error -110 whilst initialising SD card
>>

Mark,

I'm facing the same issue on my Qualcomm based boards; my eMMCs fails
to talk to me because I'm not powering them.

The problem in my case comes from the vmmc regulator having min_uV ==
max_uV and patch 1 in this series changes the logic of
of_get_regulation_constraints() to no longer set apply_uV. I.e. we end
up never calling set_voltage(), ever.

When the mmc framework calls regulator_set_load() to change voltage
REGULATOR_CHANGE_VOLTAGE is not set (because min == max) so we will
never call set_voltage().

Before patch 1 apply_uV was set and we did set up the voltage earlier,
so regulator_get_voltage() will return a valid voltage and
regulator_set_voltage() will succeed for the valid voltages (if the
range spans the current setting).


Reinstating the following snippet in of_get_regulation_constraints()
sort this out:
if (constraints->min_uV && constraints->max_uV)
   constraints->apply_uV = true;


I did look at an alternative of having regulator_set_voltage() pass
and call set_voltage() if the requested voltage matches the
constraints, but this does indeed seem to mess things up. So checking
in with you before continuing on that hack.

Regards,
Bjorn

Linux 4.6-rc1

[Linus Torvalds]

So I'm closing the merge window a day early, partly because I have
some upcoming travel, but partly because this has actually been one of
the bigger merge windows in a while, and if somebody was planning on
trying to sneak in any last-minute features, I really don't want to
hear about it any more.

On the whole, despite the size of the merge window, this was mostly
pretty pain-free. There were fairly few conflicts, and the ARM tree
that traditionally has had the most of them was really one of the
easiest experiences ever. Good job.

Of course, to offset that, we did have some unusual filesystem issues,
with both f2fs and Ceph pulls being scolded for messing up their
trees, in both cases to try to make it easier for the merge, but in
both cases I really *really* want people to just worry about their own
code, not make changes to accommodate what happened outside their
trees.

But those were mainly about git maintenance issues, not the code itself..

And while on the filesystem side, it might be worth noting that we
also have a new filesystem this time: orangefs. It's actually been
pending for a longish while, with the original pull request coming in
last August or so, but it got delayed this long due to input from Al
that I think ended up making everybody much happier. The pull request
itself came in pretty late in the merge window, but I'm happy to have
it finally merged - the orangefs maintainers have been very responsive
to the issues that got brought up.

But as usual, the *bulk* of the changes - by far - are just all the
miscellaneous driver updates. So despite the filesystem work, drivers
account for about 2/3 of the bulk of the changes. It's all over:
staging drivers, networking, drm, rdma, usb, media, sound - you name
it.

Outside of drivers, the biggest remaining changes are as usual the
architecture updates: ARM devicetree updates being a big chunk, but
there's other arm (and arm64) updates, together with x86, powerpc,
s390, xtensa, and some m68k.

The rest is generic networking, filesystem updates (in addition to the
already mentioned orangefs, f2fs and ceph stuff, there's also xfs,
btrfs, ocfs2, ext4, and generic vfs updates). And core kernel work, as
well as doc updates and tooling updates.

So quite a bit of work all over. The shortlog being much too large to
post, I'm just appending my usual "merge log", which shows who I
pulled from along with a very short description. As always, the full
credits are to be found in the git tree.

Let's hope that a reasonably painfree merge window ends up translating
to an even more painfree calming down period, despite this being a
fairly big release.

Please?

  Linus

---

Al Viro (1):
  vfs updates

Alex Williamson (1):
  VFIO updates

Alexandre Belloni (2):
  RTC updates
  more RTC updates

Andrew Morton (4):
  first patch-bomb
  second patch-bomb
  third patch-bomb
  fourth patch-bomb

Arnd Bergmann (10):
  ARM SoC non-urgent fixes
  ARM SoC cleanups
  ARM SoC platform updates
  ARM SoC 64-bit changes
  ARM DT updates
  ARM 64-bit DT updates
  ARM SoC defconfig updates
  ARM SoC driver updates
  more ARM DT changes
  asm-generic updates

Bjorn Andersson (1):
  remoteproc updates

Bjorn Helgaas (2):
  PCI updates
  PCI fixes

Bob Peterson (1):
  GFS2 updates

Borislav Petkov (1):
  EDAC updates

Brian Norris (1):
  MTD updates

Bruce Fields (2):
  nfsd updates
  more nfsd updates

Catalin Marinas (2):
  arm64 updates
  second set of arm64 updates

Chris Mason (1):
  btrfs updates

Chris Zankel (1):
  Xtensa updates

Christoph Hellwig (1):
  configfs updates

Corey Minyard (1):
  IPMI updates

Dan Williams (1):
  libnvdimm updates

Darren Hart (1):
  x86 platform driver updates

Dave Airlie (2):
  drm updates
  drm fixes

Dave Chinner (1):
  xfs updates

David Miller (2):
  networking updates
  networking bugfixes

David Teigland (1):
  dlm updates

David Vrabel (1):
  xen updates

Dmitry Torokhov (2):
  input updates
  more input updates

Doug Ledford (2):
  rdma updates
  more rdma updates

Geert Uytterhoeven (1):
  m68k updates

Greg KH (7):
  driver core updates
  char/misc updates
  tty/serial updates
  USB updates
  staging driver updates
  USB fixes
  staging driver fixes

Greg Ungerer (1):
  m68knommu updates

Guenter Roeck (2):
  hwmon updates
  more hwmon updates

Hans-Christian Egtvedt (1):
  AVR32 updates

Helge Deller (1):
  parisc updates

Herbert Xu (2):
  crypto update
  crypto fixes

Ingo Molnar (24):
  ram resource handling changes
  locking changes
  dma_*_writecombine rename
  read-only kernel memory updates
  perf updates
  RAS updates
  scheduler updates
  NOHZ updates
  x86 asm updates
  x86 boot updates
  x86 build update
  x86 fpu updates
  x86 microcode updates
  x86 mm updates
  x86 core platform updates
  x86 timer update
  RCU updates
  'objtool' stack frame validation
  EFI updates
  x86 protection key support
  locking fixes
  scheduler fixes
  x86 fixes
  perf fixes

Jacek Anaszewski (1):
  LED updates

Linux 4.6-rc1

[Linus Torvalds]

So I'm closing the merge window a day early, partly because I have
some upcoming travel, but partly because this has actually been one of
the bigger merge windows in a while, and if somebody was planning on
trying to sneak in any last-minute features, I really don't want to
hear about it any more.

On the whole, despite the size of the merge window, this was mostly
pretty pain-free. There were fairly few conflicts, and the ARM tree
that traditionally has had the most of them was really one of the
easiest experiences ever. Good job.

Of course, to offset that, we did have some unusual filesystem issues,
with both f2fs and Ceph pulls being scolded for messing up their
trees, in both cases to try to make it easier for the merge, but in
both cases I really *really* want people to just worry about their own
code, not make changes to accommodate what happened outside their
trees.

But those were mainly about git maintenance issues, not the code itself..

And while on the filesystem side, it might be worth noting that we
also have a new filesystem this time: orangefs. It's actually been
pending for a longish while, with the original pull request coming in
last August or so, but it got delayed this long due to input from Al
that I think ended up making everybody much happier. The pull request
itself came in pretty late in the merge window, but I'm happy to have
it finally merged - the orangefs maintainers have been very responsive
to the issues that got brought up.

But as usual, the *bulk* of the changes - by far - are just all the
miscellaneous driver updates. So despite the filesystem work, drivers
account for about 2/3 of the bulk of the changes. It's all over:
staging drivers, networking, drm, rdma, usb, media, sound - you name
it.

Outside of drivers, the biggest remaining changes are as usual the
architecture updates: ARM devicetree updates being a big chunk, but
there's other arm (and arm64) updates, together with x86, powerpc,
s390, xtensa, and some m68k.

The rest is generic networking, filesystem updates (in addition to the
already mentioned orangefs, f2fs and ceph stuff, there's also xfs,
btrfs, ocfs2, ext4, and generic vfs updates). And core kernel work, as
well as doc updates and tooling updates.

So quite a bit of work all over. The shortlog being much too large to
post, I'm just appending my usual "merge log", which shows who I
pulled from along with a very short description. As always, the full
credits are to be found in the git tree.

Let's hope that a reasonably painfree merge window ends up translating
to an even more painfree calming down period, despite this being a
fairly big release.

Please?

  Linus

---

Al Viro (1):
  vfs updates

Alex Williamson (1):
  VFIO updates

Alexandre Belloni (2):
  RTC updates
  more RTC updates

Andrew Morton (4):
  first patch-bomb
  second patch-bomb
  third patch-bomb
  fourth patch-bomb

Arnd Bergmann (10):
  ARM SoC non-urgent fixes
  ARM SoC cleanups
  ARM SoC platform updates
  ARM SoC 64-bit changes
  ARM DT updates
  ARM 64-bit DT updates
  ARM SoC defconfig updates
  ARM SoC driver updates
  more ARM DT changes
  asm-generic updates

Bjorn Andersson (1):
  remoteproc updates

Bjorn Helgaas (2):
  PCI updates
  PCI fixes

Bob Peterson (1):
  GFS2 updates

Borislav Petkov (1):
  EDAC updates

Brian Norris (1):
  MTD updates

Bruce Fields (2):
  nfsd updates
  more nfsd updates

Catalin Marinas (2):
  arm64 updates
  second set of arm64 updates

Chris Mason (1):
  btrfs updates

Chris Zankel (1):
  Xtensa updates

Christoph Hellwig (1):
  configfs updates

Corey Minyard (1):
  IPMI updates

Dan Williams (1):
  libnvdimm updates

Darren Hart (1):
  x86 platform driver updates

Dave Airlie (2):
  drm updates
  drm fixes

Dave Chinner (1):
  xfs updates

David Miller (2):
  networking updates
  networking bugfixes

David Teigland (1):
  dlm updates

David Vrabel (1):
  xen updates

Dmitry Torokhov (2):
  input updates
  more input updates

Doug Ledford (2):
  rdma updates
  more rdma updates

Geert Uytterhoeven (1):
  m68k updates

Greg KH (7):
  driver core updates
  char/misc updates
  tty/serial updates
  USB updates
  staging driver updates
  USB fixes
  staging driver fixes

Greg Ungerer (1):
  m68knommu updates

Guenter Roeck (2):
  hwmon updates
  more hwmon updates

Hans-Christian Egtvedt (1):
  AVR32 updates

Helge Deller (1):
  parisc updates

Herbert Xu (2):
  crypto update
  crypto fixes

Ingo Molnar (24):
  ram resource handling changes
  locking changes
  dma_*_writecombine rename
  read-only kernel memory updates
  perf updates
  RAS updates
  scheduler updates
  NOHZ updates
  x86 asm updates
  x86 boot updates
  x86 build update
  x86 fpu updates
  x86 microcode updates
  x86 mm updates
  x86 core platform updates
  x86 timer update
  RCU updates
  'objtool' stack frame validation
  EFI updates
  x86 protection key support
  locking fixes
  scheduler fixes
  x86 fixes
  perf fixes

Jacek Anaszewski (1):
  LED updates

Re: [PATCH 0/2] x86/microcode/amd: Do not overwrite specific patch levels

[Henrique de Moraes Holschuh]

On Wed, 01 Jul 2015, Borislav Petkov wrote:
> Certain patch levels supplied by the BIOS should not be upgraded and
> overwritten by the microcode loader because doing so leaves the system
> dead in the water.
> 
> The two below provide for filtering out those levels and avoiding the
> update, thereby making those patch levels final.
> 
> Borislav Petkov (2):
>   x86/microcode/amd: Extract current patch level read to a function
>   x86/microcode/amd: Do not overwrite final patch levels

This patchset looks like it is pretty much a requirement for any distro that
ships AMD microcode updates...  Maybe the two commits should be sent to
-stable, now that they have seen lots of testing in mainline 4.4.x as well
as SuSE kernels?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH 0/2] x86/microcode/amd: Do not overwrite specific patch levels

[Henrique de Moraes Holschuh]

On Wed, 01 Jul 2015, Borislav Petkov wrote:
> Certain patch levels supplied by the BIOS should not be upgraded and
> overwritten by the microcode loader because doing so leaves the system
> dead in the water.
> 
> The two below provide for filtering out those levels and avoiding the
> update, thereby making those patch levels final.
> 
> Borislav Petkov (2):
>   x86/microcode/amd: Extract current patch level read to a function
>   x86/microcode/amd: Do not overwrite final patch levels

This patchset looks like it is pretty much a requirement for any distro that
ships AMD microcode updates...  Maybe the two commits should be sent to
-stable, now that they have seen lots of testing in mainline 4.4.x as well
as SuSE kernels?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

BUSINESS RELATIONSHIP

[DR.HARUNA BELLO]

BUSINESS RELATIONSHIP

Dear Friend,

Please and Please contact me through this E_mail (drharunabello...@gmail.com)

Let me start by introducing myself,I am Dr Haruna Bello,
Manager of Bank Of Africa Burkina faso.
I am writting you this letter based on the latest development at my 
Departmentwhich I will like to bring to your personal edification.(18.5 million 
U.SDollars transfer claims).
This is a legitimate transaction and I agreed to offer you 40% of this money as 
my foreign partner after confirmation of the fund in your bank account.
If you are interested,get back to me with the following details below.

(1)Your age 
(2)Sex
(3)Your occupation.
(4)Your marital status.
(5)Your country Name..
(6)Your full residential address...
(7)Your private phone and fax number and your complete name...
(8)A copy of your int'l passport or ID card
As soon as I receive these data, I will forward to you the application form 
whichyou will send to the bank.

Please and Please contact me through this E_mail (drharunabello...@gmail.com)

Best Regard
Dr Haruna Bello

BUSINESS RELATIONSHIP

[DR.HARUNA BELLO]

BUSINESS RELATIONSHIP

Dear Friend,

Please and Please contact me through this E_mail (drharunabello...@gmail.com)

Let me start by introducing myself,I am Dr Haruna Bello,
Manager of Bank Of Africa Burkina faso.
I am writting you this letter based on the latest development at my 
Departmentwhich I will like to bring to your personal edification.(18.5 million 
U.SDollars transfer claims).
This is a legitimate transaction and I agreed to offer you 40% of this money as 
my foreign partner after confirmation of the fund in your bank account.
If you are interested,get back to me with the following details below.

(1)Your age 
(2)Sex
(3)Your occupation.
(4)Your marital status.
(5)Your country Name..
(6)Your full residential address...
(7)Your private phone and fax number and your complete name...
(8)A copy of your int'l passport or ID card
As soon as I receive these data, I will forward to you the application form 
whichyou will send to the bank.

Please and Please contact me through this E_mail (drharunabello...@gmail.com)

Best Regard
Dr Haruna Bello

Re: [GIT PULL] Ceph updates for 4.6-rc1

[Linus Torvalds]

On Sat, Mar 26, 2016 at 3:00 PM, Linus Torvalds
 wrote:
>
> But dammit, when things come in at the very end of the merge window,
> which makes me grumpy to begin with, AND it is then re-based, at that
> point I'm not inclined to let things slide any more.

Oh fudge it. I ended up pulling anyway, because this is the last thing
pending in my queue, and I'm going to do -rc1 now.

So against my "time to teach people a lesson" better judgement, I
ended up being lax about it anyway.

But next time..

Linus

Re: [GIT PULL] Ceph updates for 4.6-rc1

[Linus Torvalds]

On Sat, Mar 26, 2016 at 3:00 PM, Linus Torvalds
 wrote:
>
> But dammit, when things come in at the very end of the merge window,
> which makes me grumpy to begin with, AND it is then re-based, at that
> point I'm not inclined to let things slide any more.

Oh fudge it. I ended up pulling anyway, because this is the last thing
pending in my queue, and I'm going to do -rc1 now.

So against my "time to teach people a lesson" better judgement, I
ended up being lax about it anyway.

But next time..

Linus

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

[Yury Norov]

On Sat, Mar 26, 2016 at 09:45:53PM +0800, Zhangjian (Bamvor) wrote:
> Hi, guys

Hi,
> 
> Does any body test the bigendian? We found lots of failures in be in
> our arm64 hardware. E.g. the signal issue.

I'm afraid, nobody yet. Thank you for work on it.

> 
> IIUC, the signal of struct in ILP32 is align with the aarch32. If so,
> we need to revert the following patch wrote by Andrew in 2014 which
> align the kernel_sigaction of ilp32 to lp64:
> Revert "[AARCH64] Add kernel_sigaction.h for AARCH64 ILP32"
> 
> And we also need to handle the uc_stack properly in kernel. After
> apply these two patches, we could fix lots of failure in bigendian.
> 
> Regards
> 
> Bamvor

Andrew sent me similar patches yesterday. See 
https://github.com/apinski-cavium/linux (branch pin1)
https://github.com/norov/glibc.git (branch new-api)

There are also some other fixes, so my fail list is like this:
[Float tests skipped but fail too]
pipeio_1   FAIL   5
pipeio_6   FAIL   1
abort01FAIL   2
clone02FAIL   4
execve03   FAIL   4
fcntl17FAIL   4
fcntl21FAIL   4
kill11 FAIL   2
mmap16 FAIL   6
open12 FAIL   2
rename11   FAIL   2
rmdir02FAIL   2
umount2_01 FAIL   2
umount2_02 FAIL   2
umount2_03 FAIL   2
utime06FAIL   2
mtest06FAIL   11

Some tests fail both on lp64 and ilp32, so it seems, it's not a
problem of ilp32 itself.

Some tests fail only when run in scenario, so I cannot reproduce it.
I suspect it's because core dump fails. 

Also, Andrew told, there's an issue in unwind, and it is caused by GCC
bug, not kernel or glibc. To reproduce, run unwind from signal
handler (trigo does it). I think, at least float tests fail due to it.
Andrew is in vacation now, so he may answer longer than usual.

See Andrew's kernel signal patch:

>From b95c5250c5c869d8852886ed49e34fa11c29663e Mon Sep 17 00:00:00 2001
From: Andrew Pinski 
Date: Thu, 24 Mar 2016 23:10:08 -0700
Subject: [PATCH] Fix signals

Signed-off-by: Andrew Pinski 
Signed-off-by: Yury Norov 
---
 arch/arm64/include/asm/signal_common.h | 10 +
 arch/arm64/kernel/signal.c | 59 +
 arch/arm64/kernel/signal_ilp32.c   | 78 +++---
 3 files changed, 115 insertions(+), 32 deletions(-)

diff --git a/arch/arm64/include/asm/signal_common.h 
b/arch/arm64/include/asm/signal_common.h
index faa82c0..402e0c4 100644
--- a/arch/arm64/include/asm/signal_common.h
+++ b/arch/arm64/include/asm/signal_common.h
@@ -23,16 +23,10 @@
 #include 
 #include 
 
-struct sigframe {
-   struct ucontext uc;
-   u64 fp;
-   u64 lr;
-};
-
 int preserve_fpsimd_context(struct fpsimd_context __user *ctx);
 int restore_fpsimd_context(struct fpsimd_context __user *ctx);
-int setup_sigframe(struct sigframe __user *sf, struct pt_regs *regs, sigset_t 
*set);
-int restore_sigframe(struct pt_regs *regs, struct sigframe __user *sf);
+int setup_sigcontex(struct sigcontext __user *uc_mcontext, struct pt_regs 
*regs);
+int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sf);
 void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
void __user *frame, off_t sigframe_off, int usig);
 
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 0648aa5..5f2faf2 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -37,6 +37,12 @@
 #include 
 #include 
 
+struct sigframe {
+   struct ucontext uc;
+   u64 fp;
+   u64 lr;
+};
+
 /*
  * Do a signal return; undo the signal stack. These are aligned to 128-bit.
  */
@@ -92,23 +98,31 @@ int restore_fpsimd_context(struct fpsimd_context __user 
*ctx)
return err ? -EFAULT : 0;
 }
 
-int restore_sigframe(struct pt_regs *regs,
+static int restore_sigframe(struct pt_regs *regs,
struct sigframe __user *sf)
 {
sigset_t set;
-   int i, err;
-   void *aux = sf->uc.uc_mcontext.__reserved;
-
+   int err;
err = __copy_from_user(, >uc.uc_sigmask, sizeof(set));
if (err == 0)
set_current_blocked();
 
+   err |= restore_sigcontext(regs, >uc.uc_mcontext);
+   return err;
+}
+
+
+int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user 
*uc_mcontext)
+{
+   int i, err = 0;
+   void *aux = uc_mcontext->__reserved;
+
for (i = 0; i < 31; i++)
-   __get_user_error(regs->regs[i], >uc.uc_mcontext.regs[i],
+   __get_user_error(regs->regs[i], _mcontext->regs[i],

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

[Yury Norov]

On Sat, Mar 26, 2016 at 09:45:53PM +0800, Zhangjian (Bamvor) wrote:
> Hi, guys

Hi,
> 
> Does any body test the bigendian? We found lots of failures in be in
> our arm64 hardware. E.g. the signal issue.

I'm afraid, nobody yet. Thank you for work on it.

> 
> IIUC, the signal of struct in ILP32 is align with the aarch32. If so,
> we need to revert the following patch wrote by Andrew in 2014 which
> align the kernel_sigaction of ilp32 to lp64:
> Revert "[AARCH64] Add kernel_sigaction.h for AARCH64 ILP32"
> 
> And we also need to handle the uc_stack properly in kernel. After
> apply these two patches, we could fix lots of failure in bigendian.
> 
> Regards
> 
> Bamvor

Andrew sent me similar patches yesterday. See 
https://github.com/apinski-cavium/linux (branch pin1)
https://github.com/norov/glibc.git (branch new-api)

There are also some other fixes, so my fail list is like this:
[Float tests skipped but fail too]
pipeio_1   FAIL   5
pipeio_6   FAIL   1
abort01FAIL   2
clone02FAIL   4
execve03   FAIL   4
fcntl17FAIL   4
fcntl21FAIL   4
kill11 FAIL   2
mmap16 FAIL   6
open12 FAIL   2
rename11   FAIL   2
rmdir02FAIL   2
umount2_01 FAIL   2
umount2_02 FAIL   2
umount2_03 FAIL   2
utime06FAIL   2
mtest06FAIL   11

Some tests fail both on lp64 and ilp32, so it seems, it's not a
problem of ilp32 itself.

Some tests fail only when run in scenario, so I cannot reproduce it.
I suspect it's because core dump fails. 

Also, Andrew told, there's an issue in unwind, and it is caused by GCC
bug, not kernel or glibc. To reproduce, run unwind from signal
handler (trigo does it). I think, at least float tests fail due to it.
Andrew is in vacation now, so he may answer longer than usual.

See Andrew's kernel signal patch:

>From b95c5250c5c869d8852886ed49e34fa11c29663e Mon Sep 17 00:00:00 2001
From: Andrew Pinski 
Date: Thu, 24 Mar 2016 23:10:08 -0700
Subject: [PATCH] Fix signals

Signed-off-by: Andrew Pinski 
Signed-off-by: Yury Norov 
---
 arch/arm64/include/asm/signal_common.h | 10 +
 arch/arm64/kernel/signal.c | 59 +
 arch/arm64/kernel/signal_ilp32.c   | 78 +++---
 3 files changed, 115 insertions(+), 32 deletions(-)

diff --git a/arch/arm64/include/asm/signal_common.h 
b/arch/arm64/include/asm/signal_common.h
index faa82c0..402e0c4 100644
--- a/arch/arm64/include/asm/signal_common.h
+++ b/arch/arm64/include/asm/signal_common.h
@@ -23,16 +23,10 @@
 #include 
 #include 
 
-struct sigframe {
-   struct ucontext uc;
-   u64 fp;
-   u64 lr;
-};
-
 int preserve_fpsimd_context(struct fpsimd_context __user *ctx);
 int restore_fpsimd_context(struct fpsimd_context __user *ctx);
-int setup_sigframe(struct sigframe __user *sf, struct pt_regs *regs, sigset_t 
*set);
-int restore_sigframe(struct pt_regs *regs, struct sigframe __user *sf);
+int setup_sigcontex(struct sigcontext __user *uc_mcontext, struct pt_regs 
*regs);
+int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sf);
 void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
void __user *frame, off_t sigframe_off, int usig);
 
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 0648aa5..5f2faf2 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -37,6 +37,12 @@
 #include 
 #include 
 
+struct sigframe {
+   struct ucontext uc;
+   u64 fp;
+   u64 lr;
+};
+
 /*
  * Do a signal return; undo the signal stack. These are aligned to 128-bit.
  */
@@ -92,23 +98,31 @@ int restore_fpsimd_context(struct fpsimd_context __user 
*ctx)
return err ? -EFAULT : 0;
 }
 
-int restore_sigframe(struct pt_regs *regs,
+static int restore_sigframe(struct pt_regs *regs,
struct sigframe __user *sf)
 {
sigset_t set;
-   int i, err;
-   void *aux = sf->uc.uc_mcontext.__reserved;
-
+   int err;
err = __copy_from_user(, >uc.uc_sigmask, sizeof(set));
if (err == 0)
set_current_blocked();
 
+   err |= restore_sigcontext(regs, >uc.uc_mcontext);
+   return err;
+}
+
+
+int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user 
*uc_mcontext)
+{
+   int i, err = 0;
+   void *aux = uc_mcontext->__reserved;
+
for (i = 0; i < 31; i++)
-   __get_user_error(regs->regs[i], >uc.uc_mcontext.regs[i],
+   __get_user_error(regs->regs[i], _mcontext->regs[i],
 err);
-   __get_user_error(regs->sp, 

BUSINESS RELATIONSHIP

[DR.HARUNA BELLO]

BUSINESS RELATIONSHIP

Dear Friend,

Let me start by introducing myself,I am Dr Haruna Bello,
Manager of Bank Of Africa Burkina faso.
I am writting you this letter based on the latest development at my 
Departmentwhich I will like to bring to your personal edification.(18.5 million 
U.SDollars transfer claims).
This is a legitimate transaction and I agreed to offer you 40% of this money as 
my foreign partner after confirmation of the fund in your bank account.
If you are interested,get back to me with the following details below.

(1)Your age 
(2)Sex
(3)Your occupation.
(4)Your marital status.
(5)Your country Name..
(6)Your full residential address...
(7)Your private phone and fax number and your complete name...
(8)A copy of your int'l passport or ID card
As soon as I receive these data, I will forward to you the application form 
whichyou will send to the bank.

Best Regard
Dr Haruna Bello

BUSINESS RELATIONSHIP

[DR.HARUNA BELLO]

BUSINESS RELATIONSHIP

Dear Friend,

Let me start by introducing myself,I am Dr Haruna Bello,
Manager of Bank Of Africa Burkina faso.
I am writting you this letter based on the latest development at my 
Departmentwhich I will like to bring to your personal edification.(18.5 million 
U.SDollars transfer claims).
This is a legitimate transaction and I agreed to offer you 40% of this money as 
my foreign partner after confirmation of the fund in your bank account.
If you are interested,get back to me with the following details below.

(1)Your age 
(2)Sex
(3)Your occupation.
(4)Your marital status.
(5)Your country Name..
(6)Your full residential address...
(7)Your private phone and fax number and your complete name...
(8)A copy of your int'l passport or ID card
As soon as I receive these data, I will forward to you the application form 
whichyou will send to the bank.

Best Regard
Dr Haruna Bello

Re: [GIT PULL] Ceph updates for 4.6-rc1

[Ilya Dryomov]

On Sat, Mar 26, 2016 at 11:00 PM, Linus Torvalds
 wrote:
> On Sat, Mar 26, 2016 at 2:46 PM, Ilya Dryomov  wrote:
>>
>> FWIW, it matches -next content-wise.  SHAs don't match because of an
>> extra Signed-off-by in an unrelated commit, outside of fs/ceph.
>
> That's how git works. After you rebase, SHA's will *never* match,
> because you changed the history (dates, parenthood etc).
>
> The whole "it matches content-wise" is immaterial. You rebased and now
> I can see that it's not what was in next. It's really that simple.
>
> Just as an example of what rebasing does: it means that when I look at
> "ok, what is in next but not in my tree yet" to see what might be
> pending, the rebased commits don't cancel out, because they are
> different commits.
>
> Yes, yes, I've been lax about this. I have been ranting against people
> rebasing for years, but in the end I've usually let it slide.
>
> But dammit, when things come in at the very end of the merge window,
> which makes me grumpy to begin with, AND it is then re-based, at that
> point I'm not inclined to let things slide any more.
>
> At that point you guys are actively working to piss me off, and that
> means that I'm not in the least in the mood of pulling your work.
>
> Why *was* the pull request sent at the very end of the merge window
> anyway?  Was the code not ready?

A couple of commits were taken out and new integration snapshot was
made, based on Al's merge.  After it went through the usual test cycle,
I didn't think things through and it ended up being the pull request.

>
> So let me say again: keep your *own* tree in good shape.
>
> That's actually the only really valid reason for rebasing: if your
> *own* tree has something horribly bad going on, like majorly messed up
> commit messages, or history that is completely broken and will cause
> problems for people who want to bisect bugs, or things like that. Then
> "git rebase" is a perfectly good thing to fix bad things that are in
> _your_ tree.
>
> But no, git rebase is not a "let's react to random things that
> happened in other peoples trees". At that point you're worrying about
> entirely the wrong thing.

I get your argument.

Thanks,

Ilya

Re: [GIT PULL] Ceph updates for 4.6-rc1

[Ilya Dryomov]

On Sat, Mar 26, 2016 at 11:00 PM, Linus Torvalds
 wrote:
> On Sat, Mar 26, 2016 at 2:46 PM, Ilya Dryomov  wrote:
>>
>> FWIW, it matches -next content-wise.  SHAs don't match because of an
>> extra Signed-off-by in an unrelated commit, outside of fs/ceph.
>
> That's how git works. After you rebase, SHA's will *never* match,
> because you changed the history (dates, parenthood etc).
>
> The whole "it matches content-wise" is immaterial. You rebased and now
> I can see that it's not what was in next. It's really that simple.
>
> Just as an example of what rebasing does: it means that when I look at
> "ok, what is in next but not in my tree yet" to see what might be
> pending, the rebased commits don't cancel out, because they are
> different commits.
>
> Yes, yes, I've been lax about this. I have been ranting against people
> rebasing for years, but in the end I've usually let it slide.
>
> But dammit, when things come in at the very end of the merge window,
> which makes me grumpy to begin with, AND it is then re-based, at that
> point I'm not inclined to let things slide any more.
>
> At that point you guys are actively working to piss me off, and that
> means that I'm not in the least in the mood of pulling your work.
>
> Why *was* the pull request sent at the very end of the merge window
> anyway?  Was the code not ready?

A couple of commits were taken out and new integration snapshot was
made, based on Al's merge.  After it went through the usual test cycle,
I didn't think things through and it ended up being the pull request.

>
> So let me say again: keep your *own* tree in good shape.
>
> That's actually the only really valid reason for rebasing: if your
> *own* tree has something horribly bad going on, like majorly messed up
> commit messages, or history that is completely broken and will cause
> problems for people who want to bisect bugs, or things like that. Then
> "git rebase" is a perfectly good thing to fix bad things that are in
> _your_ tree.
>
> But no, git rebase is not a "let's react to random things that
> happened in other peoples trees". At that point you're worrying about
> entirely the wrong thing.

I get your argument.

Thanks,

Ilya

Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17

[Mathieu Desnoyers]

- On Mar 26, 2016, at 2:49 PM, Paul E. McKenney paul...@linux.vnet.ibm.com 
wrote:

> On Sat, Mar 26, 2016 at 08:28:16AM -0700, Paul E. McKenney wrote:
>> On Sat, Mar 26, 2016 at 12:29:31PM +, Mathieu Desnoyers wrote:
>> > - On Mar 25, 2016, at 5:46 PM, Paul E. McKenney 
>> > paul...@linux.vnet.ibm.com
>> > wrote:
>> > 
>> > > On Fri, Mar 25, 2016 at 09:24:14PM +, Chatre, Reinette wrote:
>> > >> Hi  Paul,
>> > >> 
>> > >> On 2016-03-23, Paul E. McKenney wrote:
>> > >> > Please boot with the following parameters:
>> > >> > 
>> > >> >   rcu_tree.rcu_kick_kthreads ftrace
>> > >> > trace_event=sched_waking,sched_wakeup,sched_wake_idle_without_ipi
>> > >> 
>> > >> With these parameters I expected more details to show up in the kernel 
>> > >> logs but
>> > >> cannot find any. Even so, today I left the machine running again and 
>> > >> when this
>> > >> happened I think I was able to capture the trace data for the event. 
>> > >> Please
>> > >> find attached the trace information for the kernel message below. Since 
>> > >> the
>> > >> complete trace file is very big I trimmed it to show the time around 
>> > >> this event
>> > >> - hopefully this will contain the information you need. I would also 
>> > >> like to
>> > >> provide some additional information. The system on which I see these 
>> > >> events had
>> > >> a time that was _very_ wrong. I noticed that this issue occurs when
>> > >> system-timesynd was one of the tasks calling the functions of interest 
>> > >> to your
>> > >> tracing and am wondering if a very out of sync time in process of being
>> > >> corrected could be the cause of this issue? As an experiment I ensured 
>> > >> the
>> > >> system time was accurate before leaving the system idle overnight and I 
>> > >> did not
>> > >> see the issue the next morning.
>> > > 
>> > > Ah!  Yes, a sudden jump in time or a disagreement about the time among
>> > > different components of the system can definitely cause these symptoms.
>> > > We have sometimes seen these problems occur when a pair of CPUs have
>> > > wildly different ideas about what time it is, for example.  Please let
>> > > me know how it goes.
>> > > 
>> > > Also, in your trace, there are no sched_waking events for the rcu_preempt
>> > > process that are not immediately followed by sched_wakeup, so your trace
>> > > isn't showing the problem that I am seeing.
>> > 
>> > This is interesting.
>> > 
>> > Perhaps we could try with those commits reverted ?
>> > 
>> > commit e3baac47f0e82c4be632f4f97215bb93bf16b342
>> > Author: Peter Zijlstra 
>> > Date:   Wed Jun 4 10:31:18 2014 -0700
>> > 
>> > sched/idle: Optimize try-to-wake-up IPI
>> > 
>> > commit fd99f91aa007ba255aac44fe6cf21c1db398243a
>> > Author: Peter Zijlstra 
>> > Date:   Wed Apr 9 15:35:08 2014 +0200
>> > 
>> > sched/idle: Avoid spurious wakeup IPIs
>> > 
>> > They appeared in 3.16.
>> 
>> At this point, I am up for trying pretty much anything.  ;-)
>> 
>> Will give it a go.
> 
> And those certainly don't revert cleanly!  Would patching the kernel
> to remove the definition of TIF_POLLING_NRFLAG be useful?  Or, more
> to the point, is there some other course of action that would be more
> useful?  At this point, the test times are measured in weeks...

Indeed, patching the kernel to remove the TIF_POLLING_NRFLAG
definition would have an effect similar to reverting those two
commits.

Since testing takes a while, we could take a more aggressive
approach towards reproducing a possible race condition: we
could re-implement the _TIF_POLLING_NRFLAG vs _TIF_NEED_RESCHED
dance, along with the ttwu pending lock-list queue, within
a dummy test module, with custom data structures, and
stress-test the invariants. We could also create a Promela
model of these ipi-skip optimisations trying to validate
progress: whenever a wakeup is requested, there should
always be a scheduling performed, even if no further wakeup
is encountered.

Each of the two approaches proposed above might be a significant
endeavor, and would only validate my specific hunch. So it might
be a good idea to just let a test run for a few weeks with
TIF_POLLING_NRFLAG disabled meanwhile.

Thoughts ?

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17

[Mathieu Desnoyers]

- On Mar 26, 2016, at 2:49 PM, Paul E. McKenney paul...@linux.vnet.ibm.com 
wrote:

> On Sat, Mar 26, 2016 at 08:28:16AM -0700, Paul E. McKenney wrote:
>> On Sat, Mar 26, 2016 at 12:29:31PM +, Mathieu Desnoyers wrote:
>> > - On Mar 25, 2016, at 5:46 PM, Paul E. McKenney 
>> > paul...@linux.vnet.ibm.com
>> > wrote:
>> > 
>> > > On Fri, Mar 25, 2016 at 09:24:14PM +, Chatre, Reinette wrote:
>> > >> Hi  Paul,
>> > >> 
>> > >> On 2016-03-23, Paul E. McKenney wrote:
>> > >> > Please boot with the following parameters:
>> > >> > 
>> > >> >   rcu_tree.rcu_kick_kthreads ftrace
>> > >> > trace_event=sched_waking,sched_wakeup,sched_wake_idle_without_ipi
>> > >> 
>> > >> With these parameters I expected more details to show up in the kernel 
>> > >> logs but
>> > >> cannot find any. Even so, today I left the machine running again and 
>> > >> when this
>> > >> happened I think I was able to capture the trace data for the event. 
>> > >> Please
>> > >> find attached the trace information for the kernel message below. Since 
>> > >> the
>> > >> complete trace file is very big I trimmed it to show the time around 
>> > >> this event
>> > >> - hopefully this will contain the information you need. I would also 
>> > >> like to
>> > >> provide some additional information. The system on which I see these 
>> > >> events had
>> > >> a time that was _very_ wrong. I noticed that this issue occurs when
>> > >> system-timesynd was one of the tasks calling the functions of interest 
>> > >> to your
>> > >> tracing and am wondering if a very out of sync time in process of being
>> > >> corrected could be the cause of this issue? As an experiment I ensured 
>> > >> the
>> > >> system time was accurate before leaving the system idle overnight and I 
>> > >> did not
>> > >> see the issue the next morning.
>> > > 
>> > > Ah!  Yes, a sudden jump in time or a disagreement about the time among
>> > > different components of the system can definitely cause these symptoms.
>> > > We have sometimes seen these problems occur when a pair of CPUs have
>> > > wildly different ideas about what time it is, for example.  Please let
>> > > me know how it goes.
>> > > 
>> > > Also, in your trace, there are no sched_waking events for the rcu_preempt
>> > > process that are not immediately followed by sched_wakeup, so your trace
>> > > isn't showing the problem that I am seeing.
>> > 
>> > This is interesting.
>> > 
>> > Perhaps we could try with those commits reverted ?
>> > 
>> > commit e3baac47f0e82c4be632f4f97215bb93bf16b342
>> > Author: Peter Zijlstra 
>> > Date:   Wed Jun 4 10:31:18 2014 -0700
>> > 
>> > sched/idle: Optimize try-to-wake-up IPI
>> > 
>> > commit fd99f91aa007ba255aac44fe6cf21c1db398243a
>> > Author: Peter Zijlstra 
>> > Date:   Wed Apr 9 15:35:08 2014 +0200
>> > 
>> > sched/idle: Avoid spurious wakeup IPIs
>> > 
>> > They appeared in 3.16.
>> 
>> At this point, I am up for trying pretty much anything.  ;-)
>> 
>> Will give it a go.
> 
> And those certainly don't revert cleanly!  Would patching the kernel
> to remove the definition of TIF_POLLING_NRFLAG be useful?  Or, more
> to the point, is there some other course of action that would be more
> useful?  At this point, the test times are measured in weeks...

Indeed, patching the kernel to remove the TIF_POLLING_NRFLAG
definition would have an effect similar to reverting those two
commits.

Since testing takes a while, we could take a more aggressive
approach towards reproducing a possible race condition: we
could re-implement the _TIF_POLLING_NRFLAG vs _TIF_NEED_RESCHED
dance, along with the ttwu pending lock-list queue, within
a dummy test module, with custom data structures, and
stress-test the invariants. We could also create a Promela
model of these ipi-skip optimisations trying to validate
progress: whenever a wakeup is requested, there should
always be a scheduling performed, even if no further wakeup
is encountered.

Each of the two approaches proposed above might be a significant
endeavor, and would only validate my specific hunch. So it might
be a good idea to just let a test run for a few weeks with
TIF_POLLING_NRFLAG disabled meanwhile.

Thoughts ?

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [PATCH 01/31] bitops: add parity functions

[Martin Kepplinger]

We do.

Am 24. März 2016 23:28:15 MEZ, schrieb Andrew Morton 
:
>On Thu, 24 Mar 2016 09:38:21 +0100 Denys Vlasenko 
>wrote:
>
>> On 03/24/2016 04:03 AM, Zhaoxiu Zeng wrote:
>> > +/*
>> > + * Type invariant interface to the compile time constant parity
>functions.
>> > + */
>> > +#define PARITY(w)PARITY64((u64)w)
>> 
>> Can result in incorrect expansion of w. Should be PARITY64((u64)(w))
>
>And we seem to be missing the other 30 patches.

-- 
Martin Kepplinger
http://martinkepplinger.com
sent from mobile

Re: [PATCH 01/31] bitops: add parity functions

[Martin Kepplinger]

We do.

Am 24. März 2016 23:28:15 MEZ, schrieb Andrew Morton 
:
>On Thu, 24 Mar 2016 09:38:21 +0100 Denys Vlasenko 
>wrote:
>
>> On 03/24/2016 04:03 AM, Zhaoxiu Zeng wrote:
>> > +/*
>> > + * Type invariant interface to the compile time constant parity
>functions.
>> > + */
>> > +#define PARITY(w)PARITY64((u64)w)
>> 
>> Can result in incorrect expansion of w. Should be PARITY64((u64)(w))
>
>And we seem to be missing the other 30 patches.

-- 
Martin Kepplinger
http://martinkepplinger.com
sent from mobile

Re: [GIT PULL] Ceph updates for 4.6-rc1

[Linus Torvalds]

On Sat, Mar 26, 2016 at 2:46 PM, Ilya Dryomov  wrote:
>
> FWIW, it matches -next content-wise.  SHAs don't match because of an
> extra Signed-off-by in an unrelated commit, outside of fs/ceph.

That's how git works. After you rebase, SHA's will *never* match,
because you changed the history (dates, parenthood etc).

The whole "it matches content-wise" is immaterial. You rebased and now
I can see that it's not what was in next. It's really that simple.

Just as an example of what rebasing does: it means that when I look at
"ok, what is in next but not in my tree yet" to see what might be
pending, the rebased commits don't cancel out, because they are
different commits.

Yes, yes, I've been lax about this. I have been ranting against people
rebasing for years, but in the end I've usually let it slide.

But dammit, when things come in at the very end of the merge window,
which makes me grumpy to begin with, AND it is then re-based, at that
point I'm not inclined to let things slide any more.

At that point you guys are actively working to piss me off, and that
means that I'm not in the least in the mood of pulling your work.

Why *was* the pull request sent at the very end of the merge window
anyway?  Was the code not ready?

So let me say again: keep your *own* tree in good shape.

That's actually the only really valid reason for rebasing: if your
*own* tree has something horribly bad going on, like majorly messed up
commit messages, or history that is completely broken and will cause
problems for people who want to bisect bugs, or things like that. Then
"git rebase" is a perfectly good thing to fix bad things that are in
_your_ tree.

But no, git rebase is not a "let's react to random things that
happened in other peoples trees". At that point you're worrying about
entirely the wrong thing.

It's doubly wrong when you rebase on top of some random point in the
middle of the merge window. That "middle of the merge window" is
pretty much by definition not a good stable base for development.
Maybe this merge window has been good and we haven't had any real
problems, but how can you be sure?

So even _if_ you have to rebase because of some major mess-up in the
tree, rebasing on top of "random commit in the merge window" is one of
the last things you should do.

   Linus

Re: [GIT PULL] Ceph updates for 4.6-rc1

[Linus Torvalds]

On Sat, Mar 26, 2016 at 2:46 PM, Ilya Dryomov  wrote:
>
> FWIW, it matches -next content-wise.  SHAs don't match because of an
> extra Signed-off-by in an unrelated commit, outside of fs/ceph.

That's how git works. After you rebase, SHA's will *never* match,
because you changed the history (dates, parenthood etc).

The whole "it matches content-wise" is immaterial. You rebased and now
I can see that it's not what was in next. It's really that simple.

Just as an example of what rebasing does: it means that when I look at
"ok, what is in next but not in my tree yet" to see what might be
pending, the rebased commits don't cancel out, because they are
different commits.

Yes, yes, I've been lax about this. I have been ranting against people
rebasing for years, but in the end I've usually let it slide.

But dammit, when things come in at the very end of the merge window,
which makes me grumpy to begin with, AND it is then re-based, at that
point I'm not inclined to let things slide any more.

At that point you guys are actively working to piss me off, and that
means that I'm not in the least in the mood of pulling your work.

Why *was* the pull request sent at the very end of the merge window
anyway?  Was the code not ready?

So let me say again: keep your *own* tree in good shape.

That's actually the only really valid reason for rebasing: if your
*own* tree has something horribly bad going on, like majorly messed up
commit messages, or history that is completely broken and will cause
problems for people who want to bisect bugs, or things like that. Then
"git rebase" is a perfectly good thing to fix bad things that are in
_your_ tree.

But no, git rebase is not a "let's react to random things that
happened in other peoples trees". At that point you're worrying about
entirely the wrong thing.

It's doubly wrong when you rebase on top of some random point in the
middle of the merge window. That "middle of the merge window" is
pretty much by definition not a good stable base for development.
Maybe this merge window has been good and we haven't had any real
problems, but how can you be sure?

So even _if_ you have to rebase because of some major mess-up in the
tree, rebasing on top of "random commit in the merge window" is one of
the last things you should do.

   Linus

Re: usb: gadget breakage on N900: bind UDC by name passed via usb_gadget_driver structure

[Ruslan Bilovol]

On Sat, Mar 26, 2016 at 11:32 PM, Ruslan Bilovol
 wrote:
> Hi
>
> On Fri, Mar 25, 2016 at 11:09 PM, Pavel Machek  wrote:
>> Hi!
>>
>>> OK, so at last I finished charging of my N900; found 1.8V USB
>>> to UART adapter and soldered it to the phone.
>>>
>>> I managed to boot N900 with working USB gadget (builtin g_ether)
>>> in boardfile mode, can ping it from PC and transfer data. I don't
>>> see any issue (except of musb name issue in twl phy driver, I've
>>> already sent a fix for that: https://lkml.org/lkml/2016/3/24/670 )
>>>
>>> Pavel, I still don't see how you've got your issue, please share
>>> more detials
>>
>> Ok, let me try. I undid all the changes in drivers/phy drivers/usb and
>> include/linux/usb . I have all the gadget stuff built-in, so that I
>> could use nfsroot, but this is boot from mmcblk.
>
> So do you mean you use original rootfs that was shipeed with N900?
>
>>
>> gzipped config is attached.
>
> Thanks, I'll try that
>
>>
>> PC is unable to work with the gadget:
>>
>> [256526.716099] usb 2-1: new full-speed USB device number 52 using
>> uhci_hcd
>> [256526.832091] usb 2-1: device descriptor read/64, error -32
>> [256527.052095] usb 2-1: device descriptor read/64, error -32
>> [256527.268160] usb 2-1: new full-speed USB device number 53 using
>> uhci_hcd
>> [256527.388121] usb 2-1: device descriptor read/64, error -32
>> [256527.608116] usb 2-1: device descriptor read/64, error -32
>> [256527.824170] usb 2-1: new full-speed USB device number 54 using
>> uhci_hcd
>> [256527.851175] usb 2-1: device descriptor read/8, error -32
>> [256527.975175] usb 2-1: device descriptor read/8, error -32
>> [256528.188133] usb 2-1: new full-speed USB device number 55 using
>> uhci_hcd
>> [256528.218184] usb 2-1: device descriptor read/8, error -32
>> [256528.343183] usb 2-1: device descriptor read/8, error -32
>> [256528.444314] usb usb2-port1: unable to enumerate USB device
>>
>> Dmesg from the n900 is attached as /tmp/delme.gz. I did _not_ apply
>> the patch from https://lkml.org/lkml/2016/3/24/670 , yet, as I'm using
>> devicetree boot.
>
> Hmm.. don't see anything strange in the boot log related to USB,
> I'll try your config

After looking into your config and boot log again, I see you use kernel
4.4, whereas the patch you've told about ("usb: gadget: bind UDC by name
passed via usb_gadget_driver structure") was merged only into 4.5 kernel.
Could you please try vanilla v4.5 with your config and see if it helps?

Best regards,
Ruslan Bilovol

Re: usb: gadget breakage on N900: bind UDC by name passed via usb_gadget_driver structure

[Ruslan Bilovol]

On Sat, Mar 26, 2016 at 11:32 PM, Ruslan Bilovol
 wrote:
> Hi
>
> On Fri, Mar 25, 2016 at 11:09 PM, Pavel Machek  wrote:
>> Hi!
>>
>>> OK, so at last I finished charging of my N900; found 1.8V USB
>>> to UART adapter and soldered it to the phone.
>>>
>>> I managed to boot N900 with working USB gadget (builtin g_ether)
>>> in boardfile mode, can ping it from PC and transfer data. I don't
>>> see any issue (except of musb name issue in twl phy driver, I've
>>> already sent a fix for that: https://lkml.org/lkml/2016/3/24/670 )
>>>
>>> Pavel, I still don't see how you've got your issue, please share
>>> more detials
>>
>> Ok, let me try. I undid all the changes in drivers/phy drivers/usb and
>> include/linux/usb . I have all the gadget stuff built-in, so that I
>> could use nfsroot, but this is boot from mmcblk.
>
> So do you mean you use original rootfs that was shipeed with N900?
>
>>
>> gzipped config is attached.
>
> Thanks, I'll try that
>
>>
>> PC is unable to work with the gadget:
>>
>> [256526.716099] usb 2-1: new full-speed USB device number 52 using
>> uhci_hcd
>> [256526.832091] usb 2-1: device descriptor read/64, error -32
>> [256527.052095] usb 2-1: device descriptor read/64, error -32
>> [256527.268160] usb 2-1: new full-speed USB device number 53 using
>> uhci_hcd
>> [256527.388121] usb 2-1: device descriptor read/64, error -32
>> [256527.608116] usb 2-1: device descriptor read/64, error -32
>> [256527.824170] usb 2-1: new full-speed USB device number 54 using
>> uhci_hcd
>> [256527.851175] usb 2-1: device descriptor read/8, error -32
>> [256527.975175] usb 2-1: device descriptor read/8, error -32
>> [256528.188133] usb 2-1: new full-speed USB device number 55 using
>> uhci_hcd
>> [256528.218184] usb 2-1: device descriptor read/8, error -32
>> [256528.343183] usb 2-1: device descriptor read/8, error -32
>> [256528.444314] usb usb2-port1: unable to enumerate USB device
>>
>> Dmesg from the n900 is attached as /tmp/delme.gz. I did _not_ apply
>> the patch from https://lkml.org/lkml/2016/3/24/670 , yet, as I'm using
>> devicetree boot.
>
> Hmm.. don't see anything strange in the boot log related to USB,
> I'll try your config

After looking into your config and boot log again, I see you use kernel
4.4, whereas the patch you've told about ("usb: gadget: bind UDC by name
passed via usb_gadget_driver structure") was merged only into 4.5 kernel.
Could you please try vanilla v4.5 with your config and see if it helps?

Best regards,
Ruslan Bilovol

Re: [GIT PULL] Ceph updates for 4.6-rc1

[Ilya Dryomov]

On Sat, Mar 26, 2016 at 10:33 PM, Linus Torvalds
 wrote:
> On Sat, Mar 26, 2016 at 2:19 PM, Ilya Dryomov  wrote:
>>
>> This really is a result of a miscommunication between us and Al.
>> Lesson learned.  Please reconsider and pull.
>
> No.
>
> If you guys rebase, I don't pull.
>
> Stop rebasing. Really.
>
> STOP REBASING.
>
> There are no excuses. Just stop doing it. I'll handle the merge
> issues. If there are complicated merge problems that you really worry
> about, what you can do is
>
>  (a) make a test-merge just to check
>
>  (b) do NOT send me that test-merge
>
>  (c) as part of the pull request, tell me that "there's a conflict
> because xyz, and this is how we think it should be handled".
>
> Because I'm really getting f*cking tired of having to get rebased
> trees that don't match -next for no good reason every single merge
> window.

FWIW, it matches -next content-wise.  SHAs don't match because of an
extra Signed-off-by in an unrelated commit, outside of fs/ceph.

>
> So I'm done with it.
>
> Let me repeat that one more time:
>
>  If you rebase during the merge window without having a damn good
> reason, don't expect me to pull the end result.

Mea culpa, my fault.

Thanks,

Ilya

Re: [GIT PULL] Ceph updates for 4.6-rc1

[Ilya Dryomov]

On Sat, Mar 26, 2016 at 10:33 PM, Linus Torvalds
 wrote:
> On Sat, Mar 26, 2016 at 2:19 PM, Ilya Dryomov  wrote:
>>
>> This really is a result of a miscommunication between us and Al.
>> Lesson learned.  Please reconsider and pull.
>
> No.
>
> If you guys rebase, I don't pull.
>
> Stop rebasing. Really.
>
> STOP REBASING.
>
> There are no excuses. Just stop doing it. I'll handle the merge
> issues. If there are complicated merge problems that you really worry
> about, what you can do is
>
>  (a) make a test-merge just to check
>
>  (b) do NOT send me that test-merge
>
>  (c) as part of the pull request, tell me that "there's a conflict
> because xyz, and this is how we think it should be handled".
>
> Because I'm really getting f*cking tired of having to get rebased
> trees that don't match -next for no good reason every single merge
> window.

FWIW, it matches -next content-wise.  SHAs don't match because of an
extra Signed-off-by in an unrelated commit, outside of fs/ceph.

>
> So I'm done with it.
>
> Let me repeat that one more time:
>
>  If you rebase during the merge window without having a damn good
> reason, don't expect me to pull the end result.

Mea culpa, my fault.

Thanks,

Ilya

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

[Jakob Unterwurzacher]

On 16.03.2016 10:44, Miklos Szeredi wrote:
> On Tue, Mar 15, 2016 at 8:55 AM, Jakob Unterwurzacher
>  wrote:
>> Just for anybody finding this thread: This still happens in v4.4, it
>> just took longer to trigger.
>>
>> I have posted more details to linux-kernel (copy-pasted below),
>> http://thread.gmane.org/gmane.linux.kernel/2132944
> 
> Okay, so you can reproduce this relatively quickly.   Can you try "git
> bisect" to find exactly which commit is responsible?
> 
> Thanks,
> Miklos

That took a while, but it looks like it got it:

> commit 947e9762a8ddefda38aa21e249e6a4fec215cd12
> Author: Tejun Heo 
> Date:   Fri May 22 18:23:32 2015 -0400
> 
> writeback: update wb_over_bg_thresh() to use wb_domain aware operations

Note that this commens seems to only activate changes that happened in the
commit before, aa661bb:

> commit aa661bbe1e61ce80ca4ae98804f673ede94b0827
> Author: Tejun Heo 
> Date:   Fri May 22 18:23:31 2015 -0400
> 
> writeback: move over_bground_thresh() to mm/page-writeback.c


Anyway, I can reliably reboot between aa661bb and 947e976 and always get the
same results:

aa661bb passes
947e976 fails

I you want to reproduce, clone https://github.com/rfjakob/mmapwrite.git and
run ./encfs-test.sh (needs encfs installed). On the bad kernel, it will hang
within a few seconds.

Thanks,
Jakob

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

[Jakob Unterwurzacher]

On 16.03.2016 10:44, Miklos Szeredi wrote:
> On Tue, Mar 15, 2016 at 8:55 AM, Jakob Unterwurzacher
>  wrote:
>> Just for anybody finding this thread: This still happens in v4.4, it
>> just took longer to trigger.
>>
>> I have posted more details to linux-kernel (copy-pasted below),
>> http://thread.gmane.org/gmane.linux.kernel/2132944
> 
> Okay, so you can reproduce this relatively quickly.   Can you try "git
> bisect" to find exactly which commit is responsible?
> 
> Thanks,
> Miklos

That took a while, but it looks like it got it:

> commit 947e9762a8ddefda38aa21e249e6a4fec215cd12
> Author: Tejun Heo 
> Date:   Fri May 22 18:23:32 2015 -0400
> 
> writeback: update wb_over_bg_thresh() to use wb_domain aware operations

Note that this commens seems to only activate changes that happened in the
commit before, aa661bb:

> commit aa661bbe1e61ce80ca4ae98804f673ede94b0827
> Author: Tejun Heo 
> Date:   Fri May 22 18:23:31 2015 -0400
> 
> writeback: move over_bground_thresh() to mm/page-writeback.c


Anyway, I can reliably reboot between aa661bb and 947e976 and always get the
same results:

aa661bb passes
947e976 fails

I you want to reproduce, clone https://github.com/rfjakob/mmapwrite.git and
run ./encfs-test.sh (needs encfs installed). On the bad kernel, it will hang
within a few seconds.

Thanks,
Jakob

Re: usb: gadget breakage on N900: bind UDC by name passed via usb_gadget_driver structure

[Ruslan Bilovol]

Hi

On Fri, Mar 25, 2016 at 11:15 PM, Pavel Machek  wrote:
> Hi!
>
>> OK, so at last I finished charging of my N900; found 1.8V USB
>> to UART adapter and soldered it to the phone.
>>
>> I managed to boot N900 with working USB gadget (builtin g_ether)
>> in boardfile mode, can ping it from PC and transfer data. I don't
>> see any issue (except of musb name issue in twl phy driver, I've
>> already sent a fix for that: https://lkml.org/lkml/2016/3/24/670 )
>
> I tried to add that one, too, and no change. Can I get your .config?

Since you use DT boot, this patch will not have any effect.
See my config attached.

Please note that I'm building simple rootfs cpio binary into the kernel
so you may need to change CONFIG_INITRAMFS_SOURCE value

Best regards,
Ruslan

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


.config.gz
Description: GNU Zip compressed data

Re: usb: gadget breakage on N900: bind UDC by name passed via usb_gadget_driver structure

[Ruslan Bilovol]

Hi

On Fri, Mar 25, 2016 at 11:15 PM, Pavel Machek  wrote:
> Hi!
>
>> OK, so at last I finished charging of my N900; found 1.8V USB
>> to UART adapter and soldered it to the phone.
>>
>> I managed to boot N900 with working USB gadget (builtin g_ether)
>> in boardfile mode, can ping it from PC and transfer data. I don't
>> see any issue (except of musb name issue in twl phy driver, I've
>> already sent a fix for that: https://lkml.org/lkml/2016/3/24/670 )
>
> I tried to add that one, too, and no change. Can I get your .config?

Since you use DT boot, this patch will not have any effect.
See my config attached.

Please note that I'm building simple rootfs cpio binary into the kernel
so you may need to change CONFIG_INITRAMFS_SOURCE value

Best regards,
Ruslan

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


.config.gz
Description: GNU Zip compressed data

[PATCH] intel_menlow: reduce code duplication

[Rasmus Villemoes]

aux0_show and aux1_show consists of almost identical code. Pull that
into a common helper and make them thin wrappers. Similarly for
_store.

Signed-off-by: Rasmus Villemoes 
---
 drivers/platform/x86/intel_menlow.c | 48 -
 1 file changed, 21 insertions(+), 27 deletions(-)

diff --git a/drivers/platform/x86/intel_menlow.c 
b/drivers/platform/x86/intel_menlow.c
index 0a919d81662c..ae3a2a831533 100644
--- a/drivers/platform/x86/intel_menlow.c
+++ b/drivers/platform/x86/intel_menlow.c
@@ -306,33 +306,32 @@ static int sensor_set_auxtrip(acpi_handle handle, int 
index, int value)
 #define to_intel_menlow_attr(_attr)\
container_of(_attr, struct intel_menlow_attribute, attr)
 
-static ssize_t aux0_show(struct device *dev,
-struct device_attribute *dev_attr, char *buf)
+static ssize_t aux_show(struct device *dev, struct device_attribute *dev_attr,
+   char *buf, int idx)
 {
struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
unsigned long long value;
int result;
 
-   result = sensor_get_auxtrip(attr->handle, 0, );
+   result = sensor_get_auxtrip(attr->handle, idx, );
 
return result ? result : sprintf(buf, "%lu", 
DECI_KELVIN_TO_CELSIUS(value));
 }
 
-static ssize_t aux1_show(struct device *dev,
+static ssize_t aux0_show(struct device *dev,
 struct device_attribute *dev_attr, char *buf)
 {
-   struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
-   unsigned long long value;
-   int result;
-
-   result = sensor_get_auxtrip(attr->handle, 1, );
+   return aux_show(dev, dev_attr, buf, 0);
+}
 
-   return result ? result : sprintf(buf, "%lu", 
DECI_KELVIN_TO_CELSIUS(value));
+static ssize_t aux1_show(struct device *dev,
+struct device_attribute *dev_attr, char *buf)
+{
+   return aux_show(dev, dev_attr, buf, 1);
 }
 
-static ssize_t aux0_store(struct device *dev,
- struct device_attribute *dev_attr,
- const char *buf, size_t count)
+static ssize_t aux_store(struct device *dev, struct device_attribute *dev_attr,
+const char *buf, size_t count, int idx)
 {
struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
int value;
@@ -345,27 +344,22 @@ static ssize_t aux0_store(struct device *dev,
if (value < 0)
return -EINVAL;
 
-   result = sensor_set_auxtrip(attr->handle, 0, 
CELSIUS_TO_DECI_KELVIN(value));
+   result = sensor_set_auxtrip(attr->handle, idx, 
CELSIUS_TO_DECI_KELVIN(value));
return result ? result : count;
 }
 
-static ssize_t aux1_store(struct device *dev,
+static ssize_t aux0_store(struct device *dev,
  struct device_attribute *dev_attr,
  const char *buf, size_t count)
 {
-   struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
-   int value;
-   int result;
-
-   /*Sanity check; should be a positive integer */
-   if (!sscanf(buf, "%d", ))
-   return -EINVAL;
-
-   if (value < 0)
-   return -EINVAL;
+   return aux_store(dev, dev_attr, buf, count, 0);
+}
 
-   result = sensor_set_auxtrip(attr->handle, 1, 
CELSIUS_TO_DECI_KELVIN(value));
-   return result ? result : count;
+static ssize_t aux1_store(struct device *dev,
+ struct device_attribute *dev_attr,
+ const char *buf, size_t count)
+{
+   return aux_store(dev, dev_attr, buf, count, 1);
 }
 
 /* BIOS can enable/disable the thermal user application in dabney platform */
-- 
2.1.4

[PATCH] intel_menlow: reduce code duplication

[Rasmus Villemoes]

aux0_show and aux1_show consists of almost identical code. Pull that
into a common helper and make them thin wrappers. Similarly for
_store.

Signed-off-by: Rasmus Villemoes 
---
 drivers/platform/x86/intel_menlow.c | 48 -
 1 file changed, 21 insertions(+), 27 deletions(-)

diff --git a/drivers/platform/x86/intel_menlow.c 
b/drivers/platform/x86/intel_menlow.c
index 0a919d81662c..ae3a2a831533 100644
--- a/drivers/platform/x86/intel_menlow.c
+++ b/drivers/platform/x86/intel_menlow.c
@@ -306,33 +306,32 @@ static int sensor_set_auxtrip(acpi_handle handle, int 
index, int value)
 #define to_intel_menlow_attr(_attr)\
container_of(_attr, struct intel_menlow_attribute, attr)
 
-static ssize_t aux0_show(struct device *dev,
-struct device_attribute *dev_attr, char *buf)
+static ssize_t aux_show(struct device *dev, struct device_attribute *dev_attr,
+   char *buf, int idx)
 {
struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
unsigned long long value;
int result;
 
-   result = sensor_get_auxtrip(attr->handle, 0, );
+   result = sensor_get_auxtrip(attr->handle, idx, );
 
return result ? result : sprintf(buf, "%lu", 
DECI_KELVIN_TO_CELSIUS(value));
 }
 
-static ssize_t aux1_show(struct device *dev,
+static ssize_t aux0_show(struct device *dev,
 struct device_attribute *dev_attr, char *buf)
 {
-   struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
-   unsigned long long value;
-   int result;
-
-   result = sensor_get_auxtrip(attr->handle, 1, );
+   return aux_show(dev, dev_attr, buf, 0);
+}
 
-   return result ? result : sprintf(buf, "%lu", 
DECI_KELVIN_TO_CELSIUS(value));
+static ssize_t aux1_show(struct device *dev,
+struct device_attribute *dev_attr, char *buf)
+{
+   return aux_show(dev, dev_attr, buf, 1);
 }
 
-static ssize_t aux0_store(struct device *dev,
- struct device_attribute *dev_attr,
- const char *buf, size_t count)
+static ssize_t aux_store(struct device *dev, struct device_attribute *dev_attr,
+const char *buf, size_t count, int idx)
 {
struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
int value;
@@ -345,27 +344,22 @@ static ssize_t aux0_store(struct device *dev,
if (value < 0)
return -EINVAL;
 
-   result = sensor_set_auxtrip(attr->handle, 0, 
CELSIUS_TO_DECI_KELVIN(value));
+   result = sensor_set_auxtrip(attr->handle, idx, 
CELSIUS_TO_DECI_KELVIN(value));
return result ? result : count;
 }
 
-static ssize_t aux1_store(struct device *dev,
+static ssize_t aux0_store(struct device *dev,
  struct device_attribute *dev_attr,
  const char *buf, size_t count)
 {
-   struct intel_menlow_attribute *attr = to_intel_menlow_attr(dev_attr);
-   int value;
-   int result;
-
-   /*Sanity check; should be a positive integer */
-   if (!sscanf(buf, "%d", ))
-   return -EINVAL;
-
-   if (value < 0)
-   return -EINVAL;
+   return aux_store(dev, dev_attr, buf, count, 0);
+}
 
-   result = sensor_set_auxtrip(attr->handle, 1, 
CELSIUS_TO_DECI_KELVIN(value));
-   return result ? result : count;
+static ssize_t aux1_store(struct device *dev,
+ struct device_attribute *dev_attr,
+ const char *buf, size_t count)
+{
+   return aux_store(dev, dev_attr, buf, count, 1);
 }
 
 /* BIOS can enable/disable the thermal user application in dabney platform */
-- 
2.1.4

Re: usb: gadget breakage on N900: bind UDC by name passed via usb_gadget_driver structure

[Ruslan Bilovol]

Hi

On Fri, Mar 25, 2016 at 11:09 PM, Pavel Machek  wrote:
> Hi!
>
>> OK, so at last I finished charging of my N900; found 1.8V USB
>> to UART adapter and soldered it to the phone.
>>
>> I managed to boot N900 with working USB gadget (builtin g_ether)
>> in boardfile mode, can ping it from PC and transfer data. I don't
>> see any issue (except of musb name issue in twl phy driver, I've
>> already sent a fix for that: https://lkml.org/lkml/2016/3/24/670 )
>>
>> Pavel, I still don't see how you've got your issue, please share
>> more detials
>
> Ok, let me try. I undid all the changes in drivers/phy drivers/usb and
> include/linux/usb . I have all the gadget stuff built-in, so that I
> could use nfsroot, but this is boot from mmcblk.

So do you mean you use original rootfs that was shipeed with N900?

>
> gzipped config is attached.

Thanks, I'll try that

>
> PC is unable to work with the gadget:
>
> [256526.716099] usb 2-1: new full-speed USB device number 52 using
> uhci_hcd
> [256526.832091] usb 2-1: device descriptor read/64, error -32
> [256527.052095] usb 2-1: device descriptor read/64, error -32
> [256527.268160] usb 2-1: new full-speed USB device number 53 using
> uhci_hcd
> [256527.388121] usb 2-1: device descriptor read/64, error -32
> [256527.608116] usb 2-1: device descriptor read/64, error -32
> [256527.824170] usb 2-1: new full-speed USB device number 54 using
> uhci_hcd
> [256527.851175] usb 2-1: device descriptor read/8, error -32
> [256527.975175] usb 2-1: device descriptor read/8, error -32
> [256528.188133] usb 2-1: new full-speed USB device number 55 using
> uhci_hcd
> [256528.218184] usb 2-1: device descriptor read/8, error -32
> [256528.343183] usb 2-1: device descriptor read/8, error -32
> [256528.444314] usb usb2-port1: unable to enumerate USB device
>
> Dmesg from the n900 is attached as /tmp/delme.gz. I did _not_ apply
> the patch from https://lkml.org/lkml/2016/3/24/670 , yet, as I'm using
> devicetree boot.

Hmm.. don't see anything strange in the boot log related to USB,
I'll try your config

Best regards
Ruslan

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

Re: [GIT PULL] Ceph updates for 4.6-rc1

[Linus Torvalds]

On Sat, Mar 26, 2016 at 2:19 PM, Ilya Dryomov  wrote:
>
> This really is a result of a miscommunication between us and Al.
> Lesson learned.  Please reconsider and pull.

No.

If you guys rebase, I don't pull.

Stop rebasing. Really.

STOP REBASING.

There are no excuses. Just stop doing it. I'll handle the merge
issues. If there are complicated merge problems that you really worry
about, what you can do is

 (a) make a test-merge just to check

 (b) do NOT send me that test-merge

 (c) as part of the pull request, tell me that "there's a conflict
because xyz, and this is how we think it should be handled".

Because I'm really getting f*cking tired of having to get rebased
trees that don't match -next for no good reason every single merge
window.

So I'm done with it.

Let me repeat that one more time:

 If you rebase during the merge window without having a damn good
reason, don't expect me to pull the end result.

I don't understand why this is so hard for people to understand.

There are valid reasons to rebase, but those are along the line of "we
messed up catastrophically, and we _have_ to clean up the history".

A simple merge conflict due to a trivial duplicated commit is not a reason.

   Linus