[tip:perf/urgent] uprobes: Fix uprobes on MIPS, allow for a cache flush after ixol breakpoint creation

[tip-bot for Marcin Nowakowski]

Commit-ID:  297e765e390a2ac996000b5f7228cbd84d995174
Gitweb: http://git.kernel.org/tip/297e765e390a2ac996000b5f7228cbd84d995174
Author: Marcin Nowakowski 
AuthorDate: Tue, 13 Dec 2016 11:40:57 +0100
Committer:  Ingo Molnar 
CommitDate: Sun, 18 Dec 2016 09:42:11 +0100

uprobes: Fix uprobes on MIPS, allow for a cache flush after ixol breakpoint 
creation

Commit:

  72e6ae285a1d ('ARM: 8043/1: uprobes need icache flush after xol write'

... has introduced an arch-specific method to ensure all caches are
flushed appropriately after an instruction is written to an XOL page.

However, when the XOL area is created and the out-of-line breakpoint
instruction is copied, caches are not flushed at all and stale data may
be found in icache.

Replace a simple copy_to_page() with arch_uprobe_copy_ixol() to allow
the arch to ensure all caches are updated accordingly.

This change fixes uprobes on MIPS InterAptiv (tested on Creator Ci40).

Signed-off-by: Marcin Nowakowski 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Victor Kamensky 
Cc: linux-m...@linux-mips.org
Link: 
http://lkml.kernel.org/r/1481625657-22850-1-git-send-email-marcin.nowakow...@imgtec.com
Signed-off-by: Ingo Molnar 
---
 kernel/events/uprobes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index f9ec9ad..b5916b4 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1194,7 +1194,7 @@ static struct xol_area *__create_xol_area(unsigned long 
vaddr)
/* Reserve the 1st slot for get_trampoline_vaddr() */
set_bit(0, area->bitmap);
atomic_set(>slot_count, 1);
-   copy_to_page(area->pages[0], 0, , UPROBE_SWBP_INSN_SIZE);
+   arch_uprobe_copy_ixol(area->pages[0], 0, , UPROBE_SWBP_INSN_SIZE);
 
if (!xol_add_vma(mm, area))
return area;

[tip:perf/urgent] uprobes: Fix uprobes on MIPS, allow for a cache flush after ixol breakpoint creation

[tip-bot for Marcin Nowakowski]

Commit-ID:  297e765e390a2ac996000b5f7228cbd84d995174
Gitweb: http://git.kernel.org/tip/297e765e390a2ac996000b5f7228cbd84d995174
Author: Marcin Nowakowski 
AuthorDate: Tue, 13 Dec 2016 11:40:57 +0100
Committer:  Ingo Molnar 
CommitDate: Sun, 18 Dec 2016 09:42:11 +0100

uprobes: Fix uprobes on MIPS, allow for a cache flush after ixol breakpoint 
creation

Commit:

  72e6ae285a1d ('ARM: 8043/1: uprobes need icache flush after xol write'

... has introduced an arch-specific method to ensure all caches are
flushed appropriately after an instruction is written to an XOL page.

However, when the XOL area is created and the out-of-line breakpoint
instruction is copied, caches are not flushed at all and stale data may
be found in icache.

Replace a simple copy_to_page() with arch_uprobe_copy_ixol() to allow
the arch to ensure all caches are updated accordingly.

This change fixes uprobes on MIPS InterAptiv (tested on Creator Ci40).

Signed-off-by: Marcin Nowakowski 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Victor Kamensky 
Cc: linux-m...@linux-mips.org
Link: 
http://lkml.kernel.org/r/1481625657-22850-1-git-send-email-marcin.nowakow...@imgtec.com
Signed-off-by: Ingo Molnar 
---
 kernel/events/uprobes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index f9ec9ad..b5916b4 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1194,7 +1194,7 @@ static struct xol_area *__create_xol_area(unsigned long 
vaddr)
/* Reserve the 1st slot for get_trampoline_vaddr() */
set_bit(0, area->bitmap);
atomic_set(>slot_count, 1);
-   copy_to_page(area->pages[0], 0, , UPROBE_SWBP_INSN_SIZE);
+   arch_uprobe_copy_ixol(area->pages[0], 0, , UPROBE_SWBP_INSN_SIZE);
 
if (!xol_add_vma(mm, area))
return area;

Re: [PATCH v4 1/5] pinctrl: aspeed: dt: Fix compatibles for the System Control Unit

[Joel Stanley]

On Tue, Dec 20, 2016 at 6:05 PM, Andrew Jeffery  wrote:
> Reference the SoC-specific compatible string in the examples as
> required.
>
> Signed-off-by: Andrew Jeffery 

Acked-by: Joel Stanley 


> ---
>  Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

Re: [PATCH v4 1/5] pinctrl: aspeed: dt: Fix compatibles for the System Control Unit

[Joel Stanley]

On Tue, Dec 20, 2016 at 6:05 PM, Andrew Jeffery  wrote:
> Reference the SoC-specific compatible string in the examples as
> required.
>
> Signed-off-by: Andrew Jeffery 

Acked-by: Joel Stanley 


> ---
>  Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

Re: [GIT PULL] MFD for v4.10

[Lee Jones]

On Mon, 19 Dec 2016, Linus Torvalds wrote:

> On Mon, Dec 19, 2016 at 3:47 AM, Lee Jones  wrote:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git HEAD
> 
> Nothing there.
> 
> I'm assuming you meant the "for-linus-4.10" tag.

Yes.  Brain malfunction trying to get the PR out too quickly...

More haste, less speed!

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [GIT PULL] MFD for v4.10

[Lee Jones]

On Mon, 19 Dec 2016, Linus Torvalds wrote:

> On Mon, Dec 19, 2016 at 3:47 AM, Lee Jones  wrote:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git HEAD
> 
> Nothing there.
> 
> I'm assuming you meant the "for-linus-4.10" tag.

Yes.  Brain malfunction trying to get the PR out too quickly...

More haste, less speed!

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v4 3/5] pinctrl: aspeed-g4: Add mux configuration for all pins

[Andrew Jeffery]

The patch introducing the g4 pinctrl driver implemented a smattering of
pins to flesh out the implementation of the core and provide bare-bones
support for some OpenPOWER platforms. Now, update the bindings document
to reflect the complete functionality and implement the necessary pin
configuration tables in the driver.

Cc: Timothy Pearson 
Signed-off-by: Andrew Jeffery 
Acked-by: Joel Stanley 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |   19 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 1097 +++-
 2 files changed, 1096 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index fb7694ec033d..a645d0be3347 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -44,13 +44,18 @@ supported:
 
 aspeed,ast2400-pinctrl, aspeed,g4-pinctrl:
 
-ACPI BMCINT DDCCLK DDCDAT FLACK FLBUSY FLWP GPID0 GPIE0 GPIE2 GPIE4 GPIE6 I2C10
-I2C11 I2C12 I2C13 I2C3 I2C4 I2C5 I2C6 I2C7 I2C8 I2C9 LPCPD LPCPME LPCSMI MDIO1
-MDIO2 NCTS1 NCTS3 NCTS4 NDCD1 NDCD3 NDCD4 NDSR1 NDSR3 NDTR1 NDTR3 NRI1 NRI3
-NRI4 NRTS1 NRTS3 PWM0 PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RMII1 ROM16
-ROM8 ROMCS1 ROMCS2 ROMCS3 ROMCS4 RXD1 RXD3 RXD4 SD1 SGPMI SIOPBI SIOPBO TIMER3
-TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD3 TXD4 UART6 VGAHS VGAVS VPI18 VPI24 VPI30
-VPO12 VPO24
+ACPI ADC0 ADC1 ADC10 ADC11 ADC12 ADC13 ADC14 ADC15 ADC2 ADC3 ADC4 ADC5 ADC6
+ADC7 ADC8 ADC9 BMCINT DDCCLK DDCDAT EXTRST FLACK FLBUSY FLWP GPID GPID0 GPID2
+GPID4 GPID6 GPIE0 GPIE2 GPIE4 GPIE6 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4
+I2C5 I2C6 I2C7 I2C8 I2C9 LPCPD LPCPME LPCRST LPCSMI MAC1LINK MAC2LINK MDIO1
+MDIO2 NCTS1 NCTS2 NCTS3 NCTS4 NDCD1 NDCD2 NDCD3 NDCD4 NDSR1 NDSR2 NDSR3 NDSR4
+NDTR1 NDTR2 NDTR3 NDTR4 NDTS4 NRI1 NRI2 NRI3 NRI4 NRTS1 NRTS2 NRTS3 OSCCLK PWM0
+PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 ROM16 ROM8 ROMCS1
+ROMCS2 ROMCS3 ROMCS4 RXD1 RXD2 RXD3 RXD4 SALT1 SALT2 SALT3 SALT4 SD1 SD2 SGPMCK
+SGPMI SGPMLD SGPMO SGPSCK SGPSI0 SGPSI1 SGPSLD SIOONCTRL SIOPBI SIOPBO SIOPWREQ
+SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1DEBUG SPI1PASSTHRU SPICS1 TIMER3 TIMER4
+TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USBCKI VGABIOS_ROM VGAHS
+VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 WDTRST2
 
 aspeed,ast2500-pinctrl, aspeed,g5-pinctrl:
 
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index 558bd102416c..09b668415c56 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -43,9 +43,18 @@
  * Not all pins have their signals defined (yet).
  */
 
+#define D6 0
+SSSF_PIN_DECL(D6, GPIOA0, MAC1LINK, SIG_DESC_SET(SCU80, 0));
+
+#define B5 1
+SSSF_PIN_DECL(B5, GPIOA1, MAC2LINK, SIG_DESC_SET(SCU80, 1));
+
 #define A4 2
 SSSF_PIN_DECL(A4, GPIOA2, TIMER3, SIG_DESC_SET(SCU80, 2));
 
+#define E6 3
+SSSF_PIN_DECL(E6, GPIOA3, TIMER4, SIG_DESC_SET(SCU80, 3));
+
 #define I2C9_DESC  SIG_DESC_SET(SCU90, 22)
 
 #define C5 4
@@ -80,6 +89,26 @@ MS_PIN_DECL(D5, GPIOA7, MDIO2, TIMER8);
 FUNC_GROUP_DECL(TIMER8, D5);
 FUNC_GROUP_DECL(MDIO2, A3, D5);
 
+#define J21 8
+SSSF_PIN_DECL(J21, GPIOB0, SALT1, SIG_DESC_SET(SCU80, 8));
+
+#define J20 9
+SSSF_PIN_DECL(J20, GPIOB1, SALT2, SIG_DESC_SET(SCU80, 9));
+
+#define H18 10
+SSSF_PIN_DECL(H18, GPIOB2, SALT3, SIG_DESC_SET(SCU80, 10));
+
+#define F18 11
+SSSF_PIN_DECL(F18, GPIOB3, SALT4, SIG_DESC_SET(SCU80, 11));
+
+#define E19 12
+SIG_EXPR_DECL(LPCRST, LPCRST, SIG_DESC_SET(SCU80, 12));
+SIG_EXPR_DECL(LPCRST, LPCRSTS, SIG_DESC_SET(HW_STRAP1, 14));
+SIG_EXPR_LIST_DECL_DUAL(LPCRST, LPCRST, LPCRSTS);
+SS_PIN_DECL(E19, GPIOB4, LPCRST);
+
+FUNC_GROUP_DECL(LPCRST, E19);
+
 #define H19 13
 #define H19_DESCSIG_DESC_SET(SCU80, 13)
 SIG_EXPR_LIST_DECL_SINGLE(LPCPD, LPCPD, H19_DESC);
@@ -92,6 +121,19 @@ FUNC_GROUP_DECL(LPCSMI, H19);
 #define H20 14
 SSSF_PIN_DECL(H20, GPIOB6, LPCPME, SIG_DESC_SET(SCU80, 14));
 
+#define E18 15
+SIG_EXPR_LIST_DECL_SINGLE(EXTRST, EXTRST,
+   SIG_DESC_SET(SCU80, 15),
+   SIG_DESC_BIT(SCU90, 31, 0),
+   SIG_DESC_SET(SCU3C, 3));
+SIG_EXPR_LIST_DECL_SINGLE(SPICS1, SPICS1,
+   SIG_DESC_SET(SCU80, 15),
+   SIG_DESC_SET(SCU90, 31));
+MS_PIN_DECL(E18, GPIOB7, EXTRST, SPICS1);
+
+FUNC_GROUP_DECL(EXTRST, E18);
+FUNC_GROUP_DECL(SPICS1, E18);
+
 #define SD1_DESC   SIG_DESC_SET(SCU90, 0)
 #define I2C10_DESC SIG_DESC_SET(SCU90, 23)
 
@@ -170,6 +212,62 @@ MS_PIN_DECL(D16, GPIOD1, SD2CMD, GPID0OUT);
 
 FUNC_GROUP_DECL(GPID0, A18, D16);
 
+#define GPID2_DESC SIG_DESC_SET(SCU8C, 9)
+
+#define B17 26
+SIG_EXPR_LIST_DECL_SINGLE(SD2DAT0, SD2, SD2_DESC);
+SIG_EXPR_DECL(GPID2IN, GPID2, GPID2_DESC);
+SIG_EXPR_DECL(GPID2IN, GPID, 

[PATCH v4 3/5] pinctrl: aspeed-g4: Add mux configuration for all pins

[Andrew Jeffery]

The patch introducing the g4 pinctrl driver implemented a smattering of
pins to flesh out the implementation of the core and provide bare-bones
support for some OpenPOWER platforms. Now, update the bindings document
to reflect the complete functionality and implement the necessary pin
configuration tables in the driver.

Cc: Timothy Pearson 
Signed-off-by: Andrew Jeffery 
Acked-by: Joel Stanley 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |   19 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 1097 +++-
 2 files changed, 1096 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index fb7694ec033d..a645d0be3347 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -44,13 +44,18 @@ supported:
 
 aspeed,ast2400-pinctrl, aspeed,g4-pinctrl:
 
-ACPI BMCINT DDCCLK DDCDAT FLACK FLBUSY FLWP GPID0 GPIE0 GPIE2 GPIE4 GPIE6 I2C10
-I2C11 I2C12 I2C13 I2C3 I2C4 I2C5 I2C6 I2C7 I2C8 I2C9 LPCPD LPCPME LPCSMI MDIO1
-MDIO2 NCTS1 NCTS3 NCTS4 NDCD1 NDCD3 NDCD4 NDSR1 NDSR3 NDTR1 NDTR3 NRI1 NRI3
-NRI4 NRTS1 NRTS3 PWM0 PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RMII1 ROM16
-ROM8 ROMCS1 ROMCS2 ROMCS3 ROMCS4 RXD1 RXD3 RXD4 SD1 SGPMI SIOPBI SIOPBO TIMER3
-TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD3 TXD4 UART6 VGAHS VGAVS VPI18 VPI24 VPI30
-VPO12 VPO24
+ACPI ADC0 ADC1 ADC10 ADC11 ADC12 ADC13 ADC14 ADC15 ADC2 ADC3 ADC4 ADC5 ADC6
+ADC7 ADC8 ADC9 BMCINT DDCCLK DDCDAT EXTRST FLACK FLBUSY FLWP GPID GPID0 GPID2
+GPID4 GPID6 GPIE0 GPIE2 GPIE4 GPIE6 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4
+I2C5 I2C6 I2C7 I2C8 I2C9 LPCPD LPCPME LPCRST LPCSMI MAC1LINK MAC2LINK MDIO1
+MDIO2 NCTS1 NCTS2 NCTS3 NCTS4 NDCD1 NDCD2 NDCD3 NDCD4 NDSR1 NDSR2 NDSR3 NDSR4
+NDTR1 NDTR2 NDTR3 NDTR4 NDTS4 NRI1 NRI2 NRI3 NRI4 NRTS1 NRTS2 NRTS3 OSCCLK PWM0
+PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 ROM16 ROM8 ROMCS1
+ROMCS2 ROMCS3 ROMCS4 RXD1 RXD2 RXD3 RXD4 SALT1 SALT2 SALT3 SALT4 SD1 SD2 SGPMCK
+SGPMI SGPMLD SGPMO SGPSCK SGPSI0 SGPSI1 SGPSLD SIOONCTRL SIOPBI SIOPBO SIOPWREQ
+SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1DEBUG SPI1PASSTHRU SPICS1 TIMER3 TIMER4
+TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USBCKI VGABIOS_ROM VGAHS
+VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 WDTRST2
 
 aspeed,ast2500-pinctrl, aspeed,g5-pinctrl:
 
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index 558bd102416c..09b668415c56 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -43,9 +43,18 @@
  * Not all pins have their signals defined (yet).
  */
 
+#define D6 0
+SSSF_PIN_DECL(D6, GPIOA0, MAC1LINK, SIG_DESC_SET(SCU80, 0));
+
+#define B5 1
+SSSF_PIN_DECL(B5, GPIOA1, MAC2LINK, SIG_DESC_SET(SCU80, 1));
+
 #define A4 2
 SSSF_PIN_DECL(A4, GPIOA2, TIMER3, SIG_DESC_SET(SCU80, 2));
 
+#define E6 3
+SSSF_PIN_DECL(E6, GPIOA3, TIMER4, SIG_DESC_SET(SCU80, 3));
+
 #define I2C9_DESC  SIG_DESC_SET(SCU90, 22)
 
 #define C5 4
@@ -80,6 +89,26 @@ MS_PIN_DECL(D5, GPIOA7, MDIO2, TIMER8);
 FUNC_GROUP_DECL(TIMER8, D5);
 FUNC_GROUP_DECL(MDIO2, A3, D5);
 
+#define J21 8
+SSSF_PIN_DECL(J21, GPIOB0, SALT1, SIG_DESC_SET(SCU80, 8));
+
+#define J20 9
+SSSF_PIN_DECL(J20, GPIOB1, SALT2, SIG_DESC_SET(SCU80, 9));
+
+#define H18 10
+SSSF_PIN_DECL(H18, GPIOB2, SALT3, SIG_DESC_SET(SCU80, 10));
+
+#define F18 11
+SSSF_PIN_DECL(F18, GPIOB3, SALT4, SIG_DESC_SET(SCU80, 11));
+
+#define E19 12
+SIG_EXPR_DECL(LPCRST, LPCRST, SIG_DESC_SET(SCU80, 12));
+SIG_EXPR_DECL(LPCRST, LPCRSTS, SIG_DESC_SET(HW_STRAP1, 14));
+SIG_EXPR_LIST_DECL_DUAL(LPCRST, LPCRST, LPCRSTS);
+SS_PIN_DECL(E19, GPIOB4, LPCRST);
+
+FUNC_GROUP_DECL(LPCRST, E19);
+
 #define H19 13
 #define H19_DESCSIG_DESC_SET(SCU80, 13)
 SIG_EXPR_LIST_DECL_SINGLE(LPCPD, LPCPD, H19_DESC);
@@ -92,6 +121,19 @@ FUNC_GROUP_DECL(LPCSMI, H19);
 #define H20 14
 SSSF_PIN_DECL(H20, GPIOB6, LPCPME, SIG_DESC_SET(SCU80, 14));
 
+#define E18 15
+SIG_EXPR_LIST_DECL_SINGLE(EXTRST, EXTRST,
+   SIG_DESC_SET(SCU80, 15),
+   SIG_DESC_BIT(SCU90, 31, 0),
+   SIG_DESC_SET(SCU3C, 3));
+SIG_EXPR_LIST_DECL_SINGLE(SPICS1, SPICS1,
+   SIG_DESC_SET(SCU80, 15),
+   SIG_DESC_SET(SCU90, 31));
+MS_PIN_DECL(E18, GPIOB7, EXTRST, SPICS1);
+
+FUNC_GROUP_DECL(EXTRST, E18);
+FUNC_GROUP_DECL(SPICS1, E18);
+
 #define SD1_DESC   SIG_DESC_SET(SCU90, 0)
 #define I2C10_DESC SIG_DESC_SET(SCU90, 23)
 
@@ -170,6 +212,62 @@ MS_PIN_DECL(D16, GPIOD1, SD2CMD, GPID0OUT);
 
 FUNC_GROUP_DECL(GPID0, A18, D16);
 
+#define GPID2_DESC SIG_DESC_SET(SCU8C, 9)
+
+#define B17 26
+SIG_EXPR_LIST_DECL_SINGLE(SD2DAT0, SD2, SD2_DESC);
+SIG_EXPR_DECL(GPID2IN, GPID2, GPID2_DESC);
+SIG_EXPR_DECL(GPID2IN, GPID, GPID_DESC);
+SIG_EXPR_LIST_DECL_DUAL(GPID2IN, GPID2, GPID);
+MS_PIN_DECL(B17, GPIOD2, 

[PATCH v4 2/5] pinctrl: aspeed: Read and write bits in LPC and GFX controllers

[Andrew Jeffery]

The System Control Unit IP block in the Aspeed SoCs is typically where
the pinmux configuration is found, but not always. A number of pins
depend on state in one of LPC Host Control (LHC) or SoC Display
Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
means to adjust these as necessary.

We use syscon to cast a regmap over the GFX and LPC blocks, which is
used as an arbitration layer between the relevant driver and the pinctrl
subsystem. The regmaps are then exposed to the SoC-specific pinctrl
drivers by phandles in the devicetree, and are selected during a mux
request by querying a new 'ip' member in struct aspeed_sig_desc.

Signed-off-by: Andrew Jeffery 
Reviewed-by: Joel Stanley 
---

Joel: I kept your r-b tag here despite reworking the g5 example bindings, as
you've given your r-b for the lpc bindings which are what I have added.

 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |  80 --
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c |  18 +--
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c |  48 --
 drivers/pinctrl/aspeed/pinctrl-aspeed.c| 161 +
 drivers/pinctrl/aspeed/pinctrl-aspeed.h|  32 ++--
 5 files changed, 242 insertions(+), 97 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index b2efb73337c6..fb7694ec033d 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -1,15 +1,23 @@
+==
 Aspeed Pin Controllers
---
+==
 
 The Aspeed SoCs vary in functionality inside a generation but have a common mux
 device register layout.
 
-Required properties:
-- compatible : Should be any one of the following:
-   "aspeed,ast2400-pinctrl"
-   "aspeed,g4-pinctrl"
-   "aspeed,ast2500-pinctrl"
-   "aspeed,g5-pinctrl"
+Required properties for g4:
+- compatible : Should be one of the following:
+   "aspeed,ast2400-pinctrl"
+   "aspeed,g4-pinctrl"
+
+Required properties for g5:
+- compatible : Should be one of the following:
+   "aspeed,ast2500-pinctrl"
+   "aspeed,g5-pinctrl"
+
+- aspeed,external-nodes:   A cell of phandles to external controller nodes:
+   0: compatible with "aspeed,ast2500-gfx", 
"syscon"
+   1: compatible with "aspeed,ast2500-lhc", 
"syscon"
 
 The pin controller node should be the child of a syscon node with the required
 property:
@@ -24,7 +32,7 @@ Refer to the the bindings described in
 Documentation/devicetree/bindings/mfd/syscon.txt
 
 Subnode Format
---
+==
 
 The required properties of child nodes are (as defined in pinctrl-bindings):
 - function
@@ -51,8 +59,11 @@ I2C9 MAC1LINK MDIO1 MDIO2 OSCCLK PEWAKE PWM0 PWM1 PWM2 PWM3 
PWM4 PWM5 PWM6 PWM7
 RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
 TIMER7 TIMER8 VGABIOSROM
 
+Examples
+
 
-Examples:
+g4 Example
+--
 
 syscon: scu@1e6e2000 {
compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
@@ -68,5 +79,56 @@ syscon: scu@1e6e2000 {
};
 };
 
+g5 Example
+--
+
+ahb {
+   apb {
+   syscon: scu@1e6e2000 {
+   compatible = "aspeed,ast2500-scu", "syscon", 
"simple-mfd";
+   reg = <0x1e6e2000 0x1a8>;
+
+   pinctrl: pinctrl {
+   compatible = "aspeed,g5-pinctrl";
+   aspeed,external-nodes = < >;
+
+   pinctrl_i2c3_default: i2c3_default {
+   function = "I2C3";
+   groups = "I2C3";
+   };
+   };
+   };
+
+   gfx: display@1e6e6000 {
+   compatible = "aspeed,ast2500-gfx", "syscon";
+   reg = <0x1e6e6000 0x1000>;
+   };
+   };
+
+   lpc: lpc@1e789000 {
+   compatible = "aspeed,ast2500-lpc", "simple-mfd";
+   reg = <0x1e789000 0x1000>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x1e789000 0x1000>;
+
+   lpc_host: lpc-host@80 {
+   compatible = "aspeed,ast2500-lpc-host", "simple-mfd", 
"syscon";
+   reg = <0x80 0x1e0>;
+   reg-io-width = <4>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x80 0x1e0>;
+
+   lhc: 

[PATCH v4 4/5] pinctrl: aspeed-g5: Add mux configuration for all pins

[Andrew Jeffery]

The patch introducing the g5 pinctrl driver implemented a smattering of
pins to flesh out the implementation of the core and provide bare-bones
support for some OpenPOWER platforms and the AST2500 evaluation board.
Now, update the bindings document to reflect the complete functionality
and implement the necessary pin configuration tables in the driver.

Signed-off-by: Andrew Jeffery 
Acked-by: Joel Stanley 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |   17 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 1476 +++-
 drivers/pinctrl/aspeed/pinctrl-aspeed.h|1 +
 3 files changed, 1487 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index a645d0be3347..b98e6f030da8 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -59,10 +59,19 @@ VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 WDTRST2
 
 aspeed,ast2500-pinctrl, aspeed,g5-pinctrl:
 
-GPID0 GPID2 GPIE0 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4 I2C5 I2C6 I2C7 I2C8
-I2C9 MAC1LINK MDIO1 MDIO2 OSCCLK PEWAKE PWM0 PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7
-RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
-TIMER7 TIMER8 VGABIOSROM
+ACPI ADC0 ADC1 ADC10 ADC11 ADC12 ADC13 ADC14 ADC15 ADC2 ADC3 ADC4 ADC5 ADC6
+ADC7 ADC8 ADC9 BMCINT DDCCLK DDCDAT ESPI FWSPICS1 FWSPICS2 GPID0 GPID2 GPID4
+GPID6 GPIE0 GPIE2 GPIE4 GPIE6 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4 I2C5 I2C6
+I2C7 I2C8 I2C9 LAD0 LAD1 LAD2 LAD3 LCLK LFRAME LPCHC LPCPD LPCPLUS LPCPME
+LPCRST LPCSMI LSIRQ MAC1LINK MAC2LINK MDIO1 MDIO2 NCTS1 NCTS2 NCTS3 NCTS4 NDCD1
+NDCD2 NDCD3 NDCD4 NDSR1 NDSR2 NDSR3 NDSR4 NDTR1 NDTR2 NDTR3 NDTR4 NRI1 NRI2
+NRI3 NRI4 NRTS1 NRTS2 NRTS3 NRTS4 OSCCLK PEWAKE PNOR PWM0 PWM1 PWM2 PWM3 PWM4
+PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 RXD1 RXD2 RXD3 RXD4 SALT1 SALT10
+SALT11 SALT12 SALT13 SALT14 SALT2 SALT3 SALT4 SALT5 SALT6 SALT7 SALT8 SALT9
+SCL1 SCL2 SD1 SD2 SDA1 SDA2 SGPS1 SGPS2 SIOONCTRL SIOPBI SIOPBO SIOPWREQ
+SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1CS1 SPI1DEBUG SPI1PASSTHRU SPI2CK SPI2CS0
+SPI2CS1 SPI2MISO SPI2MOSI TIMER3 TIMER4 TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2
+TXD3 TXD4 UART6 USBCKI VGABIOSROM VGAHS VGAVS VPI24 VPO WDTRST1 WDTRST2
 
 Examples
 
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index c5c9a1b6fa1c..43221a3c7e23 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -25,14 +25,28 @@
 #include "../pinctrl-utils.h"
 #include "pinctrl-aspeed.h"
 
-#define ASPEED_G5_NR_PINS 228
+#define ASPEED_G5_NR_PINS 232
 
 #define COND1  { ASPEED_IP_SCU, SCU90, BIT(6), 0, 0 }
 #define COND2  { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
 
+/* LHCR0 is offset from the end of the H8S/2168-compatible registers */
+#define LHCR0  0x20
+#define GFX064 0x64
+
 #define B14 0
 SSSF_PIN_DECL(B14, GPIOA0, MAC1LINK, SIG_DESC_SET(SCU80, 0));
 
+#define D14 1
+SSSF_PIN_DECL(D14, GPIOA1, MAC2LINK, SIG_DESC_SET(SCU80, 1));
+
+#define D13 2
+SIG_EXPR_LIST_DECL_SINGLE(SPI1CS1, SPI1CS1, SIG_DESC_SET(SCU80, 15));
+SIG_EXPR_LIST_DECL_SINGLE(TIMER3, TIMER3, SIG_DESC_SET(SCU80, 2));
+MS_PIN_DECL(D13, GPIOA2, SPI1CS1, TIMER3);
+FUNC_GROUP_DECL(SPI1CS1, D13);
+FUNC_GROUP_DECL(TIMER3, D13);
+
 #define E13 3
 SSSF_PIN_DECL(E13, GPIOA3, TIMER4, SIG_DESC_SET(SCU80, 3));
 
@@ -72,6 +86,32 @@ FUNC_GROUP_DECL(TIMER8, B13);
 
 FUNC_GROUP_DECL(MDIO2, C13, B13);
 
+#define K19 8
+GPIO_PIN_DECL(K19, GPIOB0);
+
+#define L19 9
+GPIO_PIN_DECL(L19, GPIOB1);
+
+#define L18 10
+GPIO_PIN_DECL(L18, GPIOB2);
+
+#define K18 11
+GPIO_PIN_DECL(K18, GPIOB3);
+
+#define J20 12
+SSSF_PIN_DECL(J20, GPIOB4, USBCKI, SIG_DESC_SET(HW_STRAP1, 23));
+
+#define H21 13
+#define H21_DESC   SIG_DESC_SET(SCU80, 13)
+SIG_EXPR_LIST_DECL_SINGLE(LPCPD, LPCPD, H21_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(LPCSMI, LPCSMI, H21_DESC);
+MS_PIN_DECL(H21, GPIOB5, LPCPD, LPCSMI);
+FUNC_GROUP_DECL(LPCPD, H21);
+FUNC_GROUP_DECL(LPCSMI, H21);
+
+#define H22 14
+SSSF_PIN_DECL(H22, GPIOB6, LPCPME, SIG_DESC_SET(SCU80, 14));
+
 #define H20 15
 GPIO_PIN_DECL(H20, GPIOB7);
 
@@ -168,7 +208,44 @@ MS_PIN_DECL(D20, GPIOD3, SD2DAT1, GPID2OUT);
 
 FUNC_GROUP_DECL(GPID2, F20, D20);
 
-#define GPIE_DESC  SIG_DESC_SET(HW_STRAP1, 21)
+#define GPID4_DESC  SIG_DESC_SET(SCU8C, 10)
+
+#define D21 28
+SIG_EXPR_LIST_DECL_SINGLE(SD2DAT2, SD2, SD2_DESC);
+SIG_EXPR_DECL(GPID4IN, GPID4, GPID4_DESC);
+SIG_EXPR_DECL(GPID4IN, GPID, GPID_DESC);
+SIG_EXPR_LIST_DECL_DUAL(GPID4IN, GPID4, GPID);
+MS_PIN_DECL(D21, GPIOD4, SD2DAT2, GPID4IN);
+
+#define E20 29
+SIG_EXPR_LIST_DECL_SINGLE(SD2DAT3, SD2, SD2_DESC);
+SIG_EXPR_DECL(GPID4OUT, GPID4, GPID4_DESC);
+SIG_EXPR_DECL(GPID4OUT, GPID, GPID_DESC);

[PATCH v4 2/5] pinctrl: aspeed: Read and write bits in LPC and GFX controllers

[Andrew Jeffery]

The System Control Unit IP block in the Aspeed SoCs is typically where
the pinmux configuration is found, but not always. A number of pins
depend on state in one of LPC Host Control (LHC) or SoC Display
Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
means to adjust these as necessary.

We use syscon to cast a regmap over the GFX and LPC blocks, which is
used as an arbitration layer between the relevant driver and the pinctrl
subsystem. The regmaps are then exposed to the SoC-specific pinctrl
drivers by phandles in the devicetree, and are selected during a mux
request by querying a new 'ip' member in struct aspeed_sig_desc.

Signed-off-by: Andrew Jeffery 
Reviewed-by: Joel Stanley 
---

Joel: I kept your r-b tag here despite reworking the g5 example bindings, as
you've given your r-b for the lpc bindings which are what I have added.

 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |  80 --
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c |  18 +--
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c |  48 --
 drivers/pinctrl/aspeed/pinctrl-aspeed.c| 161 +
 drivers/pinctrl/aspeed/pinctrl-aspeed.h|  32 ++--
 5 files changed, 242 insertions(+), 97 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index b2efb73337c6..fb7694ec033d 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -1,15 +1,23 @@
+==
 Aspeed Pin Controllers
---
+==
 
 The Aspeed SoCs vary in functionality inside a generation but have a common mux
 device register layout.
 
-Required properties:
-- compatible : Should be any one of the following:
-   "aspeed,ast2400-pinctrl"
-   "aspeed,g4-pinctrl"
-   "aspeed,ast2500-pinctrl"
-   "aspeed,g5-pinctrl"
+Required properties for g4:
+- compatible : Should be one of the following:
+   "aspeed,ast2400-pinctrl"
+   "aspeed,g4-pinctrl"
+
+Required properties for g5:
+- compatible : Should be one of the following:
+   "aspeed,ast2500-pinctrl"
+   "aspeed,g5-pinctrl"
+
+- aspeed,external-nodes:   A cell of phandles to external controller nodes:
+   0: compatible with "aspeed,ast2500-gfx", 
"syscon"
+   1: compatible with "aspeed,ast2500-lhc", 
"syscon"
 
 The pin controller node should be the child of a syscon node with the required
 property:
@@ -24,7 +32,7 @@ Refer to the the bindings described in
 Documentation/devicetree/bindings/mfd/syscon.txt
 
 Subnode Format
---
+==
 
 The required properties of child nodes are (as defined in pinctrl-bindings):
 - function
@@ -51,8 +59,11 @@ I2C9 MAC1LINK MDIO1 MDIO2 OSCCLK PEWAKE PWM0 PWM1 PWM2 PWM3 
PWM4 PWM5 PWM6 PWM7
 RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
 TIMER7 TIMER8 VGABIOSROM
 
+Examples
+
 
-Examples:
+g4 Example
+--
 
 syscon: scu@1e6e2000 {
compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
@@ -68,5 +79,56 @@ syscon: scu@1e6e2000 {
};
 };
 
+g5 Example
+--
+
+ahb {
+   apb {
+   syscon: scu@1e6e2000 {
+   compatible = "aspeed,ast2500-scu", "syscon", 
"simple-mfd";
+   reg = <0x1e6e2000 0x1a8>;
+
+   pinctrl: pinctrl {
+   compatible = "aspeed,g5-pinctrl";
+   aspeed,external-nodes = < >;
+
+   pinctrl_i2c3_default: i2c3_default {
+   function = "I2C3";
+   groups = "I2C3";
+   };
+   };
+   };
+
+   gfx: display@1e6e6000 {
+   compatible = "aspeed,ast2500-gfx", "syscon";
+   reg = <0x1e6e6000 0x1000>;
+   };
+   };
+
+   lpc: lpc@1e789000 {
+   compatible = "aspeed,ast2500-lpc", "simple-mfd";
+   reg = <0x1e789000 0x1000>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x1e789000 0x1000>;
+
+   lpc_host: lpc-host@80 {
+   compatible = "aspeed,ast2500-lpc-host", "simple-mfd", 
"syscon";
+   reg = <0x80 0x1e0>;
+   reg-io-width = <4>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x80 0x1e0>;
+
+   lhc: lhc@20 {
+

[PATCH v4 4/5] pinctrl: aspeed-g5: Add mux configuration for all pins

[Andrew Jeffery]

The patch introducing the g5 pinctrl driver implemented a smattering of
pins to flesh out the implementation of the core and provide bare-bones
support for some OpenPOWER platforms and the AST2500 evaluation board.
Now, update the bindings document to reflect the complete functionality
and implement the necessary pin configuration tables in the driver.

Signed-off-by: Andrew Jeffery 
Acked-by: Joel Stanley 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |   17 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 1476 +++-
 drivers/pinctrl/aspeed/pinctrl-aspeed.h|1 +
 3 files changed, 1487 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index a645d0be3347..b98e6f030da8 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -59,10 +59,19 @@ VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 WDTRST2
 
 aspeed,ast2500-pinctrl, aspeed,g5-pinctrl:
 
-GPID0 GPID2 GPIE0 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4 I2C5 I2C6 I2C7 I2C8
-I2C9 MAC1LINK MDIO1 MDIO2 OSCCLK PEWAKE PWM0 PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7
-RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
-TIMER7 TIMER8 VGABIOSROM
+ACPI ADC0 ADC1 ADC10 ADC11 ADC12 ADC13 ADC14 ADC15 ADC2 ADC3 ADC4 ADC5 ADC6
+ADC7 ADC8 ADC9 BMCINT DDCCLK DDCDAT ESPI FWSPICS1 FWSPICS2 GPID0 GPID2 GPID4
+GPID6 GPIE0 GPIE2 GPIE4 GPIE6 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4 I2C5 I2C6
+I2C7 I2C8 I2C9 LAD0 LAD1 LAD2 LAD3 LCLK LFRAME LPCHC LPCPD LPCPLUS LPCPME
+LPCRST LPCSMI LSIRQ MAC1LINK MAC2LINK MDIO1 MDIO2 NCTS1 NCTS2 NCTS3 NCTS4 NDCD1
+NDCD2 NDCD3 NDCD4 NDSR1 NDSR2 NDSR3 NDSR4 NDTR1 NDTR2 NDTR3 NDTR4 NRI1 NRI2
+NRI3 NRI4 NRTS1 NRTS2 NRTS3 NRTS4 OSCCLK PEWAKE PNOR PWM0 PWM1 PWM2 PWM3 PWM4
+PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 RXD1 RXD2 RXD3 RXD4 SALT1 SALT10
+SALT11 SALT12 SALT13 SALT14 SALT2 SALT3 SALT4 SALT5 SALT6 SALT7 SALT8 SALT9
+SCL1 SCL2 SD1 SD2 SDA1 SDA2 SGPS1 SGPS2 SIOONCTRL SIOPBI SIOPBO SIOPWREQ
+SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1CS1 SPI1DEBUG SPI1PASSTHRU SPI2CK SPI2CS0
+SPI2CS1 SPI2MISO SPI2MOSI TIMER3 TIMER4 TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2
+TXD3 TXD4 UART6 USBCKI VGABIOSROM VGAHS VGAVS VPI24 VPO WDTRST1 WDTRST2
 
 Examples
 
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index c5c9a1b6fa1c..43221a3c7e23 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -25,14 +25,28 @@
 #include "../pinctrl-utils.h"
 #include "pinctrl-aspeed.h"
 
-#define ASPEED_G5_NR_PINS 228
+#define ASPEED_G5_NR_PINS 232
 
 #define COND1  { ASPEED_IP_SCU, SCU90, BIT(6), 0, 0 }
 #define COND2  { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
 
+/* LHCR0 is offset from the end of the H8S/2168-compatible registers */
+#define LHCR0  0x20
+#define GFX064 0x64
+
 #define B14 0
 SSSF_PIN_DECL(B14, GPIOA0, MAC1LINK, SIG_DESC_SET(SCU80, 0));
 
+#define D14 1
+SSSF_PIN_DECL(D14, GPIOA1, MAC2LINK, SIG_DESC_SET(SCU80, 1));
+
+#define D13 2
+SIG_EXPR_LIST_DECL_SINGLE(SPI1CS1, SPI1CS1, SIG_DESC_SET(SCU80, 15));
+SIG_EXPR_LIST_DECL_SINGLE(TIMER3, TIMER3, SIG_DESC_SET(SCU80, 2));
+MS_PIN_DECL(D13, GPIOA2, SPI1CS1, TIMER3);
+FUNC_GROUP_DECL(SPI1CS1, D13);
+FUNC_GROUP_DECL(TIMER3, D13);
+
 #define E13 3
 SSSF_PIN_DECL(E13, GPIOA3, TIMER4, SIG_DESC_SET(SCU80, 3));
 
@@ -72,6 +86,32 @@ FUNC_GROUP_DECL(TIMER8, B13);
 
 FUNC_GROUP_DECL(MDIO2, C13, B13);
 
+#define K19 8
+GPIO_PIN_DECL(K19, GPIOB0);
+
+#define L19 9
+GPIO_PIN_DECL(L19, GPIOB1);
+
+#define L18 10
+GPIO_PIN_DECL(L18, GPIOB2);
+
+#define K18 11
+GPIO_PIN_DECL(K18, GPIOB3);
+
+#define J20 12
+SSSF_PIN_DECL(J20, GPIOB4, USBCKI, SIG_DESC_SET(HW_STRAP1, 23));
+
+#define H21 13
+#define H21_DESC   SIG_DESC_SET(SCU80, 13)
+SIG_EXPR_LIST_DECL_SINGLE(LPCPD, LPCPD, H21_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(LPCSMI, LPCSMI, H21_DESC);
+MS_PIN_DECL(H21, GPIOB5, LPCPD, LPCSMI);
+FUNC_GROUP_DECL(LPCPD, H21);
+FUNC_GROUP_DECL(LPCSMI, H21);
+
+#define H22 14
+SSSF_PIN_DECL(H22, GPIOB6, LPCPME, SIG_DESC_SET(SCU80, 14));
+
 #define H20 15
 GPIO_PIN_DECL(H20, GPIOB7);
 
@@ -168,7 +208,44 @@ MS_PIN_DECL(D20, GPIOD3, SD2DAT1, GPID2OUT);
 
 FUNC_GROUP_DECL(GPID2, F20, D20);
 
-#define GPIE_DESC  SIG_DESC_SET(HW_STRAP1, 21)
+#define GPID4_DESC  SIG_DESC_SET(SCU8C, 10)
+
+#define D21 28
+SIG_EXPR_LIST_DECL_SINGLE(SD2DAT2, SD2, SD2_DESC);
+SIG_EXPR_DECL(GPID4IN, GPID4, GPID4_DESC);
+SIG_EXPR_DECL(GPID4IN, GPID, GPID_DESC);
+SIG_EXPR_LIST_DECL_DUAL(GPID4IN, GPID4, GPID);
+MS_PIN_DECL(D21, GPIOD4, SD2DAT2, GPID4IN);
+
+#define E20 29
+SIG_EXPR_LIST_DECL_SINGLE(SD2DAT3, SD2, SD2_DESC);
+SIG_EXPR_DECL(GPID4OUT, GPID4, GPID4_DESC);
+SIG_EXPR_DECL(GPID4OUT, GPID, GPID_DESC);
+SIG_EXPR_LIST_DECL_DUAL(GPID4OUT, GPID4, GPID);

[PATCH v4 5/5] pinctrl: aspeed: Fix kerneldoc return descriptions

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
Acked-by: Joel Stanley 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
index 782c5c97f853..76f62bd45f02 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
@@ -97,7 +97,7 @@ static inline void aspeed_sig_desc_print_val(
  * @enabled: True to query the enabled state, false to query disabled state
  * @regmap: The IP block's regmap instance
  *
- * @return 1 if the descriptor's bitfield is configured to the state
+ * Return: 1 if the descriptor's bitfield is configured to the state
  * selected by @enabled, 0 if not, and less than zero if an unrecoverable
  * failure occurred
  *
@@ -134,7 +134,7 @@ static int aspeed_sig_desc_eval(const struct 
aspeed_sig_desc *desc,
  * @enabled: True to query the enabled state, false to query disabled state
  * @maps: The list of regmap instances
  *
- * @return 1 if the expression composed by @enabled evaluates true, 0 if not,
+ * Return: 1 if the expression composed by @enabled evaluates true, 0 if not,
  * and less than zero if an unrecoverable failure occurred.
  *
  * A mux function is enabled or disabled if the function's signal expression
@@ -175,7 +175,7 @@ static int aspeed_sig_expr_eval(const struct 
aspeed_sig_expr *expr,
  *  expression, false to disable the function's signal
  * @maps: The list of regmap instances for pinmux register access.
  *
- * @return 0 if the expression is configured as requested and a negative error
+ * Return: 0 if the expression is configured as requested and a negative error
  * code otherwise
  */
 static int aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
@@ -256,7 +256,7 @@ static int aspeed_sig_expr_disable(const struct 
aspeed_sig_expr *expr,
  * @exprs: The list of signal expressions (from a priority level on a pin)
  * @maps: The list of regmap instances for pinmux register access.
  *
- * @return 0 if all expressions are disabled, otherwise a negative error code
+ * Return: 0 if all expressions are disabled, otherwise a negative error code
  */
 static int aspeed_disable_sig(const struct aspeed_sig_expr **exprs,
   struct regmap * const *maps)
@@ -281,8 +281,8 @@ static int aspeed_disable_sig(const struct aspeed_sig_expr 
**exprs,
  * @exprs: List of signal expressions (haystack)
  * @name: The name of the requested function (needle)
  *
- * @return A pointer to the signal expression whose function tag matches the
- * provided name, otherwise NULL.
+ * Return: A pointer to the signal expression whose function tag matches the
+ * provided name, otherwise NULL.
  *
  */
 static const struct aspeed_sig_expr *aspeed_find_expr_by_name(
-- 
2.9.3

[PATCH v4 5/5] pinctrl: aspeed: Fix kerneldoc return descriptions

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
Acked-by: Joel Stanley 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
index 782c5c97f853..76f62bd45f02 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
@@ -97,7 +97,7 @@ static inline void aspeed_sig_desc_print_val(
  * @enabled: True to query the enabled state, false to query disabled state
  * @regmap: The IP block's regmap instance
  *
- * @return 1 if the descriptor's bitfield is configured to the state
+ * Return: 1 if the descriptor's bitfield is configured to the state
  * selected by @enabled, 0 if not, and less than zero if an unrecoverable
  * failure occurred
  *
@@ -134,7 +134,7 @@ static int aspeed_sig_desc_eval(const struct 
aspeed_sig_desc *desc,
  * @enabled: True to query the enabled state, false to query disabled state
  * @maps: The list of regmap instances
  *
- * @return 1 if the expression composed by @enabled evaluates true, 0 if not,
+ * Return: 1 if the expression composed by @enabled evaluates true, 0 if not,
  * and less than zero if an unrecoverable failure occurred.
  *
  * A mux function is enabled or disabled if the function's signal expression
@@ -175,7 +175,7 @@ static int aspeed_sig_expr_eval(const struct 
aspeed_sig_expr *expr,
  *  expression, false to disable the function's signal
  * @maps: The list of regmap instances for pinmux register access.
  *
- * @return 0 if the expression is configured as requested and a negative error
+ * Return: 0 if the expression is configured as requested and a negative error
  * code otherwise
  */
 static int aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
@@ -256,7 +256,7 @@ static int aspeed_sig_expr_disable(const struct 
aspeed_sig_expr *expr,
  * @exprs: The list of signal expressions (from a priority level on a pin)
  * @maps: The list of regmap instances for pinmux register access.
  *
- * @return 0 if all expressions are disabled, otherwise a negative error code
+ * Return: 0 if all expressions are disabled, otherwise a negative error code
  */
 static int aspeed_disable_sig(const struct aspeed_sig_expr **exprs,
   struct regmap * const *maps)
@@ -281,8 +281,8 @@ static int aspeed_disable_sig(const struct aspeed_sig_expr 
**exprs,
  * @exprs: List of signal expressions (haystack)
  * @name: The name of the requested function (needle)
  *
- * @return A pointer to the signal expression whose function tag matches the
- * provided name, otherwise NULL.
+ * Return: A pointer to the signal expression whose function tag matches the
+ * provided name, otherwise NULL.
  *
  */
 static const struct aspeed_sig_expr *aspeed_find_expr_by_name(
-- 
2.9.3

[PATCH v4 0/5] pinctrl: aspeed: Implement remaining pins

[Andrew Jeffery]

Hi Linus,

This is v4 of the series implementing the remainder of the pinmux tables for
the AST2400 and AST2500 SoCs. v3 of the series can be found here:

https://lkml.org/lkml/2016/12/5/847

Cheers,

Andrew

Changes since v3:

* Add a patch fixing the AST2400 SCU compatible strings in the Aspeed pinctrl
  bindings. They are mentioned to define the expectations on the pinctrl node's
  parent and also in the examples to illustrate the relationship.

* Rework the g5 example bindings in patch 2/5 to reflect the LPC/LHC
  bindings[1][2], and fix the SCU compatible string.

[1] https://lkml.org/lkml/2016/12/20/63
[2] https://lkml.org/lkml/2016/12/20/62

Significant changes since v2:

* The fix for touching bit SCU90[6] has been applied, so the patch has been
  dropped.
* The MFD devicetree bindings patches have been split out into their own
  series: https://lkml.org/lkml/2016/12/5/835
* Rework the "Read and write bits in LPC and GFX controllers" patch so that the
  changes are backwards compatible with existing devicetrees. This will lead to
  limited functionality, but no more limited than what systems with those
  devicetrees already experience.
* A fix for the kerneldoc return value descriptions

Significant changes since v1:

* Fixes from v1 have been applied, so have been dropped for v2
* A new fix has appeared, "pinctrl-aspeed-g5: Never set SCU90[6]", as noted
  above
* New bindings documents for the SoC Display and LPC Host Controllers, driven
  by the patch "pinctrl: aspeed: Read and write bits in LPCHC and GFX
  controllers"
* The v1 patch "pinctrl: aspeed: Enable capture of off-SCU pinmux state" has
  been significantly reworked and is now titled "pinctrl: aspeed: Read and
  write bits in LPCHC and GFX controllers"

Andrew Jeffery (5):
  pinctrl: aspeed: dt: Fix compatibles for the System Control Unit
  pinctrl: aspeed: Read and write bits in LPC and GFX controllers
  pinctrl: aspeed-g4: Add mux configuration for all pins
  pinctrl: aspeed-g5: Add mux configuration for all pins
  pinctrl: aspeed: Fix kerneldoc return descriptions

 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |  127 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 1115 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 1524 +++-
 drivers/pinctrl/aspeed/pinctrl-aspeed.c|  165 ++-
 drivers/pinctrl/aspeed/pinctrl-aspeed.h|   33 +-
 5 files changed, 2835 insertions(+), 129 deletions(-)

-- 
2.9.3

[PATCH v4 0/5] pinctrl: aspeed: Implement remaining pins

[Andrew Jeffery]

Hi Linus,

This is v4 of the series implementing the remainder of the pinmux tables for
the AST2400 and AST2500 SoCs. v3 of the series can be found here:

https://lkml.org/lkml/2016/12/5/847

Cheers,

Andrew

Changes since v3:

* Add a patch fixing the AST2400 SCU compatible strings in the Aspeed pinctrl
  bindings. They are mentioned to define the expectations on the pinctrl node's
  parent and also in the examples to illustrate the relationship.

* Rework the g5 example bindings in patch 2/5 to reflect the LPC/LHC
  bindings[1][2], and fix the SCU compatible string.

[1] https://lkml.org/lkml/2016/12/20/63
[2] https://lkml.org/lkml/2016/12/20/62

Significant changes since v2:

* The fix for touching bit SCU90[6] has been applied, so the patch has been
  dropped.
* The MFD devicetree bindings patches have been split out into their own
  series: https://lkml.org/lkml/2016/12/5/835
* Rework the "Read and write bits in LPC and GFX controllers" patch so that the
  changes are backwards compatible with existing devicetrees. This will lead to
  limited functionality, but no more limited than what systems with those
  devicetrees already experience.
* A fix for the kerneldoc return value descriptions

Significant changes since v1:

* Fixes from v1 have been applied, so have been dropped for v2
* A new fix has appeared, "pinctrl-aspeed-g5: Never set SCU90[6]", as noted
  above
* New bindings documents for the SoC Display and LPC Host Controllers, driven
  by the patch "pinctrl: aspeed: Read and write bits in LPCHC and GFX
  controllers"
* The v1 patch "pinctrl: aspeed: Enable capture of off-SCU pinmux state" has
  been significantly reworked and is now titled "pinctrl: aspeed: Read and
  write bits in LPCHC and GFX controllers"

Andrew Jeffery (5):
  pinctrl: aspeed: dt: Fix compatibles for the System Control Unit
  pinctrl: aspeed: Read and write bits in LPC and GFX controllers
  pinctrl: aspeed-g4: Add mux configuration for all pins
  pinctrl: aspeed-g5: Add mux configuration for all pins
  pinctrl: aspeed: Fix kerneldoc return descriptions

 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |  127 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 1115 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 1524 +++-
 drivers/pinctrl/aspeed/pinctrl-aspeed.c|  165 ++-
 drivers/pinctrl/aspeed/pinctrl-aspeed.h|   33 +-
 5 files changed, 2835 insertions(+), 129 deletions(-)

-- 
2.9.3

[PATCH v4 1/5] pinctrl: aspeed: dt: Fix compatibles for the System Control Unit

[Andrew Jeffery]

Reference the SoC-specific compatible string in the examples as
required.

Signed-off-by: Andrew Jeffery 
---
 Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index 2ad18c4ea55c..b2efb73337c6 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -11,9 +11,14 @@ Required properties:
"aspeed,ast2500-pinctrl"
"aspeed,g5-pinctrl"
 
-The pin controller node should be a child of a syscon node with the required
+The pin controller node should be the child of a syscon node with the required
 property:
-- compatible: "syscon", "simple-mfd"
+
+- compatible : Should be one of the following:
+   "aspeed,ast2400-scu", "syscon", "simple-mfd"
+   "aspeed,g4-scu", "syscon", "simple-mfd"
+   "aspeed,ast2500-scu", "syscon", "simple-mfd"
+   "aspeed,g5-scu", "syscon", "simple-mfd"
 
 Refer to the the bindings described in
 Documentation/devicetree/bindings/mfd/syscon.txt
@@ -50,7 +55,7 @@ TIMER7 TIMER8 VGABIOSROM
 Examples:
 
 syscon: scu@1e6e2000 {
-   compatible = "syscon", "simple-mfd";
+   compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
reg = <0x1e6e2000 0x1a8>;
 
pinctrl: pinctrl {
-- 
2.9.3

[PATCH v4 1/5] pinctrl: aspeed: dt: Fix compatibles for the System Control Unit

[Andrew Jeffery]

Reference the SoC-specific compatible string in the examples as
required.

Signed-off-by: Andrew Jeffery 
---
 Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index 2ad18c4ea55c..b2efb73337c6 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -11,9 +11,14 @@ Required properties:
"aspeed,ast2500-pinctrl"
"aspeed,g5-pinctrl"
 
-The pin controller node should be a child of a syscon node with the required
+The pin controller node should be the child of a syscon node with the required
 property:
-- compatible: "syscon", "simple-mfd"
+
+- compatible : Should be one of the following:
+   "aspeed,ast2400-scu", "syscon", "simple-mfd"
+   "aspeed,g4-scu", "syscon", "simple-mfd"
+   "aspeed,ast2500-scu", "syscon", "simple-mfd"
+   "aspeed,g5-scu", "syscon", "simple-mfd"
 
 Refer to the the bindings described in
 Documentation/devicetree/bindings/mfd/syscon.txt
@@ -50,7 +55,7 @@ TIMER7 TIMER8 VGABIOSROM
 Examples:
 
 syscon: scu@1e6e2000 {
-   compatible = "syscon", "simple-mfd";
+   compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
reg = <0x1e6e2000 0x1a8>;
 
pinctrl: pinctrl {
-- 
2.9.3

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Baolin Wang]

Hi,

On 20 December 2016 at 15:18, Lu Baolu  wrote:
> Hi,
>
> On 12/20/2016 02:46 PM, Baolin Wang wrote:
>> On 20 December 2016 at 14:39, Lu Baolu  wrote:
>>> Hi,
>>>
>>> On 12/20/2016 02:06 PM, Baolin Wang wrote:
 Hi,

 On 20 December 2016 at 12:29, Lu Baolu  wrote:
> Hi Mathias,
>
> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
>> On 19.12.2016 13:34, Baolin Wang wrote:
>>> Hi Mathias,
>>>
>>> On 19 December 2016 at 18:33, Mathias Nyman
>>>  wrote:
 On 13.12.2016 05:21, Baolin Wang wrote:
> Hi Mathias,
>
> On 12 December 2016 at 23:52, Mathias Nyman
>  wrote:
>> On 05.12.2016 09:51, Baolin Wang wrote:
>>> If a command event is found on the event ring during an interrupt,
>>> we need to stop the command timer with del_timer(). Since 
>>> del_timer()
>>> can fail if the timer is running and waiting on the xHCI lock, then
>>> it maybe get the wrong timeout command in 
>>> xhci_handle_command_timeout()
>>> if host fetched a new command and updated the xhci->current_cmd in
>>> handle_cmd_completion(). For this situation, we need a way to signal
>>> to the command timer that everything is fine and it should exit.
>>
>> Ah, right, this could actually happen.
>>
>>> We should introduce a counter (xhci->current_cmd_pending) for the 
>>> number
>>> of pending commands. If we need to cancel the command timer and
>>> del_timer()
>>> succeeds, we decrement the number of pending commands. If 
>>> del_timer()
>>> fails,
>>> we leave the number of pending commands alone.
>>>
>>> For handling timeout command, in xhci_handle_command_timeout() we 
>>> will
>>> check
>>> the counter after decrementing it, if the counter
>>> (xhci->current_cmd_pending)
>>> is 0, which means xhci->current_cmd is the right timeout command. 
>>> If the
>>> counter (xhci->current_cmd_pending) is greater than 0, which means
>>> current
>>> timeout command has been handled by host and host has fetched new
>>> command
>>> as
>>> xhci->current_cmd, then just return and wait for new current 
>>> command.
>>
>> A counter like this could work.
>>
>> Writing the abort bit can generate either ABORT+STOP, or just STOP
>> event, this seems to cover both.
>>
>> quick check, case 1: timeout and cmd completion at the same time.
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> queue_command(more),
>> --completion irq fires---- timer times out at same 
>> time--
>> handle_cmd_completion() handle_cmd_timeout(),)
>> lock(xhci_lock  )   spin_on(xhci_lock)
>> del_timer() fail, p (=1, nochange)
>> cur_cmd = list_next(), p++ (=2)
>> unlock(xhci_lock)
>>   lock(xhci_lock)
>>   p-- (=1)
>>   if (p > 0), exit
>> OK works
>>
>> case 2: normal timeout case with ABORT+STOP, no race.
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> queue_command(more),
>>   handle_cmd_timeout()
>>   p-- (P=0), don't exit
>>   mod_timer(), p++ (P=1)
>>   write_abort_bit()
>> handle_cmd_comletion(ABORT)
>> del_timer(), ok, p-- (p = 0)
>> handle_cmd_completion(STOP)
>> del_timer(), fail, (P=0)
>> handle_stopped_cmd_ring()
>> cur_cmd = list_next(), p++ (=1)
>> mod_timer()
>>
>> OK, works, and same for just STOP case, with the only difference that
>> during handle_cmd_completion(STOP) p is decremented (p--)
> Yes, that's the cases what I want to handle, thanks for your explicit
> explanation.
>
 Gave this some more thought over the weekend, and this implementation
 doesn't solve the case when the last command times out and races with 
 the
 completion handler:

 cpu1cpu2

 queue_command(first), p++ (=1)
 --completion irq fires---- timer times out at same 
 time--
 

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Baolin Wang]

Hi,

On 20 December 2016 at 15:18, Lu Baolu  wrote:
> Hi,
>
> On 12/20/2016 02:46 PM, Baolin Wang wrote:
>> On 20 December 2016 at 14:39, Lu Baolu  wrote:
>>> Hi,
>>>
>>> On 12/20/2016 02:06 PM, Baolin Wang wrote:
 Hi,

 On 20 December 2016 at 12:29, Lu Baolu  wrote:
> Hi Mathias,
>
> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
>> On 19.12.2016 13:34, Baolin Wang wrote:
>>> Hi Mathias,
>>>
>>> On 19 December 2016 at 18:33, Mathias Nyman
>>>  wrote:
 On 13.12.2016 05:21, Baolin Wang wrote:
> Hi Mathias,
>
> On 12 December 2016 at 23:52, Mathias Nyman
>  wrote:
>> On 05.12.2016 09:51, Baolin Wang wrote:
>>> If a command event is found on the event ring during an interrupt,
>>> we need to stop the command timer with del_timer(). Since 
>>> del_timer()
>>> can fail if the timer is running and waiting on the xHCI lock, then
>>> it maybe get the wrong timeout command in 
>>> xhci_handle_command_timeout()
>>> if host fetched a new command and updated the xhci->current_cmd in
>>> handle_cmd_completion(). For this situation, we need a way to signal
>>> to the command timer that everything is fine and it should exit.
>>
>> Ah, right, this could actually happen.
>>
>>> We should introduce a counter (xhci->current_cmd_pending) for the 
>>> number
>>> of pending commands. If we need to cancel the command timer and
>>> del_timer()
>>> succeeds, we decrement the number of pending commands. If 
>>> del_timer()
>>> fails,
>>> we leave the number of pending commands alone.
>>>
>>> For handling timeout command, in xhci_handle_command_timeout() we 
>>> will
>>> check
>>> the counter after decrementing it, if the counter
>>> (xhci->current_cmd_pending)
>>> is 0, which means xhci->current_cmd is the right timeout command. 
>>> If the
>>> counter (xhci->current_cmd_pending) is greater than 0, which means
>>> current
>>> timeout command has been handled by host and host has fetched new
>>> command
>>> as
>>> xhci->current_cmd, then just return and wait for new current 
>>> command.
>>
>> A counter like this could work.
>>
>> Writing the abort bit can generate either ABORT+STOP, or just STOP
>> event, this seems to cover both.
>>
>> quick check, case 1: timeout and cmd completion at the same time.
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> queue_command(more),
>> --completion irq fires---- timer times out at same 
>> time--
>> handle_cmd_completion() handle_cmd_timeout(),)
>> lock(xhci_lock  )   spin_on(xhci_lock)
>> del_timer() fail, p (=1, nochange)
>> cur_cmd = list_next(), p++ (=2)
>> unlock(xhci_lock)
>>   lock(xhci_lock)
>>   p-- (=1)
>>   if (p > 0), exit
>> OK works
>>
>> case 2: normal timeout case with ABORT+STOP, no race.
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> queue_command(more),
>>   handle_cmd_timeout()
>>   p-- (P=0), don't exit
>>   mod_timer(), p++ (P=1)
>>   write_abort_bit()
>> handle_cmd_comletion(ABORT)
>> del_timer(), ok, p-- (p = 0)
>> handle_cmd_completion(STOP)
>> del_timer(), fail, (P=0)
>> handle_stopped_cmd_ring()
>> cur_cmd = list_next(), p++ (=1)
>> mod_timer()
>>
>> OK, works, and same for just STOP case, with the only difference that
>> during handle_cmd_completion(STOP) p is decremented (p--)
> Yes, that's the cases what I want to handle, thanks for your explicit
> explanation.
>
 Gave this some more thought over the weekend, and this implementation
 doesn't solve the case when the last command times out and races with 
 the
 completion handler:

 cpu1cpu2

 queue_command(first), p++ (=1)
 --completion irq fires---- timer times out at same 
 time--
 handle_cmd_completion() handle_cmd_timeout(),)
 lock(xhci_lock )spin_on(xhci_lock)
 del_timer() 

Re: [PATCH 2/4] mmc: mmc: Add change to set controller to HS400 frequency in enhanced strobe

[Shawn Lin]

On 2016/12/20 13:53, Ritesh Harjani wrote:

Currently mmc_select_hs400es is not setting the desired frequency
before sending switch command. This makes CMD13 to timeout on
some controllers.
Thus add a change to set the desired HS400 frequency
in mmc_select_hs400es when the timing is switched to HS400.


What is the desired HS400 freq? I guess it is 200MHz, right?

Well, per the spec, it just say "host *may* changes frequency to
<= 200Mhz". So before setting timing to MMC_TIMING_MMC_HS400, we
already reach ext_csd.hs_max_dtr. So it should meet the spec. If
the fact that some controllers would see CMD13 timeout here, I guess
you wouldn't let folks add max-frequency to the DT as if the max freq
is set to just lower than your *desired HS400 freq* , it the same
failure result even you add this patch, right?

the root cause the controllers see failure for CMD13 is it didn't
configure the right delay phase or something similar to fit the timing
under the freq of hs_max_dtr, I guess.



Signed-off-by: Ritesh Harjani 
---
 drivers/mmc/core/mmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index b61b52f9..eb69497 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1329,6 +1329,7 @@ static int mmc_select_hs400es(struct mmc_card *card)

/* Set host controller to HS400 timing and frequency */
mmc_set_timing(host, MMC_TIMING_MMC_HS400);
+   mmc_set_bus_speed(card);

/* Controller enable enhanced strobe function */
host->ios.enhanced_strobe = true;




--
Best Regards
Shawn Lin

Re: [PATCH 2/4] mmc: mmc: Add change to set controller to HS400 frequency in enhanced strobe

[Shawn Lin]

On 2016/12/20 13:53, Ritesh Harjani wrote:

Currently mmc_select_hs400es is not setting the desired frequency
before sending switch command. This makes CMD13 to timeout on
some controllers.
Thus add a change to set the desired HS400 frequency
in mmc_select_hs400es when the timing is switched to HS400.


What is the desired HS400 freq? I guess it is 200MHz, right?

Well, per the spec, it just say "host *may* changes frequency to
<= 200Mhz". So before setting timing to MMC_TIMING_MMC_HS400, we
already reach ext_csd.hs_max_dtr. So it should meet the spec. If
the fact that some controllers would see CMD13 timeout here, I guess
you wouldn't let folks add max-frequency to the DT as if the max freq
is set to just lower than your *desired HS400 freq* , it the same
failure result even you add this patch, right?

the root cause the controllers see failure for CMD13 is it didn't
configure the right delay phase or something similar to fit the timing
under the freq of hs_max_dtr, I guess.



Signed-off-by: Ritesh Harjani 
---
 drivers/mmc/core/mmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index b61b52f9..eb69497 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1329,6 +1329,7 @@ static int mmc_select_hs400es(struct mmc_card *card)

/* Set host controller to HS400 timing and frequency */
mmc_set_timing(host, MMC_TIMING_MMC_HS400);
+   mmc_set_bus_speed(card);

/* Controller enable enhanced strobe function */
host->ios.enhanced_strobe = true;




--
Best Regards
Shawn Lin

Re: [PATCH v3 2/5] lib: Add Sed-opal library

[Christoph Hellwig]

> + u8 lr;
> + size_t key_name_len;
> + char key_name[36];

Who is going to use the key_name?  I can't find another reference to
it anywhere else in the code.   The reason why this tripped me off was
the hardcoded length so I was going to check on how access to it is
bounds checked.

> +/**
> + * struct opal_dev - The structure representing a OPAL enabled SED.
> + * @sed_ctx:The SED context, contains fn pointers to sec_send/recv.
> + * @opal_step:A series of opal methods that are necessary to complete a 
> comannd.
> + * @func_data:An array of parameters for the opal methods above.
> + * @state:Describes the current opal_step we're working on.
> + * @dev_lock:Locks the entire opal_dev structure.
> + * @parsed:Parsed response from controller.
> + * @prev_data:Data returned from a method to the controller
> + * @error_cb:Error function that handles closing sessions after a failed 
> method.
> + * @unlk_lst:A list of Locking ranges to unlock on this device during a 
> resume.
> + */

Needs spaces after the colons.

> + u16 comID;
> + u32 HSN;
> + u32 TSN;

Please use lower case variable names in Linux code, and separate
words by underscores if needed.

> +DEFINE_SPINLOCK(list_spinlock);

Should be marked static.

> +#define TPER_SYNC_SUPPORTED BIT(0)

This sounds like a protocol constant and should go into the header
with the rest of the protocol.

> +static bool check_tper(const void *data)
> +{
> + const struct d0_tper_features *tper = data;
> + u8 flags = tper->supported_features;
> +
> + if (!(flags & TPER_SYNC_SUPPORTED)) {
> + pr_err("TPer sync not supported. flags = %d\n",
> +tper->supported_features);

It would be great to use dev_err / dev_warn / etc in the opal code,
although for that you'll need to pass a struct device from the driver
into the code.

> +static bool check_SUM(const void *data)

The comment on member naming above also applies to variables and function
names.

> + bool foundComID = false, supported = true, single_user = false;
> + const struct d0_header *hdr;
> + const u8 *epos, *cpos;
> + u16 comID = 0;
> + int error = 0;
> +
> + epos = dev->cmd.resp;
> + cpos = dev->cmd.resp;
> + hdr = (struct d0_header *)dev->cmd.resp;

You probably want to structure your command buffers to use void pointers
and avoid ths kind of casting.

> +#define TINY_ATOM_DATA_MASK GENMASK(5, 0)
> +#define TINY_ATOM_SIGNED BIT(6)
> +
> +#define SHORT_ATOM_ID BIT(7)
> +#define SHORT_ATOM_BYTESTRING BIT(5)
> +#define SHORT_ATOM_SIGNED BIT(4)
> +#define SHORT_ATOM_LEN_MASK GENMASK(3, 0)

Protocol constants for the header again?

> +#define ADD_TOKEN_STRING(cmd, key, keylen)   \
> + if (!err)   \
> + err = test_and_add_string(cmd, key, keylen);
> +
> +#define ADD_TOKEN(type, cmd, tok)\
> + if (!err)   \
> + err = test_and_add_token_##type(cmd, tok);

Please remove these macros and just open code the calls.  If you want
to avoid writing the if err lines again and again just pass err
by reference to the functions and move the err check into the add_token*
helpers.

> + if ((hdr->cp.length == 0)
> + || (hdr->pkt.length == 0)
> + || (hdr->subpkt.length == 0)) {

No need for the inner braces, also please place the operators at the
end of the previous line instead of the beginning of the new line.

> + while (cpos < total) {
> + if (!(pos[0] & 0x80)) /* tiny atom */
> + token_length = response_parse_tiny(iter, pos);
> + else if (!(pos[0] & 0x40)) /* short atom */
> + token_length = response_parse_short(iter, pos);
> + else if (!(pos[0] & 0x20)) /* medium atom */
> + token_length = response_parse_medium(iter, pos);
> + else if (!(pos[0] & 0x10)) /* long atom */
> + token_length = response_parse_long(iter, pos);

Please add symbolic names for these constants to the protocol header.

> + if (num_entries == 0) {
> + pr_err("Couldn't parse response.\n");
> + return -EINVAL;
> + resp->num = num_entries;

Where is the closing brace for that if?

> + if (!((resp->toks[n].width == OPAL_WIDTH_TINY) ||
> +   (resp->toks[n].width == OPAL_WIDTH_SHORT))) {

No need for the inner braces.

> + pr_err("Atom is not short or tiny: %d\n",
> +resp->toks[n].width);
> + return 0;
> + }
> +
> + return resp->toks[n].stored.u;
> +}
> +
> +static u8 response_status(const struct parsed_resp *resp)
> +{
> + if ((token_type(resp, 0) == OPAL_DTA_TOKENID_TOKEN)
> + && (response_get_token(resp, 0) == OPAL_ENDOFSESSION)) {

Same here, also please fix the operator placement.

> + if ((token_type(resp, resp->num - 1) != 

Re: [PATCH v3 2/5] lib: Add Sed-opal library

[Christoph Hellwig]

> + u8 lr;
> + size_t key_name_len;
> + char key_name[36];

Who is going to use the key_name?  I can't find another reference to
it anywhere else in the code.   The reason why this tripped me off was
the hardcoded length so I was going to check on how access to it is
bounds checked.

> +/**
> + * struct opal_dev - The structure representing a OPAL enabled SED.
> + * @sed_ctx:The SED context, contains fn pointers to sec_send/recv.
> + * @opal_step:A series of opal methods that are necessary to complete a 
> comannd.
> + * @func_data:An array of parameters for the opal methods above.
> + * @state:Describes the current opal_step we're working on.
> + * @dev_lock:Locks the entire opal_dev structure.
> + * @parsed:Parsed response from controller.
> + * @prev_data:Data returned from a method to the controller
> + * @error_cb:Error function that handles closing sessions after a failed 
> method.
> + * @unlk_lst:A list of Locking ranges to unlock on this device during a 
> resume.
> + */

Needs spaces after the colons.

> + u16 comID;
> + u32 HSN;
> + u32 TSN;

Please use lower case variable names in Linux code, and separate
words by underscores if needed.

> +DEFINE_SPINLOCK(list_spinlock);

Should be marked static.

> +#define TPER_SYNC_SUPPORTED BIT(0)

This sounds like a protocol constant and should go into the header
with the rest of the protocol.

> +static bool check_tper(const void *data)
> +{
> + const struct d0_tper_features *tper = data;
> + u8 flags = tper->supported_features;
> +
> + if (!(flags & TPER_SYNC_SUPPORTED)) {
> + pr_err("TPer sync not supported. flags = %d\n",
> +tper->supported_features);

It would be great to use dev_err / dev_warn / etc in the opal code,
although for that you'll need to pass a struct device from the driver
into the code.

> +static bool check_SUM(const void *data)

The comment on member naming above also applies to variables and function
names.

> + bool foundComID = false, supported = true, single_user = false;
> + const struct d0_header *hdr;
> + const u8 *epos, *cpos;
> + u16 comID = 0;
> + int error = 0;
> +
> + epos = dev->cmd.resp;
> + cpos = dev->cmd.resp;
> + hdr = (struct d0_header *)dev->cmd.resp;

You probably want to structure your command buffers to use void pointers
and avoid ths kind of casting.

> +#define TINY_ATOM_DATA_MASK GENMASK(5, 0)
> +#define TINY_ATOM_SIGNED BIT(6)
> +
> +#define SHORT_ATOM_ID BIT(7)
> +#define SHORT_ATOM_BYTESTRING BIT(5)
> +#define SHORT_ATOM_SIGNED BIT(4)
> +#define SHORT_ATOM_LEN_MASK GENMASK(3, 0)

Protocol constants for the header again?

> +#define ADD_TOKEN_STRING(cmd, key, keylen)   \
> + if (!err)   \
> + err = test_and_add_string(cmd, key, keylen);
> +
> +#define ADD_TOKEN(type, cmd, tok)\
> + if (!err)   \
> + err = test_and_add_token_##type(cmd, tok);

Please remove these macros and just open code the calls.  If you want
to avoid writing the if err lines again and again just pass err
by reference to the functions and move the err check into the add_token*
helpers.

> + if ((hdr->cp.length == 0)
> + || (hdr->pkt.length == 0)
> + || (hdr->subpkt.length == 0)) {

No need for the inner braces, also please place the operators at the
end of the previous line instead of the beginning of the new line.

> + while (cpos < total) {
> + if (!(pos[0] & 0x80)) /* tiny atom */
> + token_length = response_parse_tiny(iter, pos);
> + else if (!(pos[0] & 0x40)) /* short atom */
> + token_length = response_parse_short(iter, pos);
> + else if (!(pos[0] & 0x20)) /* medium atom */
> + token_length = response_parse_medium(iter, pos);
> + else if (!(pos[0] & 0x10)) /* long atom */
> + token_length = response_parse_long(iter, pos);

Please add symbolic names for these constants to the protocol header.

> + if (num_entries == 0) {
> + pr_err("Couldn't parse response.\n");
> + return -EINVAL;
> + resp->num = num_entries;

Where is the closing brace for that if?

> + if (!((resp->toks[n].width == OPAL_WIDTH_TINY) ||
> +   (resp->toks[n].width == OPAL_WIDTH_SHORT))) {

No need for the inner braces.

> + pr_err("Atom is not short or tiny: %d\n",
> +resp->toks[n].width);
> + return 0;
> + }
> +
> + return resp->toks[n].stored.u;
> +}
> +
> +static u8 response_status(const struct parsed_resp *resp)
> +{
> + if ((token_type(resp, 0) == OPAL_DTA_TOKENID_TOKEN)
> + && (response_get_token(resp, 0) == OPAL_ENDOFSESSION)) {

Same here, also please fix the operator placement.

> + if ((token_type(resp, resp->num - 1) != 

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Lu Baolu]

Hi,

On 12/20/2016 02:46 PM, Baolin Wang wrote:
> On 20 December 2016 at 14:39, Lu Baolu  wrote:
>> Hi,
>>
>> On 12/20/2016 02:06 PM, Baolin Wang wrote:
>>> Hi,
>>>
>>> On 20 December 2016 at 12:29, Lu Baolu  wrote:
 Hi Mathias,

 On 12/19/2016 08:13 PM, Mathias Nyman wrote:
> On 19.12.2016 13:34, Baolin Wang wrote:
>> Hi Mathias,
>>
>> On 19 December 2016 at 18:33, Mathias Nyman
>>  wrote:
>>> On 13.12.2016 05:21, Baolin Wang wrote:
 Hi Mathias,

 On 12 December 2016 at 23:52, Mathias Nyman
  wrote:
> On 05.12.2016 09:51, Baolin Wang wrote:
>> If a command event is found on the event ring during an interrupt,
>> we need to stop the command timer with del_timer(). Since del_timer()
>> can fail if the timer is running and waiting on the xHCI lock, then
>> it maybe get the wrong timeout command in 
>> xhci_handle_command_timeout()
>> if host fetched a new command and updated the xhci->current_cmd in
>> handle_cmd_completion(). For this situation, we need a way to signal
>> to the command timer that everything is fine and it should exit.
>
> Ah, right, this could actually happen.
>
>> We should introduce a counter (xhci->current_cmd_pending) for the 
>> number
>> of pending commands. If we need to cancel the command timer and
>> del_timer()
>> succeeds, we decrement the number of pending commands. If del_timer()
>> fails,
>> we leave the number of pending commands alone.
>>
>> For handling timeout command, in xhci_handle_command_timeout() we 
>> will
>> check
>> the counter after decrementing it, if the counter
>> (xhci->current_cmd_pending)
>> is 0, which means xhci->current_cmd is the right timeout command. If 
>> the
>> counter (xhci->current_cmd_pending) is greater than 0, which means
>> current
>> timeout command has been handled by host and host has fetched new
>> command
>> as
>> xhci->current_cmd, then just return and wait for new current command.
>
> A counter like this could work.
>
> Writing the abort bit can generate either ABORT+STOP, or just STOP
> event, this seems to cover both.
>
> quick check, case 1: timeout and cmd completion at the same time.
>
> cpu1cpu2
>
> queue_command(first), p++ (=1)
> queue_command(more),
> --completion irq fires---- timer times out at same 
> time--
> handle_cmd_completion() handle_cmd_timeout(),)
> lock(xhci_lock  )   spin_on(xhci_lock)
> del_timer() fail, p (=1, nochange)
> cur_cmd = list_next(), p++ (=2)
> unlock(xhci_lock)
>   lock(xhci_lock)
>   p-- (=1)
>   if (p > 0), exit
> OK works
>
> case 2: normal timeout case with ABORT+STOP, no race.
>
> cpu1cpu2
>
> queue_command(first), p++ (=1)
> queue_command(more),
>   handle_cmd_timeout()
>   p-- (P=0), don't exit
>   mod_timer(), p++ (P=1)
>   write_abort_bit()
> handle_cmd_comletion(ABORT)
> del_timer(), ok, p-- (p = 0)
> handle_cmd_completion(STOP)
> del_timer(), fail, (P=0)
> handle_stopped_cmd_ring()
> cur_cmd = list_next(), p++ (=1)
> mod_timer()
>
> OK, works, and same for just STOP case, with the only difference that
> during handle_cmd_completion(STOP) p is decremented (p--)
 Yes, that's the cases what I want to handle, thanks for your explicit
 explanation.

>>> Gave this some more thought over the weekend, and this implementation
>>> doesn't solve the case when the last command times out and races with 
>>> the
>>> completion handler:
>>>
>>> cpu1cpu2
>>>
>>> queue_command(first), p++ (=1)
>>> --completion irq fires---- timer times out at same 
>>> time--
>>> handle_cmd_completion() handle_cmd_timeout(),)
>>> lock(xhci_lock )spin_on(xhci_lock)
>>> del_timer() fail, p (=1, nochange)
>>> no more commands, P (=1, nochange)
>>> unlock(xhci_lock)

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Lu Baolu]

Hi,

On 12/20/2016 02:46 PM, Baolin Wang wrote:
> On 20 December 2016 at 14:39, Lu Baolu  wrote:
>> Hi,
>>
>> On 12/20/2016 02:06 PM, Baolin Wang wrote:
>>> Hi,
>>>
>>> On 20 December 2016 at 12:29, Lu Baolu  wrote:
 Hi Mathias,

 On 12/19/2016 08:13 PM, Mathias Nyman wrote:
> On 19.12.2016 13:34, Baolin Wang wrote:
>> Hi Mathias,
>>
>> On 19 December 2016 at 18:33, Mathias Nyman
>>  wrote:
>>> On 13.12.2016 05:21, Baolin Wang wrote:
 Hi Mathias,

 On 12 December 2016 at 23:52, Mathias Nyman
  wrote:
> On 05.12.2016 09:51, Baolin Wang wrote:
>> If a command event is found on the event ring during an interrupt,
>> we need to stop the command timer with del_timer(). Since del_timer()
>> can fail if the timer is running and waiting on the xHCI lock, then
>> it maybe get the wrong timeout command in 
>> xhci_handle_command_timeout()
>> if host fetched a new command and updated the xhci->current_cmd in
>> handle_cmd_completion(). For this situation, we need a way to signal
>> to the command timer that everything is fine and it should exit.
>
> Ah, right, this could actually happen.
>
>> We should introduce a counter (xhci->current_cmd_pending) for the 
>> number
>> of pending commands. If we need to cancel the command timer and
>> del_timer()
>> succeeds, we decrement the number of pending commands. If del_timer()
>> fails,
>> we leave the number of pending commands alone.
>>
>> For handling timeout command, in xhci_handle_command_timeout() we 
>> will
>> check
>> the counter after decrementing it, if the counter
>> (xhci->current_cmd_pending)
>> is 0, which means xhci->current_cmd is the right timeout command. If 
>> the
>> counter (xhci->current_cmd_pending) is greater than 0, which means
>> current
>> timeout command has been handled by host and host has fetched new
>> command
>> as
>> xhci->current_cmd, then just return and wait for new current command.
>
> A counter like this could work.
>
> Writing the abort bit can generate either ABORT+STOP, or just STOP
> event, this seems to cover both.
>
> quick check, case 1: timeout and cmd completion at the same time.
>
> cpu1cpu2
>
> queue_command(first), p++ (=1)
> queue_command(more),
> --completion irq fires---- timer times out at same 
> time--
> handle_cmd_completion() handle_cmd_timeout(),)
> lock(xhci_lock  )   spin_on(xhci_lock)
> del_timer() fail, p (=1, nochange)
> cur_cmd = list_next(), p++ (=2)
> unlock(xhci_lock)
>   lock(xhci_lock)
>   p-- (=1)
>   if (p > 0), exit
> OK works
>
> case 2: normal timeout case with ABORT+STOP, no race.
>
> cpu1cpu2
>
> queue_command(first), p++ (=1)
> queue_command(more),
>   handle_cmd_timeout()
>   p-- (P=0), don't exit
>   mod_timer(), p++ (P=1)
>   write_abort_bit()
> handle_cmd_comletion(ABORT)
> del_timer(), ok, p-- (p = 0)
> handle_cmd_completion(STOP)
> del_timer(), fail, (P=0)
> handle_stopped_cmd_ring()
> cur_cmd = list_next(), p++ (=1)
> mod_timer()
>
> OK, works, and same for just STOP case, with the only difference that
> during handle_cmd_completion(STOP) p is decremented (p--)
 Yes, that's the cases what I want to handle, thanks for your explicit
 explanation.

>>> Gave this some more thought over the weekend, and this implementation
>>> doesn't solve the case when the last command times out and races with 
>>> the
>>> completion handler:
>>>
>>> cpu1cpu2
>>>
>>> queue_command(first), p++ (=1)
>>> --completion irq fires---- timer times out at same 
>>> time--
>>> handle_cmd_completion() handle_cmd_timeout(),)
>>> lock(xhci_lock )spin_on(xhci_lock)
>>> del_timer() fail, p (=1, nochange)
>>> no more commands, P (=1, nochange)
>>> unlock(xhci_lock)
>>>  lock(xhci_lock)
>>>  p-- 

[PATCH v4 5/5] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)

[Andrew Jeffery]

The Aspeed SoC Display Controller is presented as a syscon device to
arbitrate access by display and pinmux drivers. Video pinmux
configuration on fifth generation SoCs depends on bits in both the
System Control Unit and the Display Controller.

Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
new file mode 100644
index ..aea5370efd97
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
@@ -0,0 +1,17 @@
+* Device tree bindings for Aspeed SoC Display Controller (GFX)
+
+The Aspeed SoC Display Controller primarily does as its name suggests, but also
+participates in pinmux requests on the g5 SoCs. It is therefore considered a
+syscon device.
+
+Required properties:
+- compatible:  "aspeed,ast2500-gfx", "syscon"
+- reg: contains offset/length value of the GFX memory
+   region.
+
+Example:
+
+gfx: display@1e6e6000 {
+   compatible = "aspeed,ast2500-gfx", "syscon";
+   reg = <0x1e6e6000 0x1000>;
+};
-- 
2.9.3

[PATCH v4 4/5] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)

[Andrew Jeffery]

The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.

The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.

Signed-off-by: Andrew Jeffery 
Reviewed-by: Linus Walleij 
---

Linus: I've retained your r-b tag I don't think the addition of the ast2400
compatible string will fuss you. Please let me know if you feel this is
inappropriate.

 .../devicetree/bindings/mfd/aspeed-lpc.txt | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
index a97131aba446..514d82ced95b 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -109,3 +109,29 @@ lpc: lpc@1e789000 {
};
 };
 
+Host Node Children
+==
+
+LPC Host Controller
+---
+
+The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
+between the host and the baseboard management controller. The registers exist
+in the "host" portion of the Aspeed LPC controller, which must be the parent of
+the LPC host controller node.
+
+Required properties:
+
+- compatible:  One of:
+   "aspeed,ast2400-lhc";
+   "aspeed,ast2500-lhc";
+
+- reg: contains offset/length values of the LHC memory regions. In the
+   AST2400 and AST2500 there are two regions.
+
+Example:
+
+lhc: lhc@20 {
+   compatible = "aspeed,ast2500-lhc";
+   reg = <0x20 0x24 0x48 0x8>;
+};
-- 
2.9.3

[PATCH v4 5/5] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)

[Andrew Jeffery]

The Aspeed SoC Display Controller is presented as a syscon device to
arbitrate access by display and pinmux drivers. Video pinmux
configuration on fifth generation SoCs depends on bits in both the
System Control Unit and the Display Controller.

Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
new file mode 100644
index ..aea5370efd97
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
@@ -0,0 +1,17 @@
+* Device tree bindings for Aspeed SoC Display Controller (GFX)
+
+The Aspeed SoC Display Controller primarily does as its name suggests, but also
+participates in pinmux requests on the g5 SoCs. It is therefore considered a
+syscon device.
+
+Required properties:
+- compatible:  "aspeed,ast2500-gfx", "syscon"
+- reg: contains offset/length value of the GFX memory
+   region.
+
+Example:
+
+gfx: display@1e6e6000 {
+   compatible = "aspeed,ast2500-gfx", "syscon";
+   reg = <0x1e6e6000 0x1000>;
+};
-- 
2.9.3

[PATCH v4 4/5] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)

[Andrew Jeffery]

The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.

The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.

Signed-off-by: Andrew Jeffery 
Reviewed-by: Linus Walleij 
---

Linus: I've retained your r-b tag I don't think the addition of the ast2400
compatible string will fuss you. Please let me know if you feel this is
inappropriate.

 .../devicetree/bindings/mfd/aspeed-lpc.txt | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
index a97131aba446..514d82ced95b 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -109,3 +109,29 @@ lpc: lpc@1e789000 {
};
 };
 
+Host Node Children
+==
+
+LPC Host Controller
+---
+
+The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
+between the host and the baseboard management controller. The registers exist
+in the "host" portion of the Aspeed LPC controller, which must be the parent of
+the LPC host controller node.
+
+Required properties:
+
+- compatible:  One of:
+   "aspeed,ast2400-lhc";
+   "aspeed,ast2500-lhc";
+
+- reg: contains offset/length values of the LHC memory regions. In the
+   AST2400 and AST2500 there are two regions.
+
+Example:
+
+lhc: lhc@20 {
+   compatible = "aspeed,ast2500-lhc";
+   reg = <0x20 0x24 0x48 0x8>;
+};
-- 
2.9.3

[PATCH v4 1/5] mfd: dt: Fix "indicates" typo in mfd bindings document

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
Acked-by: Linus Walleij 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mfd/mfd.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt 
b/Documentation/devicetree/bindings/mfd/mfd.txt
index af9d6931a1a2..f1fceeda12f1 100644
--- a/Documentation/devicetree/bindings/mfd/mfd.txt
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -19,7 +19,7 @@ Optional properties:
 
 - compatible : "simple-mfd" - this signifies that the operating system should
   consider all subnodes of the MFD device as separate devices akin to how
-  "simple-bus" inidicates when to see subnodes as children for a simple
+  "simple-bus" indicates when to see subnodes as children for a simple
   memory-mapped bus. For more complex devices, when the nexus driver has to
   probe registers to figure out what child devices exist etc, this should not
   be used. In the latter case the child devices will be determined by the
-- 
2.9.3

[PATCH v4 2/5] mfd: dt: ranges, #address-cells and #size-cells as optional properties

[Andrew Jeffery]

Whilst describing a device and not a bus, simple-mfd is modelled on
simple-bus where child nodes are iterated and registered as platform
devices. Some complex devices, e.g. the Aspeed LPC controller, can
benefit from address space mapping such that child nodes can use the
regs property to describe their resource offsets within the
multi-function device.

Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mfd/mfd.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt 
b/Documentation/devicetree/bindings/mfd/mfd.txt
index f1fceeda12f1..bcb6abb9d413 100644
--- a/Documentation/devicetree/bindings/mfd/mfd.txt
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -25,6 +25,16 @@ Optional properties:
   be used. In the latter case the child devices will be determined by the
   operating system.
 
+- ranges: Describes the address mapping relationship to the parent. Should set
+  the child's base address to 0, the physical address within parent's address
+  space, and the length of the address map.
+
+- #address-cells: Specifies the number of cells used to represent physical base
+  addresses. Must be present if ranges is used.
+
+- #size-cells: Specifies the number of cells used to represent the size of an
+  address. Must be present if ranges is used.
+
 Example:
 
 foo@1000 {
-- 
2.9.3

[PATCH v4 3/5] mfd: dt: Add Aspeed Low Pin Count Controller bindings

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
Reviewed-by: Linus Walleij 
Reviewed-by: Joel Stanley 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/mfd/aspeed-lpc.txt | 111 +
 1 file changed, 111 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
new file mode 100644
index ..a97131aba446
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -0,0 +1,111 @@
+==
+Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller
+==
+
+The LPC bus is a means to bridge a host CPU to a number of low-bandwidth
+peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The
+primary use case of the Aspeed LPC controller is as a slave on the bus
+(typically in a Baseboard Management Controller SoC), but under certain
+conditions it can also take the role of bus master.
+
+The LPC controller is represented as a multi-function device to account for the
+mix of functionality it provides. The principle split is between the register
+layout at the start of the I/O space which is, to quote the Aspeed datasheet,
+"basically compatible with the [LPC registers from the] popular BMC controller
+H8S/2168[1]", and everything else, where everything else is an eclectic
+collection of functions with a esoteric register layout. "Everything else",
+here labeled the "host" portion of the controller, includes, but is not limited
+to:
+
+* An IPMI Block Transfer[2] Controller
+
+* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the
+  physical properties of some LPC pins, configuration of serial IRQs, and
+  APB-to-LPC bridging amonst other functions.
+
+* An LPC Host Interface Controller: Manages functions exposed to the host such
+  as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
+  management and bus snoop configuration.
+
+* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom
+  hardware management protocols for handover between the host and baseboard
+  management controller.
+
+Additionally the state of the LPC controller influences the pinmux
+configuration, therefore the host portion of the controller is exposed as a
+syscon as a means to arbitrate access.
+
+[0] http://www.intel.com/design/chipsets/industry/25128901.pdf
+[1] 
https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4
+[2] 
http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf
+[3] https://en.wikipedia.org/wiki/Super_I/O
+
+Required properties
+===
+
+- compatible:  One of:
+   "aspeed,ast2400-lpc", "simple-mfd"
+   "aspeed,ast2500-lpc", "simple-mfd"
+
+- reg: contains the physical address and length values of the Aspeed
+LPC memory region.
+
+- #address-cells: <1>
+- #size-cells: <1>
+- ranges:  Maps 0 to the physical address and length of the LPC memory
+region
+
+Required LPC Child nodes
+
+
+BMC Node
+
+
+- compatible:  One of:
+   "aspeed,ast2400-lpc-bmc"
+   "aspeed,ast2500-lpc-bmc"
+
+- reg: contains the physical address and length values of the
+H8S/2168-compatible LPC controller memory region
+
+Host Node
+-
+
+- compatible:   One of:
+   "aspeed,ast2400-lpc-host", "simple-mfd", "syscon"
+   "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"
+
+- reg: contains the address and length values of the host-related
+register space for the Aspeed LPC controller
+
+- #address-cells: <1>
+- #size-cells: <1>
+- ranges:  Maps 0 to the address and length of the host-related LPC memory
+region
+
+Example:
+
+lpc: lpc@1e789000 {
+   compatible = "aspeed,ast2500-lpc", "simple-mfd";
+   reg = <0x1e789000 0x1000>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x1e789000 0x1000>;
+
+   lpc_bmc: lpc-bmc@0 {
+   compatible = "aspeed,ast2500-lpc-bmc";
+   reg = <0x0 0x80>;
+   };
+
+   lpc_host: lpc-host@80 {
+   compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";
+   reg = <0x80 0x1e0>;
+   reg-io-width = <4>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x80 0x1e0>;
+   };
+};
+
-- 
2.9.3

[PATCH v4 1/5] mfd: dt: Fix "indicates" typo in mfd bindings document

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
Acked-by: Linus Walleij 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mfd/mfd.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt 
b/Documentation/devicetree/bindings/mfd/mfd.txt
index af9d6931a1a2..f1fceeda12f1 100644
--- a/Documentation/devicetree/bindings/mfd/mfd.txt
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -19,7 +19,7 @@ Optional properties:
 
 - compatible : "simple-mfd" - this signifies that the operating system should
   consider all subnodes of the MFD device as separate devices akin to how
-  "simple-bus" inidicates when to see subnodes as children for a simple
+  "simple-bus" indicates when to see subnodes as children for a simple
   memory-mapped bus. For more complex devices, when the nexus driver has to
   probe registers to figure out what child devices exist etc, this should not
   be used. In the latter case the child devices will be determined by the
-- 
2.9.3

[PATCH v4 2/5] mfd: dt: ranges, #address-cells and #size-cells as optional properties

[Andrew Jeffery]

Whilst describing a device and not a bus, simple-mfd is modelled on
simple-bus where child nodes are iterated and registered as platform
devices. Some complex devices, e.g. the Aspeed LPC controller, can
benefit from address space mapping such that child nodes can use the
regs property to describe their resource offsets within the
multi-function device.

Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mfd/mfd.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt 
b/Documentation/devicetree/bindings/mfd/mfd.txt
index f1fceeda12f1..bcb6abb9d413 100644
--- a/Documentation/devicetree/bindings/mfd/mfd.txt
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -25,6 +25,16 @@ Optional properties:
   be used. In the latter case the child devices will be determined by the
   operating system.
 
+- ranges: Describes the address mapping relationship to the parent. Should set
+  the child's base address to 0, the physical address within parent's address
+  space, and the length of the address map.
+
+- #address-cells: Specifies the number of cells used to represent physical base
+  addresses. Must be present if ranges is used.
+
+- #size-cells: Specifies the number of cells used to represent the size of an
+  address. Must be present if ranges is used.
+
 Example:
 
 foo@1000 {
-- 
2.9.3

[PATCH v4 3/5] mfd: dt: Add Aspeed Low Pin Count Controller bindings

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
Reviewed-by: Linus Walleij 
Reviewed-by: Joel Stanley 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/mfd/aspeed-lpc.txt | 111 +
 1 file changed, 111 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
new file mode 100644
index ..a97131aba446
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -0,0 +1,111 @@
+==
+Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller
+==
+
+The LPC bus is a means to bridge a host CPU to a number of low-bandwidth
+peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The
+primary use case of the Aspeed LPC controller is as a slave on the bus
+(typically in a Baseboard Management Controller SoC), but under certain
+conditions it can also take the role of bus master.
+
+The LPC controller is represented as a multi-function device to account for the
+mix of functionality it provides. The principle split is between the register
+layout at the start of the I/O space which is, to quote the Aspeed datasheet,
+"basically compatible with the [LPC registers from the] popular BMC controller
+H8S/2168[1]", and everything else, where everything else is an eclectic
+collection of functions with a esoteric register layout. "Everything else",
+here labeled the "host" portion of the controller, includes, but is not limited
+to:
+
+* An IPMI Block Transfer[2] Controller
+
+* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the
+  physical properties of some LPC pins, configuration of serial IRQs, and
+  APB-to-LPC bridging amonst other functions.
+
+* An LPC Host Interface Controller: Manages functions exposed to the host such
+  as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
+  management and bus snoop configuration.
+
+* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom
+  hardware management protocols for handover between the host and baseboard
+  management controller.
+
+Additionally the state of the LPC controller influences the pinmux
+configuration, therefore the host portion of the controller is exposed as a
+syscon as a means to arbitrate access.
+
+[0] http://www.intel.com/design/chipsets/industry/25128901.pdf
+[1] 
https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4
+[2] 
http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf
+[3] https://en.wikipedia.org/wiki/Super_I/O
+
+Required properties
+===
+
+- compatible:  One of:
+   "aspeed,ast2400-lpc", "simple-mfd"
+   "aspeed,ast2500-lpc", "simple-mfd"
+
+- reg: contains the physical address and length values of the Aspeed
+LPC memory region.
+
+- #address-cells: <1>
+- #size-cells: <1>
+- ranges:  Maps 0 to the physical address and length of the LPC memory
+region
+
+Required LPC Child nodes
+
+
+BMC Node
+
+
+- compatible:  One of:
+   "aspeed,ast2400-lpc-bmc"
+   "aspeed,ast2500-lpc-bmc"
+
+- reg: contains the physical address and length values of the
+H8S/2168-compatible LPC controller memory region
+
+Host Node
+-
+
+- compatible:   One of:
+   "aspeed,ast2400-lpc-host", "simple-mfd", "syscon"
+   "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"
+
+- reg: contains the address and length values of the host-related
+register space for the Aspeed LPC controller
+
+- #address-cells: <1>
+- #size-cells: <1>
+- ranges:  Maps 0 to the address and length of the host-related LPC memory
+region
+
+Example:
+
+lpc: lpc@1e789000 {
+   compatible = "aspeed,ast2500-lpc", "simple-mfd";
+   reg = <0x1e789000 0x1000>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x1e789000 0x1000>;
+
+   lpc_bmc: lpc-bmc@0 {
+   compatible = "aspeed,ast2500-lpc-bmc";
+   reg = <0x0 0x80>;
+   };
+
+   lpc_host: lpc-host@80 {
+   compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";
+   reg = <0x80 0x1e0>;
+   reg-io-width = <4>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x80 0x1e0>;
+   };
+};
+
-- 
2.9.3

[PATCH v4 0/5] mfd: dt: Add bindings for the Aspeed MFDs

[Andrew Jeffery]

Hi Lee,

Here's v4 of the Aspeed LPC MFD devicetree bindings series. v3 can be found at:

  https://lkml.org/lkml/2016/12/5/835

Changes since v3:

* Based on Arnd's argument[1], drop the addition of the mfd/syscon bindings
  directory as well as the the last patch in v3, which moved a number of
  existing bindings. Eventually the Aspeed display controller will have a
  device-specific driver so it doesn't belong there either.

* Add a compatible string for the AST2400 in the LPC Host Controller bindings
  as requested by Joel and slightly tweak the reg description for Rob.

[1] https://lkml.org/lkml/2016/12/13/202

Andrew Jeffery (5):
  mfd: dt: Fix "indicates" typo in mfd bindings document
  mfd: dt: ranges, #address-cells and #size-cells as optional properties
  mfd: dt: Add Aspeed Low Pin Count Controller bindings
  mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
  mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)

 .../devicetree/bindings/mfd/aspeed-gfx.txt |  17 +++
 .../devicetree/bindings/mfd/aspeed-lpc.txt | 137 +
 Documentation/devicetree/bindings/mfd/mfd.txt  |  12 +-
 3 files changed, 165 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt

-- 
2.9.3

[PATCH v4 0/5] mfd: dt: Add bindings for the Aspeed MFDs

[Andrew Jeffery]

Hi Lee,

Here's v4 of the Aspeed LPC MFD devicetree bindings series. v3 can be found at:

  https://lkml.org/lkml/2016/12/5/835

Changes since v3:

* Based on Arnd's argument[1], drop the addition of the mfd/syscon bindings
  directory as well as the the last patch in v3, which moved a number of
  existing bindings. Eventually the Aspeed display controller will have a
  device-specific driver so it doesn't belong there either.

* Add a compatible string for the AST2400 in the LPC Host Controller bindings
  as requested by Joel and slightly tweak the reg description for Rob.

[1] https://lkml.org/lkml/2016/12/13/202

Andrew Jeffery (5):
  mfd: dt: Fix "indicates" typo in mfd bindings document
  mfd: dt: ranges, #address-cells and #size-cells as optional properties
  mfd: dt: Add Aspeed Low Pin Count Controller bindings
  mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
  mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)

 .../devicetree/bindings/mfd/aspeed-gfx.txt |  17 +++
 .../devicetree/bindings/mfd/aspeed-lpc.txt | 137 +
 Documentation/devicetree/bindings/mfd/mfd.txt  |  12 +-
 3 files changed, 165 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt

-- 
2.9.3

Re: [PATCH] staging: lustre: ldlm: use designated initializers

[Dan Carpenter]

On Mon, Dec 19, 2016 at 08:47:50AM -0800, Bruce Korb wrote:
> On Mon, Dec 19, 2016 at 8:22 AM, James Simmons
> >> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> >> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> >> @@ -143,7 +143,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock 
> >> *req, __u64 *flags,
> >>   int added = (mode == LCK_NL);
> >>   int overlaps = 0;
> >>   int splitted = 0;
> >> - const struct ldlm_callback_suite null_cbs = { NULL };
> >> + const struct ldlm_callback_suite null_cbs = { };
> >>
> >>   CDEBUG(D_DLMTRACE,
> >>  "flags %#llx owner %llu pid %u mode %u start %llu end %llu\n",
> >
> > Nak. Filling null_cbs with random data is a bad idea. If you look at
> > ldlm_lock_create() where this is used you have
> >
> > if (cbs) {
> > lock->l_blocking_ast = cbs->lcs_blocking;
> > lock->l_completion_ast = cbs->lcs_completion;
> > lock->l_glimpse_ast = cbs->lcs_glimpse;
> > }
> >
> > Having lock->l_* point to random addresses is a bad idea.
> > What really needs to be done is proper initialization of that
> > structure. A bunch of patches will be coming to address this.
> 
> I'm not understanding the effect of the original difference.  If you
> specify any initializer, then all fields not specified are filled with
> zero bits. Any pointers are, perforce, NULL.  That should make both "{
> NULL }" and "{}" equivalent.

They are equivalent, yes, but people want to use a GCC plugin that
randomizes struct layouts for internal structures and the plugin doesn't
work when you use struct ordering to initialize the struct.  The plugin
requires that you use designated intializers.

regards,
dan carpenter

Re: [PATCH] staging: lustre: ldlm: use designated initializers

[Dan Carpenter]

On Mon, Dec 19, 2016 at 08:47:50AM -0800, Bruce Korb wrote:
> On Mon, Dec 19, 2016 at 8:22 AM, James Simmons
> >> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> >> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> >> @@ -143,7 +143,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock 
> >> *req, __u64 *flags,
> >>   int added = (mode == LCK_NL);
> >>   int overlaps = 0;
> >>   int splitted = 0;
> >> - const struct ldlm_callback_suite null_cbs = { NULL };
> >> + const struct ldlm_callback_suite null_cbs = { };
> >>
> >>   CDEBUG(D_DLMTRACE,
> >>  "flags %#llx owner %llu pid %u mode %u start %llu end %llu\n",
> >
> > Nak. Filling null_cbs with random data is a bad idea. If you look at
> > ldlm_lock_create() where this is used you have
> >
> > if (cbs) {
> > lock->l_blocking_ast = cbs->lcs_blocking;
> > lock->l_completion_ast = cbs->lcs_completion;
> > lock->l_glimpse_ast = cbs->lcs_glimpse;
> > }
> >
> > Having lock->l_* point to random addresses is a bad idea.
> > What really needs to be done is proper initialization of that
> > structure. A bunch of patches will be coming to address this.
> 
> I'm not understanding the effect of the original difference.  If you
> specify any initializer, then all fields not specified are filled with
> zero bits. Any pointers are, perforce, NULL.  That should make both "{
> NULL }" and "{}" equivalent.

They are equivalent, yes, but people want to use a GCC plugin that
randomizes struct layouts for internal structures and the plugin doesn't
work when you use struct ordering to initialize the struct.  The plugin
requires that you use designated intializers.

regards,
dan carpenter

Re: [tip:x86/urgent] x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6

[H. Peter Anvin]

On 12/19/16 02:56, tip-bot for Andy Lutomirski wrote:
> Commit-ID:  3df8d9208569ef0b2313e516566222d745f3b94b
> Gitweb: http://git.kernel.org/tip/3df8d9208569ef0b2313e516566222d745f3b94b
> Author: Andy Lutomirski 
> AuthorDate: Thu, 15 Dec 2016 10:14:42 -0800
> Committer:  Thomas Gleixner 
> CommitDate: Mon, 19 Dec 2016 11:50:24 +0100
> 
> x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6
> 
> A typo (or mis-merge?) resulted in leaf 6 only being probed if
> cpuid_level >= 7.
> 
> Fixes: 2ccd71f1b278 ("x86/cpufeature: Move some of the scattered feature bits 
> to x86_capability")
> Signed-off-by: Andy Lutomirski 
> Acked-by: Borislav Petkov 
> Cc: Brian Gerst 
> Link: 
> http://lkml.kernel.org/r/6ea30c0e9daec21e488b54761881a6dfcf3e04d0.1481825597.git.l...@kernel.org
> Signed-off-by: Thomas Gleixner 
> 
> ---
>  arch/x86/kernel/cpu/common.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 1f6b50a..dc1697c 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -667,13 +667,14 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
>   c->x86_capability[CPUID_1_EDX] = edx;
>   }
>  
> + /* Thermal and Power Management Leaf: level 0x0006 (eax) */
> + if (c->cpuid_level >= 0x0006)
> + c->x86_capability[CPUID_6_EAX] = cpuid_eax(0x0006);
> +
>   /* Additional Intel-defined flags: level 0x0007 */
>   if (c->cpuid_level >= 0x0007) {
>   cpuid_count(0x0007, 0, , , , );
> -
>   c->x86_capability[CPUID_7_0_EBX] = ebx;
> -
> - c->x86_capability[CPUID_6_EAX] = cpuid_eax(0x0006);
>   c->x86_capability[CPUID_7_ECX] = ecx;
>   }

Perhaps we should have something like:

void cpuid_cond(u32 leaf, u32 subleaf,
u32 *eax, u32 *ebx, u32 *ecx, u32 *edx)
{
const struct cpuinfo_x86 *c = this_cpu_ptr(_info);
u32 maxleaf;
int cpuid_level = c->cpuid_level;

switch (leaf >> 16) {
case 0x:
maxleaf = c->cpuid_level;
break;
case 0x8000:
maxleaf = c->extended_cpuid_level;
break;
case 0x4000 .. 0x40ff:
/* Not ideal, can we do better? */
maxleaf = cpu_has(X86_FEATURE_HYPERVISOR)
  ? 0x40ff : 0;
break;
/* Add Transmeta 0x8086 and VIA/Cyrix 0xc000? */
default:
/* Can we do better? */
if (c->x86_vendor_id) == X86_VENDOR_INTEL)
maxleaf = 0;
else
maxleaf = leaf | 0x;
break;
}

if (cpuid_level >= 0 && leaf >= maxleaf) {
cpuid_count(leaf, subleaf, eax, ebx, ecx, edx);
} else {
*eax = *ebx = *ecx = *edx = 0;
}
}

-hpa

P.S. I would love to (a) move the CPUID bits into a structure instead of
passing all those crazy pointers around, and (b) stop passing struct
cpuinfo * around when we only use it for the current processor anyway (a
lot of these functions are in fact completely invalid if we don't); we
could define this_cpu_info as (*this_cpu_ptr(_info)) -- basically
what I have above -- or directly use percpu functions to access these
variables.

Re: [tip:x86/urgent] x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6

[H. Peter Anvin]

On 12/19/16 02:56, tip-bot for Andy Lutomirski wrote:
> Commit-ID:  3df8d9208569ef0b2313e516566222d745f3b94b
> Gitweb: http://git.kernel.org/tip/3df8d9208569ef0b2313e516566222d745f3b94b
> Author: Andy Lutomirski 
> AuthorDate: Thu, 15 Dec 2016 10:14:42 -0800
> Committer:  Thomas Gleixner 
> CommitDate: Mon, 19 Dec 2016 11:50:24 +0100
> 
> x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6
> 
> A typo (or mis-merge?) resulted in leaf 6 only being probed if
> cpuid_level >= 7.
> 
> Fixes: 2ccd71f1b278 ("x86/cpufeature: Move some of the scattered feature bits 
> to x86_capability")
> Signed-off-by: Andy Lutomirski 
> Acked-by: Borislav Petkov 
> Cc: Brian Gerst 
> Link: 
> http://lkml.kernel.org/r/6ea30c0e9daec21e488b54761881a6dfcf3e04d0.1481825597.git.l...@kernel.org
> Signed-off-by: Thomas Gleixner 
> 
> ---
>  arch/x86/kernel/cpu/common.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 1f6b50a..dc1697c 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -667,13 +667,14 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
>   c->x86_capability[CPUID_1_EDX] = edx;
>   }
>  
> + /* Thermal and Power Management Leaf: level 0x0006 (eax) */
> + if (c->cpuid_level >= 0x0006)
> + c->x86_capability[CPUID_6_EAX] = cpuid_eax(0x0006);
> +
>   /* Additional Intel-defined flags: level 0x0007 */
>   if (c->cpuid_level >= 0x0007) {
>   cpuid_count(0x0007, 0, , , , );
> -
>   c->x86_capability[CPUID_7_0_EBX] = ebx;
> -
> - c->x86_capability[CPUID_6_EAX] = cpuid_eax(0x0006);
>   c->x86_capability[CPUID_7_ECX] = ecx;
>   }

Perhaps we should have something like:

void cpuid_cond(u32 leaf, u32 subleaf,
u32 *eax, u32 *ebx, u32 *ecx, u32 *edx)
{
const struct cpuinfo_x86 *c = this_cpu_ptr(_info);
u32 maxleaf;
int cpuid_level = c->cpuid_level;

switch (leaf >> 16) {
case 0x:
maxleaf = c->cpuid_level;
break;
case 0x8000:
maxleaf = c->extended_cpuid_level;
break;
case 0x4000 .. 0x40ff:
/* Not ideal, can we do better? */
maxleaf = cpu_has(X86_FEATURE_HYPERVISOR)
  ? 0x40ff : 0;
break;
/* Add Transmeta 0x8086 and VIA/Cyrix 0xc000? */
default:
/* Can we do better? */
if (c->x86_vendor_id) == X86_VENDOR_INTEL)
maxleaf = 0;
else
maxleaf = leaf | 0x;
break;
}

if (cpuid_level >= 0 && leaf >= maxleaf) {
cpuid_count(leaf, subleaf, eax, ebx, ecx, edx);
} else {
*eax = *ebx = *ecx = *edx = 0;
}
}

-hpa

P.S. I would love to (a) move the CPUID bits into a structure instead of
passing all those crazy pointers around, and (b) stop passing struct
cpuinfo * around when we only use it for the current processor anyway (a
lot of these functions are in fact completely invalid if we don't); we
could define this_cpu_info as (*this_cpu_ptr(_info)) -- basically
what I have above -- or directly use percpu functions to access these
variables.

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi Neil,

On 3 November 2016 at 09:25, NeilBrown  wrote:
> On Tue, Nov 01 2016, Baolin Wang wrote:
>
>
>>> So I won't be responding on this topic any further until I see a genuine
>>> attempt to understand and resolve the inconsistencies with
>>> usb_register_notifier().
>>
>> Any better solution?
>
> I'm not sure exactly what you are asking, so I'll assume you are asking
> the question I want to answer :-)
>
> 1/ Liase with the extcon developers to resolve the inconsistencies
>   with USB connector types.
>   e.g. current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP"
>   which both seem to suggest a standard downstream port.  There is no
>   documentation describing how these relate, and no consistent practice
>   to copy.
>   I suspect the intention is that
> EXTCON_USB and EXTCON_USB_HOST indicated that data capabilities of
> the cable, while EXTCON_CHG_USB* indicate the power capabilities of
> the cable.
> So EXTCON_CHG_USB_SDP should always appear together with EXTCON_USB
> while EXTCON_CHG_USB_DCP would not, and EXTCON_CHG_USB_ACA
> would normally appear with EXTCON_USB_HOST (I think).
>   Some drivers follow this model, particularly extcon-max14577.c
>   but it is not consistent.
>
>   This policy should be well documented and possibly existing drivers
>   should be updated to follow it.
>
>   At the same time it would make sense to resolve EXTCON_CHG_USB_SLOW
>   and EXTCON_CHG_USB_FAST.  These names don't mean much.
>   They were recently removed from drivers/power/axp288_charger.c
>   which is good, but are still used in drivers/extcon/extcon-max*
>   Possibly they should be changed to names from the standard, or
>   possibly they should be renamed to identify the current they are
>   expected to provide. e.g. EXTCON_CHG_USB_500MA and EXTCON_CHG_USB_1A

Now I am creating the new patchset with fixing and converting exist drivers.

I did some investigation about EXTCON subsystem. From your suggestion:
1. EXTCON_CHG_USB_SDP should always appear together with EXTCON_USB.
 After checking, now all extcon drivers were following this rule.

2. EXTCON_CHG_USB_ACA would normally appear with EXTCON_USB_HOST.
 Now no extcon drivers used EXTCON_CHG_USB_ACA, then no need to change.

3. Change EXTCON_CHG_USB_SLOW/FAST to EXTCON_CHG_USB_500MA/1A.
 There are no model that shows the slow charger should be 500mA
and fast charger is 1A. (In extcon-max77693.c file, the fast charger
can be drawn 2A), so changing to EXTCON_CHG_USB_500MA/1A is not useful
I think.

>From above investigation, I did not find anything need to be changed
now. What do you think? Thanks.

>
> 2/ Change all usb phys to register an extcon and to send appropriate
>notifications.  Many already do, but I don't think it is universal.
>It is probable that the extcon should be registered using common code
>instead of each phy driver having its own
>extcon_get_edev_by_phandle()
>or whatever.
>If the usb phy driver needs to look at battery charger registers to
>know what sort of cable was connected (which I believe is the case
>for the chips you are interested in), then it should do that.
>
> 3/ Currently some USB controllers discover that a cable was connected by
>listening on an extcon, and some by registering for a usb_notifier
>(described below) ... though there seem to only be 2 left which do that.
>Now that all USB phys send connection information via extcon (see 2),
>the USB controllers should be changed to all find out about the cable
>using extcon.
>
> 4/ struct usb_phy contains:
> /* for notification of usb_phy_events */
> struct atomic_notifier_head notifier;
>
>   This is used inconsistently.  Sometimes the argument passed
>   is NULL, sometimes it is a pointer to 'vbus_draw' - the current
>   limited negotiated via USB, sometimes it is a pointer the the gadget
>   though as far as I can tell, that last one is never used.
>
>   This should be changed to be consistent.  This notifier is no longer
>   needed to tell the USB controller that a cable was connected (extcon
>   now does that, see 3) so it is only used to communicate the
>   'vbus_draw' information.
>   So it should be changed to *only* send a notification when vbus_draw
>   is known, and it should carry that information.
>   This should probably be done in common code, and removed
>   from individual drivers.
>
> 5/ Now that all cable connection notifications are sent over extcon and
>all vbus_draw notifications are sent over the usb_phy notifier, write
>some support code that a power supply client can use to be told what
>power is available.
>e.g. a battery charger driver would call:
>register_power_client(.)
>or similar, providing a phandle (or similar) for the usb phy and a
>function to call back when the available current changes (or maybe a
>work_struct containing the function pointer)
>
>

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi Neil,

On 3 November 2016 at 09:25, NeilBrown  wrote:
> On Tue, Nov 01 2016, Baolin Wang wrote:
>
>
>>> So I won't be responding on this topic any further until I see a genuine
>>> attempt to understand and resolve the inconsistencies with
>>> usb_register_notifier().
>>
>> Any better solution?
>
> I'm not sure exactly what you are asking, so I'll assume you are asking
> the question I want to answer :-)
>
> 1/ Liase with the extcon developers to resolve the inconsistencies
>   with USB connector types.
>   e.g. current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP"
>   which both seem to suggest a standard downstream port.  There is no
>   documentation describing how these relate, and no consistent practice
>   to copy.
>   I suspect the intention is that
> EXTCON_USB and EXTCON_USB_HOST indicated that data capabilities of
> the cable, while EXTCON_CHG_USB* indicate the power capabilities of
> the cable.
> So EXTCON_CHG_USB_SDP should always appear together with EXTCON_USB
> while EXTCON_CHG_USB_DCP would not, and EXTCON_CHG_USB_ACA
> would normally appear with EXTCON_USB_HOST (I think).
>   Some drivers follow this model, particularly extcon-max14577.c
>   but it is not consistent.
>
>   This policy should be well documented and possibly existing drivers
>   should be updated to follow it.
>
>   At the same time it would make sense to resolve EXTCON_CHG_USB_SLOW
>   and EXTCON_CHG_USB_FAST.  These names don't mean much.
>   They were recently removed from drivers/power/axp288_charger.c
>   which is good, but are still used in drivers/extcon/extcon-max*
>   Possibly they should be changed to names from the standard, or
>   possibly they should be renamed to identify the current they are
>   expected to provide. e.g. EXTCON_CHG_USB_500MA and EXTCON_CHG_USB_1A

Now I am creating the new patchset with fixing and converting exist drivers.

I did some investigation about EXTCON subsystem. From your suggestion:
1. EXTCON_CHG_USB_SDP should always appear together with EXTCON_USB.
 After checking, now all extcon drivers were following this rule.

2. EXTCON_CHG_USB_ACA would normally appear with EXTCON_USB_HOST.
 Now no extcon drivers used EXTCON_CHG_USB_ACA, then no need to change.

3. Change EXTCON_CHG_USB_SLOW/FAST to EXTCON_CHG_USB_500MA/1A.
 There are no model that shows the slow charger should be 500mA
and fast charger is 1A. (In extcon-max77693.c file, the fast charger
can be drawn 2A), so changing to EXTCON_CHG_USB_500MA/1A is not useful
I think.

>From above investigation, I did not find anything need to be changed
now. What do you think? Thanks.

>
> 2/ Change all usb phys to register an extcon and to send appropriate
>notifications.  Many already do, but I don't think it is universal.
>It is probable that the extcon should be registered using common code
>instead of each phy driver having its own
>extcon_get_edev_by_phandle()
>or whatever.
>If the usb phy driver needs to look at battery charger registers to
>know what sort of cable was connected (which I believe is the case
>for the chips you are interested in), then it should do that.
>
> 3/ Currently some USB controllers discover that a cable was connected by
>listening on an extcon, and some by registering for a usb_notifier
>(described below) ... though there seem to only be 2 left which do that.
>Now that all USB phys send connection information via extcon (see 2),
>the USB controllers should be changed to all find out about the cable
>using extcon.
>
> 4/ struct usb_phy contains:
> /* for notification of usb_phy_events */
> struct atomic_notifier_head notifier;
>
>   This is used inconsistently.  Sometimes the argument passed
>   is NULL, sometimes it is a pointer to 'vbus_draw' - the current
>   limited negotiated via USB, sometimes it is a pointer the the gadget
>   though as far as I can tell, that last one is never used.
>
>   This should be changed to be consistent.  This notifier is no longer
>   needed to tell the USB controller that a cable was connected (extcon
>   now does that, see 3) so it is only used to communicate the
>   'vbus_draw' information.
>   So it should be changed to *only* send a notification when vbus_draw
>   is known, and it should carry that information.
>   This should probably be done in common code, and removed
>   from individual drivers.
>
> 5/ Now that all cable connection notifications are sent over extcon and
>all vbus_draw notifications are sent over the usb_phy notifier, write
>some support code that a power supply client can use to be told what
>power is available.
>e.g. a battery charger driver would call:
>register_power_client(.)
>or similar, providing a phandle (or similar) for the usb phy and a
>function to call back when the available current changes (or maybe a
>work_struct containing the function pointer)
>
>register_power_client() would 

Klientskie bazy dannih! Uznaite podrobnee! Skype: prodawez390 Email: prodawez...@gmail.com tel +79139230330 (whatsapp\viber\telegram) Soberem dlja Vas po internet bazu dannyh potencial'nyh klientov d

[linux-kernel@vger.kernel.org]

Klientskie bazy dannih!!! Uznaite podrobnee po Skype: prodawez390 Email: 
prodawez...@gmail.com  tel +79139230330 (whatsapp\viber\telegram) Soberem dlja 
Vas po internet bazu dannyh potencial'nyh klientov dlja Vashego Biznesa Mnogo! 
Bystro! Nedorogo! Uznajte podrobnee na kartinke https://is.gd/HP0cCY

Klientskie bazy dannih! Uznaite podrobnee! Skype: prodawez390 Email: prodawez...@gmail.com tel +79139230330 (whatsapp\viber\telegram) Soberem dlja Vas po internet bazu dannyh potencial'nyh klientov d

[linux-kernel@vger.kernel.org]

Klientskie bazy dannih!!! Uznaite podrobnee po Skype: prodawez390 Email: 
prodawez...@gmail.com  tel +79139230330 (whatsapp\viber\telegram) Soberem dlja 
Vas po internet bazu dannyh potencial'nyh klientov dlja Vashego Biznesa Mnogo! 
Bystro! Nedorogo! Uznajte podrobnee na kartinke https://is.gd/HP0cCY

Re: [PATCH] drm/mediatek: Support UYVY and YUYV format for overlay

[YT Shen]

Hi Bibby,

On Wed, 2016-12-14 at 13:14 +0800, Bibby Hsieh wrote:
> MT8173 overlay can support UYVY and YUYV format,
> we add the format in DRM driver.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 6 ++
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 019b7ca..0a340f3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -44,6 +44,8 @@
>  #define OVL_CON_CLRFMT_RGB888(1 << 12)
>  #define OVL_CON_CLRFMT_RGBA  (2 << 12)
>  #define OVL_CON_CLRFMT_ARGB  (3 << 12)
> +#define OVL_CON_CLRFMT_UYVY  (4 << 12)
> +#define OVL_CON_CLRFMT_YUYV  (5 << 12)
>  #define  OVL_CON_AEN BIT(8)
>  #define  OVL_CON_ALPHA   0xff
>  
> @@ -161,6 +163,10 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
>   case DRM_FORMAT_XBGR:
>   case DRM_FORMAT_ABGR:
>   return OVL_CON_CLRFMT_RGBA | OVL_CON_BYTE_SWAP;
> + case DRM_FORMAT_YUYV:
> + return OVL_CON_CLRFMT_YUYV;
> + case DRM_FORMAT_UYVY:
> + return OVL_CON_CLRFMT_UYVY;
>   }
>  }
Your patch looks good, but I am not sure about some details.
AFAIK, there is a color matrix here to describe how to transform from
BT.601 / BT.709 / other color space to RGB color space.  You can use the
default value if you don't care how colors are represented.  Or you can
specify the matrix in this patch.

Regards,
yt.shen

>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c461a23..b94c6ee 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -28,6 +28,8 @@
>   DRM_FORMAT_XRGB,
>   DRM_FORMAT_ARGB,
>   DRM_FORMAT_RGB565,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_UYVY,
>  };
>  
>  static void mtk_plane_reset(struct drm_plane *plane)

Re: [PATCH] drm/mediatek: Support UYVY and YUYV format for overlay

[YT Shen]

Hi Bibby,

On Wed, 2016-12-14 at 13:14 +0800, Bibby Hsieh wrote:
> MT8173 overlay can support UYVY and YUYV format,
> we add the format in DRM driver.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 6 ++
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 019b7ca..0a340f3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -44,6 +44,8 @@
>  #define OVL_CON_CLRFMT_RGB888(1 << 12)
>  #define OVL_CON_CLRFMT_RGBA  (2 << 12)
>  #define OVL_CON_CLRFMT_ARGB  (3 << 12)
> +#define OVL_CON_CLRFMT_UYVY  (4 << 12)
> +#define OVL_CON_CLRFMT_YUYV  (5 << 12)
>  #define  OVL_CON_AEN BIT(8)
>  #define  OVL_CON_ALPHA   0xff
>  
> @@ -161,6 +163,10 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
>   case DRM_FORMAT_XBGR:
>   case DRM_FORMAT_ABGR:
>   return OVL_CON_CLRFMT_RGBA | OVL_CON_BYTE_SWAP;
> + case DRM_FORMAT_YUYV:
> + return OVL_CON_CLRFMT_YUYV;
> + case DRM_FORMAT_UYVY:
> + return OVL_CON_CLRFMT_UYVY;
>   }
>  }
Your patch looks good, but I am not sure about some details.
AFAIK, there is a color matrix here to describe how to transform from
BT.601 / BT.709 / other color space to RGB color space.  You can use the
default value if you don't care how colors are represented.  Or you can
specify the matrix in this patch.

Regards,
yt.shen

>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c461a23..b94c6ee 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -28,6 +28,8 @@
>   DRM_FORMAT_XRGB,
>   DRM_FORMAT_ARGB,
>   DRM_FORMAT_RGB565,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_UYVY,
>  };
>  
>  static void mtk_plane_reset(struct drm_plane *plane)

Re: [PATCH v3 2/5] lib: Add Sed-opal library

[Al Viro]

On Mon, Dec 19, 2016 at 12:35:46PM -0700, Scott Bauer wrote:

> +int fdev_sed_ioctl(struct file *filep, unsigned int cmd,
> +unsigned long arg)
> +{
> + struct sed_key key;
> + struct sed_context *sed_ctx;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + if (!filep->f_sedctx || !filep->f_sedctx->ops || !filep->f_sedctx->dev)
> + return -ENODEV;
> +
> + sed_ctx = filep->f_sedctx;

First of all, that's a bisect hazard.  What's more, looking through the
rest of patchset, WTF does it
* need to be called that early in ioctl(2) handling, instead of
having ->ioctl() instance for that sucker calling it?
* _not_ get your ->f_sedctx as an explicit argument, passed by
the caller in ->ioctl(), seeing that it's possible to calculate by
file->private_data?
* store that thing in struct file itself, bloating it for everything
all for the sake of few drivers that might want to use that helper?

Re: [PATCH v3 2/5] lib: Add Sed-opal library

[Al Viro]

On Mon, Dec 19, 2016 at 12:35:46PM -0700, Scott Bauer wrote:

> +int fdev_sed_ioctl(struct file *filep, unsigned int cmd,
> +unsigned long arg)
> +{
> + struct sed_key key;
> + struct sed_context *sed_ctx;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + if (!filep->f_sedctx || !filep->f_sedctx->ops || !filep->f_sedctx->dev)
> + return -ENODEV;
> +
> + sed_ctx = filep->f_sedctx;

First of all, that's a bisect hazard.  What's more, looking through the
rest of patchset, WTF does it
* need to be called that early in ioctl(2) handling, instead of
having ->ioctl() instance for that sucker calling it?
* _not_ get your ->f_sedctx as an explicit argument, passed by
the caller in ->ioctl(), seeing that it's possible to calculate by
file->private_data?
* store that thing in struct file itself, bloating it for everything
all for the sake of few drivers that might want to use that helper?

[PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547

[Meng Yi]

pca9547 won't probed since its status property is disabled.
while there are devices connected to it, we need remove status
property to let ds3232 and adt7461 probed correctly.

Signed-off-by: Meng Yi 
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
index 265e0a8..2ff46ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
@@ -102,7 +102,6 @@
reg = <0x75>;
#address-cells = <1>;
#size-cells = <0>;
-   status = "disabled";
i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.1.0.27.g96db324

[PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547

[Meng Yi]

pca9547 won't probed since its status property is disabled.
while there are devices connected to it, we need remove status
property to let ds3232 and adt7461 probed correctly.

Signed-off-by: Meng Yi 
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
index 265e0a8..2ff46ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
@@ -102,7 +102,6 @@
reg = <0x75>;
#address-cells = <1>;
#size-cells = <0>;
-   status = "disabled";
i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.1.0.27.g96db324

Re: [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED Allocation code.

[Christoph Hellwig]

> +void nvme_unlock_from_suspend(struct nvme_ctrl *ctrl)
> +{
> + if (opal_unlock_from_suspend(>sed_ctx))
> + pr_warn("Failed to unlock one or more locking ranges!\n");
> +}
> +EXPORT_SYMBOL_GPL(nvme_unlock_from_suspend);

I don't think we even need this wrapper.  Also for the warning please
use dev_warn so that the user knows which controller failed.

> @@ -1765,7 +1766,7 @@ static void nvme_reset_work(struct work_struct *work)
>  {
>   struct nvme_dev *dev = container_of(work, struct nvme_dev, reset_work);
>   int result = -ENODEV;
> -
> + bool was_suspend = !!(dev->ctrl.ctrl_config & NVME_CC_SHN_NORMAL);
>   if (WARN_ON(dev->ctrl.state == NVME_CTRL_RESETTING))

Please don't remove the empty line after the variable declarations.
Also I would place your new line before the result line, as that makes
it a tad easier to read.

Re: [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED Allocation code.

[Christoph Hellwig]

> +void nvme_unlock_from_suspend(struct nvme_ctrl *ctrl)
> +{
> + if (opal_unlock_from_suspend(>sed_ctx))
> + pr_warn("Failed to unlock one or more locking ranges!\n");
> +}
> +EXPORT_SYMBOL_GPL(nvme_unlock_from_suspend);

I don't think we even need this wrapper.  Also for the warning please
use dev_warn so that the user knows which controller failed.

> @@ -1765,7 +1766,7 @@ static void nvme_reset_work(struct work_struct *work)
>  {
>   struct nvme_dev *dev = container_of(work, struct nvme_dev, reset_work);
>   int result = -ENODEV;
> -
> + bool was_suspend = !!(dev->ctrl.ctrl_config & NVME_CC_SHN_NORMAL);
>   if (WARN_ON(dev->ctrl.state == NVME_CTRL_RESETTING))

Please don't remove the empty line after the variable declarations.
Also I would place your new line before the result line, as that makes
it a tad easier to read.

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Baolin Wang]

On 20 December 2016 at 14:39, Lu Baolu  wrote:
> Hi,
>
> On 12/20/2016 02:06 PM, Baolin Wang wrote:
>> Hi,
>>
>> On 20 December 2016 at 12:29, Lu Baolu  wrote:
>>> Hi Mathias,
>>>
>>> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
 On 19.12.2016 13:34, Baolin Wang wrote:
> Hi Mathias,
>
> On 19 December 2016 at 18:33, Mathias Nyman
>  wrote:
>> On 13.12.2016 05:21, Baolin Wang wrote:
>>> Hi Mathias,
>>>
>>> On 12 December 2016 at 23:52, Mathias Nyman
>>>  wrote:
 On 05.12.2016 09:51, Baolin Wang wrote:
>
> If a command event is found on the event ring during an interrupt,
> we need to stop the command timer with del_timer(). Since del_timer()
> can fail if the timer is running and waiting on the xHCI lock, then
> it maybe get the wrong timeout command in 
> xhci_handle_command_timeout()
> if host fetched a new command and updated the xhci->current_cmd in
> handle_cmd_completion(). For this situation, we need a way to signal
> to the command timer that everything is fine and it should exit.


 Ah, right, this could actually happen.

>
> We should introduce a counter (xhci->current_cmd_pending) for the 
> number
> of pending commands. If we need to cancel the command timer and
> del_timer()
> succeeds, we decrement the number of pending commands. If del_timer()
> fails,
> we leave the number of pending commands alone.
>
> For handling timeout command, in xhci_handle_command_timeout() we will
> check
> the counter after decrementing it, if the counter
> (xhci->current_cmd_pending)
> is 0, which means xhci->current_cmd is the right timeout command. If 
> the
> counter (xhci->current_cmd_pending) is greater than 0, which means
> current
> timeout command has been handled by host and host has fetched new
> command
> as
> xhci->current_cmd, then just return and wait for new current command.


 A counter like this could work.

 Writing the abort bit can generate either ABORT+STOP, or just STOP
 event, this seems to cover both.

 quick check, case 1: timeout and cmd completion at the same time.

 cpu1cpu2

 queue_command(first), p++ (=1)
 queue_command(more),
 --completion irq fires---- timer times out at same 
 time--
 handle_cmd_completion() handle_cmd_timeout(),)
 lock(xhci_lock  )   spin_on(xhci_lock)
 del_timer() fail, p (=1, nochange)
 cur_cmd = list_next(), p++ (=2)
 unlock(xhci_lock)
   lock(xhci_lock)
   p-- (=1)
   if (p > 0), exit
 OK works

 case 2: normal timeout case with ABORT+STOP, no race.

 cpu1cpu2

 queue_command(first), p++ (=1)
 queue_command(more),
   handle_cmd_timeout()
   p-- (P=0), don't exit
   mod_timer(), p++ (P=1)
   write_abort_bit()
 handle_cmd_comletion(ABORT)
 del_timer(), ok, p-- (p = 0)
 handle_cmd_completion(STOP)
 del_timer(), fail, (P=0)
 handle_stopped_cmd_ring()
 cur_cmd = list_next(), p++ (=1)
 mod_timer()

 OK, works, and same for just STOP case, with the only difference that
 during handle_cmd_completion(STOP) p is decremented (p--)
>>>
>>> Yes, that's the cases what I want to handle, thanks for your explicit
>>> explanation.
>>>
>> Gave this some more thought over the weekend, and this implementation
>> doesn't solve the case when the last command times out and races with the
>> completion handler:
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> --completion irq fires---- timer times out at same time--
>> handle_cmd_completion() handle_cmd_timeout(),)
>> lock(xhci_lock )spin_on(xhci_lock)
>> del_timer() fail, p (=1, nochange)
>> no more commands, P (=1, nochange)
>> unlock(xhci_lock)
>>  lock(xhci_lock)
>>  p-- (=0)
>> 

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Baolin Wang]

On 20 December 2016 at 14:39, Lu Baolu  wrote:
> Hi,
>
> On 12/20/2016 02:06 PM, Baolin Wang wrote:
>> Hi,
>>
>> On 20 December 2016 at 12:29, Lu Baolu  wrote:
>>> Hi Mathias,
>>>
>>> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
 On 19.12.2016 13:34, Baolin Wang wrote:
> Hi Mathias,
>
> On 19 December 2016 at 18:33, Mathias Nyman
>  wrote:
>> On 13.12.2016 05:21, Baolin Wang wrote:
>>> Hi Mathias,
>>>
>>> On 12 December 2016 at 23:52, Mathias Nyman
>>>  wrote:
 On 05.12.2016 09:51, Baolin Wang wrote:
>
> If a command event is found on the event ring during an interrupt,
> we need to stop the command timer with del_timer(). Since del_timer()
> can fail if the timer is running and waiting on the xHCI lock, then
> it maybe get the wrong timeout command in 
> xhci_handle_command_timeout()
> if host fetched a new command and updated the xhci->current_cmd in
> handle_cmd_completion(). For this situation, we need a way to signal
> to the command timer that everything is fine and it should exit.


 Ah, right, this could actually happen.

>
> We should introduce a counter (xhci->current_cmd_pending) for the 
> number
> of pending commands. If we need to cancel the command timer and
> del_timer()
> succeeds, we decrement the number of pending commands. If del_timer()
> fails,
> we leave the number of pending commands alone.
>
> For handling timeout command, in xhci_handle_command_timeout() we will
> check
> the counter after decrementing it, if the counter
> (xhci->current_cmd_pending)
> is 0, which means xhci->current_cmd is the right timeout command. If 
> the
> counter (xhci->current_cmd_pending) is greater than 0, which means
> current
> timeout command has been handled by host and host has fetched new
> command
> as
> xhci->current_cmd, then just return and wait for new current command.


 A counter like this could work.

 Writing the abort bit can generate either ABORT+STOP, or just STOP
 event, this seems to cover both.

 quick check, case 1: timeout and cmd completion at the same time.

 cpu1cpu2

 queue_command(first), p++ (=1)
 queue_command(more),
 --completion irq fires---- timer times out at same 
 time--
 handle_cmd_completion() handle_cmd_timeout(),)
 lock(xhci_lock  )   spin_on(xhci_lock)
 del_timer() fail, p (=1, nochange)
 cur_cmd = list_next(), p++ (=2)
 unlock(xhci_lock)
   lock(xhci_lock)
   p-- (=1)
   if (p > 0), exit
 OK works

 case 2: normal timeout case with ABORT+STOP, no race.

 cpu1cpu2

 queue_command(first), p++ (=1)
 queue_command(more),
   handle_cmd_timeout()
   p-- (P=0), don't exit
   mod_timer(), p++ (P=1)
   write_abort_bit()
 handle_cmd_comletion(ABORT)
 del_timer(), ok, p-- (p = 0)
 handle_cmd_completion(STOP)
 del_timer(), fail, (P=0)
 handle_stopped_cmd_ring()
 cur_cmd = list_next(), p++ (=1)
 mod_timer()

 OK, works, and same for just STOP case, with the only difference that
 during handle_cmd_completion(STOP) p is decremented (p--)
>>>
>>> Yes, that's the cases what I want to handle, thanks for your explicit
>>> explanation.
>>>
>> Gave this some more thought over the weekend, and this implementation
>> doesn't solve the case when the last command times out and races with the
>> completion handler:
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> --completion irq fires---- timer times out at same time--
>> handle_cmd_completion() handle_cmd_timeout(),)
>> lock(xhci_lock )spin_on(xhci_lock)
>> del_timer() fail, p (=1, nochange)
>> no more commands, P (=1, nochange)
>> unlock(xhci_lock)
>>  lock(xhci_lock)
>>  p-- (=0)
>>  p == 0, continue, even if we 
>> should
>> not.
>>   

Re: [PATCH v3 1/5] include: Add definitions for sed

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 12:35:45PM -0700, Scott Bauer wrote:
> This patch adds the definitions and structures for the SED
> Opal code.

This seems to contain a few things:  userspace ABIs, on the wire
defintions, and prototypes for the code added in patch 2.

The userspace ABIs should be a header on it's own.  For new code
we also usually try to split the protocol definitions from the
in-kernel APIs, although that's not even reflected in the headers
here.  If you think it's reasonable to split those out those should
be a separate new patch, and the actual in-kernel data structures
and protoypes should just go with the actual code in your current patch
2.

> +/**
> + * struct sed_context - SED Security context for a device
> + * @ops:The Trusted Send/Recv functions.
> + * @sec_data:Opaque pointer that will be passed to the send/recv fn.
> + *Drivers can use this to pass necessary data required for
> + *Their implementation of send/recv.
> + * @dev:Currently an Opal Dev structure. In the future can be other types
> + *Of security structures.
> + */

This is missing a couple spaces for the common kerneldoc format.

> +struct sed_context {
> + const struct sec_ops *ops;
> + void *sec_data;
> + void *dev;
> +};

What is the difference between sec_data and dev?  And do your really
need either one when using the container_of trick I pointed out in
response to the other patch.

> +struct sed_key {
> + __u32 sed_type;
> + union {
> + struct opal_keyopal;
> + struct opal_new_pw opal_pw;
> + struct opal_session_info   opal_session;
> + struct opal_user_lr_setup  opal_lrs;
> + struct opal_lock_unlockopal_lk_unlk;
> + struct opal_mbr_data   opal_mbr;
> + /* additional command set key types */
> + };
> +};
> +
> +#define IOC_SED_SAVE_IOW('p', 220, struct sed_key)
> +#define IOC_SED_LOCK_UNLOCK _IOW('p', 221, struct sed_key)
> +#define IOC_SED_TAKE_OWNERSHIP  _IOW('p', 222, struct sed_key)
> +#define IOC_SED_ACTIVATE_LSP   _IOW('p', 223, struct sed_key)
> +#define IOC_SED_SET_PW _IOW('p', 224, struct sed_key)
> +#define IOC_SED_ACTIVATE_USR   _IOW('p', 225, struct sed_key)
> +#define IOC_SED_REVERT_TPR _IOW('p', 226, struct sed_key)
> +#define IOC_SED_LR_SETUP   _IOW('p', 227, struct sed_key)
> +#define IOC_SED_ADD_USR_TO_LR  _IOW('p', 228, struct sed_key)
> +#define IOC_SED_ENABLE_DISABLE_MBR _IOW('p', 229, struct sed_key)
> +#define IOC_SED_ERASE_LR   _IOW('p', 230, struct sed_key)
> +#define IOC_SED_SECURE_ERASE_LR_IOW('p', 231, struct sed_key)

I'll need to look at the details again, but it seems like each ioctl
uses exactly one of the structures in the union above, so there is no
real need for that union.

Re: [PATCH v3 1/5] include: Add definitions for sed

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 12:35:45PM -0700, Scott Bauer wrote:
> This patch adds the definitions and structures for the SED
> Opal code.

This seems to contain a few things:  userspace ABIs, on the wire
defintions, and prototypes for the code added in patch 2.

The userspace ABIs should be a header on it's own.  For new code
we also usually try to split the protocol definitions from the
in-kernel APIs, although that's not even reflected in the headers
here.  If you think it's reasonable to split those out those should
be a separate new patch, and the actual in-kernel data structures
and protoypes should just go with the actual code in your current patch
2.

> +/**
> + * struct sed_context - SED Security context for a device
> + * @ops:The Trusted Send/Recv functions.
> + * @sec_data:Opaque pointer that will be passed to the send/recv fn.
> + *Drivers can use this to pass necessary data required for
> + *Their implementation of send/recv.
> + * @dev:Currently an Opal Dev structure. In the future can be other types
> + *Of security structures.
> + */

This is missing a couple spaces for the common kerneldoc format.

> +struct sed_context {
> + const struct sec_ops *ops;
> + void *sec_data;
> + void *dev;
> +};

What is the difference between sec_data and dev?  And do your really
need either one when using the container_of trick I pointed out in
response to the other patch.

> +struct sed_key {
> + __u32 sed_type;
> + union {
> + struct opal_keyopal;
> + struct opal_new_pw opal_pw;
> + struct opal_session_info   opal_session;
> + struct opal_user_lr_setup  opal_lrs;
> + struct opal_lock_unlockopal_lk_unlk;
> + struct opal_mbr_data   opal_mbr;
> + /* additional command set key types */
> + };
> +};
> +
> +#define IOC_SED_SAVE_IOW('p', 220, struct sed_key)
> +#define IOC_SED_LOCK_UNLOCK _IOW('p', 221, struct sed_key)
> +#define IOC_SED_TAKE_OWNERSHIP  _IOW('p', 222, struct sed_key)
> +#define IOC_SED_ACTIVATE_LSP   _IOW('p', 223, struct sed_key)
> +#define IOC_SED_SET_PW _IOW('p', 224, struct sed_key)
> +#define IOC_SED_ACTIVATE_USR   _IOW('p', 225, struct sed_key)
> +#define IOC_SED_REVERT_TPR _IOW('p', 226, struct sed_key)
> +#define IOC_SED_LR_SETUP   _IOW('p', 227, struct sed_key)
> +#define IOC_SED_ADD_USR_TO_LR  _IOW('p', 228, struct sed_key)
> +#define IOC_SED_ENABLE_DISABLE_MBR _IOW('p', 229, struct sed_key)
> +#define IOC_SED_ERASE_LR   _IOW('p', 230, struct sed_key)
> +#define IOC_SED_SECURE_ERASE_LR_IOW('p', 231, struct sed_key)

I'll need to look at the details again, but it seems like each ioctl
uses exactly one of the structures in the union above, so there is no
real need for that union.

Re: [PATCH v2] fscrypt: Factor out bio specific functions

[David Gstir]

Hi,

> On 19.12.2016, at 12:25, Richard Weinberger  wrote:
> 
> That way we can get rid of the direct dependency on CONFIG_BLOCK.
> 
> Reported-by: Arnd Bergmann 
> Reported-by: Randy Dunlap 
> Suggested-by: Christoph Hellwig 
> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> Signed-off-by: Richard Weinberger 
> ---
> Changes since v1:
> - Moved fscrypt_zeroout_range() also to bio.c

Looks good to me.

Reviewed-by: David Gstir 

- David

Re: [PATCH v2] fscrypt: Factor out bio specific functions

[David Gstir]

Hi,

> On 19.12.2016, at 12:25, Richard Weinberger  wrote:
> 
> That way we can get rid of the direct dependency on CONFIG_BLOCK.
> 
> Reported-by: Arnd Bergmann 
> Reported-by: Randy Dunlap 
> Suggested-by: Christoph Hellwig 
> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> Signed-off-by: Richard Weinberger 
> ---
> Changes since v1:
> - Moved fscrypt_zeroout_range() also to bio.c

Looks good to me.

Reviewed-by: David Gstir 

- David

[PATCH v3 4/6] powerpc/perf: Add event attribute and group to IMC pmus

[Hemant Kumar]

Device tree IMC driver code parses the IMC units and their events. It
passes the information to IMC pmu code which is placed in powerpc/perf
as "imc-pmu.c".

This patch creates only event attributes and attribute groups for the
IMC pmus.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/perf/Makefile|  6 +-
 arch/powerpc/perf/imc-pmu.c   | 96 +++
 arch/powerpc/platforms/powernv/opal-imc.c | 12 +++-
 3 files changed, 111 insertions(+), 3 deletions(-)
 create mode 100644 arch/powerpc/perf/imc-pmu.c

diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index f102d53..6f1d0ac 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -2,10 +2,14 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
 
 obj-$(CONFIG_PERF_EVENTS)  += callchain.o perf_regs.o
 
+imc-$(CONFIG_PPC_POWERNV)   += imc-pmu.o
+
 obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o bhrb.o
 obj64-$(CONFIG_PPC_PERF_CTRS)  += power4-pmu.o ppc970-pmu.o power5-pmu.o \
   power5+-pmu.o power6-pmu.o power7-pmu.o \
-  isa207-common.o power8-pmu.o power9-pmu.o
+  isa207-common.o power8-pmu.o power9-pmu.o \
+  $(imc-y)
+
 obj32-$(CONFIG_PPC_PERF_CTRS)  += mpc7450-pmu.o
 
 obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
new file mode 100644
index 000..7b6ce50
--- /dev/null
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -0,0 +1,96 @@
+/*
+ * Nest Performance Monitor counter support.
+ *
+ * Copyright (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ *  (C) 2016 Hemant K Shaw, IBM Corporation.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
+struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+
+/* dev_str_attr : Populate event "name" and string "str" in attribute */
+static struct attribute *dev_str_attr(const char *name, const char *str)
+{
+   struct perf_pmu_events_attr *attr;
+
+   attr = kzalloc(sizeof(*attr), GFP_KERNEL);
+
+   sysfs_attr_init(>attr.attr);
+
+   attr->event_str = str;
+   attr->attr.attr.name = name;
+   attr->attr.attr.mode = 0444;
+   attr->attr.show = perf_event_sysfs_show;
+
+   return >attr.attr;
+}
+
+/*
+ * update_events_in_group: Update the "events" information in an attr_group
+ * and assign the attr_group to the pmu "pmu".
+ */
+static int update_events_in_group(struct imc_events *events,
+ int idx, struct imc_pmu *pmu)
+{
+   struct attribute_group *attr_group;
+   struct attribute **attrs;
+   int i;
+
+   /* Allocate memory for attribute group */
+   attr_group = kzalloc(sizeof(*attr_group), GFP_KERNEL);
+   if (!attr_group)
+   return -ENOMEM;
+
+   /* Allocate memory for attributes */
+   attrs = kzalloc((sizeof(struct attribute *) * (idx + 1)), GFP_KERNEL);
+   if (!attrs) {
+   kfree(attr_group);
+   return -ENOMEM;
+   }
+
+   attr_group->name = "events";
+   attr_group->attrs = attrs;
+   for (i = 0; i < idx; i++, events++) {
+   attrs[i] = dev_str_attr((char *)events->ev_name,
+   (char *)events->ev_value);
+   }
+
+   pmu->attr_groups[0] = attr_group;
+   return 0;
+}
+
+/*
+ * init_imc_pmu : Setup the IMC pmu device in "pmu_ptr" and its events
+ *"events".
+ * Setup the cpu mask information for these pmus and setup the state machine
+ * hotplug notifiers as well.
+ */
+int init_imc_pmu(struct imc_events *events, int idx,
+struct imc_pmu *pmu_ptr)
+{
+   int ret = -ENODEV;
+
+   ret = update_events_in_group(events, idx, pmu_ptr);
+   if (ret)
+   goto err_free;
+
+   return 0;
+
+err_free:
+   /* Only free the attr_groups which are dynamically allocated  */
+   if (pmu_ptr->attr_groups[0]) {
+   kfree(pmu_ptr->attr_groups[0]->attrs);
+   kfree(pmu_ptr->attr_groups[0]);
+   }
+
+   return ret;
+}
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c 

[PATCH v3 3/6] powerpc/powernv: Detect supported IMC units and its events

[Hemant Kumar]

Parse device tree to detect IMC units. Traverse through each IMC unit
node to find supported events and corresponding unit/scale files (if any).

Right now, only nest IMC units are supported.
The nest IMC unit event node from device tree will contain the offset in
the reserved memory region to get the counter data for a given
event. The offsets for the nest events are contained in the "reg"
property of the event "node".

Kernel code uses this offset as event configuration value.

Device tree parser code also looks for scale/unit property in the event
node and passes on the value as an event attr for perf interface to use
in the post processing by the perf tool. Some PMUs may have common scale
and unit properties which implies that all events supported by this PMU
inherit the scale and unit properties of the PMU itself. For those
events, we need to set the common unit and scale values.

For failure to initialize any unit or any event, disable that unit and
continue setting up the rest of them.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/platforms/powernv/opal-imc.c | 332 ++
 1 file changed, 332 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/opal-imc.c 
b/arch/powerpc/platforms/powernv/opal-imc.c
index ee2ae45..5ee93402 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -32,6 +32,337 @@
 #include 
 
 struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
+struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+
+static int imc_event_info(char *name, struct imc_events *events)
+{
+   char *buf;
+
+   /* memory for content */
+   buf = kzalloc(IMC_MAX_PMU_NAME_LEN, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   events->ev_name = name;
+   events->ev_value = buf;
+   return 0;
+}
+
+static int imc_event_info_str(struct property *pp, char *name,
+  struct imc_events *events)
+{
+   int ret;
+
+   ret = imc_event_info(name, events);
+   if (ret)
+   return ret;
+
+   if (!pp->value || (strnlen(pp->value, pp->length) == pp->length) ||
+  (pp->length > IMC_MAX_PMU_NAME_LEN))
+   return -EINVAL;
+   strncpy(events->ev_value, (const char *)pp->value, pp->length);
+
+   return 0;
+}
+
+static int imc_event_info_val(char *name, u32 val,
+ struct imc_events *events)
+{
+   int ret;
+
+   ret = imc_event_info(name, events);
+   if (ret)
+   return ret;
+   sprintf(events->ev_value, "event=0x%x", val);
+
+   return 0;
+}
+
+static int set_event_property(struct property *pp, char *event_prop,
+ struct imc_events *events, char *ev_name)
+{
+   char *buf;
+   int ret;
+
+   buf = kzalloc(IMC_MAX_PMU_NAME_LEN, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   sprintf(buf, "%s.%s", ev_name, event_prop);
+   ret = imc_event_info_str(pp, buf, events);
+   if (ret) {
+   kfree(events->ev_name);
+   kfree(events->ev_value);
+   }
+
+   return ret;
+}
+
+/*
+ * imc_events_node_parser: Parse the event node "dev" and assign the parsed
+ * information to event "events".
+ *
+ * Parses the "reg" property of this event. "reg" gives us the event offset.
+ * Also, parse the "scale" and "unit" properties, if any.
+ */
+static int imc_events_node_parser(struct device_node *dev,
+ struct imc_events *events,
+ struct property *event_scale,
+ struct property *event_unit)
+{
+   struct property *name, *pp;
+   char *ev_name;
+   u32 val;
+   int idx = 0, ret;
+
+   if (!dev)
+   return -EINVAL;
+
+   /*
+* Loop through each property of an event node
+*/
+   name = of_find_property(dev, "event-name", NULL);
+   if (!name)
+   return -ENODEV;
+
+   if (!name->value ||
+ (strnlen(name->value, name->length) == name->length) ||
+ (name->length > IMC_MAX_PMU_NAME_LEN))
+   return -EINVAL;
+
+   ev_name = kzalloc(IMC_MAX_PMU_NAME_LEN, GFP_KERNEL);
+   if (!ev_name)
+   return -ENOMEM;
+
+   strncpy(ev_name, name->value, name->length);
+
+   /*
+* Parse each property of this event node "dev". Property "reg" has
+* the offset which is assigned to 

[PATCH v3 4/6] powerpc/perf: Add event attribute and group to IMC pmus

[Hemant Kumar]

Device tree IMC driver code parses the IMC units and their events. It
passes the information to IMC pmu code which is placed in powerpc/perf
as "imc-pmu.c".

This patch creates only event attributes and attribute groups for the
IMC pmus.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/perf/Makefile|  6 +-
 arch/powerpc/perf/imc-pmu.c   | 96 +++
 arch/powerpc/platforms/powernv/opal-imc.c | 12 +++-
 3 files changed, 111 insertions(+), 3 deletions(-)
 create mode 100644 arch/powerpc/perf/imc-pmu.c

diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index f102d53..6f1d0ac 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -2,10 +2,14 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
 
 obj-$(CONFIG_PERF_EVENTS)  += callchain.o perf_regs.o
 
+imc-$(CONFIG_PPC_POWERNV)   += imc-pmu.o
+
 obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o bhrb.o
 obj64-$(CONFIG_PPC_PERF_CTRS)  += power4-pmu.o ppc970-pmu.o power5-pmu.o \
   power5+-pmu.o power6-pmu.o power7-pmu.o \
-  isa207-common.o power8-pmu.o power9-pmu.o
+  isa207-common.o power8-pmu.o power9-pmu.o \
+  $(imc-y)
+
 obj32-$(CONFIG_PPC_PERF_CTRS)  += mpc7450-pmu.o
 
 obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
new file mode 100644
index 000..7b6ce50
--- /dev/null
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -0,0 +1,96 @@
+/*
+ * Nest Performance Monitor counter support.
+ *
+ * Copyright (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ *  (C) 2016 Hemant K Shaw, IBM Corporation.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
+struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+
+/* dev_str_attr : Populate event "name" and string "str" in attribute */
+static struct attribute *dev_str_attr(const char *name, const char *str)
+{
+   struct perf_pmu_events_attr *attr;
+
+   attr = kzalloc(sizeof(*attr), GFP_KERNEL);
+
+   sysfs_attr_init(>attr.attr);
+
+   attr->event_str = str;
+   attr->attr.attr.name = name;
+   attr->attr.attr.mode = 0444;
+   attr->attr.show = perf_event_sysfs_show;
+
+   return >attr.attr;
+}
+
+/*
+ * update_events_in_group: Update the "events" information in an attr_group
+ * and assign the attr_group to the pmu "pmu".
+ */
+static int update_events_in_group(struct imc_events *events,
+ int idx, struct imc_pmu *pmu)
+{
+   struct attribute_group *attr_group;
+   struct attribute **attrs;
+   int i;
+
+   /* Allocate memory for attribute group */
+   attr_group = kzalloc(sizeof(*attr_group), GFP_KERNEL);
+   if (!attr_group)
+   return -ENOMEM;
+
+   /* Allocate memory for attributes */
+   attrs = kzalloc((sizeof(struct attribute *) * (idx + 1)), GFP_KERNEL);
+   if (!attrs) {
+   kfree(attr_group);
+   return -ENOMEM;
+   }
+
+   attr_group->name = "events";
+   attr_group->attrs = attrs;
+   for (i = 0; i < idx; i++, events++) {
+   attrs[i] = dev_str_attr((char *)events->ev_name,
+   (char *)events->ev_value);
+   }
+
+   pmu->attr_groups[0] = attr_group;
+   return 0;
+}
+
+/*
+ * init_imc_pmu : Setup the IMC pmu device in "pmu_ptr" and its events
+ *"events".
+ * Setup the cpu mask information for these pmus and setup the state machine
+ * hotplug notifiers as well.
+ */
+int init_imc_pmu(struct imc_events *events, int idx,
+struct imc_pmu *pmu_ptr)
+{
+   int ret = -ENODEV;
+
+   ret = update_events_in_group(events, idx, pmu_ptr);
+   if (ret)
+   goto err_free;
+
+   return 0;
+
+err_free:
+   /* Only free the attr_groups which are dynamically allocated  */
+   if (pmu_ptr->attr_groups[0]) {
+   kfree(pmu_ptr->attr_groups[0]->attrs);
+   kfree(pmu_ptr->attr_groups[0]);
+   }
+
+   return ret;
+}
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c 
b/arch/powerpc/platforms/powernv/opal-imc.c
index 5ee93402..7870401 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -31,8 +31,11 @@
 #include 
 #include 
 
-struct perchip_nest_info 

[PATCH v3 3/6] powerpc/powernv: Detect supported IMC units and its events

[Hemant Kumar]

Parse device tree to detect IMC units. Traverse through each IMC unit
node to find supported events and corresponding unit/scale files (if any).

Right now, only nest IMC units are supported.
The nest IMC unit event node from device tree will contain the offset in
the reserved memory region to get the counter data for a given
event. The offsets for the nest events are contained in the "reg"
property of the event "node".

Kernel code uses this offset as event configuration value.

Device tree parser code also looks for scale/unit property in the event
node and passes on the value as an event attr for perf interface to use
in the post processing by the perf tool. Some PMUs may have common scale
and unit properties which implies that all events supported by this PMU
inherit the scale and unit properties of the PMU itself. For those
events, we need to set the common unit and scale values.

For failure to initialize any unit or any event, disable that unit and
continue setting up the rest of them.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/platforms/powernv/opal-imc.c | 332 ++
 1 file changed, 332 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/opal-imc.c 
b/arch/powerpc/platforms/powernv/opal-imc.c
index ee2ae45..5ee93402 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -32,6 +32,337 @@
 #include 
 
 struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
+struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+
+static int imc_event_info(char *name, struct imc_events *events)
+{
+   char *buf;
+
+   /* memory for content */
+   buf = kzalloc(IMC_MAX_PMU_NAME_LEN, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   events->ev_name = name;
+   events->ev_value = buf;
+   return 0;
+}
+
+static int imc_event_info_str(struct property *pp, char *name,
+  struct imc_events *events)
+{
+   int ret;
+
+   ret = imc_event_info(name, events);
+   if (ret)
+   return ret;
+
+   if (!pp->value || (strnlen(pp->value, pp->length) == pp->length) ||
+  (pp->length > IMC_MAX_PMU_NAME_LEN))
+   return -EINVAL;
+   strncpy(events->ev_value, (const char *)pp->value, pp->length);
+
+   return 0;
+}
+
+static int imc_event_info_val(char *name, u32 val,
+ struct imc_events *events)
+{
+   int ret;
+
+   ret = imc_event_info(name, events);
+   if (ret)
+   return ret;
+   sprintf(events->ev_value, "event=0x%x", val);
+
+   return 0;
+}
+
+static int set_event_property(struct property *pp, char *event_prop,
+ struct imc_events *events, char *ev_name)
+{
+   char *buf;
+   int ret;
+
+   buf = kzalloc(IMC_MAX_PMU_NAME_LEN, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   sprintf(buf, "%s.%s", ev_name, event_prop);
+   ret = imc_event_info_str(pp, buf, events);
+   if (ret) {
+   kfree(events->ev_name);
+   kfree(events->ev_value);
+   }
+
+   return ret;
+}
+
+/*
+ * imc_events_node_parser: Parse the event node "dev" and assign the parsed
+ * information to event "events".
+ *
+ * Parses the "reg" property of this event. "reg" gives us the event offset.
+ * Also, parse the "scale" and "unit" properties, if any.
+ */
+static int imc_events_node_parser(struct device_node *dev,
+ struct imc_events *events,
+ struct property *event_scale,
+ struct property *event_unit)
+{
+   struct property *name, *pp;
+   char *ev_name;
+   u32 val;
+   int idx = 0, ret;
+
+   if (!dev)
+   return -EINVAL;
+
+   /*
+* Loop through each property of an event node
+*/
+   name = of_find_property(dev, "event-name", NULL);
+   if (!name)
+   return -ENODEV;
+
+   if (!name->value ||
+ (strnlen(name->value, name->length) == name->length) ||
+ (name->length > IMC_MAX_PMU_NAME_LEN))
+   return -EINVAL;
+
+   ev_name = kzalloc(IMC_MAX_PMU_NAME_LEN, GFP_KERNEL);
+   if (!ev_name)
+   return -ENOMEM;
+
+   strncpy(ev_name, name->value, name->length);
+
+   /*
+* Parse each property of this event node "dev". Property "reg" has
+* the offset which is assigned to the event name. Other properties
+* like "scale" and "unit" are assigned to event.scale and event.unit
+* accordingly.
+*/
+   for_each_property_of_node(dev, pp) {
+   /*
+* If there is an 

[PATCH v3 6/6] powerpc/perf: IMC pmu cpumask and cpu hotplug support

[Hemant Kumar]

Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any
online CPU) from each chip for nest PMUs is designated to read counters.

On CPU hotplug, dying CPU is checked to see whether it is one of the
designated cpus, if yes, next online cpu from the same chip (for nest
units) is designated as new cpu to read counters.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/include/asm/opal-api.h|   3 +-
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/perf/imc-pmu.c| 167 -
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 4 files changed, 171 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 0e2e57b..48e1d3e 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -167,7 +167,8 @@
 #define OPAL_INT_EOI   124
 #define OPAL_INT_SET_MFRR  125
 #define OPAL_PCI_TCE_KILL  126
-#define OPAL_LAST  126
+#define OPAL_NEST_IMC_COUNTERS_CONTROL  128
+#define OPAL_LAST  128
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index e958b70..fe72b57 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -229,6 +229,8 @@ int64_t opal_pci_tce_kill(uint64_t phb_id, uint32_t 
kill_type,
 int64_t opal_rm_pci_tce_kill(uint64_t phb_id, uint32_t kill_type,
 uint32_t pe_num, uint32_t tce_size,
 uint64_t dma_addr, uint32_t npages);
+int64_t opal_nest_imc_counters_control(uint64_t mode, uint64_t value1,
+ uint64_t value2, uint64_t value3);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index f12ece8..49f6486 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -16,6 +16,7 @@
 
 struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
 struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+static cpumask_t nest_imc_cpumask;
 
 /* Needed for sanity check */
 extern u64 nest_max_offset;
@@ -31,6 +32,164 @@ static struct attribute_group imc_format_group = {
.attrs = imc_format_attrs,
 };
 
+/* Get the cpumask printed to a buffer "buf" */
+static ssize_t imc_pmu_cpumask_get_attr(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   cpumask_t *active_mask;
+
+   active_mask = _imc_cpumask;
+   return cpumap_print_to_pagebuf(true, buf, active_mask);
+}
+
+static DEVICE_ATTR(cpumask, S_IRUGO, imc_pmu_cpumask_get_attr, NULL);
+
+static struct attribute *imc_pmu_cpumask_attrs[] = {
+   _attr_cpumask.attr,
+   NULL,
+};
+
+static struct attribute_group imc_pmu_cpumask_attr_group = {
+   .attrs = imc_pmu_cpumask_attrs,
+};
+
+/*
+ * nest_init : Initializes the nest imc engine for the current chip.
+ */
+static void nest_init(int *loc)
+{
+   int rc;
+
+   rc = opal_nest_imc_counters_control(NEST_IMC_PRODUCTION_MODE,
+   NEST_IMC_ENGINE_START, 0, 0);
+   if (rc)
+   loc[smp_processor_id()] = 1;
+}
+
+static void nest_change_cpu_context(int old_cpu, int new_cpu)
+{
+   int i;
+
+   for (i = 0;
+(per_nest_pmu_arr[i] != NULL) && (i < IMC_MAX_PMUS); i++)
+   perf_pmu_migrate_context(_nest_pmu_arr[i]->pmu,
+   old_cpu, new_cpu);
+}
+
+static int ppc_nest_imc_cpu_online(unsigned int cpu)
+{
+   int nid, fcpu, ncpu;
+   struct cpumask *l_cpumask, tmp_mask;
+
+   /* Fint the cpumask of this node */
+   nid = cpu_to_node(cpu);
+   l_cpumask = cpumask_of_node(nid);
+
+   /*
+* If any of the cpu from this node is already present in the mask,
+* just return, if not, then set this cpu in the mask.
+*/
+   if (!cpumask_and(_mask, l_cpumask, _imc_cpumask)) {
+   cpumask_set_cpu(cpu, _imc_cpumask);
+   return 0;
+   }
+
+   fcpu = cpumask_first(l_cpumask);
+   ncpu = cpumask_next(cpu, l_cpumask);
+   if (cpu == fcpu) {
+   if (cpumask_test_and_clear_cpu(ncpu, _imc_cpumask)) {
+   cpumask_set_cpu(cpu, _imc_cpumask);

[PATCH v3 6/6] powerpc/perf: IMC pmu cpumask and cpu hotplug support

[Hemant Kumar]

Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any
online CPU) from each chip for nest PMUs is designated to read counters.

On CPU hotplug, dying CPU is checked to see whether it is one of the
designated cpus, if yes, next online cpu from the same chip (for nest
units) is designated as new cpu to read counters.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/include/asm/opal-api.h|   3 +-
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/perf/imc-pmu.c| 167 -
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 4 files changed, 171 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 0e2e57b..48e1d3e 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -167,7 +167,8 @@
 #define OPAL_INT_EOI   124
 #define OPAL_INT_SET_MFRR  125
 #define OPAL_PCI_TCE_KILL  126
-#define OPAL_LAST  126
+#define OPAL_NEST_IMC_COUNTERS_CONTROL  128
+#define OPAL_LAST  128
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index e958b70..fe72b57 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -229,6 +229,8 @@ int64_t opal_pci_tce_kill(uint64_t phb_id, uint32_t 
kill_type,
 int64_t opal_rm_pci_tce_kill(uint64_t phb_id, uint32_t kill_type,
 uint32_t pe_num, uint32_t tce_size,
 uint64_t dma_addr, uint32_t npages);
+int64_t opal_nest_imc_counters_control(uint64_t mode, uint64_t value1,
+ uint64_t value2, uint64_t value3);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index f12ece8..49f6486 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -16,6 +16,7 @@
 
 struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
 struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+static cpumask_t nest_imc_cpumask;
 
 /* Needed for sanity check */
 extern u64 nest_max_offset;
@@ -31,6 +32,164 @@ static struct attribute_group imc_format_group = {
.attrs = imc_format_attrs,
 };
 
+/* Get the cpumask printed to a buffer "buf" */
+static ssize_t imc_pmu_cpumask_get_attr(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   cpumask_t *active_mask;
+
+   active_mask = _imc_cpumask;
+   return cpumap_print_to_pagebuf(true, buf, active_mask);
+}
+
+static DEVICE_ATTR(cpumask, S_IRUGO, imc_pmu_cpumask_get_attr, NULL);
+
+static struct attribute *imc_pmu_cpumask_attrs[] = {
+   _attr_cpumask.attr,
+   NULL,
+};
+
+static struct attribute_group imc_pmu_cpumask_attr_group = {
+   .attrs = imc_pmu_cpumask_attrs,
+};
+
+/*
+ * nest_init : Initializes the nest imc engine for the current chip.
+ */
+static void nest_init(int *loc)
+{
+   int rc;
+
+   rc = opal_nest_imc_counters_control(NEST_IMC_PRODUCTION_MODE,
+   NEST_IMC_ENGINE_START, 0, 0);
+   if (rc)
+   loc[smp_processor_id()] = 1;
+}
+
+static void nest_change_cpu_context(int old_cpu, int new_cpu)
+{
+   int i;
+
+   for (i = 0;
+(per_nest_pmu_arr[i] != NULL) && (i < IMC_MAX_PMUS); i++)
+   perf_pmu_migrate_context(_nest_pmu_arr[i]->pmu,
+   old_cpu, new_cpu);
+}
+
+static int ppc_nest_imc_cpu_online(unsigned int cpu)
+{
+   int nid, fcpu, ncpu;
+   struct cpumask *l_cpumask, tmp_mask;
+
+   /* Fint the cpumask of this node */
+   nid = cpu_to_node(cpu);
+   l_cpumask = cpumask_of_node(nid);
+
+   /*
+* If any of the cpu from this node is already present in the mask,
+* just return, if not, then set this cpu in the mask.
+*/
+   if (!cpumask_and(_mask, l_cpumask, _imc_cpumask)) {
+   cpumask_set_cpu(cpu, _imc_cpumask);
+   return 0;
+   }
+
+   fcpu = cpumask_first(l_cpumask);
+   ncpu = cpumask_next(cpu, l_cpumask);
+   if (cpu == fcpu) {
+   if (cpumask_test_and_clear_cpu(ncpu, _imc_cpumask)) {
+   cpumask_set_cpu(cpu, _imc_cpumask);
+   nest_change_cpu_context(ncpu, cpu);
+   }
+   }
+
+   return 0;
+}
+
+static int ppc_nest_imc_cpu_offline(unsigned int cpu)
+{
+   int nid, target = -1;
+   struct cpumask *l_cpumask;
+
+   

[PATCH v3 2/6] powerpc/powernv: Autoload IMC device driver module

[Hemant Kumar]

This patch does three things :
 - Enables "opal.c" to create a platform device for the IMC interface
   according to the appropriate compatibility string.
 - Find the reserved-memory region details from the system device tree
   and get the base address of HOMER region address for each chip.
 - We also get the Nest PMU counter data offsets (in the HOMER region)
   and their sizes. The offsets for the counters' data are fixed and
   won't change from chip to chip.

The device tree parsing logic is separated from the PMU creation
functions (which is done in subsequent patches). Right now, only Nest
units are taken care of.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/platforms/powernv/Makefile   |   2 +-
 arch/powerpc/platforms/powernv/opal-imc.c | 117 ++
 arch/powerpc/platforms/powernv/opal.c |  13 
 3 files changed, 131 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/platforms/powernv/opal-imc.c

diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index b5d98cb..44909fe 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o
+obj-y  += opal-kmsg.o opal-imc.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c 
b/arch/powerpc/platforms/powernv/opal-imc.c
new file mode 100644
index 000..ee2ae45
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -0,0 +1,117 @@
+/*
+ * OPAL IMC interface detection driver
+ * Supported on POWERNV platform
+ *
+ * Copyright  (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ *(C) 2016 Hemant K Shaw, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
+
+static int opal_imc_counters_probe(struct platform_device *pdev)
+{
+   struct device_node *child, *imc_dev, *rm_node = NULL;
+   struct perchip_nest_info *pcni;
+   u32 reg[4], pages, nest_offset, nest_size, idx;
+   int i = 0;
+   const char *node_name;
+
+   if (!pdev || !pdev->dev.of_node)
+   return -ENODEV;
+
+   imc_dev = pdev->dev.of_node;
+
+   /*
+* nest_offset : where the nest-counters' data start.
+* size : size of the entire nest-counters region
+*/
+   if (of_property_read_u32(imc_dev, "imc-nest-offset", _offset))
+   goto err;
+   if (of_property_read_u32(imc_dev, "imc-nest-size", _size))
+   goto err;
+
+   /* Find the "homer region" for each chip */
+   rm_node = of_find_node_by_path("/reserved-memory");
+   if (!rm_node)
+   goto err;
+
+   for_each_child_of_node(rm_node, child) {
+   if (of_property_read_string_index(child, "name", 0,
+ _name))
+   continue;
+   if (strncmp("ibm,homer-image", node_name,
+   strlen("ibm,homer-image")))
+   continue;
+
+   /* Get the chip id to which the above homer region belongs to */
+   if (of_property_read_u32(child, "ibm,chip-id", ))
+   goto err;
+
+   /* reg property will have four u32 cells. */
+   if (of_property_read_u32_array(child, "reg", reg, 4))
+   goto err;
+
+   pcni = _perchip_info[idx];
+
+   /* Fetch the homer region base 

[PATCH v3 0/6] IMC Instrumentation Support

[Hemant Kumar]

Power 9 has In-Memory-Collection (IMC) infrastructure which contains
various Performance Monitoring Units (PMUs) at Nest level (these are
on-chip but off-core). These Nest PMU counters are handled by a Nest
IMC microcode. This microcode runs in the OCC (On-Chip Controller)
complex and its purpose is to program the nest counters, collect the
counter data and move the counter data to memory. 

The IMC infrastructure encapsulates nest (per-chip), core and thread
level counters. While the nest IMC PMUs are handled by the nest IMC
microcode, the core and thread level PMUs are handled by the Core-HPMC
engine. This patchset enables the nest IMC PMUs and is based on the
initial work done by Madhavan Srinivasan.
"Nest Instrumentation Support" : 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-August/132078.html

v1 for this patchset can be found here :
https://lwn.net/Articles/705475/

Nest events:
Per-chip nest instrumentation provides various per-chip metrics
such as memory, powerbus, Xlink and Alink bandwidth.

PMU Events' Information:
OPAL obtains the Nest PMU and event information from the IMC Catalog
and passes on to the kernel via the device tree. The events' information
contains :
 - Event name
 - Event Offset
 - Event description
and, maybe :
 - Event scale
 - Event unit

Some PMUs may have a common scale and unit values for all their
supported events. For those cases, the scale and unit properties for
those events must be inherited from the PMU.

The event offset in the memory is where the counter data gets
accumulated.

The OPAL-side patches are posted upstream :
https://lists.ozlabs.org/pipermail/skiboot/2016-November/005552.html

The kernel discovers the IMC counters information in the device tree
at the "imc-counters" device node which has a compatible field
"ibm,opal-in-memory-counters".

Parsing of the Events' information:
To parse the IMC PMUs and events information, the kernel has to
discover the "imc-counters" node and walk through the pmu and event
nodes.

Here is an excerpt of the dt showing the imc-counters and mcs node:
/dts-v1/;

[...]
imc-counters {   
imc-nest-offset = <0x32>;
compatible = "ibm,opal-in-memory-counters";
imc-nest-size = <0x3>;
#address-cells = <0x1>;
#size-cells = <0x1>;
phandle = <0x1238>;
version-id = [00];

mcs0 {
compatible = "ibm,imc-counters-chip";
ranges;
#address-cells = <0x1>;
#size-cells = <0x1>;
phandle = <0x1279>;
scale = "1.2207e-4";
unit = "MiB";

event@528 {
event-name = "PM_MCS_UP_128B_DATA_XFER_MC0" ;
desc = "Total Read Bandwidth seen on both MCS 
of MC0";
phandle = <0x128c>;
reg = <0x118 0x8>;
};
[...]

>From the device tree, the kernel parses the PMUs and their events'
information.

After parsing the nest IMC PMUs and their events, the PMUs and their
attributes are registered in the kernel.

Example Usage :
 # perf list

  [...]
  nest_mcs0/PM_MCS_DOWN_128B_DATA_XFER_MC0/   [Kernel PMU event]
  nest_mcs0/PM_MCS_DOWN_128B_DATA_XFER_MC0_LAST_SAMPLE/ [Kernel PMU event]
  [...]

 # perf stat -e "nest_mcs0/PM_MCS_DOWN_128B_DATA_XFER_MC0/" -a --per-socket

TODOs:
 - Add support for Core IMC.
 - Add support for thread IMC.

Comments/feedback/suggestions are welcome.

Changelog:
 v2 -> v3 :
 - Changed all references for IMA (In-Memory Accumulation) to IMC (In-Memory
   Collection).
 v1 -> v2 :
 - Account for the cases where a PMU can have a common scale and unit
   values for all its supported events (Patch 3/6).
 - Fixed a Build error (for maple_defconfig) by enabling imc_pmu.o
   only for CONFIG_PPC_POWERNV=y (Patch 4/6)
 - Read from the "event-name" property instead of "name" for an event
   node (Patch 3/6).

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 

Hemant Kumar (6):
  powerpc/powernv: Data structure and macros definitions
  powerpc/powernv: Autoload IMC device driver module
  powerpc/powernv: Detect supported IMC units and its events
  powerpc/perf: Add event attribute and group to IMC pmus
  powerpc/perf: 

[PATCH v3 1/6] powerpc/powernv: Data structure and macros definitions

[Hemant Kumar]

Create new header file "imc-pmu.h" to add the data structures
and macros needed for IMC pmu support.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/include/asm/imc-pmu.h | 73 ++
 1 file changed, 73 insertions(+)
 create mode 100644 arch/powerpc/include/asm/imc-pmu.h

diff --git a/arch/powerpc/include/asm/imc-pmu.h 
b/arch/powerpc/include/asm/imc-pmu.h
new file mode 100644
index 000..911d837
--- /dev/null
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -0,0 +1,73 @@
+#ifndef PPC_POWERNV_IMC_PMU_DEF_H
+#define PPC_POWERNV_IMC_PMU_DEF_H
+
+/*
+ * IMC Nest Performance Monitor counter support.
+ *
+ * Copyright (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ *   (C) 2016 Hemant K Shaw, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMC_MAX_CHIPS  32
+#define IMC_MAX_PMUS   32
+#define IMC_MAX_PMU_NAME_LEN   256
+
+#define NEST_IMC_ENGINE_START  1
+#define NEST_IMC_ENGINE_STOP   0
+#define NEST_MAX_PAGES 16
+
+#define NEST_IMC_PRODUCTION_MODE   1
+
+#define IMC_DTB_COMPAT "ibm,opal-in-memory-counters"
+#define IMC_DTB_NEST_COMPAT"ibm,imc-counters-chip"
+
+/*
+ * Structure to hold per chip specific memory address
+ * information for nest pmus. Nest Counter data are exported
+ * in per-chip reserved memory region by the PORE Engine.
+ */
+struct perchip_nest_info {
+   u32 chip_id;
+   u64 pbase;
+   u64 vbase[NEST_MAX_PAGES];
+   u64 size;
+};
+
+/*
+ * Place holder for nest pmu events and values.
+ */
+struct imc_events {
+   char *ev_name;
+   char *ev_value;
+};
+
+/*
+ * Device tree parser code detects IMC pmu support and
+ * registers new IMC pmus. This structure will
+ * hold the pmu functions and attrs for each imc pmu and
+ * will be referenced at the time of pmu registration.
+ */
+struct imc_pmu {
+   struct pmu pmu;
+   int domain;
+   const struct attribute_group *attr_groups[4];
+};
+
+/*
+ * Domains for IMC PMUs
+ */
+#define IMC_DOMAIN_NEST1
+
+#define UNKNOWN_DOMAIN -1
+
+#endif /* PPC_POWERNV_IMC_PMU_DEF_H */
-- 
2.7.4

[PATCH v3 5/6] powerpc/perf: Generic imc pmu event functions

[Hemant Kumar]

Since, the IMC counters' data are periodically fed to a memory location,
the functions to read/update, start/stop, add/del can be generic and can
be used by all IMC PMU units.

This patch adds a set of generic imc pmu related event functions to be
used  by each imc pmu unit. Add code to setup format attribute and to
register imc pmus. Add a event_init function for nest_imc events.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/include/asm/imc-pmu.h|   1 +
 arch/powerpc/perf/imc-pmu.c   | 122 ++
 arch/powerpc/platforms/powernv/opal-imc.c |  29 ++-
 3 files changed, 148 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/imc-pmu.h 
b/arch/powerpc/include/asm/imc-pmu.h
index 911d837..ceb6b1f 100644
--- a/arch/powerpc/include/asm/imc-pmu.h
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -70,4 +70,5 @@ struct imc_pmu {
 
 #define UNKNOWN_DOMAIN -1
 
+int imc_get_domain(struct device_node *pmu_dev);
 #endif /* PPC_POWERNV_IMC_PMU_DEF_H */
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 7b6ce50..f12ece8 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -17,6 +17,117 @@
 struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
 struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
 
+/* Needed for sanity check */
+extern u64 nest_max_offset;
+
+PMU_FORMAT_ATTR(event, "config:0-20");
+static struct attribute *imc_format_attrs[] = {
+   _attr_event.attr,
+   NULL,
+};
+
+static struct attribute_group imc_format_group = {
+   .name = "format",
+   .attrs = imc_format_attrs,
+};
+
+static int nest_imc_event_init(struct perf_event *event)
+{
+   int chip_id;
+   u32 config = event->attr.config;
+   struct perchip_nest_info *pcni;
+
+   if (event->attr.type != event->pmu->type)
+   return -ENOENT;
+
+   /* Sampling not supported */
+   if (event->hw.sample_period)
+   return -EINVAL;
+
+   /* unsupported modes and filters */
+   if (event->attr.exclude_user   ||
+   event->attr.exclude_kernel ||
+   event->attr.exclude_hv ||
+   event->attr.exclude_idle   ||
+   event->attr.exclude_host   ||
+   event->attr.exclude_guest)
+   return -EINVAL;
+
+   if (event->cpu < 0)
+   return -EINVAL;
+
+   /* Sanity check for config (event offset) */
+   if (config > nest_max_offset)
+   return -EINVAL;
+
+   chip_id = topology_physical_package_id(event->cpu);
+   pcni = _perchip_info[chip_id];
+   event->hw.event_base = pcni->vbase[config/PAGE_SIZE] +
+   (config & ~PAGE_MASK);
+
+   return 0;
+}
+
+static void imc_read_counter(struct perf_event *event)
+{
+   u64 *addr, data;
+
+   addr = (u64 *)event->hw.event_base;
+   data = __be64_to_cpu(*addr);
+   local64_set(>hw.prev_count, data);
+}
+
+static void imc_perf_event_update(struct perf_event *event)
+{
+   u64 counter_prev, counter_new, final_count, *addr;
+
+   addr = (u64 *)event->hw.event_base;
+   counter_prev = local64_read(>hw.prev_count);
+   counter_new = __be64_to_cpu(*addr);
+   final_count = counter_new - counter_prev;
+
+   local64_set(>hw.prev_count, counter_new);
+   local64_add(final_count, >count);
+}
+
+static void imc_event_start(struct perf_event *event, int flags)
+{
+   imc_read_counter(event);
+}
+
+static void imc_event_stop(struct perf_event *event, int flags)
+{
+   if (flags & PERF_EF_UPDATE)
+   imc_perf_event_update(event);
+}
+
+static int imc_event_add(struct perf_event *event, int flags)
+{
+   if (flags & PERF_EF_START)
+   imc_event_start(event, flags);
+
+   return 0;
+}
+
+/* update_pmu_ops : Populate the appropriate operations for "pmu" */
+static int update_pmu_ops(struct imc_pmu *pmu)
+{
+   if (!pmu)
+   return -EINVAL;
+
+   pmu->pmu.task_ctx_nr = perf_invalid_context;
+   pmu->pmu.event_init = nest_imc_event_init;
+   pmu->pmu.add = imc_event_add;
+   pmu->pmu.del = imc_event_stop;
+   pmu->pmu.start = imc_event_start;
+   pmu->pmu.stop = imc_event_stop;
+   pmu->pmu.read = imc_perf_event_update;
+   pmu->attr_groups[1] = _format_group;
+   pmu->pmu.attr_groups = pmu->attr_groups;
+
+   return 0;
+}
+
 /* dev_str_attr : Populate event "name" and string "str" in attribute */
 static struct 

[PATCH v3 1/6] powerpc/powernv: Data structure and macros definitions

[Hemant Kumar]

Create new header file "imc-pmu.h" to add the data structures
and macros needed for IMC pmu support.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/include/asm/imc-pmu.h | 73 ++
 1 file changed, 73 insertions(+)
 create mode 100644 arch/powerpc/include/asm/imc-pmu.h

diff --git a/arch/powerpc/include/asm/imc-pmu.h 
b/arch/powerpc/include/asm/imc-pmu.h
new file mode 100644
index 000..911d837
--- /dev/null
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -0,0 +1,73 @@
+#ifndef PPC_POWERNV_IMC_PMU_DEF_H
+#define PPC_POWERNV_IMC_PMU_DEF_H
+
+/*
+ * IMC Nest Performance Monitor counter support.
+ *
+ * Copyright (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ *   (C) 2016 Hemant K Shaw, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMC_MAX_CHIPS  32
+#define IMC_MAX_PMUS   32
+#define IMC_MAX_PMU_NAME_LEN   256
+
+#define NEST_IMC_ENGINE_START  1
+#define NEST_IMC_ENGINE_STOP   0
+#define NEST_MAX_PAGES 16
+
+#define NEST_IMC_PRODUCTION_MODE   1
+
+#define IMC_DTB_COMPAT "ibm,opal-in-memory-counters"
+#define IMC_DTB_NEST_COMPAT"ibm,imc-counters-chip"
+
+/*
+ * Structure to hold per chip specific memory address
+ * information for nest pmus. Nest Counter data are exported
+ * in per-chip reserved memory region by the PORE Engine.
+ */
+struct perchip_nest_info {
+   u32 chip_id;
+   u64 pbase;
+   u64 vbase[NEST_MAX_PAGES];
+   u64 size;
+};
+
+/*
+ * Place holder for nest pmu events and values.
+ */
+struct imc_events {
+   char *ev_name;
+   char *ev_value;
+};
+
+/*
+ * Device tree parser code detects IMC pmu support and
+ * registers new IMC pmus. This structure will
+ * hold the pmu functions and attrs for each imc pmu and
+ * will be referenced at the time of pmu registration.
+ */
+struct imc_pmu {
+   struct pmu pmu;
+   int domain;
+   const struct attribute_group *attr_groups[4];
+};
+
+/*
+ * Domains for IMC PMUs
+ */
+#define IMC_DOMAIN_NEST1
+
+#define UNKNOWN_DOMAIN -1
+
+#endif /* PPC_POWERNV_IMC_PMU_DEF_H */
-- 
2.7.4

[PATCH v3 5/6] powerpc/perf: Generic imc pmu event functions

[Hemant Kumar]

Since, the IMC counters' data are periodically fed to a memory location,
the functions to read/update, start/stop, add/del can be generic and can
be used by all IMC PMU units.

This patch adds a set of generic imc pmu related event functions to be
used  by each imc pmu unit. Add code to setup format attribute and to
register imc pmus. Add a event_init function for nest_imc events.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/include/asm/imc-pmu.h|   1 +
 arch/powerpc/perf/imc-pmu.c   | 122 ++
 arch/powerpc/platforms/powernv/opal-imc.c |  29 ++-
 3 files changed, 148 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/imc-pmu.h 
b/arch/powerpc/include/asm/imc-pmu.h
index 911d837..ceb6b1f 100644
--- a/arch/powerpc/include/asm/imc-pmu.h
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -70,4 +70,5 @@ struct imc_pmu {
 
 #define UNKNOWN_DOMAIN -1
 
+int imc_get_domain(struct device_node *pmu_dev);
 #endif /* PPC_POWERNV_IMC_PMU_DEF_H */
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 7b6ce50..f12ece8 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -17,6 +17,117 @@
 struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
 struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
 
+/* Needed for sanity check */
+extern u64 nest_max_offset;
+
+PMU_FORMAT_ATTR(event, "config:0-20");
+static struct attribute *imc_format_attrs[] = {
+   _attr_event.attr,
+   NULL,
+};
+
+static struct attribute_group imc_format_group = {
+   .name = "format",
+   .attrs = imc_format_attrs,
+};
+
+static int nest_imc_event_init(struct perf_event *event)
+{
+   int chip_id;
+   u32 config = event->attr.config;
+   struct perchip_nest_info *pcni;
+
+   if (event->attr.type != event->pmu->type)
+   return -ENOENT;
+
+   /* Sampling not supported */
+   if (event->hw.sample_period)
+   return -EINVAL;
+
+   /* unsupported modes and filters */
+   if (event->attr.exclude_user   ||
+   event->attr.exclude_kernel ||
+   event->attr.exclude_hv ||
+   event->attr.exclude_idle   ||
+   event->attr.exclude_host   ||
+   event->attr.exclude_guest)
+   return -EINVAL;
+
+   if (event->cpu < 0)
+   return -EINVAL;
+
+   /* Sanity check for config (event offset) */
+   if (config > nest_max_offset)
+   return -EINVAL;
+
+   chip_id = topology_physical_package_id(event->cpu);
+   pcni = _perchip_info[chip_id];
+   event->hw.event_base = pcni->vbase[config/PAGE_SIZE] +
+   (config & ~PAGE_MASK);
+
+   return 0;
+}
+
+static void imc_read_counter(struct perf_event *event)
+{
+   u64 *addr, data;
+
+   addr = (u64 *)event->hw.event_base;
+   data = __be64_to_cpu(*addr);
+   local64_set(>hw.prev_count, data);
+}
+
+static void imc_perf_event_update(struct perf_event *event)
+{
+   u64 counter_prev, counter_new, final_count, *addr;
+
+   addr = (u64 *)event->hw.event_base;
+   counter_prev = local64_read(>hw.prev_count);
+   counter_new = __be64_to_cpu(*addr);
+   final_count = counter_new - counter_prev;
+
+   local64_set(>hw.prev_count, counter_new);
+   local64_add(final_count, >count);
+}
+
+static void imc_event_start(struct perf_event *event, int flags)
+{
+   imc_read_counter(event);
+}
+
+static void imc_event_stop(struct perf_event *event, int flags)
+{
+   if (flags & PERF_EF_UPDATE)
+   imc_perf_event_update(event);
+}
+
+static int imc_event_add(struct perf_event *event, int flags)
+{
+   if (flags & PERF_EF_START)
+   imc_event_start(event, flags);
+
+   return 0;
+}
+
+/* update_pmu_ops : Populate the appropriate operations for "pmu" */
+static int update_pmu_ops(struct imc_pmu *pmu)
+{
+   if (!pmu)
+   return -EINVAL;
+
+   pmu->pmu.task_ctx_nr = perf_invalid_context;
+   pmu->pmu.event_init = nest_imc_event_init;
+   pmu->pmu.add = imc_event_add;
+   pmu->pmu.del = imc_event_stop;
+   pmu->pmu.start = imc_event_start;
+   pmu->pmu.stop = imc_event_stop;
+   pmu->pmu.read = imc_perf_event_update;
+   pmu->attr_groups[1] = _format_group;
+   pmu->pmu.attr_groups = pmu->attr_groups;
+
+   return 0;
+}
+
 /* dev_str_attr : Populate event "name" and string "str" in attribute */
 static struct attribute *dev_str_attr(const char *name, const char *str)
 {
@@ -83,6 +194,17 @@ int init_imc_pmu(struct imc_events *events, int idx,
if (ret)
goto err_free;
 
+   ret = update_pmu_ops(pmu_ptr);
+   if (ret)
+ 

[PATCH v3 2/6] powerpc/powernv: Autoload IMC device driver module

[Hemant Kumar]

This patch does three things :
 - Enables "opal.c" to create a platform device for the IMC interface
   according to the appropriate compatibility string.
 - Find the reserved-memory region details from the system device tree
   and get the base address of HOMER region address for each chip.
 - We also get the Nest PMU counter data offsets (in the HOMER region)
   and their sizes. The offsets for the counters' data are fixed and
   won't change from chip to chip.

The device tree parsing logic is separated from the PMU creation
functions (which is done in subsequent patches). Right now, only Nest
units are taken care of.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 
---
 arch/powerpc/platforms/powernv/Makefile   |   2 +-
 arch/powerpc/platforms/powernv/opal-imc.c | 117 ++
 arch/powerpc/platforms/powernv/opal.c |  13 
 3 files changed, 131 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/platforms/powernv/opal-imc.c

diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index b5d98cb..44909fe 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o
+obj-y  += opal-kmsg.o opal-imc.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c 
b/arch/powerpc/platforms/powernv/opal-imc.c
new file mode 100644
index 000..ee2ae45
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -0,0 +1,117 @@
+/*
+ * OPAL IMC interface detection driver
+ * Supported on POWERNV platform
+ *
+ * Copyright  (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ *(C) 2016 Hemant K Shaw, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
+
+static int opal_imc_counters_probe(struct platform_device *pdev)
+{
+   struct device_node *child, *imc_dev, *rm_node = NULL;
+   struct perchip_nest_info *pcni;
+   u32 reg[4], pages, nest_offset, nest_size, idx;
+   int i = 0;
+   const char *node_name;
+
+   if (!pdev || !pdev->dev.of_node)
+   return -ENODEV;
+
+   imc_dev = pdev->dev.of_node;
+
+   /*
+* nest_offset : where the nest-counters' data start.
+* size : size of the entire nest-counters region
+*/
+   if (of_property_read_u32(imc_dev, "imc-nest-offset", _offset))
+   goto err;
+   if (of_property_read_u32(imc_dev, "imc-nest-size", _size))
+   goto err;
+
+   /* Find the "homer region" for each chip */
+   rm_node = of_find_node_by_path("/reserved-memory");
+   if (!rm_node)
+   goto err;
+
+   for_each_child_of_node(rm_node, child) {
+   if (of_property_read_string_index(child, "name", 0,
+ _name))
+   continue;
+   if (strncmp("ibm,homer-image", node_name,
+   strlen("ibm,homer-image")))
+   continue;
+
+   /* Get the chip id to which the above homer region belongs to */
+   if (of_property_read_u32(child, "ibm,chip-id", ))
+   goto err;
+
+   /* reg property will have four u32 cells. */
+   if (of_property_read_u32_array(child, "reg", reg, 4))
+   goto err;
+
+   pcni = _perchip_info[idx];
+
+   /* Fetch the homer region base address */
+   pcni->pbase = reg[0];
+   pcni->pbase = pcni->pbase << 32 | reg[1];
+   /* Add the nest IMC Base offset */
+   pcni->pbase = pcni->pbase + nest_offset;
+   /* Fetch the 

[PATCH v3 0/6] IMC Instrumentation Support

[Hemant Kumar]

Power 9 has In-Memory-Collection (IMC) infrastructure which contains
various Performance Monitoring Units (PMUs) at Nest level (these are
on-chip but off-core). These Nest PMU counters are handled by a Nest
IMC microcode. This microcode runs in the OCC (On-Chip Controller)
complex and its purpose is to program the nest counters, collect the
counter data and move the counter data to memory. 

The IMC infrastructure encapsulates nest (per-chip), core and thread
level counters. While the nest IMC PMUs are handled by the nest IMC
microcode, the core and thread level PMUs are handled by the Core-HPMC
engine. This patchset enables the nest IMC PMUs and is based on the
initial work done by Madhavan Srinivasan.
"Nest Instrumentation Support" : 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-August/132078.html

v1 for this patchset can be found here :
https://lwn.net/Articles/705475/

Nest events:
Per-chip nest instrumentation provides various per-chip metrics
such as memory, powerbus, Xlink and Alink bandwidth.

PMU Events' Information:
OPAL obtains the Nest PMU and event information from the IMC Catalog
and passes on to the kernel via the device tree. The events' information
contains :
 - Event name
 - Event Offset
 - Event description
and, maybe :
 - Event scale
 - Event unit

Some PMUs may have a common scale and unit values for all their
supported events. For those cases, the scale and unit properties for
those events must be inherited from the PMU.

The event offset in the memory is where the counter data gets
accumulated.

The OPAL-side patches are posted upstream :
https://lists.ozlabs.org/pipermail/skiboot/2016-November/005552.html

The kernel discovers the IMC counters information in the device tree
at the "imc-counters" device node which has a compatible field
"ibm,opal-in-memory-counters".

Parsing of the Events' information:
To parse the IMC PMUs and events information, the kernel has to
discover the "imc-counters" node and walk through the pmu and event
nodes.

Here is an excerpt of the dt showing the imc-counters and mcs node:
/dts-v1/;

[...]
imc-counters {   
imc-nest-offset = <0x32>;
compatible = "ibm,opal-in-memory-counters";
imc-nest-size = <0x3>;
#address-cells = <0x1>;
#size-cells = <0x1>;
phandle = <0x1238>;
version-id = [00];

mcs0 {
compatible = "ibm,imc-counters-chip";
ranges;
#address-cells = <0x1>;
#size-cells = <0x1>;
phandle = <0x1279>;
scale = "1.2207e-4";
unit = "MiB";

event@528 {
event-name = "PM_MCS_UP_128B_DATA_XFER_MC0" ;
desc = "Total Read Bandwidth seen on both MCS 
of MC0";
phandle = <0x128c>;
reg = <0x118 0x8>;
};
[...]

>From the device tree, the kernel parses the PMUs and their events'
information.

After parsing the nest IMC PMUs and their events, the PMUs and their
attributes are registered in the kernel.

Example Usage :
 # perf list

  [...]
  nest_mcs0/PM_MCS_DOWN_128B_DATA_XFER_MC0/   [Kernel PMU event]
  nest_mcs0/PM_MCS_DOWN_128B_DATA_XFER_MC0_LAST_SAMPLE/ [Kernel PMU event]
  [...]

 # perf stat -e "nest_mcs0/PM_MCS_DOWN_128B_DATA_XFER_MC0/" -a --per-socket

TODOs:
 - Add support for Core IMC.
 - Add support for thread IMC.

Comments/feedback/suggestions are welcome.

Changelog:
 v2 -> v3 :
 - Changed all references for IMA (In-Memory Accumulation) to IMC (In-Memory
   Collection).
 v1 -> v2 :
 - Account for the cases where a PMU can have a common scale and unit
   values for all its supported events (Patch 3/6).
 - Fixed a Build error (for maple_defconfig) by enabling imc_pmu.o
   only for CONFIG_PPC_POWERNV=y (Patch 4/6)
 - Read from the "event-name" property instead of "name" for an event
   node (Patch 3/6).

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Anton Blanchard 
Cc: Sukadev Bhattiprolu 
Cc: Michael Neuling 
Cc: Stewart Smith 
Cc: Daniel Axtens 
Cc: Stephane Eranian 
Signed-off-by: Hemant Kumar 

Hemant Kumar (6):
  powerpc/powernv: Data structure and macros definitions
  powerpc/powernv: Autoload IMC device driver module
  powerpc/powernv: Detect supported IMC units and its events
  powerpc/perf: Add event attribute and group to IMC pmus
  powerpc/perf: Generic imc pmu event functions
  powerpc/perf: IMC pmu cpumask and cpu hotplug support

 arch/powerpc/include/asm/imc-pmu.h |  74 
 arch/powerpc/include/asm/opal-api.h|   3 +-
 arch/powerpc/include/asm/opal.h   

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Lu Baolu]

Hi,

On 12/20/2016 02:06 PM, Baolin Wang wrote:
> Hi,
>
> On 20 December 2016 at 12:29, Lu Baolu  wrote:
>> Hi Mathias,
>>
>> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
>>> On 19.12.2016 13:34, Baolin Wang wrote:
 Hi Mathias,

 On 19 December 2016 at 18:33, Mathias Nyman
  wrote:
> On 13.12.2016 05:21, Baolin Wang wrote:
>> Hi Mathias,
>>
>> On 12 December 2016 at 23:52, Mathias Nyman
>>  wrote:
>>> On 05.12.2016 09:51, Baolin Wang wrote:

 If a command event is found on the event ring during an interrupt,
 we need to stop the command timer with del_timer(). Since del_timer()
 can fail if the timer is running and waiting on the xHCI lock, then
 it maybe get the wrong timeout command in xhci_handle_command_timeout()
 if host fetched a new command and updated the xhci->current_cmd in
 handle_cmd_completion(). For this situation, we need a way to signal
 to the command timer that everything is fine and it should exit.
>>>
>>>
>>> Ah, right, this could actually happen.
>>>

 We should introduce a counter (xhci->current_cmd_pending) for the 
 number
 of pending commands. If we need to cancel the command timer and
 del_timer()
 succeeds, we decrement the number of pending commands. If del_timer()
 fails,
 we leave the number of pending commands alone.

 For handling timeout command, in xhci_handle_command_timeout() we will
 check
 the counter after decrementing it, if the counter
 (xhci->current_cmd_pending)
 is 0, which means xhci->current_cmd is the right timeout command. If 
 the
 counter (xhci->current_cmd_pending) is greater than 0, which means
 current
 timeout command has been handled by host and host has fetched new
 command
 as
 xhci->current_cmd, then just return and wait for new current command.
>>>
>>>
>>> A counter like this could work.
>>>
>>> Writing the abort bit can generate either ABORT+STOP, or just STOP
>>> event, this seems to cover both.
>>>
>>> quick check, case 1: timeout and cmd completion at the same time.
>>>
>>> cpu1cpu2
>>>
>>> queue_command(first), p++ (=1)
>>> queue_command(more),
>>> --completion irq fires---- timer times out at same 
>>> time--
>>> handle_cmd_completion() handle_cmd_timeout(),)
>>> lock(xhci_lock  )   spin_on(xhci_lock)
>>> del_timer() fail, p (=1, nochange)
>>> cur_cmd = list_next(), p++ (=2)
>>> unlock(xhci_lock)
>>>   lock(xhci_lock)
>>>   p-- (=1)
>>>   if (p > 0), exit
>>> OK works
>>>
>>> case 2: normal timeout case with ABORT+STOP, no race.
>>>
>>> cpu1cpu2
>>>
>>> queue_command(first), p++ (=1)
>>> queue_command(more),
>>>   handle_cmd_timeout()
>>>   p-- (P=0), don't exit
>>>   mod_timer(), p++ (P=1)
>>>   write_abort_bit()
>>> handle_cmd_comletion(ABORT)
>>> del_timer(), ok, p-- (p = 0)
>>> handle_cmd_completion(STOP)
>>> del_timer(), fail, (P=0)
>>> handle_stopped_cmd_ring()
>>> cur_cmd = list_next(), p++ (=1)
>>> mod_timer()
>>>
>>> OK, works, and same for just STOP case, with the only difference that
>>> during handle_cmd_completion(STOP) p is decremented (p--)
>>
>> Yes, that's the cases what I want to handle, thanks for your explicit
>> explanation.
>>
> Gave this some more thought over the weekend, and this implementation
> doesn't solve the case when the last command times out and races with the
> completion handler:
>
> cpu1cpu2
>
> queue_command(first), p++ (=1)
> --completion irq fires---- timer times out at same time--
> handle_cmd_completion() handle_cmd_timeout(),)
> lock(xhci_lock )spin_on(xhci_lock)
> del_timer() fail, p (=1, nochange)
> no more commands, P (=1, nochange)
> unlock(xhci_lock)
>  lock(xhci_lock)
>  p-- (=0)
>  p == 0, continue, even if we 
> should
> not.
>For this we still need to rely 
> on
> checking cur_cmd == NULL in the 

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Lu Baolu]

Hi,

On 12/20/2016 02:06 PM, Baolin Wang wrote:
> Hi,
>
> On 20 December 2016 at 12:29, Lu Baolu  wrote:
>> Hi Mathias,
>>
>> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
>>> On 19.12.2016 13:34, Baolin Wang wrote:
 Hi Mathias,

 On 19 December 2016 at 18:33, Mathias Nyman
  wrote:
> On 13.12.2016 05:21, Baolin Wang wrote:
>> Hi Mathias,
>>
>> On 12 December 2016 at 23:52, Mathias Nyman
>>  wrote:
>>> On 05.12.2016 09:51, Baolin Wang wrote:

 If a command event is found on the event ring during an interrupt,
 we need to stop the command timer with del_timer(). Since del_timer()
 can fail if the timer is running and waiting on the xHCI lock, then
 it maybe get the wrong timeout command in xhci_handle_command_timeout()
 if host fetched a new command and updated the xhci->current_cmd in
 handle_cmd_completion(). For this situation, we need a way to signal
 to the command timer that everything is fine and it should exit.
>>>
>>>
>>> Ah, right, this could actually happen.
>>>

 We should introduce a counter (xhci->current_cmd_pending) for the 
 number
 of pending commands. If we need to cancel the command timer and
 del_timer()
 succeeds, we decrement the number of pending commands. If del_timer()
 fails,
 we leave the number of pending commands alone.

 For handling timeout command, in xhci_handle_command_timeout() we will
 check
 the counter after decrementing it, if the counter
 (xhci->current_cmd_pending)
 is 0, which means xhci->current_cmd is the right timeout command. If 
 the
 counter (xhci->current_cmd_pending) is greater than 0, which means
 current
 timeout command has been handled by host and host has fetched new
 command
 as
 xhci->current_cmd, then just return and wait for new current command.
>>>
>>>
>>> A counter like this could work.
>>>
>>> Writing the abort bit can generate either ABORT+STOP, or just STOP
>>> event, this seems to cover both.
>>>
>>> quick check, case 1: timeout and cmd completion at the same time.
>>>
>>> cpu1cpu2
>>>
>>> queue_command(first), p++ (=1)
>>> queue_command(more),
>>> --completion irq fires---- timer times out at same 
>>> time--
>>> handle_cmd_completion() handle_cmd_timeout(),)
>>> lock(xhci_lock  )   spin_on(xhci_lock)
>>> del_timer() fail, p (=1, nochange)
>>> cur_cmd = list_next(), p++ (=2)
>>> unlock(xhci_lock)
>>>   lock(xhci_lock)
>>>   p-- (=1)
>>>   if (p > 0), exit
>>> OK works
>>>
>>> case 2: normal timeout case with ABORT+STOP, no race.
>>>
>>> cpu1cpu2
>>>
>>> queue_command(first), p++ (=1)
>>> queue_command(more),
>>>   handle_cmd_timeout()
>>>   p-- (P=0), don't exit
>>>   mod_timer(), p++ (P=1)
>>>   write_abort_bit()
>>> handle_cmd_comletion(ABORT)
>>> del_timer(), ok, p-- (p = 0)
>>> handle_cmd_completion(STOP)
>>> del_timer(), fail, (P=0)
>>> handle_stopped_cmd_ring()
>>> cur_cmd = list_next(), p++ (=1)
>>> mod_timer()
>>>
>>> OK, works, and same for just STOP case, with the only difference that
>>> during handle_cmd_completion(STOP) p is decremented (p--)
>>
>> Yes, that's the cases what I want to handle, thanks for your explicit
>> explanation.
>>
> Gave this some more thought over the weekend, and this implementation
> doesn't solve the case when the last command times out and races with the
> completion handler:
>
> cpu1cpu2
>
> queue_command(first), p++ (=1)
> --completion irq fires---- timer times out at same time--
> handle_cmd_completion() handle_cmd_timeout(),)
> lock(xhci_lock )spin_on(xhci_lock)
> del_timer() fail, p (=1, nochange)
> no more commands, P (=1, nochange)
> unlock(xhci_lock)
>  lock(xhci_lock)
>  p-- (=0)
>  p == 0, continue, even if we 
> should
> not.
>For this we still need to rely 
> on
> checking cur_cmd == NULL in the timeout function.
> (Baolus patch sets it to NULL if there are no more commands pending)

[PATCH v2] ipc/sem.c: fix incorrect sem_lock pairing

[Manfred Spraul]

Based on the syzcaller test case from dvyukov:
https://gist.githubusercontent.com/dvyukov/d0e5efefe4d7d6daed829f5c3ca26a40/raw/08d0a261fe3c987bed04fbf267e08ba04bd533ea/gistfile1.txt

The slow (i.e.: failure to acquire) syscall exit from semtimedop()
incorrectly assumed that the the same lock is acquired as it was
at the initial syscall entry.

This is wrong:
- thread A: single semop semop(), sleeps
- thread B: multi semop semop(), sleeps
- thread A: woken up by signal/timeout

With this sequence, the initial sem_lock() call locks the
per-semaphore spinlock, and it is unlocked with sem_unlock().
The call at the syscall return locks the global spinlock.
Because locknum is not updated, the following sem_unlock() call
unlocks the per-semaphore spinlock, which is actually not locked.

The fix is trivial: Use the return value from sem_lock.

Reported-by: dvyu...@google.com
Signed-off-by: Manfred Spraul 
Fixes: 370b262c896e ("ipc/sem: avoid idr tree lookup for interrupted semop")
Cc: d...@stgolabs.net

---

Patch V2:
- subject line updated
- documentation slightly updated

 ipc/sem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index e08b948..3ec5742 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf 
__user *, tsops,
}
 
rcu_read_lock();
-   sem_lock(sma, sops, nsops);
+   locknum = sem_lock(sma, sops, nsops);
 
if (!ipc_valid_object(>sem_perm))
goto out_unlock_free;
-- 
2.7.4

[PATCH v2] ipc/sem.c: fix incorrect sem_lock pairing

[Manfred Spraul]

Based on the syzcaller test case from dvyukov:
https://gist.githubusercontent.com/dvyukov/d0e5efefe4d7d6daed829f5c3ca26a40/raw/08d0a261fe3c987bed04fbf267e08ba04bd533ea/gistfile1.txt

The slow (i.e.: failure to acquire) syscall exit from semtimedop()
incorrectly assumed that the the same lock is acquired as it was
at the initial syscall entry.

This is wrong:
- thread A: single semop semop(), sleeps
- thread B: multi semop semop(), sleeps
- thread A: woken up by signal/timeout

With this sequence, the initial sem_lock() call locks the
per-semaphore spinlock, and it is unlocked with sem_unlock().
The call at the syscall return locks the global spinlock.
Because locknum is not updated, the following sem_unlock() call
unlocks the per-semaphore spinlock, which is actually not locked.

The fix is trivial: Use the return value from sem_lock.

Reported-by: dvyu...@google.com
Signed-off-by: Manfred Spraul 
Fixes: 370b262c896e ("ipc/sem: avoid idr tree lookup for interrupted semop")
Cc: d...@stgolabs.net

---

Patch V2:
- subject line updated
- documentation slightly updated

 ipc/sem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index e08b948..3ec5742 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf 
__user *, tsops,
}
 
rcu_read_lock();
-   sem_lock(sma, sops, nsops);
+   locknum = sem_lock(sma, sops, nsops);
 
if (!ipc_valid_object(>sem_perm))
goto out_unlock_free;
-- 
2.7.4

Re: [PATCH v3 3/5] fs: Wire up SED/Opal to ioctl

[Christoph Hellwig]

> @@ -853,6 +854,7 @@ struct file {
>  #ifdef CONFIG_SECURITY
>   void*f_security;
>  #endif
> + struct sed_context  *f_sedctx;

Adding a new field to the global struct file for a block driver
feature is not acceptable.  And I don't really see why it would
be nessecary anyway.

Re: [PATCH v3 3/5] fs: Wire up SED/Opal to ioctl

[Christoph Hellwig]

> @@ -853,6 +854,7 @@ struct file {
>  #ifdef CONFIG_SECURITY
>   void*f_security;
>  #endif
> + struct sed_context  *f_sedctx;

Adding a new field to the global struct file for a block driver
feature is not acceptable.  And I don't really see why it would
be nessecary anyway.

Re: [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED Allocation code.

[Christoph Hellwig]

> +static int nvme_sec_send(void *ctrl_data, u16 spsp, u8 secp,
> +  void *buf, size_t len)
> +{
> + return nvme_sec_submit(ctrl_data, spsp, secp, buf, len,
> +nvme_admin_security_send);
> +}
> +
> +static int nvme_sec_recv(void *ctrl_data, u16 spsp, u8 secp,
> +  void *buf, size_t len)
> +{
> + return nvme_sec_submit(ctrl_data, spsp, secp, buf, len,
> +nvme_admin_security_recv);
> +}
> +
> +static const struct sec_ops nvme_sec_ops = {
> + .sec_send = nvme_sec_send,
> + .sec_recv = nvme_sec_recv,
> +};

Just make sec_submit the callback passed to the core and avoid
this boiler-plate code.

>  
> +int nvme_opal_initialize(struct nvme_ctrl *ctrl)
> +{
> + /* Opal dev has already been allocated for this controller */
> + if (ctrl->sed_ctx.dev)
> + return 0;
> +
> + ctrl->sed_ctx.dev = alloc_opal_dev(ctrl->admin_q);
> + if (!ctrl->sed_ctx.dev)
> + return -ENOMEM;
> + ctrl->sed_ctx.ops = _sec_ops;
> + ctrl->sed_ctx.sec_data = ctrl;

No need for sec_data callback, just pass the sed_ctx to the driver
and use container_of to get at the containing structure.

Re: [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED Allocation code.

[Christoph Hellwig]

> +static int nvme_sec_send(void *ctrl_data, u16 spsp, u8 secp,
> +  void *buf, size_t len)
> +{
> + return nvme_sec_submit(ctrl_data, spsp, secp, buf, len,
> +nvme_admin_security_send);
> +}
> +
> +static int nvme_sec_recv(void *ctrl_data, u16 spsp, u8 secp,
> +  void *buf, size_t len)
> +{
> + return nvme_sec_submit(ctrl_data, spsp, secp, buf, len,
> +nvme_admin_security_recv);
> +}
> +
> +static const struct sec_ops nvme_sec_ops = {
> + .sec_send = nvme_sec_send,
> + .sec_recv = nvme_sec_recv,
> +};

Just make sec_submit the callback passed to the core and avoid
this boiler-plate code.

>  
> +int nvme_opal_initialize(struct nvme_ctrl *ctrl)
> +{
> + /* Opal dev has already been allocated for this controller */
> + if (ctrl->sed_ctx.dev)
> + return 0;
> +
> + ctrl->sed_ctx.dev = alloc_opal_dev(ctrl->admin_q);
> + if (!ctrl->sed_ctx.dev)
> + return -ENOMEM;
> + ctrl->sed_ctx.ops = _sec_ops;
> + ctrl->sed_ctx.sec_data = ctrl;

No need for sec_data callback, just pass the sed_ctx to the driver
and use container_of to get at the containing structure.

Re: [tpmdd-devel] [PATCH] tpm, tpm_crb: Handle 64-bit resource in crb_check_resource()

[Jiandi An]

On 12/19/16 07:56, Jarkko Sakkinen wrote:
> On Sun, Dec 18, 2016 at 10:20:53PM -0600, Jiandi An wrote:
>> crb_check_resource() in TPM CRB driver calls
>> acpi_dev_resource_memory() which only handles 32-bit resources.
>> Adding a call to acpi_dev_resource_address_space() in TPM CRB
>> driver which handles 64-bit resources.
>>
>> Signed-off-by: Jiandi An 
> 
> 1. Is there a platform in existence where this change fixes a problem?
> 2. What is difference between "memory" and "address space" conceptually?
>Just wondering why 32-bit stuff is "memory" and 64-bit stuff is
>"address space". Could there be a one function that would work both
>for 32-bit and 64-bit cases?
>
> Yeah, I do not know this API too well. That's why I'm asking.
> 
> /Jarkko
> 
> 
> If this is the right thing it also needs to be done in tpm_tis.
> 
> I will point out that this driver only works with memory, so using a
> generic decoder without checking for IO maps may not be correct..
> 
> Jason
> 

Hi Jarkko and Jason,

Thanks for your comments.
I am a developer at Qualcomm and we are trying to enable TPM CRB driver
on ARM64 for Qualcomm Centriq 2400.  Spec changes to ACPI table for TPM 2.0
have been submitted and approved by TCG and are currently in the 60 day waiting
period for release.  I have a series of patches that do this TPM CRB driver
enablement for ARM64 that I'll be submitting.

But first, for our platform the control area buffer address is greater than 
32-bit.
It is memory with no IO effects.  I ran into this issue first when I use
QWordMemory in ACPI ASL to describe the resource.  MemoryRangeType is specified 
as
AddressRangeMemory. 

The QWordMemory macro evaluates to a buffer which contains a 64-bit memory
resource descriptor, which describes a range of memory addresses.  It is
a QWord Address Space Descriptor.  acpi_dev_resource_address_space()
handles the 64-bit memory described using QWordMemory macro in ACPI ASL.

The Memory32Fixed macro evaluates to a buffer which contains a 32-bit memory
descriptor, which describes a fixed range of memory addresses.
acpi_dev_resource_memory() handles the 32-bit memory described using 
Memory32Fixed
in ACPI ASL.

I did not see a specific acpi_dev_resource_ service that handles 64-bit resource
address and doesn't use the generic acpi_decode_space() decoder.

I do have a question about having to specify _CRS method in ACPI ASL.
When I was doing early prototyping for this enablement work on ARM64 back
during the time with 4.5 kernel, it was before the introduction of the following
two patches:
commit 1bd047be37d95bf65a219f4931215f71878ac060
tpm_crb: Use devm_ioremap_resource
commit 51dd43dff74b0547ad844638f6910ca29c956819
tpm_tis: Use devm_ioremap_resource

The control area buffer is specified in the TPM2.0 static ACPI table.  TPM
CRB driver maps the control area address and reads out cmd and rsp buffer
addresses and maps them.  There is no requirement in the TCG TPM ACPI spec
for specifying _CRS to describe the control area buffer.  When I rebased
the early prototype for CRB driver ARM64 enablement to the latest kernel,
I hit this issue where I have to specify _CRS method.  So in _CRS method
I specify the same control area address that's in the TPM2.0 static ACPI table.

I see the _CRS requirement in the CRB driver is for resource synchronization
between the TIS and CRB drivers to support force mode in TIS. Could I get some
background on that so I could be more careful not breaking TIS while making
changes to CRB driver for ARM64 enablement?

Thanks in advance.

>> ---
>>  drivers/char/tpm/tpm_crb.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
>> index 717b6b4..86f355b 100644
>> --- a/drivers/char/tpm/tpm_crb.c
>> +++ b/drivers/char/tpm/tpm_crb.c
>> @@ -264,10 +264,12 @@ static bool crb_req_canceled(struct tpm_chip *chip, u8 
>> status)
>>  static int crb_check_resource(struct acpi_resource *ares, void *data)
>>  {
>>  struct resource *io_res = data;
>> -struct resource res;
>> +struct resource_win win;
>> +struct resource *res = &(win.res);
>>  
>> -if (acpi_dev_resource_memory(ares, )) {
>> -*io_res = res;
>> +if (acpi_dev_resource_memory(ares, res) ||
>> +acpi_dev_resource_address_space(ares, )) {
>> +*io_res = *res;
>>  io_res->name = NULL;
>>  }
>>  
>> -- 
>> Jiandi An
>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
>> Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
>> Foundation Collaborative Project.
>>
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> tpmdd-devel mailing list
> 

Re: [tpmdd-devel] [PATCH] tpm, tpm_crb: Handle 64-bit resource in crb_check_resource()

[Jiandi An]

On 12/19/16 07:56, Jarkko Sakkinen wrote:
> On Sun, Dec 18, 2016 at 10:20:53PM -0600, Jiandi An wrote:
>> crb_check_resource() in TPM CRB driver calls
>> acpi_dev_resource_memory() which only handles 32-bit resources.
>> Adding a call to acpi_dev_resource_address_space() in TPM CRB
>> driver which handles 64-bit resources.
>>
>> Signed-off-by: Jiandi An 
> 
> 1. Is there a platform in existence where this change fixes a problem?
> 2. What is difference between "memory" and "address space" conceptually?
>Just wondering why 32-bit stuff is "memory" and 64-bit stuff is
>"address space". Could there be a one function that would work both
>for 32-bit and 64-bit cases?
>
> Yeah, I do not know this API too well. That's why I'm asking.
> 
> /Jarkko
> 
> 
> If this is the right thing it also needs to be done in tpm_tis.
> 
> I will point out that this driver only works with memory, so using a
> generic decoder without checking for IO maps may not be correct..
> 
> Jason
> 

Hi Jarkko and Jason,

Thanks for your comments.
I am a developer at Qualcomm and we are trying to enable TPM CRB driver
on ARM64 for Qualcomm Centriq 2400.  Spec changes to ACPI table for TPM 2.0
have been submitted and approved by TCG and are currently in the 60 day waiting
period for release.  I have a series of patches that do this TPM CRB driver
enablement for ARM64 that I'll be submitting.

But first, for our platform the control area buffer address is greater than 
32-bit.
It is memory with no IO effects.  I ran into this issue first when I use
QWordMemory in ACPI ASL to describe the resource.  MemoryRangeType is specified 
as
AddressRangeMemory. 

The QWordMemory macro evaluates to a buffer which contains a 64-bit memory
resource descriptor, which describes a range of memory addresses.  It is
a QWord Address Space Descriptor.  acpi_dev_resource_address_space()
handles the 64-bit memory described using QWordMemory macro in ACPI ASL.

The Memory32Fixed macro evaluates to a buffer which contains a 32-bit memory
descriptor, which describes a fixed range of memory addresses.
acpi_dev_resource_memory() handles the 32-bit memory described using 
Memory32Fixed
in ACPI ASL.

I did not see a specific acpi_dev_resource_ service that handles 64-bit resource
address and doesn't use the generic acpi_decode_space() decoder.

I do have a question about having to specify _CRS method in ACPI ASL.
When I was doing early prototyping for this enablement work on ARM64 back
during the time with 4.5 kernel, it was before the introduction of the following
two patches:
commit 1bd047be37d95bf65a219f4931215f71878ac060
tpm_crb: Use devm_ioremap_resource
commit 51dd43dff74b0547ad844638f6910ca29c956819
tpm_tis: Use devm_ioremap_resource

The control area buffer is specified in the TPM2.0 static ACPI table.  TPM
CRB driver maps the control area address and reads out cmd and rsp buffer
addresses and maps them.  There is no requirement in the TCG TPM ACPI spec
for specifying _CRS to describe the control area buffer.  When I rebased
the early prototype for CRB driver ARM64 enablement to the latest kernel,
I hit this issue where I have to specify _CRS method.  So in _CRS method
I specify the same control area address that's in the TPM2.0 static ACPI table.

I see the _CRS requirement in the CRB driver is for resource synchronization
between the TIS and CRB drivers to support force mode in TIS. Could I get some
background on that so I could be more careful not breaking TIS while making
changes to CRB driver for ARM64 enablement?

Thanks in advance.

>> ---
>>  drivers/char/tpm/tpm_crb.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
>> index 717b6b4..86f355b 100644
>> --- a/drivers/char/tpm/tpm_crb.c
>> +++ b/drivers/char/tpm/tpm_crb.c
>> @@ -264,10 +264,12 @@ static bool crb_req_canceled(struct tpm_chip *chip, u8 
>> status)
>>  static int crb_check_resource(struct acpi_resource *ares, void *data)
>>  {
>>  struct resource *io_res = data;
>> -struct resource res;
>> +struct resource_win win;
>> +struct resource *res = &(win.res);
>>  
>> -if (acpi_dev_resource_memory(ares, )) {
>> -*io_res = res;
>> +if (acpi_dev_resource_memory(ares, res) ||
>> +acpi_dev_resource_address_space(ares, )) {
>> +*io_res = *res;
>>  io_res->name = NULL;
>>  }
>>  
>> -- 
>> Jiandi An
>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
>> Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
>> Foundation Collaborative Project.
>>
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> tpmdd-devel mailing list
> tpmdd-de...@lists.sourceforge.net
> 

Re: [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED Allocation code.

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 03:23:12PM -0700, Scott Bauer wrote:
> I went back and reviewed the spec 1.2.1:
> 
> http://www.nvmexpress.org/wp-content/uploads/NVM_Express_1_2_1_Gold_20160603.pdf
> Section 5.18 (page 140->141)
> 
> Describes the security send command type and it doesn't have any reference of
> a namespace ID. Anecdotally, I just removed the ns->ns_id line from the code 
> and
> everything still works as intended. Is there another portion of the spec or 
> errata
> that requires ns_id? (I can't access 1.2.1 errta the link doesn't work).

As far as I can tell Security Send / Receive has always been intended to
apply to the whole controller, even if that's something I would not
personally think is a good idea.

Re: [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED Allocation code.

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 03:23:12PM -0700, Scott Bauer wrote:
> I went back and reviewed the spec 1.2.1:
> 
> http://www.nvmexpress.org/wp-content/uploads/NVM_Express_1_2_1_Gold_20160603.pdf
> Section 5.18 (page 140->141)
> 
> Describes the security send command type and it doesn't have any reference of
> a namespace ID. Anecdotally, I just removed the ns->ns_id line from the code 
> and
> everything still works as intended. Is there another portion of the spec or 
> errata
> that requires ns_id? (I can't access 1.2.1 errta the link doesn't work).

As far as I can tell Security Send / Receive has always been intended to
apply to the whole controller, even if that's something I would not
personally think is a good idea.

Re: [PATCH v3 2/5] lib: Add Sed-opal library

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 04:34:15PM -0500, Keith Busch wrote:
> This seems like an optional library that some environments may wish to
> opt-out of building into the kernel. Any reason not to add an entry into
> the Kconfig to turn this on/off?

This needs to be a CONFIG_BLOCK_SED / CONFIG_BLOCK_SED_OPAL and
should move to block/.

Re: [PATCH v3 2/5] lib: Add Sed-opal library

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 04:34:15PM -0500, Keith Busch wrote:
> This seems like an optional library that some environments may wish to
> opt-out of building into the kernel. Any reason not to add an entry into
> the Kconfig to turn this on/off?

This needs to be a CONFIG_BLOCK_SED / CONFIG_BLOCK_SED_OPAL and
should move to block/.

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Baolin Wang]

Hi,

On 20 December 2016 at 12:29, Lu Baolu  wrote:
> Hi Mathias,
>
> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
>> On 19.12.2016 13:34, Baolin Wang wrote:
>>> Hi Mathias,
>>>
>>> On 19 December 2016 at 18:33, Mathias Nyman
>>>  wrote:
 On 13.12.2016 05:21, Baolin Wang wrote:
>
> Hi Mathias,
>
> On 12 December 2016 at 23:52, Mathias Nyman
>  wrote:
>>
>> On 05.12.2016 09:51, Baolin Wang wrote:
>>>
>>>
>>> If a command event is found on the event ring during an interrupt,
>>> we need to stop the command timer with del_timer(). Since del_timer()
>>> can fail if the timer is running and waiting on the xHCI lock, then
>>> it maybe get the wrong timeout command in xhci_handle_command_timeout()
>>> if host fetched a new command and updated the xhci->current_cmd in
>>> handle_cmd_completion(). For this situation, we need a way to signal
>>> to the command timer that everything is fine and it should exit.
>>
>>
>>
>> Ah, right, this could actually happen.
>>
>>>
>>>
>>> We should introduce a counter (xhci->current_cmd_pending) for the number
>>> of pending commands. If we need to cancel the command timer and
>>> del_timer()
>>> succeeds, we decrement the number of pending commands. If del_timer()
>>> fails,
>>> we leave the number of pending commands alone.
>>>
>>> For handling timeout command, in xhci_handle_command_timeout() we will
>>> check
>>> the counter after decrementing it, if the counter
>>> (xhci->current_cmd_pending)
>>> is 0, which means xhci->current_cmd is the right timeout command. If the
>>> counter (xhci->current_cmd_pending) is greater than 0, which means
>>> current
>>> timeout command has been handled by host and host has fetched new
>>> command
>>> as
>>> xhci->current_cmd, then just return and wait for new current command.
>>
>>
>>
>> A counter like this could work.
>>
>> Writing the abort bit can generate either ABORT+STOP, or just STOP
>> event, this seems to cover both.
>>
>> quick check, case 1: timeout and cmd completion at the same time.
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> queue_command(more),
>> --completion irq fires---- timer times out at same time--
>> handle_cmd_completion() handle_cmd_timeout(),)
>> lock(xhci_lock  )   spin_on(xhci_lock)
>> del_timer() fail, p (=1, nochange)
>> cur_cmd = list_next(), p++ (=2)
>> unlock(xhci_lock)
>>   lock(xhci_lock)
>>   p-- (=1)
>>   if (p > 0), exit
>> OK works
>>
>> case 2: normal timeout case with ABORT+STOP, no race.
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> queue_command(more),
>>   handle_cmd_timeout()
>>   p-- (P=0), don't exit
>>   mod_timer(), p++ (P=1)
>>   write_abort_bit()
>> handle_cmd_comletion(ABORT)
>> del_timer(), ok, p-- (p = 0)
>> handle_cmd_completion(STOP)
>> del_timer(), fail, (P=0)
>> handle_stopped_cmd_ring()
>> cur_cmd = list_next(), p++ (=1)
>> mod_timer()
>>
>> OK, works, and same for just STOP case, with the only difference that
>> during handle_cmd_completion(STOP) p is decremented (p--)
>
>
> Yes, that's the cases what I want to handle, thanks for your explicit
> explanation.
>

 Gave this some more thought over the weekend, and this implementation
 doesn't solve the case when the last command times out and races with the
 completion handler:

 cpu1cpu2

 queue_command(first), p++ (=1)
 --completion irq fires---- timer times out at same time--
 handle_cmd_completion() handle_cmd_timeout(),)
 lock(xhci_lock )spin_on(xhci_lock)
 del_timer() fail, p (=1, nochange)
 no more commands, P (=1, nochange)
 unlock(xhci_lock)
  lock(xhci_lock)
  p-- (=0)
  p == 0, continue, even if we 
 should
 not.
For this we still need to rely 
 on
 checking cur_cmd == NULL in the timeout function.
 (Baolus patch sets it to NULL if there are no more commands pending)
>>>
>>> As I pointed out in patch 1 of this patchset, 

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Baolin Wang]

Hi,

On 20 December 2016 at 12:29, Lu Baolu  wrote:
> Hi Mathias,
>
> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
>> On 19.12.2016 13:34, Baolin Wang wrote:
>>> Hi Mathias,
>>>
>>> On 19 December 2016 at 18:33, Mathias Nyman
>>>  wrote:
 On 13.12.2016 05:21, Baolin Wang wrote:
>
> Hi Mathias,
>
> On 12 December 2016 at 23:52, Mathias Nyman
>  wrote:
>>
>> On 05.12.2016 09:51, Baolin Wang wrote:
>>>
>>>
>>> If a command event is found on the event ring during an interrupt,
>>> we need to stop the command timer with del_timer(). Since del_timer()
>>> can fail if the timer is running and waiting on the xHCI lock, then
>>> it maybe get the wrong timeout command in xhci_handle_command_timeout()
>>> if host fetched a new command and updated the xhci->current_cmd in
>>> handle_cmd_completion(). For this situation, we need a way to signal
>>> to the command timer that everything is fine and it should exit.
>>
>>
>>
>> Ah, right, this could actually happen.
>>
>>>
>>>
>>> We should introduce a counter (xhci->current_cmd_pending) for the number
>>> of pending commands. If we need to cancel the command timer and
>>> del_timer()
>>> succeeds, we decrement the number of pending commands. If del_timer()
>>> fails,
>>> we leave the number of pending commands alone.
>>>
>>> For handling timeout command, in xhci_handle_command_timeout() we will
>>> check
>>> the counter after decrementing it, if the counter
>>> (xhci->current_cmd_pending)
>>> is 0, which means xhci->current_cmd is the right timeout command. If the
>>> counter (xhci->current_cmd_pending) is greater than 0, which means
>>> current
>>> timeout command has been handled by host and host has fetched new
>>> command
>>> as
>>> xhci->current_cmd, then just return and wait for new current command.
>>
>>
>>
>> A counter like this could work.
>>
>> Writing the abort bit can generate either ABORT+STOP, or just STOP
>> event, this seems to cover both.
>>
>> quick check, case 1: timeout and cmd completion at the same time.
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> queue_command(more),
>> --completion irq fires---- timer times out at same time--
>> handle_cmd_completion() handle_cmd_timeout(),)
>> lock(xhci_lock  )   spin_on(xhci_lock)
>> del_timer() fail, p (=1, nochange)
>> cur_cmd = list_next(), p++ (=2)
>> unlock(xhci_lock)
>>   lock(xhci_lock)
>>   p-- (=1)
>>   if (p > 0), exit
>> OK works
>>
>> case 2: normal timeout case with ABORT+STOP, no race.
>>
>> cpu1cpu2
>>
>> queue_command(first), p++ (=1)
>> queue_command(more),
>>   handle_cmd_timeout()
>>   p-- (P=0), don't exit
>>   mod_timer(), p++ (P=1)
>>   write_abort_bit()
>> handle_cmd_comletion(ABORT)
>> del_timer(), ok, p-- (p = 0)
>> handle_cmd_completion(STOP)
>> del_timer(), fail, (P=0)
>> handle_stopped_cmd_ring()
>> cur_cmd = list_next(), p++ (=1)
>> mod_timer()
>>
>> OK, works, and same for just STOP case, with the only difference that
>> during handle_cmd_completion(STOP) p is decremented (p--)
>
>
> Yes, that's the cases what I want to handle, thanks for your explicit
> explanation.
>

 Gave this some more thought over the weekend, and this implementation
 doesn't solve the case when the last command times out and races with the
 completion handler:

 cpu1cpu2

 queue_command(first), p++ (=1)
 --completion irq fires---- timer times out at same time--
 handle_cmd_completion() handle_cmd_timeout(),)
 lock(xhci_lock )spin_on(xhci_lock)
 del_timer() fail, p (=1, nochange)
 no more commands, P (=1, nochange)
 unlock(xhci_lock)
  lock(xhci_lock)
  p-- (=0)
  p == 0, continue, even if we 
 should
 not.
For this we still need to rely 
 on
 checking cur_cmd == NULL in the timeout function.
 (Baolus patch sets it to NULL if there are no more commands pending)
>>>
>>> As I pointed out in patch 1 of this patchset, this patchset is based
>>> on Lu Baolu's new fix patch:
>>> usb: xhci: fix possible wild 

BQ27xxx registers

[Chris Lapa]

Hi,

I'm testing out the 4.9 kernel on a AM3359 board fitted with a 
BQ27510-G3 fuel gauge. The board previously worked on the 4.1 kernel, 
however on the 4.9 kernel the bq27xxx_battery.c driver is spitting out 
this error continuously:


power_supply bq27510-0: driver failed to report `charge_full_design' 
property: -121


I have narrowed down the problem to commit 099867a16 where the 
BQ27XXX_REG_DCAP value was changed from 0x2e to 0x3c.


I can generate a patch to fix this issue, however the bigger problem 
exists as to which revision fuel gauge the bq27xxx_battery.c driver is 
intended to support for each family.


Attached is a table I put together of all the register addresses for 
each supported device under the BQ27500 definition and what the current 
driver utilizes (I didn't paste it here as the word wrapping messes with 
the formatting).


There isn't really an ideal solution I can see where we keep the single 
BQ27500 definition and support all the functionality of each revision.


We can try and just support the latest revisions (BQ27510-G3 and 
BQ27520-G4) but I think it could hurt backwards compatibility for 
existing hardware.


I'm happy to work on a fix but just wanted to get some thoughts before 
proceeding.


Cheers,
Chris
RegisterBQ27500/1   BQ27510-G1  BQ27510-G2  
BQ27510-G3  BQ27520-G1  BQ27520-G2  BQ27520-G3  BQ27520-G4  
bq27xxx_battery.c
BQ27XXX_REG_CTRL0x000x000x000x00
0x000x000x000x000x00
BQ27XXX_REG_TEMP0x060x060x060x06
0x060x060x060x060x06
BQ27XXX_REG_INT_TEMP—   -   -   0x28
-   0x360x360x280x28
BQ27XXX_REG_VOLT0x080x080x080x08
0x080x080x080x080x08
BQ27XXX_REG_AI  0x140x140x140x14
0x140x140x140x140x14
BQ27XXX_REG_FLAGS   0x0a0x0a0x0a0x0a
0x0a0x0a0x0a0x0a0x0a
BQ27XXX_REG_TTE 0x160x160x160x16
0x160x160x160x160x16
BQ27XXX_REG_TTF 0x180x180x18—   
0x180x18-   -   -
BQ27XXX_REG_TTES0x1c0x1c0x1c0x1a
0x1c0x1c0x1c0x1a0x1a
BQ27XXX_REG_TTECP   0x260x260x26-   
0x260x260x26-   -
BQ27XXX_REG_NAC 0x0c0x0c0x0c0x0c
0x0c0x0c0x0c0x0c0x0c
BQ27XXX_REG_FCC 0x120x120x120x12
0x120x120x120x120x12
BQ27XXX_REG_CYCT0x2a0x2a0x2a0x1e
-   0x2a0x2a0x1e0x2a
BQ27XXX_REG_AE  0x220x220x22-   
0x220x220x22-   -
BQ27XXX_REG_SOC 0x2c0x2c0x2c0x20
0x2c0x2c0x2c0x200x2c
BQ27XXX_REG_DCAP0x3c0x3c0x3c0x2e
0x3c0x3c0x3c-   0x3c
BQ27XXX_REG_AP  0x240x240x24-   
0x240x240x24-   -

BQ27xxx registers

[Chris Lapa]

Hi,

I'm testing out the 4.9 kernel on a AM3359 board fitted with a 
BQ27510-G3 fuel gauge. The board previously worked on the 4.1 kernel, 
however on the 4.9 kernel the bq27xxx_battery.c driver is spitting out 
this error continuously:


power_supply bq27510-0: driver failed to report `charge_full_design' 
property: -121


I have narrowed down the problem to commit 099867a16 where the 
BQ27XXX_REG_DCAP value was changed from 0x2e to 0x3c.


I can generate a patch to fix this issue, however the bigger problem 
exists as to which revision fuel gauge the bq27xxx_battery.c driver is 
intended to support for each family.


Attached is a table I put together of all the register addresses for 
each supported device under the BQ27500 definition and what the current 
driver utilizes (I didn't paste it here as the word wrapping messes with 
the formatting).


There isn't really an ideal solution I can see where we keep the single 
BQ27500 definition and support all the functionality of each revision.


We can try and just support the latest revisions (BQ27510-G3 and 
BQ27520-G4) but I think it could hurt backwards compatibility for 
existing hardware.


I'm happy to work on a fix but just wanted to get some thoughts before 
proceeding.


Cheers,
Chris
RegisterBQ27500/1   BQ27510-G1  BQ27510-G2  
BQ27510-G3  BQ27520-G1  BQ27520-G2  BQ27520-G3  BQ27520-G4  
bq27xxx_battery.c
BQ27XXX_REG_CTRL0x000x000x000x00
0x000x000x000x000x00
BQ27XXX_REG_TEMP0x060x060x060x06
0x060x060x060x060x06
BQ27XXX_REG_INT_TEMP—   -   -   0x28
-   0x360x360x280x28
BQ27XXX_REG_VOLT0x080x080x080x08
0x080x080x080x080x08
BQ27XXX_REG_AI  0x140x140x140x14
0x140x140x140x140x14
BQ27XXX_REG_FLAGS   0x0a0x0a0x0a0x0a
0x0a0x0a0x0a0x0a0x0a
BQ27XXX_REG_TTE 0x160x160x160x16
0x160x160x160x160x16
BQ27XXX_REG_TTF 0x180x180x18—   
0x180x18-   -   -
BQ27XXX_REG_TTES0x1c0x1c0x1c0x1a
0x1c0x1c0x1c0x1a0x1a
BQ27XXX_REG_TTECP   0x260x260x26-   
0x260x260x26-   -
BQ27XXX_REG_NAC 0x0c0x0c0x0c0x0c
0x0c0x0c0x0c0x0c0x0c
BQ27XXX_REG_FCC 0x120x120x120x12
0x120x120x120x120x12
BQ27XXX_REG_CYCT0x2a0x2a0x2a0x1e
-   0x2a0x2a0x1e0x2a
BQ27XXX_REG_AE  0x220x220x22-   
0x220x220x22-   -
BQ27XXX_REG_SOC 0x2c0x2c0x2c0x20
0x2c0x2c0x2c0x200x2c
BQ27XXX_REG_DCAP0x3c0x3c0x3c0x2e
0x3c0x3c0x3c-   0x3c
BQ27XXX_REG_AP  0x240x240x24-   
0x240x240x24-   -

[PATCH v2 2/2] usb: host: xhci: Handle the right timeout command

[Baolin Wang]

If a command event is found on the event ring during an interrupt,
we need to stop the command timer with del_timer(). Since del_timer()
can fail if the timer is running and waiting on the xHCI lock, then
it maybe get the wrong timeout command in xhci_handle_command_timeout()
if host fetched a new command and updated the xhci->current_cmd in
handle_cmd_completion(). For this situation, we need a way to signal
to the command timer that everything is fine and it should exit.

We should check if the command timer is pending in xhci_handle_command_timeout()
function, if the command timer is pending, which means current timeout
command has been handled by host and host has fetched new command and
re-added the command timer, then just return and wait for new current
command. If not, it means current command is timeout and need to be
handled.

Signed-off-by: Baolin Wang 
---
Changes since v1:
 - Remove the counter and just check if the command timer is pending.
---
 drivers/usb/host/xhci-ring.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 9965a4c..3947344 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1269,7 +1269,7 @@ void xhci_handle_command_timeout(unsigned long data)
xhci = (struct xhci_hcd *) data;
 
spin_lock_irqsave(>lock, flags);
-   if (!xhci->current_cmd) {
+   if (!xhci->current_cmd || timer_pending(>cmd_timer)) {
spin_unlock_irqrestore(>lock, flags);
return;
}
-- 
1.7.9.5

[PATCH v2 2/2] usb: host: xhci: Handle the right timeout command

[Baolin Wang]

If a command event is found on the event ring during an interrupt,
we need to stop the command timer with del_timer(). Since del_timer()
can fail if the timer is running and waiting on the xHCI lock, then
it maybe get the wrong timeout command in xhci_handle_command_timeout()
if host fetched a new command and updated the xhci->current_cmd in
handle_cmd_completion(). For this situation, we need a way to signal
to the command timer that everything is fine and it should exit.

We should check if the command timer is pending in xhci_handle_command_timeout()
function, if the command timer is pending, which means current timeout
command has been handled by host and host has fetched new command and
re-added the command timer, then just return and wait for new current
command. If not, it means current command is timeout and need to be
handled.

Signed-off-by: Baolin Wang 
---
Changes since v1:
 - Remove the counter and just check if the command timer is pending.
---
 drivers/usb/host/xhci-ring.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 9965a4c..3947344 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1269,7 +1269,7 @@ void xhci_handle_command_timeout(unsigned long data)
xhci = (struct xhci_hcd *) data;
 
spin_lock_irqsave(>lock, flags);
-   if (!xhci->current_cmd) {
+   if (!xhci->current_cmd || timer_pending(>cmd_timer)) {
spin_unlock_irqrestore(>lock, flags);
return;
}
-- 
1.7.9.5

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

[Boqun Feng]

On Mon, Dec 19, 2016 at 09:09:13PM -0800, Paul E. McKenney wrote:
> On Mon, Dec 19, 2016 at 11:15:15PM +0800, Boqun Feng wrote:
> > On Thu, Dec 15, 2016 at 02:51:36PM +, Colin Ian King wrote:
> > > On 15/12/16 14:42, Boqun Feng wrote:
> > > > On Thu, Dec 15, 2016 at 12:04:59PM +, Mark Rutland wrote:
> > > >> On Thu, Dec 15, 2016 at 10:42:03AM +0800, Boqun Feng wrote:
> > > >>> ->qsmask of an RCU leaf node is usually more sparse than the
> > > >>> corresponding cpu_possible_mask. So replace the
> > > >>> for_each_leaf_node_possible_cpu() in force_qs_rnp() with
> > > >>> for_each_leaf_node_cpu() to save several checks.
> > > >>>
> > > >>> [Note we need to use "1UL << bit" instead of "1 << bit" to generate 
> > > >>> the
> > > >>> corresponding mask for a bit because @mask is unsigned long, this was
> > > >>> spotted by Colin Ian King  and CoverityScan 
> > > >>> in
> > > >>> a previous version of this patch.]
> > > >>
> > > >> Nit: This note can go now that we use leaf_node_cpu_bit(). ;)
> > > >>
> > > > 
> > > > I kinda keep this here for honoring the effort of finding out this bug
> > > > from Colin, but yes, it's no longer needed here for the current code.
> > > 
> > > Yep, remove it.
> > > 
> > 
> > Paul, here is a modified version of this patch, what I only did is
> > removing this note.
> > 
> > Besides I rebased the whole series on the current rcu/dev branch of -rcu
> > tree, on this very commit:
> > 
> > 8e9b2521b18a ("doc: Quick-Quiz answers are now inline")
> > 
> > And I put the latest version at
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/boqun/linux.git leaf-node
> > 
> > If you thought it's better, I could send a v3 ;-)
> 
> I would feel better about this patchset if it reduced the number of lines
> of code rather than increasing them.  That said, part of the increase
> is a commment.  Still, I am not convinced that the extra level of macro
> is carrying its weight.
> 
> dbf18a2422e2 ("rcu: Introduce for_each_leaf_node_cpu()")
> 
>   The commit log needs a bit of wordsmithing.
> 
>   The added WARN_ON_ONCE(!cpu_possible(cpu)) still seems strange.
>   What is its purpose, really?  What does its triggering tell you?
>   What other checks did you consider as an alternative?
> 

The check is an over-case one, it's introduced because I'm worried about
some code outside the RCU code mis-sets the ->qsmask* or ->expmask* on
an "impossible" CPU. I will explanation later in more details.

>   And if you are going to add checks of this type, should you
>   also check for this being a leaf rcu_node structure?
> 

I don't think I want to check that, and I don't think check
cpu_possible(cpu) in the macro is similar to that.

> 3f0b4ba1fe94 ("rcu: Use for_each_leaf_node_cpu() in RCU stall checking")
> 
>   This does look a bit nicer, but why the added blank lines?
>   Are they really helping?
> 
>   The commit log seems a bit misplaced.  This code is almost never
>   executed (once per 21 seconds at the most), so performance really
>   isn't a consideration.  The simpler-looking code might be.
> 
> fd799f1ac7b7 ("rcu: Use for_each_leaf_node_cpu() in ->expmask iteration")
> 
>   Ditto on blank lines.
> 
>   Again, this code is executed per expedited grace period, so
>   performance really isn't a big deal.  More of a big deal than
>   the stall-warning code, but we still are way off of any fastpath.
> 
> 69a1baedbf42 ("rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()")
> 
>   Ditto again on blank lines.
> 
>   And on the commit log.  This code is executed about once
>   per several jiffies, and on larger machines, per 20 jiffies
>   or so.  Performance really isn't a consideration.
> 
> 7b00e50e3efb ("rcu: Use for_each_leaf_node_cpu() in online CPU iteration")
> 
>   And another ditto on blank lines.
> 
>   This code executes once per CPU-hotplug operation, so again isn't
>   at all performance critical.
> 
> In short, if you are trying to sell this to me as a significant performance
> boost, I am not buying.  The added WARN_ON_ONCE() looks quite dubious,

Yep, it won't help the performance a lot, but it 

1)  helps the performance in theory, because it iterates less CPUs

2)  makes code cleaner. By "cleaner", I mean we can a) affort more
blank lines to make loops separated from other code and b)
descrease the indent levels for those loops. But, yes I should
add those points in the commit log, because those are more
visible effects.

> though perhaps I am misunderstanding its purpose.  My assumption is
> that you want to detect missing UL suffixes on bitmask constants, in
> which case I bet there is a better way.
> 

The WARN_ON_ONCE() is not for detecting missing UL suffixes on bitmask
constatns, and we don't need to check that, because we use
leaf_node_cpu_id() now. As I said, this is an over-case check, and we
can drop if we 

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

[Boqun Feng]

On Mon, Dec 19, 2016 at 09:09:13PM -0800, Paul E. McKenney wrote:
> On Mon, Dec 19, 2016 at 11:15:15PM +0800, Boqun Feng wrote:
> > On Thu, Dec 15, 2016 at 02:51:36PM +, Colin Ian King wrote:
> > > On 15/12/16 14:42, Boqun Feng wrote:
> > > > On Thu, Dec 15, 2016 at 12:04:59PM +, Mark Rutland wrote:
> > > >> On Thu, Dec 15, 2016 at 10:42:03AM +0800, Boqun Feng wrote:
> > > >>> ->qsmask of an RCU leaf node is usually more sparse than the
> > > >>> corresponding cpu_possible_mask. So replace the
> > > >>> for_each_leaf_node_possible_cpu() in force_qs_rnp() with
> > > >>> for_each_leaf_node_cpu() to save several checks.
> > > >>>
> > > >>> [Note we need to use "1UL << bit" instead of "1 << bit" to generate 
> > > >>> the
> > > >>> corresponding mask for a bit because @mask is unsigned long, this was
> > > >>> spotted by Colin Ian King  and CoverityScan 
> > > >>> in
> > > >>> a previous version of this patch.]
> > > >>
> > > >> Nit: This note can go now that we use leaf_node_cpu_bit(). ;)
> > > >>
> > > > 
> > > > I kinda keep this here for honoring the effort of finding out this bug
> > > > from Colin, but yes, it's no longer needed here for the current code.
> > > 
> > > Yep, remove it.
> > > 
> > 
> > Paul, here is a modified version of this patch, what I only did is
> > removing this note.
> > 
> > Besides I rebased the whole series on the current rcu/dev branch of -rcu
> > tree, on this very commit:
> > 
> > 8e9b2521b18a ("doc: Quick-Quiz answers are now inline")
> > 
> > And I put the latest version at
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/boqun/linux.git leaf-node
> > 
> > If you thought it's better, I could send a v3 ;-)
> 
> I would feel better about this patchset if it reduced the number of lines
> of code rather than increasing them.  That said, part of the increase
> is a commment.  Still, I am not convinced that the extra level of macro
> is carrying its weight.
> 
> dbf18a2422e2 ("rcu: Introduce for_each_leaf_node_cpu()")
> 
>   The commit log needs a bit of wordsmithing.
> 
>   The added WARN_ON_ONCE(!cpu_possible(cpu)) still seems strange.
>   What is its purpose, really?  What does its triggering tell you?
>   What other checks did you consider as an alternative?
> 

The check is an over-case one, it's introduced because I'm worried about
some code outside the RCU code mis-sets the ->qsmask* or ->expmask* on
an "impossible" CPU. I will explanation later in more details.

>   And if you are going to add checks of this type, should you
>   also check for this being a leaf rcu_node structure?
> 

I don't think I want to check that, and I don't think check
cpu_possible(cpu) in the macro is similar to that.

> 3f0b4ba1fe94 ("rcu: Use for_each_leaf_node_cpu() in RCU stall checking")
> 
>   This does look a bit nicer, but why the added blank lines?
>   Are they really helping?
> 
>   The commit log seems a bit misplaced.  This code is almost never
>   executed (once per 21 seconds at the most), so performance really
>   isn't a consideration.  The simpler-looking code might be.
> 
> fd799f1ac7b7 ("rcu: Use for_each_leaf_node_cpu() in ->expmask iteration")
> 
>   Ditto on blank lines.
> 
>   Again, this code is executed per expedited grace period, so
>   performance really isn't a big deal.  More of a big deal than
>   the stall-warning code, but we still are way off of any fastpath.
> 
> 69a1baedbf42 ("rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()")
> 
>   Ditto again on blank lines.
> 
>   And on the commit log.  This code is executed about once
>   per several jiffies, and on larger machines, per 20 jiffies
>   or so.  Performance really isn't a consideration.
> 
> 7b00e50e3efb ("rcu: Use for_each_leaf_node_cpu() in online CPU iteration")
> 
>   And another ditto on blank lines.
> 
>   This code executes once per CPU-hotplug operation, so again isn't
>   at all performance critical.
> 
> In short, if you are trying to sell this to me as a significant performance
> boost, I am not buying.  The added WARN_ON_ONCE() looks quite dubious,

Yep, it won't help the performance a lot, but it 

1)  helps the performance in theory, because it iterates less CPUs

2)  makes code cleaner. By "cleaner", I mean we can a) affort more
blank lines to make loops separated from other code and b)
descrease the indent levels for those loops. But, yes I should
add those points in the commit log, because those are more
visible effects.

> though perhaps I am misunderstanding its purpose.  My assumption is
> that you want to detect missing UL suffixes on bitmask constants, in
> which case I bet there is a better way.
> 

The WARN_ON_ONCE() is not for detecting missing UL suffixes on bitmask
constatns, and we don't need to check that, because we use
leaf_node_cpu_id() now. As I said, this is an over-case check, and we
can drop if we guarante that CPUs masked in 

Re: [PATCH v2] fscrypt: Factor out bio specific functions

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

Re: [PATCH v2] fscrypt: Factor out bio specific functions

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

[PATCH 4/4] mmc: sdhci-msm: provide enhanced_strobe mode feature support

[Ritesh Harjani]

This provide support for enhanced_strobe feature to sdhci-msm.

Signed-off-by: Ritesh Harjani 
---
 drivers/mmc/host/sdhci-msm.c | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 32879b8..d092a16 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -102,6 +102,7 @@
 
 #define CORE_DDR_200_CFG   0x184
 #define CORE_CDC_T4_DLY_SELBIT(0)
+#define CORE_CMDIN_RCLK_EN BIT(1)
 #define CORE_START_CDC_TRAFFIC BIT(6)
 #define CORE_VENDOR_SPEC3  0x1b0
 #define CORE_PWRSAVE_DLL   BIT(3)
@@ -579,6 +580,7 @@ static int sdhci_msm_cdclp533_calibration(struct sdhci_host 
*host)
 
 static int sdhci_msm_cm_dll_sdc4_calibration(struct sdhci_host *host)
 {
+   struct mmc_host *mmc = host->mmc;
u32 dll_status, config;
int ret;
 
@@ -593,6 +595,12 @@ static int sdhci_msm_cm_dll_sdc4_calibration(struct 
sdhci_host *host)
 */
writel_relaxed(DDR_CONFIG_POR_VAL, host->ioaddr + CORE_DDR_CONFIG);
 
+   if (mmc->ios.enhanced_strobe) {
+   config = readl_relaxed(host->ioaddr + CORE_DDR_200_CFG);
+   config |= CORE_CMDIN_RCLK_EN;
+   writel_relaxed(config, host->ioaddr + CORE_DDR_200_CFG);
+   }
+
config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG_2);
config |= CORE_DDR_CAL_EN;
writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG_2);
@@ -627,6 +635,7 @@ static int sdhci_msm_hs400_dll_calibration(struct 
sdhci_host *host)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+   struct mmc_host *mmc = host->mmc;
int ret;
u32 config;
 
@@ -640,14 +649,17 @@ static int sdhci_msm_hs400_dll_calibration(struct 
sdhci_host *host)
if (ret)
goto out;
 
-   /* Set the selected phase in delay line hw block */
-   ret = msm_config_cm_dll_phase(host, msm_host->saved_tuning_phase);
-   if (ret)
-   goto out;
+   if (!mmc->ios.enhanced_strobe) {
+   /* Set the selected phase in delay line hw block */
+   ret = msm_config_cm_dll_phase(host,
+ msm_host->saved_tuning_phase);
+   if (ret)
+   goto out;
+   config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
+   config |= CORE_CMD_DAT_TRACK_SEL;
+   writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
+   }
 
-   config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
-   config |= CORE_CMD_DAT_TRACK_SEL;
-   writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
if (msm_host->use_cdclp533)
ret = sdhci_msm_cdclp533_calibration(host);
else
@@ -802,7 +814,8 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host 
*host,
spin_unlock_irq(>lock);
/* CDCLP533 HW calibration is only required for HS400 mode*/
if (host->clock > CORE_FREQ_100MHZ &&
-   msm_host->tuning_done && !msm_host->calibration_done &&
+   (msm_host->tuning_done || mmc->ios.enhanced_strobe) &&
+   !msm_host->calibration_done &&
mmc->ios.timing == MMC_TIMING_MMC_HS400)
if (!sdhci_msm_hs400_dll_calibration(host))
msm_host->calibration_done = true;
@@ -941,7 +954,8 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
 * Select HS400 mode using the HC_SELECT_IN from VENDOR SPEC
 * register
 */
-   if (msm_host->tuning_done && !msm_host->calibration_done) {
+   if ((msm_host->tuning_done || curr_ios.enhanced_strobe) &&
+   !msm_host->calibration_done) {
/*
 * Write 0x6 to HC_SELECT_IN and 1 to HC_SELECT_IN_EN
 * field in VENDOR_SPEC_FUNC
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project.

[PATCH 2/4] mmc: mmc: Add change to set controller to HS400 frequency in enhanced strobe

[Ritesh Harjani]

Currently mmc_select_hs400es is not setting the desired frequency
before sending switch command. This makes CMD13 to timeout on
some controllers.
Thus add a change to set the desired HS400 frequency
in mmc_select_hs400es when the timing is switched to HS400.

Signed-off-by: Ritesh Harjani 
---
 drivers/mmc/core/mmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index b61b52f9..eb69497 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1329,6 +1329,7 @@ static int mmc_select_hs400es(struct mmc_card *card)
 
/* Set host controller to HS400 timing and frequency */
mmc_set_timing(host, MMC_TIMING_MMC_HS400);
+   mmc_set_bus_speed(card);
 
/* Controller enable enhanced strobe function */
host->ios.enhanced_strobe = true;
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project.