Re: [Outreachy kernel] [PATCH v3 3/4] staging: sm750fb: Alignment should match open parenthesis

2017-03-13 Thread Julia Lawall


On Tue, 14 Mar 2017, Arushi Singhal wrote:

> Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".

I thought you were going to take another approach to improve this code?

julia

>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/sm750fb/ddk750_mode.c | 79 
> +--
>  1 file changed, 39 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
> b/drivers/staging/sm750fb/ddk750_mode.c
> index 45af806c8d55..eea5aef2956f 100644
> --- a/drivers/staging/sm750fb/ddk750_mode.c
> +++ b/drivers/staging/sm750fb/ddk750_mode.c
> @@ -28,9 +28,9 @@ static unsigned long 
> displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
>   poke32(CRT_AUTO_CENTERING_TL, 0);
>
>   poke32(CRT_AUTO_CENTERING_BR,
> - (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
> - CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
> - ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
> +(((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
> + CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
> +((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
>
>   /*
>* Assume common fields in dispControl have been properly set before
> @@ -72,8 +72,7 @@ static unsigned long 
> displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
>  }
>
>  /* only timing related registers will be  programed */
> -static int programModeRegisters(mode_parameter_t *pModeParam,
> - struct pll_value *pll)
> +static int programModeRegisters(mode_parameter_t *pModeParam, struct 
> pll_value *pll)
>  {
>   int ret = 0;
>   int cnt = 0;
> @@ -83,32 +82,32 @@ static int programModeRegisters(mode_parameter_t 
> *pModeParam,
>   /* programe secondary pixel clock */
>   poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
>   poke32(CRT_HORIZONTAL_TOTAL,
> - (((pModeParam->horizontal_total - 1) <<
> - CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
> - CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
> - ((pModeParam->horizontal_display_end - 1) &
> - CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
> +(((pModeParam->horizontal_total - 1) <<
> +  CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
> + CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
> +((pModeParam->horizontal_display_end - 1) &
> + CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
>
>   poke32(CRT_HORIZONTAL_SYNC,
> - ((pModeParam->horizontal_sync_width <<
> - CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
> - CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
> - ((pModeParam->horizontal_sync_start - 1) &
> - CRT_HORIZONTAL_SYNC_START_MASK));
> +((pModeParam->horizontal_sync_width <<
> +  CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
> + CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
> +((pModeParam->horizontal_sync_start - 1) &
> + CRT_HORIZONTAL_SYNC_START_MASK));
>
>   poke32(CRT_VERTICAL_TOTAL,
> - (((pModeParam->vertical_total - 1) <<
> - CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
> - CRT_VERTICAL_TOTAL_TOTAL_MASK) |
> - ((pModeParam->vertical_display_end - 1) &
> - CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
> +(((pModeParam->vertical_total - 1) <<
> +  CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
> + CRT_VERTICAL_TOTAL_TOTAL_MASK) |
> +((pModeParam->vertical_display_end - 1) &
> + CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
>
>   poke32(CRT_VERTICAL_SYNC,
> - ((pModeParam->vertical_sync_height <<
> - CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
> - CRT_VERTICAL_SYNC_HEIGHT_MASK) |
> - ((pModeParam->vertical_sync_start - 1) &
> - CRT_VERTICAL_SYNC_START_MASK));
> +((pModeParam->vertical_sync_height <<
> +  CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
> + CRT_VERTICAL_SYNC_HEIGHT_MASK) |
> +((pModeParam->vertical_sync_start - 1) &
> + CRT_VERTICAL_SYNC_START_MASK));
>
>   tmp = DISPLAY_CTRL_TIMING | DISPLAY_CTRL_PLANE;
>   if (pModeParam->vertical_sync_polarity)
> @@ -140,25 +139,25 @@ static int programModeRegisters(mode_parameter_t 
> *pModeParam,
>   poke32(PANEL_HORIZONTAL_TOTAL, reg);
>
>   poke32(PANEL_HORIZONTAL_SYNC,
> - 

Re: [Outreachy kernel] [PATCH v3 3/4] staging: sm750fb: Alignment should match open parenthesis

2017-03-13 Thread Julia Lawall


On Tue, 14 Mar 2017, Arushi Singhal wrote:

> Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".

I thought you were going to take another approach to improve this code?

julia

>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/sm750fb/ddk750_mode.c | 79 
> +--
>  1 file changed, 39 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
> b/drivers/staging/sm750fb/ddk750_mode.c
> index 45af806c8d55..eea5aef2956f 100644
> --- a/drivers/staging/sm750fb/ddk750_mode.c
> +++ b/drivers/staging/sm750fb/ddk750_mode.c
> @@ -28,9 +28,9 @@ static unsigned long 
> displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
>   poke32(CRT_AUTO_CENTERING_TL, 0);
>
>   poke32(CRT_AUTO_CENTERING_BR,
> - (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
> - CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
> - ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
> +(((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
> + CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
> +((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
>
>   /*
>* Assume common fields in dispControl have been properly set before
> @@ -72,8 +72,7 @@ static unsigned long 
> displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
>  }
>
>  /* only timing related registers will be  programed */
> -static int programModeRegisters(mode_parameter_t *pModeParam,
> - struct pll_value *pll)
> +static int programModeRegisters(mode_parameter_t *pModeParam, struct 
> pll_value *pll)
>  {
>   int ret = 0;
>   int cnt = 0;
> @@ -83,32 +82,32 @@ static int programModeRegisters(mode_parameter_t 
> *pModeParam,
>   /* programe secondary pixel clock */
>   poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
>   poke32(CRT_HORIZONTAL_TOTAL,
> - (((pModeParam->horizontal_total - 1) <<
> - CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
> - CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
> - ((pModeParam->horizontal_display_end - 1) &
> - CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
> +(((pModeParam->horizontal_total - 1) <<
> +  CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
> + CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
> +((pModeParam->horizontal_display_end - 1) &
> + CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
>
>   poke32(CRT_HORIZONTAL_SYNC,
> - ((pModeParam->horizontal_sync_width <<
> - CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
> - CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
> - ((pModeParam->horizontal_sync_start - 1) &
> - CRT_HORIZONTAL_SYNC_START_MASK));
> +((pModeParam->horizontal_sync_width <<
> +  CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
> + CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
> +((pModeParam->horizontal_sync_start - 1) &
> + CRT_HORIZONTAL_SYNC_START_MASK));
>
>   poke32(CRT_VERTICAL_TOTAL,
> - (((pModeParam->vertical_total - 1) <<
> - CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
> - CRT_VERTICAL_TOTAL_TOTAL_MASK) |
> - ((pModeParam->vertical_display_end - 1) &
> - CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
> +(((pModeParam->vertical_total - 1) <<
> +  CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
> + CRT_VERTICAL_TOTAL_TOTAL_MASK) |
> +((pModeParam->vertical_display_end - 1) &
> + CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
>
>   poke32(CRT_VERTICAL_SYNC,
> - ((pModeParam->vertical_sync_height <<
> - CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
> - CRT_VERTICAL_SYNC_HEIGHT_MASK) |
> - ((pModeParam->vertical_sync_start - 1) &
> - CRT_VERTICAL_SYNC_START_MASK));
> +((pModeParam->vertical_sync_height <<
> +  CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
> + CRT_VERTICAL_SYNC_HEIGHT_MASK) |
> +((pModeParam->vertical_sync_start - 1) &
> + CRT_VERTICAL_SYNC_START_MASK));
>
>   tmp = DISPLAY_CTRL_TIMING | DISPLAY_CTRL_PLANE;
>   if (pModeParam->vertical_sync_polarity)
> @@ -140,25 +139,25 @@ static int programModeRegisters(mode_parameter_t 
> *pModeParam,
>   poke32(PANEL_HORIZONTAL_TOTAL, reg);
>
>   poke32(PANEL_HORIZONTAL_SYNC,
> - 

Re: [PATCH] Fixed a minor coding style warning. Arguments in the macros should be coverd in brackets to aviod any precedence issues.

2017-03-13 Thread Greg KH
On Mon, Mar 13, 2017 at 09:52:14PM -0700, mshan wrote:
> Signed-off-by: mshan 
> ---
>  drivers/staging/fwserial/fwserial.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot


Re: [PATCH] Fixed a minor coding style warning. Arguments in the macros should be coverd in brackets to aviod any precedence issues.

2017-03-13 Thread Greg KH
On Mon, Mar 13, 2017 at 09:52:14PM -0700, mshan wrote:
> Signed-off-by: mshan 
> ---
>  drivers/staging/fwserial/fwserial.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot


Re: [PATCH] MAINTAINERS: add Masahiro Yamada as a Kbuild maintainer

2017-03-13 Thread Masahiro Yamada
2017-03-10 10:41 GMT+09:00 Masahiro Yamada :
> It has been difficult lately for Michal to work on Kbuild on his
> regular basis.  We discussed the maintainership of Kbuild, and I
> decided to be a co-maintainer.
>
> Add myself to the maintainer field, and replace the repository with
> my own.
>
> Signed-off-by: Masahiro Yamada 
> Acked-by: Michal Marek 


Applied to linux-kbuild/fixes.



-- 
Best Regards
Masahiro Yamada


Re: [PATCH] MAINTAINERS: add Masahiro Yamada as a Kbuild maintainer

2017-03-13 Thread Masahiro Yamada
2017-03-10 10:41 GMT+09:00 Masahiro Yamada :
> It has been difficult lately for Michal to work on Kbuild on his
> regular basis.  We discussed the maintainership of Kbuild, and I
> decided to be a co-maintainer.
>
> Add myself to the maintainer field, and replace the repository with
> my own.
>
> Signed-off-by: Masahiro Yamada 
> Acked-by: Michal Marek 


Applied to linux-kbuild/fixes.



-- 
Best Regards
Masahiro Yamada


[PATCH] ks7010: adding parenthesis to macro argument

2017-03-13 Thread Pushkar Jambhlekar
Description:
In driver module ks7010, "checkpatch.pl" flags error for adding parenthesis 
around macro params.
Also, removing extra line.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/staging/ks7010/ks7010_sdio.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
b/drivers/staging/ks7010/ks7010_sdio.c
index a604c83..644b8d4 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -35,18 +35,18 @@ MODULE_DEVICE_TABLE(sdio, ks7010_sdio_ids);
 /* macro */
 
 #define inc_txqhead(priv) \
-   (priv->tx_dev.qhead = (priv->tx_dev.qhead + 1) % TX_DEVICE_BUFF_SIZE)
+   ((priv)->tx_dev.qhead = ((priv)->tx_dev.qhead + 1) % 
TX_DEVICE_BUFF_SIZE)
 #define inc_txqtail(priv) \
-   (priv->tx_dev.qtail = (priv->tx_dev.qtail + 1) % TX_DEVICE_BUFF_SIZE)
+   ((priv)->tx_dev.qtail = ((priv)->tx_dev.qtail + 1) % 
TX_DEVICE_BUFF_SIZE)
 #define cnt_txqbody(priv) \
-   (((priv->tx_dev.qtail + TX_DEVICE_BUFF_SIZE) - (priv->tx_dev.qhead)) % 
TX_DEVICE_BUFF_SIZE)
+   priv)->tx_dev.qtail + TX_DEVICE_BUFF_SIZE) - 
((priv)->tx_dev.qhead)) % TX_DEVICE_BUFF_SIZE)
 
 #define inc_rxqhead(priv) \
-   (priv->rx_dev.qhead = (priv->rx_dev.qhead + 1) % RX_DEVICE_BUFF_SIZE)
+   ((priv)->rx_dev.qhead = ((priv)->rx_dev.qhead + 1) % 
RX_DEVICE_BUFF_SIZE)
 #define inc_rxqtail(priv) \
-   (priv->rx_dev.qtail = (priv->rx_dev.qtail + 1) % RX_DEVICE_BUFF_SIZE)
+   ((priv)->rx_dev.qtail = ((priv)->rx_dev.qtail + 1) % 
RX_DEVICE_BUFF_SIZE)
 #define cnt_rxqbody(priv) \
-   (((priv->rx_dev.qtail + RX_DEVICE_BUFF_SIZE) - (priv->rx_dev.qhead)) % 
RX_DEVICE_BUFF_SIZE)
+   priv)->rx_dev.qtail + RX_DEVICE_BUFF_SIZE) - 
((priv)->rx_dev.qhead)) % RX_DEVICE_BUFF_SIZE)
 
 static int ks7010_sdio_read(struct ks_wlan_private *priv, unsigned int address,
unsigned char *buffer, int length)
@@ -884,7 +884,6 @@ static void ks7010_card_init(struct ks_wlan_private *priv)
if (priv->mac_address_valid && priv->version_size)
priv->dev_state = DEVICE_STATE_PREINIT;
 
-
hostif_sme_enqueue(priv, SME_GET_EEPROM_CKSUM);
 
/* load initial wireless parameter */
-- 
2.7.4



[PATCH] ks7010: adding parenthesis to macro argument

2017-03-13 Thread Pushkar Jambhlekar
Description:
In driver module ks7010, "checkpatch.pl" flags error for adding parenthesis 
around macro params.
Also, removing extra line.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/staging/ks7010/ks7010_sdio.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
b/drivers/staging/ks7010/ks7010_sdio.c
index a604c83..644b8d4 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -35,18 +35,18 @@ MODULE_DEVICE_TABLE(sdio, ks7010_sdio_ids);
 /* macro */
 
 #define inc_txqhead(priv) \
-   (priv->tx_dev.qhead = (priv->tx_dev.qhead + 1) % TX_DEVICE_BUFF_SIZE)
+   ((priv)->tx_dev.qhead = ((priv)->tx_dev.qhead + 1) % 
TX_DEVICE_BUFF_SIZE)
 #define inc_txqtail(priv) \
-   (priv->tx_dev.qtail = (priv->tx_dev.qtail + 1) % TX_DEVICE_BUFF_SIZE)
+   ((priv)->tx_dev.qtail = ((priv)->tx_dev.qtail + 1) % 
TX_DEVICE_BUFF_SIZE)
 #define cnt_txqbody(priv) \
-   (((priv->tx_dev.qtail + TX_DEVICE_BUFF_SIZE) - (priv->tx_dev.qhead)) % 
TX_DEVICE_BUFF_SIZE)
+   priv)->tx_dev.qtail + TX_DEVICE_BUFF_SIZE) - 
((priv)->tx_dev.qhead)) % TX_DEVICE_BUFF_SIZE)
 
 #define inc_rxqhead(priv) \
-   (priv->rx_dev.qhead = (priv->rx_dev.qhead + 1) % RX_DEVICE_BUFF_SIZE)
+   ((priv)->rx_dev.qhead = ((priv)->rx_dev.qhead + 1) % 
RX_DEVICE_BUFF_SIZE)
 #define inc_rxqtail(priv) \
-   (priv->rx_dev.qtail = (priv->rx_dev.qtail + 1) % RX_DEVICE_BUFF_SIZE)
+   ((priv)->rx_dev.qtail = ((priv)->rx_dev.qtail + 1) % 
RX_DEVICE_BUFF_SIZE)
 #define cnt_rxqbody(priv) \
-   (((priv->rx_dev.qtail + RX_DEVICE_BUFF_SIZE) - (priv->rx_dev.qhead)) % 
RX_DEVICE_BUFF_SIZE)
+   priv)->rx_dev.qtail + RX_DEVICE_BUFF_SIZE) - 
((priv)->rx_dev.qhead)) % RX_DEVICE_BUFF_SIZE)
 
 static int ks7010_sdio_read(struct ks_wlan_private *priv, unsigned int address,
unsigned char *buffer, int length)
@@ -884,7 +884,6 @@ static void ks7010_card_init(struct ks_wlan_private *priv)
if (priv->mac_address_valid && priv->version_size)
priv->dev_state = DEVICE_STATE_PREINIT;
 
-
hostif_sme_enqueue(priv, SME_GET_EEPROM_CKSUM);
 
/* load initial wireless parameter */
-- 
2.7.4



Re: [PATCH v5 2/4] dt-bindings: mfd: Add LED subnode binding for MT6323 PMIC

2017-03-13 Thread Sean Wang
On Mon, 2017-03-13 at 13:00 +0100, Matthias Brugger wrote:
> 
> On 03/03/17 14:56, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> >
> > This patch adds documentation for devicetree bindings
> > for LED support as the subnode of MT6323 PMIC
> >
> > Signed-off-by: Sean Wang 
> > ---
> >  Documentation/devicetree/bindings/mfd/mt6397.txt | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt 
> > b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > index 949c85f..522a3bb 100644
> > --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> > +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > @@ -6,6 +6,7 @@ MT6397/MT6323 is a multifunction device with the following 
> > sub modules:
> >  - Audio codec
> >  - GPIO
> >  - Clock
> > +- LED
> >
> >  It is interfaced to host controller using SPI interface by a proprietary 
> > hardware
> >  called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
> > @@ -34,6 +35,10 @@ Optional subnodes:
> >  - clk
> > Required properties:
> > - compatible: "mediatek,mt6397-clk"
> > +- led
> > +   Required properties:
> > +   - compatible: "mediatek,mt6323-led"
> > +   see Documentation/devicetree/bindings/leds/leds-mt6323.txt
> 
> Part of this patch is already part of linux-next:
> 05daab3 ("Documentation: devicetree: Add LED subnode binding for MT6323 
> PMIC")
> 
Hi Matthias,

There is still small differences from the merged patch. 

I will submit the series for the next version based on newer kernel and

split the already merged ones out. Thanks for your kindly remainder.

Sean
> Regards,
> Matthias




Re: [PATCH v5 2/4] dt-bindings: mfd: Add LED subnode binding for MT6323 PMIC

2017-03-13 Thread Sean Wang
On Mon, 2017-03-13 at 13:00 +0100, Matthias Brugger wrote:
> 
> On 03/03/17 14:56, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> >
> > This patch adds documentation for devicetree bindings
> > for LED support as the subnode of MT6323 PMIC
> >
> > Signed-off-by: Sean Wang 
> > ---
> >  Documentation/devicetree/bindings/mfd/mt6397.txt | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt 
> > b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > index 949c85f..522a3bb 100644
> > --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> > +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > @@ -6,6 +6,7 @@ MT6397/MT6323 is a multifunction device with the following 
> > sub modules:
> >  - Audio codec
> >  - GPIO
> >  - Clock
> > +- LED
> >
> >  It is interfaced to host controller using SPI interface by a proprietary 
> > hardware
> >  called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
> > @@ -34,6 +35,10 @@ Optional subnodes:
> >  - clk
> > Required properties:
> > - compatible: "mediatek,mt6397-clk"
> > +- led
> > +   Required properties:
> > +   - compatible: "mediatek,mt6323-led"
> > +   see Documentation/devicetree/bindings/leds/leds-mt6323.txt
> 
> Part of this patch is already part of linux-next:
> 05daab3 ("Documentation: devicetree: Add LED subnode binding for MT6323 
> PMIC")
> 
Hi Matthias,

There is still small differences from the merged patch. 

I will submit the series for the next version based on newer kernel and

split the already merged ones out. Thanks for your kindly remainder.

Sean
> Regards,
> Matthias




Re: [PATCH v9 00/11] uapi: export all headers under uapi directories

2017-03-13 Thread Masahiro Yamada
Ni Nicolas,


2017-03-14 1:57 GMT+09:00 Nicolas Dichtel :
>> BTW, this series does not apply cleanly.
>>
>> If you could rebase it onto v4.11-rc1 tag,
>> it would be helpful.
> You really want this on top of 4.11-rc1 or the last linus tag, ie v4.11-rc2?
>

Basically, I queue up patches based on -rc1 tag
unless there is a particular reason for otherwise.

If it is based on -rc1, will it cause conflicts with Linus tree?


-- 
Best Regards
Masahiro Yamada


Re: [PATCH v9 00/11] uapi: export all headers under uapi directories

2017-03-13 Thread Masahiro Yamada
Ni Nicolas,


2017-03-14 1:57 GMT+09:00 Nicolas Dichtel :
>> BTW, this series does not apply cleanly.
>>
>> If you could rebase it onto v4.11-rc1 tag,
>> it would be helpful.
> You really want this on top of 4.11-rc1 or the last linus tag, ie v4.11-rc2?
>

Basically, I queue up patches based on -rc1 tag
unless there is a particular reason for otherwise.

If it is based on -rc1, will it cause conflicts with Linus tree?


-- 
Best Regards
Masahiro Yamada


Re: [PATCH V7 4/7] LPC: Support the device-tree LPC host on Hip06/Hip07 (fwd)

2017-03-13 Thread Julia Lawall
Line 460 looks suspicious.  Can tmprange be different than range but not
be an ERR_PTR?  If so, lpcdev->io_host will have an invalid value.

julia

-- Forwarded message --
Date: Tue, 14 Mar 2017 13:12:05 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: Re: [PATCH V7 4/7] LPC: Support the device-tree LPC host on Hip06/Hip07

Hi zhichang.yuan,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
:: branch date: 85 minutes ago
:: commit date: 85 minutes ago

>> drivers/bus/hisi_lpc.c:465:19-24: ERROR: reference preceded by free on line 
>> 460

git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 4e05ad6c3274fa75c903c7809ef0b51329a31ab2
vim +465 drivers/bus/hisi_lpc.c

4e05ad6c zhichang.yuan 2017-03-13  454  range->flags = IO_HOST_INDIRECT;
4e05ad6c zhichang.yuan 2017-03-13  455  range->size = LPC_BUS_IO_SIZE;
4e05ad6c zhichang.yuan 2017-03-13  456  range->hw_start = 
LPC_MIN_BUS_RANGE;
4e05ad6c zhichang.yuan 2017-03-13  457
4e05ad6c zhichang.yuan 2017-03-13  458  tmprange = 
register_libio_range(range);
4e05ad6c zhichang.yuan 2017-03-13  459  if (tmprange != range) {
4e05ad6c zhichang.yuan 2017-03-13 @460  kfree(range);
4e05ad6c zhichang.yuan 2017-03-13  461  if (IS_ERR(tmprange))
4e05ad6c zhichang.yuan 2017-03-13  462  return -EFAULT;
4e05ad6c zhichang.yuan 2017-03-13  463  }
4e05ad6c zhichang.yuan 2017-03-13  464
4e05ad6c zhichang.yuan 2017-03-13 @465  lpcdev->io_host = range;
4e05ad6c zhichang.yuan 2017-03-13  466
4e05ad6c zhichang.yuan 2017-03-13  467  return 0;
4e05ad6c zhichang.yuan 2017-03-13  468  }

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


Re: [PATCH V7 4/7] LPC: Support the device-tree LPC host on Hip06/Hip07 (fwd)

2017-03-13 Thread Julia Lawall
Line 460 looks suspicious.  Can tmprange be different than range but not
be an ERR_PTR?  If so, lpcdev->io_host will have an invalid value.

julia

-- Forwarded message --
Date: Tue, 14 Mar 2017 13:12:05 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: Re: [PATCH V7 4/7] LPC: Support the device-tree LPC host on Hip06/Hip07

Hi zhichang.yuan,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
:: branch date: 85 minutes ago
:: commit date: 85 minutes ago

>> drivers/bus/hisi_lpc.c:465:19-24: ERROR: reference preceded by free on line 
>> 460

git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 4e05ad6c3274fa75c903c7809ef0b51329a31ab2
vim +465 drivers/bus/hisi_lpc.c

4e05ad6c zhichang.yuan 2017-03-13  454  range->flags = IO_HOST_INDIRECT;
4e05ad6c zhichang.yuan 2017-03-13  455  range->size = LPC_BUS_IO_SIZE;
4e05ad6c zhichang.yuan 2017-03-13  456  range->hw_start = 
LPC_MIN_BUS_RANGE;
4e05ad6c zhichang.yuan 2017-03-13  457
4e05ad6c zhichang.yuan 2017-03-13  458  tmprange = 
register_libio_range(range);
4e05ad6c zhichang.yuan 2017-03-13  459  if (tmprange != range) {
4e05ad6c zhichang.yuan 2017-03-13 @460  kfree(range);
4e05ad6c zhichang.yuan 2017-03-13  461  if (IS_ERR(tmprange))
4e05ad6c zhichang.yuan 2017-03-13  462  return -EFAULT;
4e05ad6c zhichang.yuan 2017-03-13  463  }
4e05ad6c zhichang.yuan 2017-03-13  464
4e05ad6c zhichang.yuan 2017-03-13 @465  lpcdev->io_host = range;
4e05ad6c zhichang.yuan 2017-03-13  466
4e05ad6c zhichang.yuan 2017-03-13  467  return 0;
4e05ad6c zhichang.yuan 2017-03-13  468  }

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


[PATCH] drm/msm/hdmi: redefinitions of macros not required

2017-03-13 Thread Vinay Simha BN
4 macros already defined in hdmi.h,
which is not required to redefine in hdmi_audio.c

Signed-off-by: Vinay Simha BN 
---
 drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
index a54d3bb..8177e85 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
@@ -18,13 +18,6 @@
 #include 
 #include "hdmi.h"
 
-
-/* Supported HDMI Audio channels */
-#define MSM_HDMI_AUDIO_CHANNEL_2   0
-#define MSM_HDMI_AUDIO_CHANNEL_4   1
-#define MSM_HDMI_AUDIO_CHANNEL_6   2
-#define MSM_HDMI_AUDIO_CHANNEL_8   3
-
 /* maps MSM_HDMI_AUDIO_CHANNEL_n consts used by audio driver to # of channels: 
*/
 static int nchannels[] = { 2, 4, 6, 8 };
 
-- 
2.7.4



[PATCH] drm/msm/hdmi: redefinitions of macros not required

2017-03-13 Thread Vinay Simha BN
4 macros already defined in hdmi.h,
which is not required to redefine in hdmi_audio.c

Signed-off-by: Vinay Simha BN 
---
 drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
index a54d3bb..8177e85 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
@@ -18,13 +18,6 @@
 #include 
 #include "hdmi.h"
 
-
-/* Supported HDMI Audio channels */
-#define MSM_HDMI_AUDIO_CHANNEL_2   0
-#define MSM_HDMI_AUDIO_CHANNEL_4   1
-#define MSM_HDMI_AUDIO_CHANNEL_6   2
-#define MSM_HDMI_AUDIO_CHANNEL_8   3
-
 /* maps MSM_HDMI_AUDIO_CHANNEL_n consts used by audio driver to # of channels: 
*/
 static int nchannels[] = { 2, 4, 6, 8 };
 
-- 
2.7.4



Re: [PATCH V7 7/7] LPC: Add the ACPI LPC support

2017-03-13 Thread kbuild test robot
Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/list.h:8:0,
from include/linux/resource_ext.h:17,
from include/linux/acpi.h:26,
from drivers/bus/hisi_lpc.c:19:
   drivers/bus/hisi_lpc.c: In function 'hisilpc_host_io_register':
>> include/linux/list.h:463:43: error: dereferencing pointer to incomplete type 
>> 'struct acpi_device'
 for (pos = list_first_entry(head, typeof(*pos), member); \
   
   include/linux/kernel.h:852:18: note: in definition of macro 'container_of'
 const typeof( ((type *)0)->member ) *__mptr = (ptr); \
 ^~~~
   include/linux/list.h:376:2: note: in expansion of macro 'list_entry'
 list_entry((ptr)->next, type, member)
 ^~
   include/linux/list.h:463:13: note: in expansion of macro 'list_first_entry'
 for (pos = list_first_entry(head, typeof(*pos), member); \
^~~~
>> drivers/bus/hisi_lpc.c:477:3: note: in expansion of macro 
>> 'list_for_each_entry'
  list_for_each_entry(child, >children, node) {
  ^~~
   drivers/bus/hisi_lpc.c: In function 'hisilpc_probe':
   drivers/bus/hisi_lpc.c:550:4: error: implicit declaration of function 
'acpi_walk_dep_device_list' [-Werror=implicit-function-declaration]
   acpi_walk_dep_device_list(adev->handle);
   ^
   cc1: some warnings being treated as errors

vim +463 include/linux/list.h

^1da177e Linus Torvalds 2005-04-16  457   * list_for_each_entry -   iterate 
over list of given type
8e3a67a9 Randy Dunlap   2006-06-25  458   * @pos:   the type * to use as a 
loop cursor.
^1da177e Linus Torvalds 2005-04-16  459   * @head:  the head for your list.
3943f42c Andrey Utkin   2014-11-14  460   * @member:the name of the 
list_head within the struct.
^1da177e Linus Torvalds 2005-04-16  461   */
^1da177e Linus Torvalds 2005-04-16  462  #define list_for_each_entry(pos, head, 
member) \
93be3c2e Oleg Nesterov  2013-11-12 @463 for (pos = 
list_first_entry(head, typeof(*pos), member);\
e66eed65 Linus Torvalds 2011-05-19  464  >member != (head);
\
8120e2e5 Oleg Nesterov  2013-11-12  465  pos = list_next_entry(pos, 
member))
^1da177e Linus Torvalds 2005-04-16  466  

:: The code at line 463 was first introduced by commit
:: 93be3c2eb3371f022ad88acf1ab6bee8e3c38378 list: introduce 
list_last_entry(), use list_{first,last}_entry()

:: TO: Oleg Nesterov 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip


Re: [PATCH V7 7/7] LPC: Add the ACPI LPC support

2017-03-13 Thread kbuild test robot
Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/list.h:8:0,
from include/linux/resource_ext.h:17,
from include/linux/acpi.h:26,
from drivers/bus/hisi_lpc.c:19:
   drivers/bus/hisi_lpc.c: In function 'hisilpc_host_io_register':
>> include/linux/list.h:463:43: error: dereferencing pointer to incomplete type 
>> 'struct acpi_device'
 for (pos = list_first_entry(head, typeof(*pos), member); \
   
   include/linux/kernel.h:852:18: note: in definition of macro 'container_of'
 const typeof( ((type *)0)->member ) *__mptr = (ptr); \
 ^~~~
   include/linux/list.h:376:2: note: in expansion of macro 'list_entry'
 list_entry((ptr)->next, type, member)
 ^~
   include/linux/list.h:463:13: note: in expansion of macro 'list_first_entry'
 for (pos = list_first_entry(head, typeof(*pos), member); \
^~~~
>> drivers/bus/hisi_lpc.c:477:3: note: in expansion of macro 
>> 'list_for_each_entry'
  list_for_each_entry(child, >children, node) {
  ^~~
   drivers/bus/hisi_lpc.c: In function 'hisilpc_probe':
   drivers/bus/hisi_lpc.c:550:4: error: implicit declaration of function 
'acpi_walk_dep_device_list' [-Werror=implicit-function-declaration]
   acpi_walk_dep_device_list(adev->handle);
   ^
   cc1: some warnings being treated as errors

vim +463 include/linux/list.h

^1da177e Linus Torvalds 2005-04-16  457   * list_for_each_entry -   iterate 
over list of given type
8e3a67a9 Randy Dunlap   2006-06-25  458   * @pos:   the type * to use as a 
loop cursor.
^1da177e Linus Torvalds 2005-04-16  459   * @head:  the head for your list.
3943f42c Andrey Utkin   2014-11-14  460   * @member:the name of the 
list_head within the struct.
^1da177e Linus Torvalds 2005-04-16  461   */
^1da177e Linus Torvalds 2005-04-16  462  #define list_for_each_entry(pos, head, 
member) \
93be3c2e Oleg Nesterov  2013-11-12 @463 for (pos = 
list_first_entry(head, typeof(*pos), member);\
e66eed65 Linus Torvalds 2011-05-19  464  >member != (head);
\
8120e2e5 Oleg Nesterov  2013-11-12  465  pos = list_next_entry(pos, 
member))
^1da177e Linus Torvalds 2005-04-16  466  

:: The code at line 463 was first introduced by commit
:: 93be3c2eb3371f022ad88acf1ab6bee8e3c38378 list: introduce 
list_last_entry(), use list_{first,last}_entry()

:: TO: Oleg Nesterov 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip


Re: [PATCH] Kbuild: support designated_init attribute

2017-03-13 Thread Masahiro Yamada
Hi Kees,


2017-02-02 8:04 GMT+09:00 Kees Cook :
> If a structure is marked with __attribute__((designated_init)) from
> GCC or Sparse, it needs to have all static initializers using designated
> initialization. Fail the build for any missing cases. This attribute will
> be used by the randstruct plugin to make sure randomized structures are
> being correctly initialized.
>
> Signed-off-by: Kees Cook 
> ---
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 96b27a888285..d4e0550e7abd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -793,6 +793,9 @@ KBUILD_CFLAGS   += $(call cc-option,-Werror=date-time)
>  # enforce correct pointer usage
>  KBUILD_CFLAGS   += $(call cc-option,-Werror=incompatible-pointer-types)
>
> +# Require designated initializers for all marked structures
> +KBUILD_CFLAGS   += $(call cc-option,-Werror=designated-init)
> +
>  # use the deterministic mode of AR if available
>  KBUILD_ARFLAGS := $(call ar-option,D)
>


The code looks OK to me.

As far as I understood, this patch changes
designated-init warnings into errors.  Correct?

If so, I think the commit subject "Kbuild: support designated_init attribute"
does not directly describe what this patch does.




-- 
Best Regards
Masahiro Yamada


Re: [PATCH] Kbuild: support designated_init attribute

2017-03-13 Thread Masahiro Yamada
Hi Kees,


2017-02-02 8:04 GMT+09:00 Kees Cook :
> If a structure is marked with __attribute__((designated_init)) from
> GCC or Sparse, it needs to have all static initializers using designated
> initialization. Fail the build for any missing cases. This attribute will
> be used by the randstruct plugin to make sure randomized structures are
> being correctly initialized.
>
> Signed-off-by: Kees Cook 
> ---
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 96b27a888285..d4e0550e7abd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -793,6 +793,9 @@ KBUILD_CFLAGS   += $(call cc-option,-Werror=date-time)
>  # enforce correct pointer usage
>  KBUILD_CFLAGS   += $(call cc-option,-Werror=incompatible-pointer-types)
>
> +# Require designated initializers for all marked structures
> +KBUILD_CFLAGS   += $(call cc-option,-Werror=designated-init)
> +
>  # use the deterministic mode of AR if available
>  KBUILD_ARFLAGS := $(call ar-option,D)
>


The code looks OK to me.

As far as I understood, this patch changes
designated-init warnings into errors.  Correct?

If so, I think the commit subject "Kbuild: support designated_init attribute"
does not directly describe what this patch does.




-- 
Best Regards
Masahiro Yamada


[PATCH] cpufreq: dbx500: Manage cooling device from cpufreq driver

2017-03-13 Thread Viresh Kumar
The best place to register the CPU cooling device is from the cpufreq
driver as we would know if all the resources are already available or
not. That's what is done for the cpufreq-dt.c driver as well.

The cpu-cooling driver for dbx500 platform was just (un)registering
with the thermal framework and that can be handled easily by the cpufreq
driver as well and in proper sequence as well.

Get rid of the cooling driver and its its users and manage everything
from the cpufreq driver instead.

Signed-off-by: Viresh Kumar 
---
Only compile tested.

 arch/arm/boot/dts/ste-dbx5x0.dtsi|   5 --
 drivers/cpufreq/dbx500-cpufreq.c |  20 ++
 drivers/thermal/Kconfig  |  12 
 drivers/thermal/Makefile |   1 -
 drivers/thermal/db8500_cpufreq_cooling.c | 105 ---
 5 files changed, 20 insertions(+), 123 deletions(-)
 delete mode 100644 drivers/thermal/db8500_cpufreq_cooling.c

diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi 
b/arch/arm/boot/dts/ste-dbx5x0.dtsi
index 82d8c4771293..9eea52013914 100644
--- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
@@ -1170,11 +1170,6 @@
status = "disabled";
};
 
-   cpufreq-cooling {
-   compatible = "stericsson,db8500-cpufreq-cooling";
-   status = "disabled";
-   };
-
mcde@a035 {
compatible = "stericsson,mcde";
reg = <0xa035 0x1000>, /* MCDE */
diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
index 5c3ec1dd4921..3575b82210ba 100644
--- a/drivers/cpufreq/dbx500-cpufreq.c
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +19,7 @@
 
 static struct cpufreq_frequency_table *freq_table;
 static struct clk *armss_clk;
+static struct thermal_cooling_device *cdev;
 
 static int dbx500_cpufreq_target(struct cpufreq_policy *policy,
unsigned int index)
@@ -32,6 +34,22 @@ static int dbx500_cpufreq_init(struct cpufreq_policy *policy)
return cpufreq_generic_init(policy, freq_table, 20 * 1000);
 }
 
+static int dbx500_cpufreq_exit(struct cpufreq_policy *policy)
+{
+   if (!IS_ERR(cdev))
+   cpufreq_cooling_unregister(cdev);
+   return 0;
+}
+
+static void dbx500_cpufreq_ready(struct cpufreq_policy *policy)
+{
+   cdev = cpufreq_cooling_register(policy->cpus);
+   if (IS_ERR(cdev))
+   pr_err("Failed to register cooling device %ld\n", 
PTR_ERR(cdev));
+   else
+   pr_info("Cooling device registered: %s\n", cdev->type);
+}
+
 static struct cpufreq_driver dbx500_cpufreq_driver = {
.flags  = CPUFREQ_STICKY | CPUFREQ_CONST_LOOPS |
CPUFREQ_NEED_INITIAL_FREQ_CHECK,
@@ -39,6 +57,8 @@ static struct cpufreq_driver dbx500_cpufreq_driver = {
.target_index = dbx500_cpufreq_target,
.get= cpufreq_generic_get,
.init   = dbx500_cpufreq_init,
+   .exit  = dbx500_cpufreq_exit,
+   .ready  = dbx500_cpufreq_ready,
.name   = "DBX500",
.attr   = cpufreq_generic_attr,
 };
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 776b34396144..0a16cf4bed39 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -291,18 +291,6 @@ config ARMADA_THERMAL
  Enable this option if you want to have support for thermal management
  controller present in Armada 370 and Armada XP SoC.
 
-config DB8500_CPUFREQ_COOLING
-   tristate "DB8500 cpufreq cooling"
-   depends on ARCH_U8500 || COMPILE_TEST
-   depends on HAS_IOMEM
-   depends on CPU_THERMAL
-   default y
-   help
- Adds DB8500 cpufreq cooling devices, and these cooling devices can be
- bound to thermal zone trip points. When a trip point reached, the
- bound cpufreq cooling device turns active to set CPU frequency low to
- cool down the CPU.
-
 config INTEL_POWERCLAMP
tristate "Intel PowerClamp idle injection driver"
depends on THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 7adae2029355..c2372f10dae5 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -41,7 +41,6 @@ obj-$(CONFIG_TANGO_THERMAL)   += tango_thermal.o
 obj-$(CONFIG_IMX_THERMAL)  += imx_thermal.o
 obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
 obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
-obj-$(CONFIG_DB8500_CPUFREQ_COOLING)   += db8500_cpufreq_cooling.o
 obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
 obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
 obj-$(CONFIG_INTEL_SOC_DTS_IOSF_CORE)  += intel_soc_dts_iosf.o
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c 
b/drivers/thermal/db8500_cpufreq_cooling.c

[PATCH] cpufreq: dbx500: Manage cooling device from cpufreq driver

2017-03-13 Thread Viresh Kumar
The best place to register the CPU cooling device is from the cpufreq
driver as we would know if all the resources are already available or
not. That's what is done for the cpufreq-dt.c driver as well.

The cpu-cooling driver for dbx500 platform was just (un)registering
with the thermal framework and that can be handled easily by the cpufreq
driver as well and in proper sequence as well.

Get rid of the cooling driver and its its users and manage everything
from the cpufreq driver instead.

Signed-off-by: Viresh Kumar 
---
Only compile tested.

 arch/arm/boot/dts/ste-dbx5x0.dtsi|   5 --
 drivers/cpufreq/dbx500-cpufreq.c |  20 ++
 drivers/thermal/Kconfig  |  12 
 drivers/thermal/Makefile |   1 -
 drivers/thermal/db8500_cpufreq_cooling.c | 105 ---
 5 files changed, 20 insertions(+), 123 deletions(-)
 delete mode 100644 drivers/thermal/db8500_cpufreq_cooling.c

diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi 
b/arch/arm/boot/dts/ste-dbx5x0.dtsi
index 82d8c4771293..9eea52013914 100644
--- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
@@ -1170,11 +1170,6 @@
status = "disabled";
};
 
-   cpufreq-cooling {
-   compatible = "stericsson,db8500-cpufreq-cooling";
-   status = "disabled";
-   };
-
mcde@a035 {
compatible = "stericsson,mcde";
reg = <0xa035 0x1000>, /* MCDE */
diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
index 5c3ec1dd4921..3575b82210ba 100644
--- a/drivers/cpufreq/dbx500-cpufreq.c
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +19,7 @@
 
 static struct cpufreq_frequency_table *freq_table;
 static struct clk *armss_clk;
+static struct thermal_cooling_device *cdev;
 
 static int dbx500_cpufreq_target(struct cpufreq_policy *policy,
unsigned int index)
@@ -32,6 +34,22 @@ static int dbx500_cpufreq_init(struct cpufreq_policy *policy)
return cpufreq_generic_init(policy, freq_table, 20 * 1000);
 }
 
+static int dbx500_cpufreq_exit(struct cpufreq_policy *policy)
+{
+   if (!IS_ERR(cdev))
+   cpufreq_cooling_unregister(cdev);
+   return 0;
+}
+
+static void dbx500_cpufreq_ready(struct cpufreq_policy *policy)
+{
+   cdev = cpufreq_cooling_register(policy->cpus);
+   if (IS_ERR(cdev))
+   pr_err("Failed to register cooling device %ld\n", 
PTR_ERR(cdev));
+   else
+   pr_info("Cooling device registered: %s\n", cdev->type);
+}
+
 static struct cpufreq_driver dbx500_cpufreq_driver = {
.flags  = CPUFREQ_STICKY | CPUFREQ_CONST_LOOPS |
CPUFREQ_NEED_INITIAL_FREQ_CHECK,
@@ -39,6 +57,8 @@ static struct cpufreq_driver dbx500_cpufreq_driver = {
.target_index = dbx500_cpufreq_target,
.get= cpufreq_generic_get,
.init   = dbx500_cpufreq_init,
+   .exit  = dbx500_cpufreq_exit,
+   .ready  = dbx500_cpufreq_ready,
.name   = "DBX500",
.attr   = cpufreq_generic_attr,
 };
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 776b34396144..0a16cf4bed39 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -291,18 +291,6 @@ config ARMADA_THERMAL
  Enable this option if you want to have support for thermal management
  controller present in Armada 370 and Armada XP SoC.
 
-config DB8500_CPUFREQ_COOLING
-   tristate "DB8500 cpufreq cooling"
-   depends on ARCH_U8500 || COMPILE_TEST
-   depends on HAS_IOMEM
-   depends on CPU_THERMAL
-   default y
-   help
- Adds DB8500 cpufreq cooling devices, and these cooling devices can be
- bound to thermal zone trip points. When a trip point reached, the
- bound cpufreq cooling device turns active to set CPU frequency low to
- cool down the CPU.
-
 config INTEL_POWERCLAMP
tristate "Intel PowerClamp idle injection driver"
depends on THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 7adae2029355..c2372f10dae5 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -41,7 +41,6 @@ obj-$(CONFIG_TANGO_THERMAL)   += tango_thermal.o
 obj-$(CONFIG_IMX_THERMAL)  += imx_thermal.o
 obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
 obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
-obj-$(CONFIG_DB8500_CPUFREQ_COOLING)   += db8500_cpufreq_cooling.o
 obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
 obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
 obj-$(CONFIG_INTEL_SOC_DTS_IOSF_CORE)  += intel_soc_dts_iosf.o
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c 
b/drivers/thermal/db8500_cpufreq_cooling.c
deleted file mode 100644
index 

[PATCH v3 2/2] staging: speakup: fix "Alignment match open parenthesis"

2017-03-13 Thread Arushi Singhal
Alig arguments with open parenthesis.

Signed-off-by: Arushi Singhal 
---
 changes in v3
 - Improve the commit message.

 drivers/staging/speakup/kobjects.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index 8a586323b728..ca85476e3ff7 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -93,7 +93,7 @@ static void report_char_chartab_status(int reset, int 
received, int used,
} else if (received) {
len = snprintf(buf, sizeof(buf),
   " updated %d of %d %s\n",
-   used, received, object_type[do_characters]);
+  used, received, object_type[do_characters]);
if (rejected)
snprintf(buf + (len - 1), sizeof(buf) - (len - 1),
 " with %d reject%s\n",
-- 
2.11.0



[PATCH v3 2/2] staging: speakup: fix "Alignment match open parenthesis"

2017-03-13 Thread Arushi Singhal
Alig arguments with open parenthesis.

Signed-off-by: Arushi Singhal 
---
 changes in v3
 - Improve the commit message.

 drivers/staging/speakup/kobjects.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index 8a586323b728..ca85476e3ff7 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -93,7 +93,7 @@ static void report_char_chartab_status(int reset, int 
received, int used,
} else if (received) {
len = snprintf(buf, sizeof(buf),
   " updated %d of %d %s\n",
-   used, received, object_type[do_characters]);
+  used, received, object_type[do_characters]);
if (rejected)
snprintf(buf + (len - 1), sizeof(buf) - (len - 1),
 " with %d reject%s\n",
-- 
2.11.0



[PATCH v3 1/2] staging: speakup: Add blank line after declarations

2017-03-13 Thread Arushi Singhal
Patch fixes the warnings reported by checkpatch.pl
for please use a blank line after function/struct/union/enum
declarations.
Add a blank line after enum and struct declarations.

Signed-off-by: Arushi Singhal 
---
 changes in v3
 - change the subject and commit message to make it more relevant.

 drivers/staging/speakup/main.c | 1 +
 drivers/staging/speakup/serialio.c | 1 +
 drivers/staging/speakup/speakup_dtlk.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 6786cfab7460..4b750ec8cd59 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -108,6 +108,7 @@ enum {
CT_Window,
CT_Max
 };
+
 #define read_all_mode CT_Max
 
 static struct tty_struct *tty;
diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index aade52ee15a0..d51e382cb835 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -21,6 +21,7 @@ static void start_serial_interrupt(int irq);
 static const struct old_serial_port rs_table[] = {
SERIAL_PORT_DFNS
 };
+
 static const struct old_serial_port *serstate;
 static int timeouts;
 
diff --git a/drivers/staging/speakup/speakup_dtlk.c 
b/drivers/staging/speakup/speakup_dtlk.c
index eede2d82183a..c0b2208aa8a7 100644
--- a/drivers/staging/speakup/speakup_dtlk.c
+++ b/drivers/staging/speakup/speakup_dtlk.c
@@ -43,6 +43,7 @@ static int port_forced;
 static unsigned int synth_portlist[] = {
 0x25e, 0x29e, 0x2de, 0x31e, 0x35e, 0x39e, 0
 };
+
 static u_char synth_status;
 
 static struct var_t vars[] = {
-- 
2.11.0



[PATCH v3 1/2] staging: speakup: Add blank line after declarations

2017-03-13 Thread Arushi Singhal
Patch fixes the warnings reported by checkpatch.pl
for please use a blank line after function/struct/union/enum
declarations.
Add a blank line after enum and struct declarations.

Signed-off-by: Arushi Singhal 
---
 changes in v3
 - change the subject and commit message to make it more relevant.

 drivers/staging/speakup/main.c | 1 +
 drivers/staging/speakup/serialio.c | 1 +
 drivers/staging/speakup/speakup_dtlk.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 6786cfab7460..4b750ec8cd59 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -108,6 +108,7 @@ enum {
CT_Window,
CT_Max
 };
+
 #define read_all_mode CT_Max
 
 static struct tty_struct *tty;
diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index aade52ee15a0..d51e382cb835 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -21,6 +21,7 @@ static void start_serial_interrupt(int irq);
 static const struct old_serial_port rs_table[] = {
SERIAL_PORT_DFNS
 };
+
 static const struct old_serial_port *serstate;
 static int timeouts;
 
diff --git a/drivers/staging/speakup/speakup_dtlk.c 
b/drivers/staging/speakup/speakup_dtlk.c
index eede2d82183a..c0b2208aa8a7 100644
--- a/drivers/staging/speakup/speakup_dtlk.c
+++ b/drivers/staging/speakup/speakup_dtlk.c
@@ -43,6 +43,7 @@ static int port_forced;
 static unsigned int synth_portlist[] = {
 0x25e, 0x29e, 0x2de, 0x31e, 0x35e, 0x39e, 0
 };
+
 static u_char synth_status;
 
 static struct var_t vars[] = {
-- 
2.11.0



[PATCH v3 0/2] staging: speakup: checkpatch guided cleanups.

2017-03-13 Thread Arushi Singhal
Improve readability by fixing multiple checkpatch.pl
issues in speakup driver.

Arushi Singhal (2):
  staging: speakup: Add blank line after declarations
  staging: speakup: fix "Alignment match open parenthesis"

 drivers/staging/speakup/kobjects.c | 2 +-
 drivers/staging/speakup/main.c | 1 +
 drivers/staging/speakup/serialio.c | 1 +
 drivers/staging/speakup/speakup_dtlk.c | 1 +
 4 files changed, 4 insertions(+), 1 deletion(-)

-- 
2.11.0



[PATCH v3 0/2] staging: speakup: checkpatch guided cleanups.

2017-03-13 Thread Arushi Singhal
Improve readability by fixing multiple checkpatch.pl
issues in speakup driver.

Arushi Singhal (2):
  staging: speakup: Add blank line after declarations
  staging: speakup: fix "Alignment match open parenthesis"

 drivers/staging/speakup/kobjects.c | 2 +-
 drivers/staging/speakup/main.c | 1 +
 drivers/staging/speakup/serialio.c | 1 +
 drivers/staging/speakup/speakup_dtlk.c | 1 +
 4 files changed, 4 insertions(+), 1 deletion(-)

-- 
2.11.0



Re: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose dependency has not met

2017-03-13 Thread kbuild test robot
Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All errors (new ones prefixed by >>):

   drivers/bus/hisi_lpc.c: In function 'hisilpc_probe':
>> drivers/bus/hisi_lpc.c:529:4: error: implicit declaration of function 
>> 'acpi_walk_dep_device_list' [-Werror=implicit-function-declaration]
   acpi_walk_dep_device_list(adev->handle);
   ^
>> drivers/bus/hisi_lpc.c:529:34: error: dereferencing pointer to incomplete 
>> type 'struct acpi_device'
   acpi_walk_dep_device_list(adev->handle);
 ^~
   cc1: some warnings being treated as errors

vim +/acpi_walk_dep_device_list +529 drivers/bus/hisi_lpc.c

   523  struct acpi_device *adev;
   524  
   525  adev = to_acpi_device_node(dev->fwnode);
   526  if (!adev)
   527  ret = -ENODEV;
   528  else
 > 529  acpi_walk_dep_device_list(adev->handle);
   530  } else {
   531  ret = of_platform_populate(dev->of_node, NULL, NULL, 
dev);
   532  if (ret)

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


.config.gz
Description: application/gzip


Re: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose dependency has not met

2017-03-13 Thread kbuild test robot
Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All errors (new ones prefixed by >>):

   drivers/bus/hisi_lpc.c: In function 'hisilpc_probe':
>> drivers/bus/hisi_lpc.c:529:4: error: implicit declaration of function 
>> 'acpi_walk_dep_device_list' [-Werror=implicit-function-declaration]
   acpi_walk_dep_device_list(adev->handle);
   ^
>> drivers/bus/hisi_lpc.c:529:34: error: dereferencing pointer to incomplete 
>> type 'struct acpi_device'
   acpi_walk_dep_device_list(adev->handle);
 ^~
   cc1: some warnings being treated as errors

vim +/acpi_walk_dep_device_list +529 drivers/bus/hisi_lpc.c

   523  struct acpi_device *adev;
   524  
   525  adev = to_acpi_device_node(dev->fwnode);
   526  if (!adev)
   527  ret = -ENODEV;
   528  else
 > 529  acpi_walk_dep_device_list(adev->handle);
   530  } else {
   531  ret = of_platform_populate(dev->of_node, NULL, NULL, 
dev);
   532  if (ret)

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


.config.gz
Description: application/gzip


Re: [PATCH V7 6/7] LIBIO: Support the dynamically logical PIO registration of ACPI host I/O

2017-03-13 Thread kbuild test robot
Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All error/warnings (new ones prefixed by >>):

   include/linux/ratelimit.h: In function 'ratelimit_state_exit':
>> arch/blackfin/kernel/module.c:7:40: error: 'mod' undeclared (first use in 
>> this function)
#define pr_fmt(fmt) "module %s: " fmt, mod->name
   ^
   include/linux/printk.h:303:22: note: in expansion of macro 'pr_fmt'
 printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
 ^~
   include/linux/printk.h:304:17: note: in expansion of macro 'pr_warning'
#define pr_warn pr_warning
^~
>> include/linux/ratelimit.h:61:3: note: in expansion of macro 'pr_warn'
  pr_warn("%s: %d output lines suppressed due to ratelimiting\n",
  ^~~
   arch/blackfin/kernel/module.c:7:40: note: each undeclared identifier is 
reported only once for each function it appears in
#define pr_fmt(fmt) "module %s: " fmt, mod->name
   ^
   include/linux/printk.h:303:22: note: in expansion of macro 'pr_fmt'
 printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
 ^~
   include/linux/printk.h:304:17: note: in expansion of macro 'pr_warning'
#define pr_warn pr_warning
^~
>> include/linux/ratelimit.h:61:3: note: in expansion of macro 'pr_warn'
  pr_warn("%s: %d output lines suppressed due to ratelimiting\n",
  ^~~

vim +/mod +7 arch/blackfin/kernel/module.c

1394f032 Bryan Wu2007-05-06   1  /*
96f1050d Robin Getz  2009-09-24   2   * Copyright 2004-2009 Analog Devices Inc.
1394f032 Bryan Wu2007-05-06   3   *
96f1050d Robin Getz  2009-09-24   4   * Licensed under the GPL-2 or later
1394f032 Bryan Wu2007-05-06   5   */
1394f032 Bryan Wu2007-05-06   6  
b75a9e6b Joe Perches 2010-10-20  @7  #define pr_fmt(fmt) "module %s: " fmt, 
mod->name
1394f032 Bryan Wu2007-05-06   8  
1394f032 Bryan Wu2007-05-06   9  #include 
1394f032 Bryan Wu2007-05-06  10  #include 
1394f032 Bryan Wu2007-05-06  11  #include 
1394f032 Bryan Wu2007-05-06  12  #include 
1394f032 Bryan Wu2007-05-06  13  #include 
1394f032 Bryan Wu2007-05-06  14  #include 
1394f032 Bryan Wu2007-05-06  15  #include 

:: The code at line 7 was first introduced by commit
:: b75a9e6bfba5c7343391ac1bacd44d6652dde8da Blackfin: use more standard 
pr_fmt in the module loader

:: TO: Joe Perches 
:: CC: Mike Frysinger 

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


.config.gz
Description: application/gzip


Re: [PATCH V7 6/7] LIBIO: Support the dynamically logical PIO registration of ACPI host I/O

2017-03-13 Thread kbuild test robot
Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All error/warnings (new ones prefixed by >>):

   include/linux/ratelimit.h: In function 'ratelimit_state_exit':
>> arch/blackfin/kernel/module.c:7:40: error: 'mod' undeclared (first use in 
>> this function)
#define pr_fmt(fmt) "module %s: " fmt, mod->name
   ^
   include/linux/printk.h:303:22: note: in expansion of macro 'pr_fmt'
 printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
 ^~
   include/linux/printk.h:304:17: note: in expansion of macro 'pr_warning'
#define pr_warn pr_warning
^~
>> include/linux/ratelimit.h:61:3: note: in expansion of macro 'pr_warn'
  pr_warn("%s: %d output lines suppressed due to ratelimiting\n",
  ^~~
   arch/blackfin/kernel/module.c:7:40: note: each undeclared identifier is 
reported only once for each function it appears in
#define pr_fmt(fmt) "module %s: " fmt, mod->name
   ^
   include/linux/printk.h:303:22: note: in expansion of macro 'pr_fmt'
 printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
 ^~
   include/linux/printk.h:304:17: note: in expansion of macro 'pr_warning'
#define pr_warn pr_warning
^~
>> include/linux/ratelimit.h:61:3: note: in expansion of macro 'pr_warn'
  pr_warn("%s: %d output lines suppressed due to ratelimiting\n",
  ^~~

vim +/mod +7 arch/blackfin/kernel/module.c

1394f032 Bryan Wu2007-05-06   1  /*
96f1050d Robin Getz  2009-09-24   2   * Copyright 2004-2009 Analog Devices Inc.
1394f032 Bryan Wu2007-05-06   3   *
96f1050d Robin Getz  2009-09-24   4   * Licensed under the GPL-2 or later
1394f032 Bryan Wu2007-05-06   5   */
1394f032 Bryan Wu2007-05-06   6  
b75a9e6b Joe Perches 2010-10-20  @7  #define pr_fmt(fmt) "module %s: " fmt, 
mod->name
1394f032 Bryan Wu2007-05-06   8  
1394f032 Bryan Wu2007-05-06   9  #include 
1394f032 Bryan Wu2007-05-06  10  #include 
1394f032 Bryan Wu2007-05-06  11  #include 
1394f032 Bryan Wu2007-05-06  12  #include 
1394f032 Bryan Wu2007-05-06  13  #include 
1394f032 Bryan Wu2007-05-06  14  #include 
1394f032 Bryan Wu2007-05-06  15  #include 

:: The code at line 7 was first introduced by commit
:: b75a9e6bfba5c7343391ac1bacd44d6652dde8da Blackfin: use more standard 
pr_fmt in the module loader

:: TO: Joe Perches 
:: CC: Mike Frysinger 

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


.config.gz
Description: application/gzip


Re: Synaptics RMI4 touchpad regression in 4.11-rc1

2017-03-13 Thread Cameron Gutman


On 03/13/2017 06:35 PM, Andrew Duggan wrote:
> 
> 
> On 03/13/2017 06:15 AM, Benjamin Tissoires wrote:
>> [Resending, forgot to add Jiri in CC]
>>
>> On Mar 13 2017 or thereabouts, Benjamin Tissoires wrote:
>>> On Mar 13 2017 or thereabouts, Thorsten Leemhuis wrote:
 Lo! On 12.03.2017 02:55, Cameron Gutman wrote:
> Beginning in 4.11-rc1, it looks like RMI4 is binding to my XPS 13 9343's
> Synaptics touchpad and dropping some errors into dmesg. Here are the
> messages that seem RMI-related:
>
> rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized bootloader version
> rmi4_f34: probe of rmi4-00.fn34 failed with error -22
> rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, 
> product: TM3038-001, fw id: 1832324
> input: Synaptics TM3038-001 as 
> /devices/pci:00/INT3433:00/i2c-7/i2c-DLL0665:01/0018:06CB:76AD.0001/input/input19
> hid-rmi 0018:06CB:76AD.0001: input,hidraw0: I2C HID v1.00 Mouse 
> [DLL0665:01 06CB:76AD] on i2c-DLL0665:01
 FWIW, I get this on my XPS 13 DE (9360) with 4.11-rc1:

 input: SynPS/2 Synaptics TouchPad as
 /devices/platform/i8042/serio1/input/input6
 rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized bootloader version
 rmi4_f34: probe of rmi4-00.fn34 failed with error -22
 rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics,
 product: TM3038-003, fw id: 2375007
 input: Synaptics TM3038-003 as
 /devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DLL075B:01/0018:06CB:76AF.0001/input/input20
 hid-rmi 0018:06CB:76AF.0001: input,hidraw0: I2C HID v1.00 Mouse
 [DLL075B:01 06CB:76AF] on i2c-DLL075B:01

> […]
> Compared to hid-multitouch, the RMI stack seems to have completely broken
> palm rejection and introduced some random jumpiness during fine pointing
> motions. I don't know if these issues are caused by the above errors or
> are a separate issue.
> 
> The error about the bootloader version not being recognized just means that 
> updating the firmware is not supported on this touchpad. It is only the F34 
> firmware update functionality which is failing to load. The palm rejection 
> and jumps are not related to this error.
> 

Maybe that code path should be changed to not make as much noise when it runs
on known unsupported hardware. Something like the attached patch?

> Looking at how hid-multitouch handles palms it looks like palms should not be 
> reported as active when calling input_mt_report_slot_state(). I'm setting the 
> tool type to MT_TOOL_PALM when the firmware determines that a contact is a 
> palm. But, that does not seem to be sufficient enough to have the palms 
> filtered out. After some quick testing it looks like the change below will 
> restore palm rejection similar to that provided by hid-multitouch.
> 

It looks like your email client ate the tabs, but if I apply the change
myself it seems to fix the palm rejection regression for me.

Tested-by: Cameron Gutman 

 Just to confirm: I noticed "jumpiness during fine pointing motions" as
 well since switching to 4.11-rc.
> 
> One of my test systems is a XPS 13 9343 and I have not really seen any 
> jumpiness. But, based on the data I am seeing that if I lift my finger and 
> place it again in a short period of time the first event or so will be at the 
> location of the previous contact. Then it will switch over to the current 
> location. When switching over to hid-multitouch I was unable to reproduce 
> this behavior. This definitely could be the source of the jumps.
> 

The jumpiness definitely happens without lifting my finger, but I'm willing
to test any patch you think would improve the situation. Moving one finger
slowly in a figure-8 across my touchpad shows the issue clearly for me. The
small variations in speed of my finger due to the friction on the trackpad
get magnified to relatively large jumpy pointer movements on screen. It
seems much more noticeable in diagonal movements than completely vertical
or horizontal movements.

Regards,
Cameron

---
diff --git a/drivers/input/rmi4/rmi_f34v7.c b/drivers/input/rmi4/rmi_f34v7.c
index 56c6c39..1291d9a 100644
--- a/drivers/input/rmi4/rmi_f34v7.c
+++ b/drivers/input/rmi4/rmi_f34v7.c
@@ -1369,9 +1369,9 @@ int rmi_f34v7_probe(struct f34_data *f34)
} else if (f34->bootloader_id[1] == 7) {
f34->bl_version = 7;
} else {
-   dev_err(>fn->dev, "%s: Unrecognized bootloader version\n",
-   __func__);
-   return -EINVAL;
+   dev_info(>fn->dev, "%s: Unsupported bootloader version: 
%u\n",
+   __func__, f34->bootloader_id[1]);
+   return -ENODEV;
}
 
memset(>v7.blkcount, 0x00, sizeof(f34->v7.blkcount));


Re: Synaptics RMI4 touchpad regression in 4.11-rc1

2017-03-13 Thread Cameron Gutman


On 03/13/2017 06:35 PM, Andrew Duggan wrote:
> 
> 
> On 03/13/2017 06:15 AM, Benjamin Tissoires wrote:
>> [Resending, forgot to add Jiri in CC]
>>
>> On Mar 13 2017 or thereabouts, Benjamin Tissoires wrote:
>>> On Mar 13 2017 or thereabouts, Thorsten Leemhuis wrote:
 Lo! On 12.03.2017 02:55, Cameron Gutman wrote:
> Beginning in 4.11-rc1, it looks like RMI4 is binding to my XPS 13 9343's
> Synaptics touchpad and dropping some errors into dmesg. Here are the
> messages that seem RMI-related:
>
> rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized bootloader version
> rmi4_f34: probe of rmi4-00.fn34 failed with error -22
> rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, 
> product: TM3038-001, fw id: 1832324
> input: Synaptics TM3038-001 as 
> /devices/pci:00/INT3433:00/i2c-7/i2c-DLL0665:01/0018:06CB:76AD.0001/input/input19
> hid-rmi 0018:06CB:76AD.0001: input,hidraw0: I2C HID v1.00 Mouse 
> [DLL0665:01 06CB:76AD] on i2c-DLL0665:01
 FWIW, I get this on my XPS 13 DE (9360) with 4.11-rc1:

 input: SynPS/2 Synaptics TouchPad as
 /devices/platform/i8042/serio1/input/input6
 rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized bootloader version
 rmi4_f34: probe of rmi4-00.fn34 failed with error -22
 rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics,
 product: TM3038-003, fw id: 2375007
 input: Synaptics TM3038-003 as
 /devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DLL075B:01/0018:06CB:76AF.0001/input/input20
 hid-rmi 0018:06CB:76AF.0001: input,hidraw0: I2C HID v1.00 Mouse
 [DLL075B:01 06CB:76AF] on i2c-DLL075B:01

> […]
> Compared to hid-multitouch, the RMI stack seems to have completely broken
> palm rejection and introduced some random jumpiness during fine pointing
> motions. I don't know if these issues are caused by the above errors or
> are a separate issue.
> 
> The error about the bootloader version not being recognized just means that 
> updating the firmware is not supported on this touchpad. It is only the F34 
> firmware update functionality which is failing to load. The palm rejection 
> and jumps are not related to this error.
> 

Maybe that code path should be changed to not make as much noise when it runs
on known unsupported hardware. Something like the attached patch?

> Looking at how hid-multitouch handles palms it looks like palms should not be 
> reported as active when calling input_mt_report_slot_state(). I'm setting the 
> tool type to MT_TOOL_PALM when the firmware determines that a contact is a 
> palm. But, that does not seem to be sufficient enough to have the palms 
> filtered out. After some quick testing it looks like the change below will 
> restore palm rejection similar to that provided by hid-multitouch.
> 

It looks like your email client ate the tabs, but if I apply the change
myself it seems to fix the palm rejection regression for me.

Tested-by: Cameron Gutman 

 Just to confirm: I noticed "jumpiness during fine pointing motions" as
 well since switching to 4.11-rc.
> 
> One of my test systems is a XPS 13 9343 and I have not really seen any 
> jumpiness. But, based on the data I am seeing that if I lift my finger and 
> place it again in a short period of time the first event or so will be at the 
> location of the previous contact. Then it will switch over to the current 
> location. When switching over to hid-multitouch I was unable to reproduce 
> this behavior. This definitely could be the source of the jumps.
> 

The jumpiness definitely happens without lifting my finger, but I'm willing
to test any patch you think would improve the situation. Moving one finger
slowly in a figure-8 across my touchpad shows the issue clearly for me. The
small variations in speed of my finger due to the friction on the trackpad
get magnified to relatively large jumpy pointer movements on screen. It
seems much more noticeable in diagonal movements than completely vertical
or horizontal movements.

Regards,
Cameron

---
diff --git a/drivers/input/rmi4/rmi_f34v7.c b/drivers/input/rmi4/rmi_f34v7.c
index 56c6c39..1291d9a 100644
--- a/drivers/input/rmi4/rmi_f34v7.c
+++ b/drivers/input/rmi4/rmi_f34v7.c
@@ -1369,9 +1369,9 @@ int rmi_f34v7_probe(struct f34_data *f34)
} else if (f34->bootloader_id[1] == 7) {
f34->bl_version = 7;
} else {
-   dev_err(>fn->dev, "%s: Unrecognized bootloader version\n",
-   __func__);
-   return -EINVAL;
+   dev_info(>fn->dev, "%s: Unsupported bootloader version: 
%u\n",
+   __func__, f34->bootloader_id[1]);
+   return -ENODEV;
}
 
memset(>v7.blkcount, 0x00, sizeof(f34->v7.blkcount));


Re: [PATCH net, v2] dccp/tcp: fix routing redirect race

2017-03-13 Thread David Miller
From: Jon Maxwell 
Date: Fri, 10 Mar 2017 16:40:33 +1100

> As Eric Dumazet pointed out this also needs to be fixed in IPv6.
> v2: Contains the IPv6 tcp/Ipv6 dccp patches as well.
> 
> We have seen a few incidents lately where a dst_enty has been freed
> with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that
> dst_entry. If the conditions/timings are right a crash then ensues when the
> freed dst_entry is referenced later on. A Common crashing back trace is:
 ...
> Of course it may happen with other NIC drivers as well.
> 
> It's found the freed dst_entry here:
 ...
> But there are other backtraces attributed to the same freed dst_entry in
> netfilter code as well.
> 
> All the vmcores showed 2 significant clues:
> 
> - Remote hosts behind the default gateway had always been redirected to a
> different gateway. A rtable/dst_entry will be added for that host. Making
> more dst_entrys with lower reference counts. Making this more probable.
> 
> - All vmcores showed a postitive LockDroppedIcmps value, e.g:
> 
> LockDroppedIcmps  267
> 
> A closer look at the tcp_v4_err() handler revealed that do_redirect() will run
> regardless of whether user space has the socket locked. This can result in a
> race condition where the same dst_entry cached in sk->sk_dst_entry can be
> decremented twice for the same socket via:
> 
> do_redirect()->__sk_dst_check()-> dst_release().
> 
> Which leads to the dst_entry being prematurely freed with another socket
> pointing to it via sk->sk_dst_cache and a subsequent crash.
> 
> To fix this skip do_redirect() if usespace has the socket locked. Instead let
> the redirect take place later when user space does not have the socket
> locked.
> 
> The dccp/IPv6 code is very similar in this respect, so fixing it there too.
> 
> As Eric Garver pointed out the following commit now invalidates routes. Which
> can set the dst->obsolete flag so that ipv4_dst_check() returns null and
> triggers the dst_release().
> 
> Fixes: ceb3320610d6 ("ipv4: Kill routes during PMTU/redirect updates.")
> Cc: Eric Garver 
> Cc: Hannes Sowa 
> Signed-off-by: Jon Maxwell 

Applied and queued up for -stable, thank you.


Re: [PATCH net, v2] dccp/tcp: fix routing redirect race

2017-03-13 Thread David Miller
From: Jon Maxwell 
Date: Fri, 10 Mar 2017 16:40:33 +1100

> As Eric Dumazet pointed out this also needs to be fixed in IPv6.
> v2: Contains the IPv6 tcp/Ipv6 dccp patches as well.
> 
> We have seen a few incidents lately where a dst_enty has been freed
> with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that
> dst_entry. If the conditions/timings are right a crash then ensues when the
> freed dst_entry is referenced later on. A Common crashing back trace is:
 ...
> Of course it may happen with other NIC drivers as well.
> 
> It's found the freed dst_entry here:
 ...
> But there are other backtraces attributed to the same freed dst_entry in
> netfilter code as well.
> 
> All the vmcores showed 2 significant clues:
> 
> - Remote hosts behind the default gateway had always been redirected to a
> different gateway. A rtable/dst_entry will be added for that host. Making
> more dst_entrys with lower reference counts. Making this more probable.
> 
> - All vmcores showed a postitive LockDroppedIcmps value, e.g:
> 
> LockDroppedIcmps  267
> 
> A closer look at the tcp_v4_err() handler revealed that do_redirect() will run
> regardless of whether user space has the socket locked. This can result in a
> race condition where the same dst_entry cached in sk->sk_dst_entry can be
> decremented twice for the same socket via:
> 
> do_redirect()->__sk_dst_check()-> dst_release().
> 
> Which leads to the dst_entry being prematurely freed with another socket
> pointing to it via sk->sk_dst_cache and a subsequent crash.
> 
> To fix this skip do_redirect() if usespace has the socket locked. Instead let
> the redirect take place later when user space does not have the socket
> locked.
> 
> The dccp/IPv6 code is very similar in this respect, so fixing it there too.
> 
> As Eric Garver pointed out the following commit now invalidates routes. Which
> can set the dst->obsolete flag so that ipv4_dst_check() returns null and
> triggers the dst_release().
> 
> Fixes: ceb3320610d6 ("ipv4: Kill routes during PMTU/redirect updates.")
> Cc: Eric Garver 
> Cc: Hannes Sowa 
> Signed-off-by: Jon Maxwell 

Applied and queued up for -stable, thank you.


Re: [PATCH net-next 00/12] net: bcmgenet: add support for GENETv5

2017-03-13 Thread David Miller
From: Doug Berger 
Date: Mon, 13 Mar 2017 17:41:30 -0700

> This collection of patches contains changes related to adding
> support for the BCM7260, BCM7268, and BCM7271 devices that
> contain a new version of the GENET MAC IP block (v5) and a new
> fast ethernet (10/100BASE-T) internal PHY.
> 
> These patches were originally developed on top of the bug fixes
> of the "[PATCH v2 net 0/8] net: bcmgenet: minor bug fixes" patch
> set previously accepted into the net repository, but this
> submission is designed to be applied to the current net-next
> that does not yet include them. As a result there will be some
> merge conflicts that I would be happy to help resolve if desired.
> 
> Specifically, conflicts should occur with these patches from the
> minor bug fixes set:
> [PATCH v2 net 3/8] net: bcmgenet: reserved phy revisions must be checked first
> [PATCH v2 net 5/8] net: bcmgenet: synchronize irq0 status between the isr and 
> task
> [PATCH v2 net 8/8] net: bcmgenet: decouple flow control from 
> bcmgenet_tx_reclaim

Series applied, thanks Doug.


Re: [PATCH net-next 00/12] net: bcmgenet: add support for GENETv5

2017-03-13 Thread David Miller
From: Doug Berger 
Date: Mon, 13 Mar 2017 17:41:30 -0700

> This collection of patches contains changes related to adding
> support for the BCM7260, BCM7268, and BCM7271 devices that
> contain a new version of the GENET MAC IP block (v5) and a new
> fast ethernet (10/100BASE-T) internal PHY.
> 
> These patches were originally developed on top of the bug fixes
> of the "[PATCH v2 net 0/8] net: bcmgenet: minor bug fixes" patch
> set previously accepted into the net repository, but this
> submission is designed to be applied to the current net-next
> that does not yet include them. As a result there will be some
> merge conflicts that I would be happy to help resolve if desired.
> 
> Specifically, conflicts should occur with these patches from the
> minor bug fixes set:
> [PATCH v2 net 3/8] net: bcmgenet: reserved phy revisions must be checked first
> [PATCH v2 net 5/8] net: bcmgenet: synchronize irq0 status between the isr and 
> task
> [PATCH v2 net 8/8] net: bcmgenet: decouple flow control from 
> bcmgenet_tx_reclaim

Series applied, thanks Doug.


[PATCH] Fixed a minor coding style warning. Arguments in the macros should be coverd in brackets to aviod any precedence issues.

2017-03-13 Thread mshan
Signed-off-by: mshan 
---
 drivers/staging/fwserial/fwserial.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fwserial/fwserial.c 
b/drivers/staging/fwserial/fwserial.c
index 41a49c8..d693c03 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -98,7 +98,7 @@ struct fwtty_transaction {
};
 };
 
-#define to_device(a, b)(a->b)
+#define to_device(a, b)((a)->(b))
 #define fwtty_err(p, fmt, ...) \
dev_err(to_device(p, device), fmt, ##__VA_ARGS__)
 #define fwtty_info(p, fmt, ...)
\
-- 
2.7.4



[PATCH] Fixed a minor coding style warning. Arguments in the macros should be coverd in brackets to aviod any precedence issues.

2017-03-13 Thread mshan
Signed-off-by: mshan 
---
 drivers/staging/fwserial/fwserial.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fwserial/fwserial.c 
b/drivers/staging/fwserial/fwserial.c
index 41a49c8..d693c03 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -98,7 +98,7 @@ struct fwtty_transaction {
};
 };
 
-#define to_device(a, b)(a->b)
+#define to_device(a, b)((a)->(b))
 #define fwtty_err(p, fmt, ...) \
dev_err(to_device(p, device), fmt, ##__VA_ARGS__)
 #define fwtty_info(p, fmt, ...)
\
-- 
2.7.4



Re: [PATCH] dma-engine: Fix array index out of bounds warning in __get_unmap_pool()

2017-03-13 Thread Vinod Koul
On Mon, Mar 13, 2017 at 02:30:29PM -0700, Matthias Kaehlcke wrote:
> This fixes the following warning when building with clang and
> CONFIG_DMA_ENGINE_RAID=n :
> 
> drivers/dma/dmaengine.c:1102:11: error: array index 2 is past the end of the 
> array (which contains 1 element) [-Werror,-Warray-bounds]
> return _pool[2];
> ^  ~
> drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here
> static struct dmaengine_unmap_pool unmap_pool[] = {
> ^
> drivers/dma/dmaengine.c:1104:11: error: array index 3 is past the end of the 
> array (which contains 1 element) [-Werror,-Warray-bounds]
> return _pool[3];
> ^  ~
> drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here
> static struct dmaengine_unmap_pool unmap_pool[] = {

Applied, thanks

-- 
~Vinod


Re: [PATCH] dma-engine: Fix array index out of bounds warning in __get_unmap_pool()

2017-03-13 Thread Vinod Koul
On Mon, Mar 13, 2017 at 02:30:29PM -0700, Matthias Kaehlcke wrote:
> This fixes the following warning when building with clang and
> CONFIG_DMA_ENGINE_RAID=n :
> 
> drivers/dma/dmaengine.c:1102:11: error: array index 2 is past the end of the 
> array (which contains 1 element) [-Werror,-Warray-bounds]
> return _pool[2];
> ^  ~
> drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here
> static struct dmaengine_unmap_pool unmap_pool[] = {
> ^
> drivers/dma/dmaengine.c:1104:11: error: array index 3 is past the end of the 
> array (which contains 1 element) [-Werror,-Warray-bounds]
> return _pool[3];
> ^  ~
> drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here
> static struct dmaengine_unmap_pool unmap_pool[] = {

Applied, thanks

-- 
~Vinod


Re: Applied "ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE" to the asoc tree

2017-03-13 Thread Chen-Yu Tsai
Hi Mark,

On Wed, Mar 8, 2017 at 9:22 PM, Mark Brown  wrote:
> The patch
>
>ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE
>
> has been applied to the asoc tree at
>
>git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
> From ca14da6e611674cad275f29ac2aaf1e2eb427c6b Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Myl=C3=A8ne=20Josserand?=
>  
> Date: Fri, 10 Feb 2017 10:41:31 +0100
> Subject: [PATCH] ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Update the driver to use the new SOC_DAPM_DOUBLE definition
> on the digital DAC mixer.
> Update the names accordingly as, when they are shared, the
> controls are not prefixed with the widget's name anymore.
>
> Signed-off-by: Mylène Josserand 
> Acked-by: Chen-Yu Tsai 
> Signed-off-by: Mark Brown 
> ---
>  sound/soc/sunxi/sun8i-codec.c | 45 
> ---
>  1 file changed, 21 insertions(+), 24 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
> index d60f6fbd36a2..107fa8213600 100644
> --- a/sound/soc/sunxi/sun8i-codec.c
> +++ b/sound/soc/sunxi/sun8i-codec.c
> @@ -259,25 +259,20 @@ static int sun8i_codec_hw_params(struct 
> snd_pcm_substream *substream,
> return 0;
>  }
>
> -static const struct snd_kcontrol_new sun8i_output_left_mixer_controls[] = {
> -   SOC_DAPM_SINGLE("LSlot 0", SUN8I_DAC_MXR_SRC,
> -   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L, 1, 0),
> -   SOC_DAPM_SINGLE("LSlot 1", SUN8I_DAC_MXR_SRC,
> -   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L, 1, 0),
> -   SOC_DAPM_SINGLE("DACL", SUN8I_DAC_MXR_SRC,
> -   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL, 1, 0),
> -   SOC_DAPM_SINGLE("ADCL", SUN8I_DAC_MXR_SRC,
> -   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL, 1, 0),
> -};
> -
> -static const struct snd_kcontrol_new sun8i_output_right_mixer_controls[] = {
> -   SOC_DAPM_SINGLE("RSlot 0", SUN8I_DAC_MXR_SRC,
> +static const struct snd_kcontrol_new sun8i_dac_mixer_controls[] = {
> +   SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital DAC Playback Switch",
> +   SUN8I_DAC_MXR_SRC,
> +   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L,
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA0R, 1, 0),
> -   SOC_DAPM_SINGLE("RSlot 1", SUN8I_DAC_MXR_SRC,
> +   SOC_DAPM_DOUBLE("AIF1 Slot 1 Digital DAC Playback Switch",
> +   SUN8I_DAC_MXR_SRC,
> +   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L,
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA1R, 1, 0),
> -   SOC_DAPM_SINGLE("DACR", SUN8I_DAC_MXR_SRC,
> +   SOC_DAPM_DOUBLE("AIF2 Digital DAC Playback Switch", SUN8I_DAC_MXR_SRC,
> +   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL,
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF2DACR, 1, 0),
> -   SOC_DAPM_SINGLE("ADCR", SUN8I_DAC_MXR_SRC,
> +   SOC_DAPM_DOUBLE("ADC Digital DAC Playback Switch", SUN8I_DAC_MXR_SRC,
> +   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL,
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
>  };
>
> @@ -293,12 +288,12 @@ static const struct snd_soc_dapm_widget 
> sun8i_codec_dapm_widgets[] = {
>  SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),
>
> /* DAC Mixers */
> -   SND_SOC_DAPM_MIXER("Left DAC Mixer", SND_SOC_NOPM, 0, 0,
> -  sun8i_output_left_mixer_controls,
> -  ARRAY_SIZE(sun8i_output_left_mixer_controls)),
> -   SND_SOC_DAPM_MIXER("Right DAC Mixer", SND_SOC_NOPM, 0, 0,
> -  sun8i_output_right_mixer_controls,
> -  ARRAY_SIZE(sun8i_output_right_mixer_controls)),
> +   SND_SOC_DAPM_MIXER("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
> +  sun8i_dac_mixer_controls,
> +  

Re: Applied "ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE" to the asoc tree

2017-03-13 Thread Chen-Yu Tsai
Hi Mark,

On Wed, Mar 8, 2017 at 9:22 PM, Mark Brown  wrote:
> The patch
>
>ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE
>
> has been applied to the asoc tree at
>
>git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
> From ca14da6e611674cad275f29ac2aaf1e2eb427c6b Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Myl=C3=A8ne=20Josserand?=
>  
> Date: Fri, 10 Feb 2017 10:41:31 +0100
> Subject: [PATCH] ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Update the driver to use the new SOC_DAPM_DOUBLE definition
> on the digital DAC mixer.
> Update the names accordingly as, when they are shared, the
> controls are not prefixed with the widget's name anymore.
>
> Signed-off-by: Mylène Josserand 
> Acked-by: Chen-Yu Tsai 
> Signed-off-by: Mark Brown 
> ---
>  sound/soc/sunxi/sun8i-codec.c | 45 
> ---
>  1 file changed, 21 insertions(+), 24 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
> index d60f6fbd36a2..107fa8213600 100644
> --- a/sound/soc/sunxi/sun8i-codec.c
> +++ b/sound/soc/sunxi/sun8i-codec.c
> @@ -259,25 +259,20 @@ static int sun8i_codec_hw_params(struct 
> snd_pcm_substream *substream,
> return 0;
>  }
>
> -static const struct snd_kcontrol_new sun8i_output_left_mixer_controls[] = {
> -   SOC_DAPM_SINGLE("LSlot 0", SUN8I_DAC_MXR_SRC,
> -   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L, 1, 0),
> -   SOC_DAPM_SINGLE("LSlot 1", SUN8I_DAC_MXR_SRC,
> -   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L, 1, 0),
> -   SOC_DAPM_SINGLE("DACL", SUN8I_DAC_MXR_SRC,
> -   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL, 1, 0),
> -   SOC_DAPM_SINGLE("ADCL", SUN8I_DAC_MXR_SRC,
> -   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL, 1, 0),
> -};
> -
> -static const struct snd_kcontrol_new sun8i_output_right_mixer_controls[] = {
> -   SOC_DAPM_SINGLE("RSlot 0", SUN8I_DAC_MXR_SRC,
> +static const struct snd_kcontrol_new sun8i_dac_mixer_controls[] = {
> +   SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital DAC Playback Switch",
> +   SUN8I_DAC_MXR_SRC,
> +   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L,
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA0R, 1, 0),
> -   SOC_DAPM_SINGLE("RSlot 1", SUN8I_DAC_MXR_SRC,
> +   SOC_DAPM_DOUBLE("AIF1 Slot 1 Digital DAC Playback Switch",
> +   SUN8I_DAC_MXR_SRC,
> +   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L,
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA1R, 1, 0),
> -   SOC_DAPM_SINGLE("DACR", SUN8I_DAC_MXR_SRC,
> +   SOC_DAPM_DOUBLE("AIF2 Digital DAC Playback Switch", SUN8I_DAC_MXR_SRC,
> +   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL,
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF2DACR, 1, 0),
> -   SOC_DAPM_SINGLE("ADCR", SUN8I_DAC_MXR_SRC,
> +   SOC_DAPM_DOUBLE("ADC Digital DAC Playback Switch", SUN8I_DAC_MXR_SRC,
> +   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL,
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
>  };
>
> @@ -293,12 +288,12 @@ static const struct snd_soc_dapm_widget 
> sun8i_codec_dapm_widgets[] = {
>  SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),
>
> /* DAC Mixers */
> -   SND_SOC_DAPM_MIXER("Left DAC Mixer", SND_SOC_NOPM, 0, 0,
> -  sun8i_output_left_mixer_controls,
> -  ARRAY_SIZE(sun8i_output_left_mixer_controls)),
> -   SND_SOC_DAPM_MIXER("Right DAC Mixer", SND_SOC_NOPM, 0, 0,
> -  sun8i_output_right_mixer_controls,
> -  ARRAY_SIZE(sun8i_output_right_mixer_controls)),
> +   SND_SOC_DAPM_MIXER("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
> +  sun8i_dac_mixer_controls,
> +  ARRAY_SIZE(sun8i_dac_mixer_controls)),
> +   SND_SOC_DAPM_MIXER("Right Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
> +  

Re: [PATCH V7 6/7] LIBIO: Support the dynamically logical PIO registration of ACPI host I/O

2017-03-13 Thread kbuild test robot
Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86/boot/compressed/misc.h:24:0,
from arch/x86/boot/compressed/cmdline.c:1:
>> arch/x86/boot/compressed/../ctype.h:4:19: error: redefinition of 'isdigit'
static inline int isdigit(int ch)
  ^~~
   In file included from include/acpi/platform/aclinux.h:82:0,
from include/acpi/platform/acenv.h:186,
from include/acpi/acpi.h:56,
from include/linux/acpi.h:33,
from include/linux/libio.h:23,
from include/linux/io.h:27,
from arch/x86/boot/compressed/misc.h:17,
from arch/x86/boot/compressed/cmdline.c:1:
   include/linux/ctype.h:25:19: note: previous definition of 'isdigit' was here
static inline int isdigit(int c)
  ^~~
>> arch/x86/boot/compressed/../ctype.h:9:32: error: expected ')' before 'ch'
static inline int isxdigit(int ch)
   ^
   include/linux/ctype.h:20:50: note: in definition of macro '__ismask'
#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
 ^
   arch/x86/boot/compressed/../ctype.h:9:19: note: in expansion of macro 
'isxdigit'
static inline int isxdigit(int ch)
  ^~~~
   include/linux/ctype.h:20:52: error: expected expression before ']' token
#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
   ^
   include/linux/ctype.h:36:23: note: in expansion of macro '__ismask'
#define isxdigit(c) ((__ismask(c)&(_D|_X)) != 0)
  ^~~~
   arch/x86/boot/compressed/../ctype.h:9:19: note: in expansion of macro 
'isxdigit'
static inline int isxdigit(int ch)
  ^~~~
   include/linux/ctype.h:36:44: error: expected ')' before '!=' token
#define isxdigit(c) ((__ismask(c)&(_D|_X)) != 0)
   ^
   arch/x86/boot/compressed/../ctype.h:9:19: note: in expansion of macro 
'isxdigit'
static inline int isxdigit(int ch)
  ^~~~

vim +/isdigit +4 arch/x86/boot/compressed/../ctype.h

60b217a0 arch/x86/boot/ctype.h   Alexander Kuleshov 2015-01-03   1  #ifndef 
BOOT_CTYPE_H
60b217a0 arch/x86/boot/ctype.h   Alexander Kuleshov 2015-01-03   2  #define 
BOOT_CTYPE_H
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   3  
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  @4  static 
inline int isdigit(int ch)
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   5  {
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   6  return 
(ch >= '0') && (ch <= '9');
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   7  }
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   8  
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  @9  static 
inline int isxdigit(int ch)
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  10  {
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  11  if 
(isdigit(ch))
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  12  
return true;

:: The code at line 4 was first introduced by commit
:: f4ed2877b16e8146427306aea8819adac5c88374 x86, setup: reorganize the 
early console setup

:: TO: Yinghai Lu 
:: CC: H. Peter Anvin 

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


.config.gz
Description: application/gzip


Re: [PATCH V7 6/7] LIBIO: Support the dynamically logical PIO registration of ACPI host I/O

2017-03-13 Thread kbuild test robot
Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/zhichang-yuan/LPC-legacy-ISA-I-O-support/20170314-114635
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86/boot/compressed/misc.h:24:0,
from arch/x86/boot/compressed/cmdline.c:1:
>> arch/x86/boot/compressed/../ctype.h:4:19: error: redefinition of 'isdigit'
static inline int isdigit(int ch)
  ^~~
   In file included from include/acpi/platform/aclinux.h:82:0,
from include/acpi/platform/acenv.h:186,
from include/acpi/acpi.h:56,
from include/linux/acpi.h:33,
from include/linux/libio.h:23,
from include/linux/io.h:27,
from arch/x86/boot/compressed/misc.h:17,
from arch/x86/boot/compressed/cmdline.c:1:
   include/linux/ctype.h:25:19: note: previous definition of 'isdigit' was here
static inline int isdigit(int c)
  ^~~
>> arch/x86/boot/compressed/../ctype.h:9:32: error: expected ')' before 'ch'
static inline int isxdigit(int ch)
   ^
   include/linux/ctype.h:20:50: note: in definition of macro '__ismask'
#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
 ^
   arch/x86/boot/compressed/../ctype.h:9:19: note: in expansion of macro 
'isxdigit'
static inline int isxdigit(int ch)
  ^~~~
   include/linux/ctype.h:20:52: error: expected expression before ']' token
#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
   ^
   include/linux/ctype.h:36:23: note: in expansion of macro '__ismask'
#define isxdigit(c) ((__ismask(c)&(_D|_X)) != 0)
  ^~~~
   arch/x86/boot/compressed/../ctype.h:9:19: note: in expansion of macro 
'isxdigit'
static inline int isxdigit(int ch)
  ^~~~
   include/linux/ctype.h:36:44: error: expected ')' before '!=' token
#define isxdigit(c) ((__ismask(c)&(_D|_X)) != 0)
   ^
   arch/x86/boot/compressed/../ctype.h:9:19: note: in expansion of macro 
'isxdigit'
static inline int isxdigit(int ch)
  ^~~~

vim +/isdigit +4 arch/x86/boot/compressed/../ctype.h

60b217a0 arch/x86/boot/ctype.h   Alexander Kuleshov 2015-01-03   1  #ifndef 
BOOT_CTYPE_H
60b217a0 arch/x86/boot/ctype.h   Alexander Kuleshov 2015-01-03   2  #define 
BOOT_CTYPE_H
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   3  
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  @4  static 
inline int isdigit(int ch)
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   5  {
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   6  return 
(ch >= '0') && (ch <= '9');
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   7  }
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02   8  
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  @9  static 
inline int isxdigit(int ch)
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  10  {
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  11  if 
(isdigit(ch))
f4ed2877 arch/x86/boot/isdigit.h Yinghai Lu 2010-08-02  12  
return true;

:: The code at line 4 was first introduced by commit
:: f4ed2877b16e8146427306aea8819adac5c88374 x86, setup: reorganize the 
early console setup

:: TO: Yinghai Lu 
:: CC: H. Peter Anvin 

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


.config.gz
Description: application/gzip


[PATCH] x86/unwind: Fix last frame check for aligned function stacks

2017-03-13 Thread Josh Poimboeuf
Pavel Machek reported the following warning on x86-32:

  WARNING: kernel stack frame pointer at f50cdf98 in swapper/2:0 has bad value  
 (null)

The warning is caused by the unwinder not realizing that it reached the
end of the stack, due to an unusual prologue which gcc sometimes
generates for aligned stacks.  The prologue is based on a gcc feature
called the Dynamic Realign Argument Pointer (DRAP).  It's almost always
enabled for aligned stacks when -maccumulate-outgoing-args isn't set.

This issue is similar to the one fixed by the following commit:

  8023e0e2a48d ("x86/unwind: Adjust last frame check for aligned function 
stacks")

... but that fix was specific to x86-64.

Make the fix more generic to cover x86-32 as well, and also ensure that
the return address referred to by the frame pointer is a copy of the
original return address.

Reported-by: Pavel Machek 
Fixes: acb4608ad186 ("x86/unwind: Create stack frames for saved syscall 
registers")
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/kernel/unwind_frame.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index 478d15d..0833926 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -82,19 +82,43 @@ static size_t regs_size(struct pt_regs *regs)
return sizeof(*regs);
 }
 
+#ifdef CONFIG_X86_32
+#define GCC_REALIGN_WORDS 3
+#else
+#define GCC_REALIGN_WORDS 1
+#endif
+
 static bool is_last_task_frame(struct unwind_state *state)
 {
-   unsigned long bp = (unsigned long)state->bp;
-   unsigned long regs = (unsigned long)task_pt_regs(state->task);
+   unsigned long *last_bp = (unsigned long *)task_pt_regs(state->task) - 2;
+   unsigned long *aligned_bp = last_bp - GCC_REALIGN_WORDS;
 
/*
 * We have to check for the last task frame at two different locations
 * because gcc can occasionally decide to realign the stack pointer and
-* change the offset of the stack frame by a word in the prologue of a
-* function called by head/entry code.
+* change the offset of the stack frame in the prologue of a function
+* called by head/entry code.  Examples:
+*
+* :
+*  push   %edi
+*  lea0x8(%esp),%edi
+*  and$0xfff8,%esp
+*  pushl  -0x4(%edi)
+*  push   %ebp
+*  mov%esp,%ebp
+*
+* :
+*  lea0x8(%rsp),%r10
+*  and$0xfff0,%rsp
+*  pushq  -0x8(%r10)
+*  push   %rbp
+*  mov%rsp,%rbp
+*
+* Note that after aligning the stack, it pushes a duplicate copy of
+* the return address before pushing the frame pointer.
 */
-   return bp == regs - FRAME_HEADER_SIZE ||
-  bp == regs - FRAME_HEADER_SIZE - sizeof(long);
+   return (state->bp == last_bp ||
+   (state->bp == aligned_bp && *(aligned_bp+1) == *(last_bp+1)));
 }
 
 /*
-- 
2.7.4



[PATCH] x86/unwind: Fix last frame check for aligned function stacks

2017-03-13 Thread Josh Poimboeuf
Pavel Machek reported the following warning on x86-32:

  WARNING: kernel stack frame pointer at f50cdf98 in swapper/2:0 has bad value  
 (null)

The warning is caused by the unwinder not realizing that it reached the
end of the stack, due to an unusual prologue which gcc sometimes
generates for aligned stacks.  The prologue is based on a gcc feature
called the Dynamic Realign Argument Pointer (DRAP).  It's almost always
enabled for aligned stacks when -maccumulate-outgoing-args isn't set.

This issue is similar to the one fixed by the following commit:

  8023e0e2a48d ("x86/unwind: Adjust last frame check for aligned function 
stacks")

... but that fix was specific to x86-64.

Make the fix more generic to cover x86-32 as well, and also ensure that
the return address referred to by the frame pointer is a copy of the
original return address.

Reported-by: Pavel Machek 
Fixes: acb4608ad186 ("x86/unwind: Create stack frames for saved syscall 
registers")
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/kernel/unwind_frame.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index 478d15d..0833926 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -82,19 +82,43 @@ static size_t regs_size(struct pt_regs *regs)
return sizeof(*regs);
 }
 
+#ifdef CONFIG_X86_32
+#define GCC_REALIGN_WORDS 3
+#else
+#define GCC_REALIGN_WORDS 1
+#endif
+
 static bool is_last_task_frame(struct unwind_state *state)
 {
-   unsigned long bp = (unsigned long)state->bp;
-   unsigned long regs = (unsigned long)task_pt_regs(state->task);
+   unsigned long *last_bp = (unsigned long *)task_pt_regs(state->task) - 2;
+   unsigned long *aligned_bp = last_bp - GCC_REALIGN_WORDS;
 
/*
 * We have to check for the last task frame at two different locations
 * because gcc can occasionally decide to realign the stack pointer and
-* change the offset of the stack frame by a word in the prologue of a
-* function called by head/entry code.
+* change the offset of the stack frame in the prologue of a function
+* called by head/entry code.  Examples:
+*
+* :
+*  push   %edi
+*  lea0x8(%esp),%edi
+*  and$0xfff8,%esp
+*  pushl  -0x4(%edi)
+*  push   %ebp
+*  mov%esp,%ebp
+*
+* :
+*  lea0x8(%rsp),%r10
+*  and$0xfff0,%rsp
+*  pushq  -0x8(%r10)
+*  push   %rbp
+*  mov%rsp,%rbp
+*
+* Note that after aligning the stack, it pushes a duplicate copy of
+* the return address before pushing the frame pointer.
 */
-   return bp == regs - FRAME_HEADER_SIZE ||
-  bp == regs - FRAME_HEADER_SIZE - sizeof(long);
+   return (state->bp == last_bp ||
+   (state->bp == aligned_bp && *(aligned_bp+1) == *(last_bp+1)));
 }
 
 /*
-- 
2.7.4



Re: [PATCH v2 06/12] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

2017-03-13 Thread Vinod Koul
On Sun, Mar 05, 2017 at 09:37:03PM +0800, Icenowy Zheng wrote:
> Originally we enable a special gate bit when the compatible indicates
> A23/33.
> 
> But according to BSP sources and user manuals, more SoCs will need this
> gate bit.
> 
> So make it a common quirk configured in the config struct.
> 
> The BSP source also indicates that A83T will need this gate bit (there's
> "SUN8IW6" in the #ifdef's), so also enable this gate bit for it.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/dma/sun6i-dma.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a2358780ab2c..889fb24023cd 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -101,6 +101,7 @@ struct sun6i_dma_config {
>   u32 nr_max_channels;
>   u32 nr_max_requests;
>   u32 nr_max_vchans;
> + bool gate_needed;

can you please explain what gate means here

-- 
~Vinod


Re: [PATCH v2 06/12] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

2017-03-13 Thread Vinod Koul
On Sun, Mar 05, 2017 at 09:37:03PM +0800, Icenowy Zheng wrote:
> Originally we enable a special gate bit when the compatible indicates
> A23/33.
> 
> But according to BSP sources and user manuals, more SoCs will need this
> gate bit.
> 
> So make it a common quirk configured in the config struct.
> 
> The BSP source also indicates that A83T will need this gate bit (there's
> "SUN8IW6" in the #ifdef's), so also enable this gate bit for it.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/dma/sun6i-dma.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a2358780ab2c..889fb24023cd 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -101,6 +101,7 @@ struct sun6i_dma_config {
>   u32 nr_max_channels;
>   u32 nr_max_requests;
>   u32 nr_max_vchans;
> + bool gate_needed;

can you please explain what gate means here

-- 
~Vinod


Re: [PATCH] x86/mm: trivial code cleanup for memory_map_top_doown()

2017-03-13 Thread Wei Yang
On Mon, Mar 13, 2017 at 07:50:21PM +0100, Borislav Petkov wrote:
>On Fri, Feb 17, 2017 at 10:30:33PM +0800, Wei Yang wrote:
>> In case (last_start <= step_size), start is for sure to be 0. So, it is
>

Hmm, I may write it more specific:

"start" is for sure to be set to 0 with round_down(last_start - 1, step_size).

>Well, lemme see:
>
>[0.00] memory_map_top_down: entry, [0x10:0x7ffdf000)
>[0.00] memory_map_top_down: addr: 0x7fc0, real_end: 0x7fe0
>[0.00] memory_map_top_down: last_start: 0x4000 <= step_size: 
>0x20, start: 0x4000
>   
>   ^^
>It doesn't look like 0 to me.
>
>---
>diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>index 2193799ca800..d3b02a416df3 100644
>--- a/arch/x86/mm/init.c
>+++ b/arch/x86/mm/init.c
>@@ -527,8 +531,13 @@ static void __init memory_map_top_down(unsigned long 
>map_start,
>   start = round_down(last_start - 1, step_size);
>   if (start < map_start)
>   start = map_start;
>-  } else
>+  } else {
>+  pr_info("%s: last_start: 0x%lx <= step_size: 0x%lx, 
>start: 0x%lx\n",
>+  __func__, last_start, step_size, start);
>+

If you change this log with the following

pr_err("%s: last_start: 0x%lx <= step_size: 0x%lx, 
start: 0x%lx\n",
__func__, last_start, step_size,
round_down(last_start - 1, step_size));

You could see after calculation, start is 0 when (last_start <= step_size).

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH] x86/mm: trivial code cleanup for memory_map_top_doown()

2017-03-13 Thread Wei Yang
On Mon, Mar 13, 2017 at 07:50:21PM +0100, Borislav Petkov wrote:
>On Fri, Feb 17, 2017 at 10:30:33PM +0800, Wei Yang wrote:
>> In case (last_start <= step_size), start is for sure to be 0. So, it is
>

Hmm, I may write it more specific:

"start" is for sure to be set to 0 with round_down(last_start - 1, step_size).

>Well, lemme see:
>
>[0.00] memory_map_top_down: entry, [0x10:0x7ffdf000)
>[0.00] memory_map_top_down: addr: 0x7fc0, real_end: 0x7fe0
>[0.00] memory_map_top_down: last_start: 0x4000 <= step_size: 
>0x20, start: 0x4000
>   
>   ^^
>It doesn't look like 0 to me.
>
>---
>diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>index 2193799ca800..d3b02a416df3 100644
>--- a/arch/x86/mm/init.c
>+++ b/arch/x86/mm/init.c
>@@ -527,8 +531,13 @@ static void __init memory_map_top_down(unsigned long 
>map_start,
>   start = round_down(last_start - 1, step_size);
>   if (start < map_start)
>   start = map_start;
>-  } else
>+  } else {
>+  pr_info("%s: last_start: 0x%lx <= step_size: 0x%lx, 
>start: 0x%lx\n",
>+  __func__, last_start, step_size, start);
>+

If you change this log with the following

pr_err("%s: last_start: 0x%lx <= step_size: 0x%lx, 
start: 0x%lx\n",
__func__, last_start, step_size,
round_down(last_start - 1, step_size));

You could see after calculation, start is 0 when (last_start <= step_size).

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH] fscrypt: remove broken support for detecting keyring key revocation

2017-03-13 Thread Michael Halcrow
On Tue, Feb 21, 2017 at 03:07:11PM -0800, Eric Biggers wrote:
> From: Eric Biggers 
> 
> Filesystem encryption ostensibly supported revoking a keyring key
> that had been used to "unlock" encrypted files, causing those files
> to become "locked" again. This was, however, buggy for several
> reasons, the most severe of which was that when key revocation
> happened to be detected for an inode, its fscrypt_info was
> immediately freed, even while other threads could be using it for
> encryption or decryption concurrently.  This could be exploited to
> crash the kernel or worse.

Removing the attempt at that functionality seems like the right
approach.

> This patch fixes the use-after-free by removing the code which
> detects the keyring key having been revoked, invalidated, or
> expired.  Instead, an encrypted inode that is "unlocked" now simply
> remains unlocked until it is evicted from memory.  Note that this is
> no worse than the case for block device-level encryption,
> e.g. dm-crypt, and it still remains possible for a privileged user
> to evict unused pages, inodes, and dentries by running 'sync; echo 3
> > /proc/sys/vm/drop_caches', or by simply unmounting the filesystem.
> In fact, one of those actions was already needed anyway for key
> revocation to work even somewhat sanely.  This change is not
> expected to break any applications.

I don't see any problem with this reasoning.

> In the future I'd like to implement a real API for fscrypt key
> revocation that interacts sanely with ongoing filesystem operations ---
> waiting for existing operations to complete and blocking new operations,
> and invalidating and sanitizing key material and plaintext from the VFS
> caches.  But this is a hard problem, and for now this bug must be fixed.
> 
> This bug affected almost all versions of ext4, f2fs, and ubifs
> encryption, and it was potentially reachable in any kernel configured
> with encryption support (CONFIG_EXT4_ENCRYPTION=y,
> CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
> CONFIG_UBIFS_FS_ENCRYPTION=y).  Note that older kernels did not use the
> shared fs/crypto/ code, but due to the potential security implications
> of this bug, it may still be worthwhile to backport this fix to them.

Agreed.

> Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
> Cc: sta...@vger.kernel.org # v4.2+
> Signed-off-by: Eric Biggers 

Acked-by: Michael Halcrow 

> ---
>  fs/crypto/crypto.c  | 10 +
>  fs/crypto/fname.c   |  2 +-
>  fs/crypto/fscrypt_private.h |  4 
>  fs/crypto/keyinfo.c | 52 
> -
>  4 files changed, 11 insertions(+), 57 deletions(-)
> 
> diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c
> index 02a7a9286449..6d6eca394d4d 100644
> --- a/fs/crypto/crypto.c
> +++ b/fs/crypto/crypto.c
> @@ -327,7 +327,6 @@ EXPORT_SYMBOL(fscrypt_decrypt_page);
>  static int fscrypt_d_revalidate(struct dentry *dentry, unsigned int flags)
>  {
>   struct dentry *dir;
> - struct fscrypt_info *ci;
>   int dir_has_key, cached_with_key;
>  
>   if (flags & LOOKUP_RCU)
> @@ -339,18 +338,11 @@ static int fscrypt_d_revalidate(struct dentry *dentry, 
> unsigned int flags)
>   return 0;
>   }
>  
> - ci = d_inode(dir)->i_crypt_info;
> - if (ci && ci->ci_keyring_key &&
> - (ci->ci_keyring_key->flags & ((1 << KEY_FLAG_INVALIDATED) |
> -   (1 << KEY_FLAG_REVOKED) |
> -   (1 << KEY_FLAG_DEAD
> - ci = NULL;
> -
>   /* this should eventually be an flag in d_flags */
>   spin_lock(>d_lock);
>   cached_with_key = dentry->d_flags & DCACHE_ENCRYPTED_WITH_KEY;
>   spin_unlock(>d_lock);
> - dir_has_key = (ci != NULL);
> + dir_has_key = (d_inode(dir)->i_crypt_info != NULL);
>   dput(dir);
>  
>   /*
> diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c
> index 13052b85c393..37b49894c762 100644
> --- a/fs/crypto/fname.c
> +++ b/fs/crypto/fname.c
> @@ -350,7 +350,7 @@ int fscrypt_setup_filename(struct inode *dir, const 
> struct qstr *iname,
>   fname->disk_name.len = iname->len;
>   return 0;
>   }
> - ret = fscrypt_get_crypt_info(dir);
> + ret = fscrypt_get_encryption_info(dir);
>   if (ret && ret != -EOPNOTSUPP)
>   return ret;
>  
> diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
> index fdbb8af32eaf..e39696e64494 100644
> --- a/fs/crypto/fscrypt_private.h
> +++ b/fs/crypto/fscrypt_private.h
> @@ -67,7 +67,6 @@ struct fscrypt_info {
>   u8 ci_filename_mode;
>   u8 ci_flags;
>   struct crypto_skcipher *ci_ctfm;
> - struct key *ci_keyring_key;
>   u8 ci_master_key[FS_KEY_DESCRIPTOR_SIZE];
>  };
>  
> @@ -101,7 +100,4 @@ extern int fscrypt_do_page_crypto(const struct inode 
> *inode,
>  extern struct 

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

2017-03-13 Thread Mauro Carvalho Chehab
Hi Sakari,

I started preparing a long argument about it, but gave up in favor of a
simpler one.

Em Mon, 13 Mar 2017 14:46:22 +0200
Sakari Ailus  escreveu:

> Drivers are written to support hardware, not particular use case.  

No, it is just the reverse: drivers and hardware are developed to
support use cases.

Btw, you should remember that the hardware is the full board, not just the
SoC. In practice, the board do limit the use cases: several provide a
single physical CSI connector, allowing just one sensor.

> > This situation is there since 2009. If I remember well, you tried to write
> > such generic plugin in the past, but never finished it, apparently because
> > it is too complex. Others tried too over the years.   
> 
> I'd argue I know better what happened with that attempt than you do. I had a
> prototype of a generic pipeline configuration library but due to various
> reasons I haven't been able to continue working on that since around 2012.

...

> > The last trial was done by Jacek, trying to cover just the exynos4 driver. 
> > Yet, even such limited scope plugin was not good enough, as it was never
> > merged upstream. Currently, there's no such plugins upstream.
> > 
> > If we can't even merge a plugin that solves it for just *one* driver,
> > I have no hope that we'll be able to do it for the generic case.  
> 
> I believe Jacek ceased to work on that plugin in his day job; other than
> that, there are some matters left to be addressed in his latest patchset.

The two above basically summaries the issue: the task of doing a generic
plugin on userspace, even for a single driver is complex enough to
not cover within a reasonable timeline.

>From 2009 to 2012, you were working on it, but didn't finish it.

Apparently, nobody worked on it between 2013-2014 (but I may be wrong, as
I didn't check when the generic plugin interface was added to libv4l).

In the case of Jacek's work, the first patch I was able to find was
written in Oct, 2014:
https://patchwork.kernel.org/patch/5098111/
(not sure what happened with the version 1).

The last e-mail about this subject was issued in Dec, 2016.

In summary, you had this on your task for 3 years for an OMAP3
plugin (where you have a good expertise), and Jacek for 2 years, 
for Exynos 4, where he should also have a good knowledge.

Yet, with all that efforts, no concrete results were achieved, as none
of the plugins got merged.

Even if they were merged, if we keep the same mean time to develop a
libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
years to be developed.

There's a clear message on it:
- we shouldn't keep pushing for a solution via libv4l.

Thanks,
Mauro


Re: [PATCH] fscrypt: remove broken support for detecting keyring key revocation

2017-03-13 Thread Michael Halcrow
On Tue, Feb 21, 2017 at 03:07:11PM -0800, Eric Biggers wrote:
> From: Eric Biggers 
> 
> Filesystem encryption ostensibly supported revoking a keyring key
> that had been used to "unlock" encrypted files, causing those files
> to become "locked" again. This was, however, buggy for several
> reasons, the most severe of which was that when key revocation
> happened to be detected for an inode, its fscrypt_info was
> immediately freed, even while other threads could be using it for
> encryption or decryption concurrently.  This could be exploited to
> crash the kernel or worse.

Removing the attempt at that functionality seems like the right
approach.

> This patch fixes the use-after-free by removing the code which
> detects the keyring key having been revoked, invalidated, or
> expired.  Instead, an encrypted inode that is "unlocked" now simply
> remains unlocked until it is evicted from memory.  Note that this is
> no worse than the case for block device-level encryption,
> e.g. dm-crypt, and it still remains possible for a privileged user
> to evict unused pages, inodes, and dentries by running 'sync; echo 3
> > /proc/sys/vm/drop_caches', or by simply unmounting the filesystem.
> In fact, one of those actions was already needed anyway for key
> revocation to work even somewhat sanely.  This change is not
> expected to break any applications.

I don't see any problem with this reasoning.

> In the future I'd like to implement a real API for fscrypt key
> revocation that interacts sanely with ongoing filesystem operations ---
> waiting for existing operations to complete and blocking new operations,
> and invalidating and sanitizing key material and plaintext from the VFS
> caches.  But this is a hard problem, and for now this bug must be fixed.
> 
> This bug affected almost all versions of ext4, f2fs, and ubifs
> encryption, and it was potentially reachable in any kernel configured
> with encryption support (CONFIG_EXT4_ENCRYPTION=y,
> CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
> CONFIG_UBIFS_FS_ENCRYPTION=y).  Note that older kernels did not use the
> shared fs/crypto/ code, but due to the potential security implications
> of this bug, it may still be worthwhile to backport this fix to them.

Agreed.

> Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
> Cc: sta...@vger.kernel.org # v4.2+
> Signed-off-by: Eric Biggers 

Acked-by: Michael Halcrow 

> ---
>  fs/crypto/crypto.c  | 10 +
>  fs/crypto/fname.c   |  2 +-
>  fs/crypto/fscrypt_private.h |  4 
>  fs/crypto/keyinfo.c | 52 
> -
>  4 files changed, 11 insertions(+), 57 deletions(-)
> 
> diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c
> index 02a7a9286449..6d6eca394d4d 100644
> --- a/fs/crypto/crypto.c
> +++ b/fs/crypto/crypto.c
> @@ -327,7 +327,6 @@ EXPORT_SYMBOL(fscrypt_decrypt_page);
>  static int fscrypt_d_revalidate(struct dentry *dentry, unsigned int flags)
>  {
>   struct dentry *dir;
> - struct fscrypt_info *ci;
>   int dir_has_key, cached_with_key;
>  
>   if (flags & LOOKUP_RCU)
> @@ -339,18 +338,11 @@ static int fscrypt_d_revalidate(struct dentry *dentry, 
> unsigned int flags)
>   return 0;
>   }
>  
> - ci = d_inode(dir)->i_crypt_info;
> - if (ci && ci->ci_keyring_key &&
> - (ci->ci_keyring_key->flags & ((1 << KEY_FLAG_INVALIDATED) |
> -   (1 << KEY_FLAG_REVOKED) |
> -   (1 << KEY_FLAG_DEAD
> - ci = NULL;
> -
>   /* this should eventually be an flag in d_flags */
>   spin_lock(>d_lock);
>   cached_with_key = dentry->d_flags & DCACHE_ENCRYPTED_WITH_KEY;
>   spin_unlock(>d_lock);
> - dir_has_key = (ci != NULL);
> + dir_has_key = (d_inode(dir)->i_crypt_info != NULL);
>   dput(dir);
>  
>   /*
> diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c
> index 13052b85c393..37b49894c762 100644
> --- a/fs/crypto/fname.c
> +++ b/fs/crypto/fname.c
> @@ -350,7 +350,7 @@ int fscrypt_setup_filename(struct inode *dir, const 
> struct qstr *iname,
>   fname->disk_name.len = iname->len;
>   return 0;
>   }
> - ret = fscrypt_get_crypt_info(dir);
> + ret = fscrypt_get_encryption_info(dir);
>   if (ret && ret != -EOPNOTSUPP)
>   return ret;
>  
> diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
> index fdbb8af32eaf..e39696e64494 100644
> --- a/fs/crypto/fscrypt_private.h
> +++ b/fs/crypto/fscrypt_private.h
> @@ -67,7 +67,6 @@ struct fscrypt_info {
>   u8 ci_filename_mode;
>   u8 ci_flags;
>   struct crypto_skcipher *ci_ctfm;
> - struct key *ci_keyring_key;
>   u8 ci_master_key[FS_KEY_DESCRIPTOR_SIZE];
>  };
>  
> @@ -101,7 +100,4 @@ extern int fscrypt_do_page_crypto(const struct inode 
> *inode,
>  extern struct page *fscrypt_alloc_bounce_page(struct fscrypt_ctx *ctx,
>   

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

2017-03-13 Thread Mauro Carvalho Chehab
Hi Sakari,

I started preparing a long argument about it, but gave up in favor of a
simpler one.

Em Mon, 13 Mar 2017 14:46:22 +0200
Sakari Ailus  escreveu:

> Drivers are written to support hardware, not particular use case.  

No, it is just the reverse: drivers and hardware are developed to
support use cases.

Btw, you should remember that the hardware is the full board, not just the
SoC. In practice, the board do limit the use cases: several provide a
single physical CSI connector, allowing just one sensor.

> > This situation is there since 2009. If I remember well, you tried to write
> > such generic plugin in the past, but never finished it, apparently because
> > it is too complex. Others tried too over the years.   
> 
> I'd argue I know better what happened with that attempt than you do. I had a
> prototype of a generic pipeline configuration library but due to various
> reasons I haven't been able to continue working on that since around 2012.

...

> > The last trial was done by Jacek, trying to cover just the exynos4 driver. 
> > Yet, even such limited scope plugin was not good enough, as it was never
> > merged upstream. Currently, there's no such plugins upstream.
> > 
> > If we can't even merge a plugin that solves it for just *one* driver,
> > I have no hope that we'll be able to do it for the generic case.  
> 
> I believe Jacek ceased to work on that plugin in his day job; other than
> that, there are some matters left to be addressed in his latest patchset.

The two above basically summaries the issue: the task of doing a generic
plugin on userspace, even for a single driver is complex enough to
not cover within a reasonable timeline.

>From 2009 to 2012, you were working on it, but didn't finish it.

Apparently, nobody worked on it between 2013-2014 (but I may be wrong, as
I didn't check when the generic plugin interface was added to libv4l).

In the case of Jacek's work, the first patch I was able to find was
written in Oct, 2014:
https://patchwork.kernel.org/patch/5098111/
(not sure what happened with the version 1).

The last e-mail about this subject was issued in Dec, 2016.

In summary, you had this on your task for 3 years for an OMAP3
plugin (where you have a good expertise), and Jacek for 2 years, 
for Exynos 4, where he should also have a good knowledge.

Yet, with all that efforts, no concrete results were achieved, as none
of the plugins got merged.

Even if they were merged, if we keep the same mean time to develop a
libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
years to be developed.

There's a clear message on it:
- we shouldn't keep pushing for a solution via libv4l.

Thanks,
Mauro


Re: [PATCH v2 2/2] dma: xilinx: Add reset support

2017-03-13 Thread Vinod Koul
On Mon, Mar 06, 2017 at 12:17:39PM +, Ramiro Oliveira wrote:
> Add a DT property to control an optional external reset line
> 
> Signed-off-by: Ramiro Oliveira 
> ---
>  drivers/dma/xilinx/xilinx_dma.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 5c9f11b623ca..589cbb611bc8 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -32,20 +32,21 @@
>   */
>  
>  #include 
> -#include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
> +#include 
>  #include 
> -#include 
> -#include 

this is noise in the patch, if you want to change the order feel free to
send a separate patch

>  
>  #include "../dmaengine.h"
>  
> @@ -409,6 +410,7 @@ struct xilinx_dma_device {
>   struct clk *rxs_clk;
>   u32 nr_channels;
>   u32 chan_id;
> + struct reset_control *rst;
>  };
>  
>  /* Macros */
> @@ -2543,6 +2545,20 @@ static int xilinx_dma_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(xdev->regs))
>   return PTR_ERR(xdev->regs);
>  
> + xdev->rst = devm_reset_control_get_optional_shared(>dev, NULL);
> + if (IS_ERR(xdev->rst)) {
> + err = PTR_ERR(xdev->rst);
> + if (err == -EPROBE_DEFER)
> + return err;
> + xdev->rst = NULL;

is this optional, how will it work if you can't bring device out if reset

> + } else {
> + err = reset_control_deassert(xdev->rst);
> + if (err) {
> + dev_err(xdev->dev, "error deasserting reset %d\n", err);
> + return err;
> + }
> + }
> +
>   /* Retrieve the DMA engine properties from the device tree */
>   xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
>   if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
> -- 
> 2.11.0
> 
> 

-- 
~Vinod


Re: [PATCH v2 2/2] dma: xilinx: Add reset support

2017-03-13 Thread Vinod Koul
On Mon, Mar 06, 2017 at 12:17:39PM +, Ramiro Oliveira wrote:
> Add a DT property to control an optional external reset line
> 
> Signed-off-by: Ramiro Oliveira 
> ---
>  drivers/dma/xilinx/xilinx_dma.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 5c9f11b623ca..589cbb611bc8 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -32,20 +32,21 @@
>   */
>  
>  #include 
> -#include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
> +#include 
>  #include 
> -#include 
> -#include 

this is noise in the patch, if you want to change the order feel free to
send a separate patch

>  
>  #include "../dmaengine.h"
>  
> @@ -409,6 +410,7 @@ struct xilinx_dma_device {
>   struct clk *rxs_clk;
>   u32 nr_channels;
>   u32 chan_id;
> + struct reset_control *rst;
>  };
>  
>  /* Macros */
> @@ -2543,6 +2545,20 @@ static int xilinx_dma_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(xdev->regs))
>   return PTR_ERR(xdev->regs);
>  
> + xdev->rst = devm_reset_control_get_optional_shared(>dev, NULL);
> + if (IS_ERR(xdev->rst)) {
> + err = PTR_ERR(xdev->rst);
> + if (err == -EPROBE_DEFER)
> + return err;
> + xdev->rst = NULL;

is this optional, how will it work if you can't bring device out if reset

> + } else {
> + err = reset_control_deassert(xdev->rst);
> + if (err) {
> + dev_err(xdev->dev, "error deasserting reset %d\n", err);
> + return err;
> + }
> + }
> +
>   /* Retrieve the DMA engine properties from the device tree */
>   xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
>   if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
> -- 
> 2.11.0
> 
> 

-- 
~Vinod


[PATCH v8 3/4] irqchip/qeic: merge qeic_of_init into qe_ic_init

2017-03-13 Thread Zhao Qiang
qeic_of_init just get device_node of qeic from dtb and call qe_ic_init,
pass the device_node to qe_ic_init.
So merge qeic_of_init into qe_ic_init to get the qeic node in
qe_ic_init.

Signed-off-by: Zhao Qiang 
---
 drivers/irqchip/irq-qeic.c | 82 ++
 include/soc/fsl/qe/qe_ic.h |  7 
 2 files changed, 46 insertions(+), 43 deletions(-)

diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c
index 346a7ee..97a1f5f 100644
--- a/drivers/irqchip/irq-qeic.c
+++ b/drivers/irqchip/irq-qeic.c
@@ -406,27 +406,33 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
return irq_linear_revmap(qe_ic->irqhost, irq);
 }
 
-void __init qe_ic_init(struct device_node *node, unsigned int flags,
-  void (*low_handler)(struct irq_desc *desc),
-  void (*high_handler)(struct irq_desc *desc))
+static int __init qe_ic_init(struct device_node *node, unsigned int flags)
 {
struct qe_ic *qe_ic;
struct resource res;
-   u32 temp = 0, ret, high_active = 0;
+   u32 temp = 0, high_active = 0;
+   int ret = 0;
+
+   if (!node)
+   return -ENODEV;
 
ret = of_address_to_resource(node, 0, );
-   if (ret)
-   return;
+   if (ret) {
+   ret = -ENODEV;
+   goto err_put_node;
+   }
 
qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL);
-   if (qe_ic == NULL)
-   return;
+   if (qe_ic == NULL) {
+   ret = -ENOMEM;
+   goto err_put_node;
+   }
 
qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
   _ic_host_ops, qe_ic);
if (qe_ic->irqhost == NULL) {
-   kfree(qe_ic);
-   return;
+   ret = -ENOMEM;
+   goto err_free_qe_ic;
}
 
qe_ic->regs = ioremap(res.start, resource_size());
@@ -437,9 +443,9 @@ void __init qe_ic_init(struct device_node *node, unsigned 
int flags,
qe_ic->virq_low = irq_of_parse_and_map(node, 1);
 
if (qe_ic->virq_low == NO_IRQ) {
-   printk(KERN_ERR "Failed to map QE_IC low IRQ\n");
-   kfree(qe_ic);
-   return;
+   pr_err("Failed to map QE_IC low IRQ\n");
+   ret = -ENOMEM;
+   goto err_domain_remove;
}
 
/* default priority scheme is grouped. If spread mode is*/
@@ -466,13 +472,24 @@ void __init qe_ic_init(struct device_node *node, unsigned 
int flags,
qe_ic_write(qe_ic->regs, QEIC_CICR, temp);
 
irq_set_handler_data(qe_ic->virq_low, qe_ic);
-   irq_set_chained_handler(qe_ic->virq_low, low_handler);
+   irq_set_chained_handler(qe_ic->virq_low, qe_ic_cascade_low_mpic);
 
if (qe_ic->virq_high != NO_IRQ &&
qe_ic->virq_high != qe_ic->virq_low) {
irq_set_handler_data(qe_ic->virq_high, qe_ic);
-   irq_set_chained_handler(qe_ic->virq_high, high_handler);
+   irq_set_chained_handler(qe_ic->virq_high,
+   qe_ic_cascade_high_mpic);
}
+   of_node_put(node);
+   return 0;
+
+err_domain_remove:
+   irq_domain_remove(qe_ic->irqhost);
+err_free_qe_ic:
+   kfree(qe_ic);
+err_put_node:
+   of_node_put(node);
+   return ret;
 }
 
 void qe_ic_set_highest_priority(unsigned int virq, int high)
@@ -579,34 +596,27 @@ static struct device device_qe_ic = {
.bus = _ic_subsys,
 };
 
-static int __init init_qe_ic_sysfs(void)
+static int __init init_qe_ic(struct device_node *node,
+struct device_node *parent)
 {
-   int rc;
+   int ret;
 
-   printk(KERN_DEBUG "Registering qe_ic with sysfs...\n");
+   ret = qe_ic_init(node, 0);
+   if (ret)
+   return ret;
 
-   rc = subsys_system_register(_ic_subsys, NULL);
-   if (rc) {
-   printk(KERN_ERR "Failed registering qe_ic sys class\n");
+   ret = subsys_system_register(_ic_subsys, NULL);
+   if (ret) {
+   pr_err("Failed registering qe_ic sys class\n");
return -ENODEV;
}
-   rc = device_register(_qe_ic);
-   if (rc) {
-   printk(KERN_ERR "Failed registering qe_ic sys device\n");
+   ret = device_register(_qe_ic);
+   if (ret) {
+   pr_err("Failed registering qe_ic sys device\n");
return -ENODEV;
}
-   return 0;
-}
 
-static int __init qeic_of_init(struct device_node *node,
-  struct device_node *parent)
-{
-   if (!node)
-   return;
-   qe_ic_init(node, 0, qe_ic_cascade_low_mpic,
-  qe_ic_cascade_high_mpic);
-   of_node_put(node);
+   return 0;
 }
 
-IRQCHIP_DECLARE(qeic, "fsl,qe-ic", qeic_of_init);
-subsys_initcall(init_qe_ic_sysfs);
+IRQCHIP_DECLARE(qeic, "fsl,qe-ic", 

[PATCH v8 4/4] irqchip/qeic: remove PPCisms for QEIC

2017-03-13 Thread Zhao Qiang
QEIC was supported on PowerPC, and dependent on PPC,
Now it is supported on other platforms, so remove PPCisms.

Signed-off-by: Zhao Qiang 
---
 arch/powerpc/platforms/83xx/km83xx.c  |   1 -
 arch/powerpc/platforms/83xx/misc.c|   1 -
 arch/powerpc/platforms/83xx/mpc832x_mds.c |   1 -
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |   1 -
 arch/powerpc/platforms/83xx/mpc836x_mds.c |   1 -
 arch/powerpc/platforms/83xx/mpc836x_rdk.c |   1 -
 arch/powerpc/platforms/85xx/corenet_generic.c |   1 -
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |   1 -
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |   1 -
 arch/powerpc/platforms/85xx/twr_p102x.c   |   1 -
 drivers/irqchip/irq-qeic.c| 220 +-
 include/soc/fsl/qe/qe_ic.h| 132 
 12 files changed, 112 insertions(+), 250 deletions(-)
 delete mode 100644 include/soc/fsl/qe/qe_ic.h

diff --git a/arch/powerpc/platforms/83xx/km83xx.c 
b/arch/powerpc/platforms/83xx/km83xx.c
index d8642a4..b1cef0a 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -38,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "mpc83xx.h"
 
diff --git a/arch/powerpc/platforms/83xx/misc.c 
b/arch/powerpc/platforms/83xx/misc.c
index c09a135..07a0e61 100644
--- a/arch/powerpc/platforms/83xx/misc.c
+++ b/arch/powerpc/platforms/83xx/misc.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c 
b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index bb7b25a..a1cadf4 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "mpc83xx.h"
 
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c 
b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index d7c9b18..6c66527 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c 
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 4fc3051..9234d63 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -45,7 +45,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "mpc83xx.h"
 
diff --git a/arch/powerpc/platforms/83xx/mpc836x_rdk.c 
b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
index 93f024f..82fa344 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_rdk.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 1b385ac..9ca27b1 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 06f34a9..8102e5f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -49,7 +49,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include "smp.h"
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 000d385..f806b6b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c 
b/arch/powerpc/platforms/85xx/twr_p102x.c
index 6be9b33..4f620f2 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c
index 97a1f5f..3c67a0b 100644
--- a/drivers/irqchip/irq-qeic.c
+++ b/drivers/irqchip/irq-qeic.c
@@ -18,7 +18,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -26,9 +30,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
-#include 
 
 #define NR_QE_IC_INTS  64
 
@@ -86,6 +89,43 @@
 #define SIGNAL_HIGH2
 #define SIGNAL_LOW 0
 
+#define NUM_OF_QE_IC_GROUPS6
+
+/* Flags when we init the QE IC */
+#define QE_IC_SPREADMODE_GRP_W 0x0001
+#define QE_IC_SPREADMODE_GRP_X 0x0002
+#define QE_IC_SPREADMODE_GRP_Y 0x0004
+#define QE_IC_SPREADMODE_GRP_Z 0x0008
+#define QE_IC_SPREADMODE_GRP_RISCA 0x0010
+#define 

[PATCH v8 3/4] irqchip/qeic: merge qeic_of_init into qe_ic_init

2017-03-13 Thread Zhao Qiang
qeic_of_init just get device_node of qeic from dtb and call qe_ic_init,
pass the device_node to qe_ic_init.
So merge qeic_of_init into qe_ic_init to get the qeic node in
qe_ic_init.

Signed-off-by: Zhao Qiang 
---
 drivers/irqchip/irq-qeic.c | 82 ++
 include/soc/fsl/qe/qe_ic.h |  7 
 2 files changed, 46 insertions(+), 43 deletions(-)

diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c
index 346a7ee..97a1f5f 100644
--- a/drivers/irqchip/irq-qeic.c
+++ b/drivers/irqchip/irq-qeic.c
@@ -406,27 +406,33 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
return irq_linear_revmap(qe_ic->irqhost, irq);
 }
 
-void __init qe_ic_init(struct device_node *node, unsigned int flags,
-  void (*low_handler)(struct irq_desc *desc),
-  void (*high_handler)(struct irq_desc *desc))
+static int __init qe_ic_init(struct device_node *node, unsigned int flags)
 {
struct qe_ic *qe_ic;
struct resource res;
-   u32 temp = 0, ret, high_active = 0;
+   u32 temp = 0, high_active = 0;
+   int ret = 0;
+
+   if (!node)
+   return -ENODEV;
 
ret = of_address_to_resource(node, 0, );
-   if (ret)
-   return;
+   if (ret) {
+   ret = -ENODEV;
+   goto err_put_node;
+   }
 
qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL);
-   if (qe_ic == NULL)
-   return;
+   if (qe_ic == NULL) {
+   ret = -ENOMEM;
+   goto err_put_node;
+   }
 
qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
   _ic_host_ops, qe_ic);
if (qe_ic->irqhost == NULL) {
-   kfree(qe_ic);
-   return;
+   ret = -ENOMEM;
+   goto err_free_qe_ic;
}
 
qe_ic->regs = ioremap(res.start, resource_size());
@@ -437,9 +443,9 @@ void __init qe_ic_init(struct device_node *node, unsigned 
int flags,
qe_ic->virq_low = irq_of_parse_and_map(node, 1);
 
if (qe_ic->virq_low == NO_IRQ) {
-   printk(KERN_ERR "Failed to map QE_IC low IRQ\n");
-   kfree(qe_ic);
-   return;
+   pr_err("Failed to map QE_IC low IRQ\n");
+   ret = -ENOMEM;
+   goto err_domain_remove;
}
 
/* default priority scheme is grouped. If spread mode is*/
@@ -466,13 +472,24 @@ void __init qe_ic_init(struct device_node *node, unsigned 
int flags,
qe_ic_write(qe_ic->regs, QEIC_CICR, temp);
 
irq_set_handler_data(qe_ic->virq_low, qe_ic);
-   irq_set_chained_handler(qe_ic->virq_low, low_handler);
+   irq_set_chained_handler(qe_ic->virq_low, qe_ic_cascade_low_mpic);
 
if (qe_ic->virq_high != NO_IRQ &&
qe_ic->virq_high != qe_ic->virq_low) {
irq_set_handler_data(qe_ic->virq_high, qe_ic);
-   irq_set_chained_handler(qe_ic->virq_high, high_handler);
+   irq_set_chained_handler(qe_ic->virq_high,
+   qe_ic_cascade_high_mpic);
}
+   of_node_put(node);
+   return 0;
+
+err_domain_remove:
+   irq_domain_remove(qe_ic->irqhost);
+err_free_qe_ic:
+   kfree(qe_ic);
+err_put_node:
+   of_node_put(node);
+   return ret;
 }
 
 void qe_ic_set_highest_priority(unsigned int virq, int high)
@@ -579,34 +596,27 @@ static struct device device_qe_ic = {
.bus = _ic_subsys,
 };
 
-static int __init init_qe_ic_sysfs(void)
+static int __init init_qe_ic(struct device_node *node,
+struct device_node *parent)
 {
-   int rc;
+   int ret;
 
-   printk(KERN_DEBUG "Registering qe_ic with sysfs...\n");
+   ret = qe_ic_init(node, 0);
+   if (ret)
+   return ret;
 
-   rc = subsys_system_register(_ic_subsys, NULL);
-   if (rc) {
-   printk(KERN_ERR "Failed registering qe_ic sys class\n");
+   ret = subsys_system_register(_ic_subsys, NULL);
+   if (ret) {
+   pr_err("Failed registering qe_ic sys class\n");
return -ENODEV;
}
-   rc = device_register(_qe_ic);
-   if (rc) {
-   printk(KERN_ERR "Failed registering qe_ic sys device\n");
+   ret = device_register(_qe_ic);
+   if (ret) {
+   pr_err("Failed registering qe_ic sys device\n");
return -ENODEV;
}
-   return 0;
-}
 
-static int __init qeic_of_init(struct device_node *node,
-  struct device_node *parent)
-{
-   if (!node)
-   return;
-   qe_ic_init(node, 0, qe_ic_cascade_low_mpic,
-  qe_ic_cascade_high_mpic);
-   of_node_put(node);
+   return 0;
 }
 
-IRQCHIP_DECLARE(qeic, "fsl,qe-ic", qeic_of_init);
-subsys_initcall(init_qe_ic_sysfs);
+IRQCHIP_DECLARE(qeic, "fsl,qe-ic", init_qe_ic);
diff --git 

[PATCH v8 4/4] irqchip/qeic: remove PPCisms for QEIC

2017-03-13 Thread Zhao Qiang
QEIC was supported on PowerPC, and dependent on PPC,
Now it is supported on other platforms, so remove PPCisms.

Signed-off-by: Zhao Qiang 
---
 arch/powerpc/platforms/83xx/km83xx.c  |   1 -
 arch/powerpc/platforms/83xx/misc.c|   1 -
 arch/powerpc/platforms/83xx/mpc832x_mds.c |   1 -
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |   1 -
 arch/powerpc/platforms/83xx/mpc836x_mds.c |   1 -
 arch/powerpc/platforms/83xx/mpc836x_rdk.c |   1 -
 arch/powerpc/platforms/85xx/corenet_generic.c |   1 -
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |   1 -
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |   1 -
 arch/powerpc/platforms/85xx/twr_p102x.c   |   1 -
 drivers/irqchip/irq-qeic.c| 220 +-
 include/soc/fsl/qe/qe_ic.h| 132 
 12 files changed, 112 insertions(+), 250 deletions(-)
 delete mode 100644 include/soc/fsl/qe/qe_ic.h

diff --git a/arch/powerpc/platforms/83xx/km83xx.c 
b/arch/powerpc/platforms/83xx/km83xx.c
index d8642a4..b1cef0a 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -38,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "mpc83xx.h"
 
diff --git a/arch/powerpc/platforms/83xx/misc.c 
b/arch/powerpc/platforms/83xx/misc.c
index c09a135..07a0e61 100644
--- a/arch/powerpc/platforms/83xx/misc.c
+++ b/arch/powerpc/platforms/83xx/misc.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c 
b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index bb7b25a..a1cadf4 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "mpc83xx.h"
 
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c 
b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index d7c9b18..6c66527 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c 
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 4fc3051..9234d63 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -45,7 +45,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "mpc83xx.h"
 
diff --git a/arch/powerpc/platforms/83xx/mpc836x_rdk.c 
b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
index 93f024f..82fa344 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_rdk.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 1b385ac..9ca27b1 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 06f34a9..8102e5f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -49,7 +49,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include "smp.h"
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 000d385..f806b6b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c 
b/arch/powerpc/platforms/85xx/twr_p102x.c
index 6be9b33..4f620f2 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c
index 97a1f5f..3c67a0b 100644
--- a/drivers/irqchip/irq-qeic.c
+++ b/drivers/irqchip/irq-qeic.c
@@ -18,7 +18,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -26,9 +30,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
-#include 
 
 #define NR_QE_IC_INTS  64
 
@@ -86,6 +89,43 @@
 #define SIGNAL_HIGH2
 #define SIGNAL_LOW 0
 
+#define NUM_OF_QE_IC_GROUPS6
+
+/* Flags when we init the QE IC */
+#define QE_IC_SPREADMODE_GRP_W 0x0001
+#define QE_IC_SPREADMODE_GRP_X 0x0002
+#define QE_IC_SPREADMODE_GRP_Y 0x0004
+#define QE_IC_SPREADMODE_GRP_Z 0x0008
+#define QE_IC_SPREADMODE_GRP_RISCA 0x0010
+#define QE_IC_SPREADMODE_GRP_RISCB 

[PATCH v8 1/4] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

2017-03-13 Thread Zhao Qiang
move the driver from drivers/soc/fsl/qe to drivers/irqchip,
merge qe_ic.h and qe_ic.c into irq-qeic.c.

Signed-off-by: Zhao Qiang 
---
 MAINTAINERS|   6 ++
 drivers/irqchip/Makefile   |   1 +
 drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} |  95 ++-
 drivers/soc/fsl/qe/Makefile|   2 +-
 drivers/soc/fsl/qe/qe_ic.h | 103 -
 5 files changed, 100 insertions(+), 107 deletions(-)
 rename drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} (85%)
 delete mode 100644 drivers/soc/fsl/qe/qe_ic.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5f..9ef06df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5269,6 +5269,12 @@ F:   drivers/soc/fsl/qe/
 F: include/soc/fsl/*qe*.h
 F: include/soc/fsl/*ucc*.h
 
+FREESCALE QEIC DRIVERS
+M: Qiang Zhao 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: drivers/irqchip/irq-qeic.c
+
 FREESCALE USB PERIPHERAL DRIVERS
 M: Li Yang 
 L: linux-...@vger.kernel.org
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 152bc40..78f3c63 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_EZNPS_GIC)   += irq-eznps.o
 obj-$(CONFIG_ARCH_ASPEED)  += irq-aspeed-vic.o
 obj-$(CONFIG_STM32_EXTI)   += irq-stm32-exti.o
 obj-$(CONFIG_QCOM_IRQ_COMBINER)+= qcom-irq-combiner.o
+obj-$(CONFIG_QUICC_ENGINE) += irq-qeic.o
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/irqchip/irq-qeic.c
similarity index 85%
rename from drivers/soc/fsl/qe/qe_ic.c
rename to drivers/irqchip/irq-qeic.c
index ec2ca86..9b4660c 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/irqchip/irq-qeic.c
@@ -1,7 +1,7 @@
 /*
- * arch/powerpc/sysdev/qe_lib/qe_ic.c
+ * drivers/irqchip/irq-qeic.c
  *
- * Copyright (C) 2006 Freescale Semiconductor, Inc.  All rights reserved.
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.  All rights reserved.
  *
  * Author: Li Yang 
  * Based on code from Shlomi Gridish 
@@ -30,7 +30,96 @@
 #include 
 #include 
 
-#include "qe_ic.h"
+#define NR_QE_IC_INTS  64
+
+/* QE IC registers offset */
+#define QEIC_CICR  0x00
+#define QEIC_CIVEC 0x04
+#define QEIC_CRIPNR0x08
+#define QEIC_CIPNR 0x0c
+#define QEIC_CIPXCC0x10
+#define QEIC_CIPYCC0x14
+#define QEIC_CIPWCC0x18
+#define QEIC_CIPZCC0x1c
+#define QEIC_CIMR  0x20
+#define QEIC_CRIMR 0x24
+#define QEIC_CICNR 0x28
+#define QEIC_CIPRTA0x30
+#define QEIC_CIPRTB0x34
+#define QEIC_CRICR 0x3c
+#define QEIC_CHIVEC0x60
+
+/* Interrupt priority registers */
+#define CIPCC_SHIFT_PRI0   29
+#define CIPCC_SHIFT_PRI1   26
+#define CIPCC_SHIFT_PRI2   23
+#define CIPCC_SHIFT_PRI3   20
+#define CIPCC_SHIFT_PRI4   13
+#define CIPCC_SHIFT_PRI5   10
+#define CIPCC_SHIFT_PRI6   7
+#define CIPCC_SHIFT_PRI7   4
+
+/* CICR priority modes */
+#define CICR_GWCC  0x0004
+#define CICR_GXCC  0x0002
+#define CICR_GYCC  0x0001
+#define CICR_GZCC  0x0008
+#define CICR_GRTA  0x0020
+#define CICR_GRTB  0x0040
+#define CICR_HPIT_SHIFT8
+#define CICR_HPIT_MASK 0x0300
+#define CICR_HP_SHIFT  24
+#define CICR_HP_MASK   0x3f00
+
+/* CICNR */
+#define CICNR_WCC1T_SHIFT  20
+#define CICNR_ZCC1T_SHIFT  28
+#define CICNR_YCC1T_SHIFT  12
+#define CICNR_XCC1T_SHIFT  4
+
+/* CRICR */
+#define CRICR_RTA1T_SHIFT  20
+#define CRICR_RTB1T_SHIFT  28
+
+/* Signal indicator */
+#define SIGNAL_MASK3
+#define SIGNAL_HIGH2
+#define SIGNAL_LOW 0
+
+struct qe_ic {
+   /* Control registers offset */
+   u32 __iomem *regs;
+
+   /* The remapper for this QEIC */
+   struct irq_domain *irqhost;
+
+   /* The "linux" controller struct */
+   struct irq_chip hc_irq;
+
+   /* VIRQ numbers of QE high/low irqs */
+   unsigned int virq_high;
+   unsigned int virq_low;
+};
+
+/*
+ * QE interrupt controller internal structure
+ */
+struct qe_ic_info {
+   /* location of this source at the QIMR register. */
+   u32 mask;
+
+   /* Mask register offset */
+   u32 mask_reg;
+
+   /*
+* for grouped interrupts sources - the interrupt
+* code as appears at the group priority register
+*/
+   u8  pri_code;
+
+   /* Group priority register offset */
+   u32 pri_reg;
+};
 
 static DEFINE_RAW_SPINLOCK(qe_ic_lock);
 
diff --git a/drivers/soc/fsl/qe/Makefile 

[PATCH v8 1/4] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

2017-03-13 Thread Zhao Qiang
move the driver from drivers/soc/fsl/qe to drivers/irqchip,
merge qe_ic.h and qe_ic.c into irq-qeic.c.

Signed-off-by: Zhao Qiang 
---
 MAINTAINERS|   6 ++
 drivers/irqchip/Makefile   |   1 +
 drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} |  95 ++-
 drivers/soc/fsl/qe/Makefile|   2 +-
 drivers/soc/fsl/qe/qe_ic.h | 103 -
 5 files changed, 100 insertions(+), 107 deletions(-)
 rename drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} (85%)
 delete mode 100644 drivers/soc/fsl/qe/qe_ic.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5f..9ef06df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5269,6 +5269,12 @@ F:   drivers/soc/fsl/qe/
 F: include/soc/fsl/*qe*.h
 F: include/soc/fsl/*ucc*.h
 
+FREESCALE QEIC DRIVERS
+M: Qiang Zhao 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: drivers/irqchip/irq-qeic.c
+
 FREESCALE USB PERIPHERAL DRIVERS
 M: Li Yang 
 L: linux-...@vger.kernel.org
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 152bc40..78f3c63 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_EZNPS_GIC)   += irq-eznps.o
 obj-$(CONFIG_ARCH_ASPEED)  += irq-aspeed-vic.o
 obj-$(CONFIG_STM32_EXTI)   += irq-stm32-exti.o
 obj-$(CONFIG_QCOM_IRQ_COMBINER)+= qcom-irq-combiner.o
+obj-$(CONFIG_QUICC_ENGINE) += irq-qeic.o
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/irqchip/irq-qeic.c
similarity index 85%
rename from drivers/soc/fsl/qe/qe_ic.c
rename to drivers/irqchip/irq-qeic.c
index ec2ca86..9b4660c 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/irqchip/irq-qeic.c
@@ -1,7 +1,7 @@
 /*
- * arch/powerpc/sysdev/qe_lib/qe_ic.c
+ * drivers/irqchip/irq-qeic.c
  *
- * Copyright (C) 2006 Freescale Semiconductor, Inc.  All rights reserved.
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.  All rights reserved.
  *
  * Author: Li Yang 
  * Based on code from Shlomi Gridish 
@@ -30,7 +30,96 @@
 #include 
 #include 
 
-#include "qe_ic.h"
+#define NR_QE_IC_INTS  64
+
+/* QE IC registers offset */
+#define QEIC_CICR  0x00
+#define QEIC_CIVEC 0x04
+#define QEIC_CRIPNR0x08
+#define QEIC_CIPNR 0x0c
+#define QEIC_CIPXCC0x10
+#define QEIC_CIPYCC0x14
+#define QEIC_CIPWCC0x18
+#define QEIC_CIPZCC0x1c
+#define QEIC_CIMR  0x20
+#define QEIC_CRIMR 0x24
+#define QEIC_CICNR 0x28
+#define QEIC_CIPRTA0x30
+#define QEIC_CIPRTB0x34
+#define QEIC_CRICR 0x3c
+#define QEIC_CHIVEC0x60
+
+/* Interrupt priority registers */
+#define CIPCC_SHIFT_PRI0   29
+#define CIPCC_SHIFT_PRI1   26
+#define CIPCC_SHIFT_PRI2   23
+#define CIPCC_SHIFT_PRI3   20
+#define CIPCC_SHIFT_PRI4   13
+#define CIPCC_SHIFT_PRI5   10
+#define CIPCC_SHIFT_PRI6   7
+#define CIPCC_SHIFT_PRI7   4
+
+/* CICR priority modes */
+#define CICR_GWCC  0x0004
+#define CICR_GXCC  0x0002
+#define CICR_GYCC  0x0001
+#define CICR_GZCC  0x0008
+#define CICR_GRTA  0x0020
+#define CICR_GRTB  0x0040
+#define CICR_HPIT_SHIFT8
+#define CICR_HPIT_MASK 0x0300
+#define CICR_HP_SHIFT  24
+#define CICR_HP_MASK   0x3f00
+
+/* CICNR */
+#define CICNR_WCC1T_SHIFT  20
+#define CICNR_ZCC1T_SHIFT  28
+#define CICNR_YCC1T_SHIFT  12
+#define CICNR_XCC1T_SHIFT  4
+
+/* CRICR */
+#define CRICR_RTA1T_SHIFT  20
+#define CRICR_RTB1T_SHIFT  28
+
+/* Signal indicator */
+#define SIGNAL_MASK3
+#define SIGNAL_HIGH2
+#define SIGNAL_LOW 0
+
+struct qe_ic {
+   /* Control registers offset */
+   u32 __iomem *regs;
+
+   /* The remapper for this QEIC */
+   struct irq_domain *irqhost;
+
+   /* The "linux" controller struct */
+   struct irq_chip hc_irq;
+
+   /* VIRQ numbers of QE high/low irqs */
+   unsigned int virq_high;
+   unsigned int virq_low;
+};
+
+/*
+ * QE interrupt controller internal structure
+ */
+struct qe_ic_info {
+   /* location of this source at the QIMR register. */
+   u32 mask;
+
+   /* Mask register offset */
+   u32 mask_reg;
+
+   /*
+* for grouped interrupts sources - the interrupt
+* code as appears at the group priority register
+*/
+   u8  pri_code;
+
+   /* Group priority register offset */
+   u32 pri_reg;
+};
 
 static DEFINE_RAW_SPINLOCK(qe_ic_lock);
 
diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile
index 2031d38..51e4726 100644
--- a/drivers/soc/fsl/qe/Makefile
+++ b/drivers/soc/fsl/qe/Makefile
@@ 

[PATCH v8 0/4] this patchset is to remove PPCisms for QEIC

2017-03-13 Thread Zhao Qiang
QEIC is supported more than just powerpc boards, so remove PPCisms.

changelog:
Changes for v8:
- use IRQCHIP_DECLARE() instead of subsys_initcall in qeic driver
- remove include/soc/fsl/qe/qe_ic.h

Zhao Qiang (4):
  irqchip/qeic: move qeic driver from drivers/soc/fsl/qe
Changes for v2:
- modify the subject and commit msg
Changes for v3:
- merge .h file to .c, rename it with irq-qeic.c
Changes for v4:
- modify comments
Changes for v5:
- disable rename detection
Changes for v6:
- rebase
Changes for v7:
- na

  irqchip/qeic: merge qeic init code from platforms to a common function
Changes for v2:
- modify subject and commit msg
- add check for qeic by type
Changes for v3:
- na
Changes for v4:
- na
Changes for v5:
- na
Changes for v6:
- rebase
Changes for v7:
- na
Changes for v8:
- use IRQCHIP_DECLARE() instead of subsys_initcall

  irqchip/qeic: merge qeic_of_init into qe_ic_init
Changes for v2:
- modify subject and commit msg
- return 0 and add put node when return in qe_ic_init
Changes for v3:
- na
Changes for v4:
- na
Changes for v5:
- na
Changes for v6:
- rebase
Changes for v7:
- na

  irqchip/qeic: remove PPCisms for QEIC
Changes for v6:
- new added
Changes for v7:
- fix warning
Changes for v8:
- remove include/soc/fsl/qe/qe_ic.h

 arch/powerpc/platforms/83xx/km83xx.c  |   1 -
 arch/powerpc/platforms/83xx/misc.c|  16 -
 arch/powerpc/platforms/83xx/mpc832x_mds.c |   1 -
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |   1 -
 arch/powerpc/platforms/83xx/mpc836x_mds.c |   1 -
 arch/powerpc/platforms/83xx/mpc836x_rdk.c |   1 -
 arch/powerpc/platforms/85xx/corenet_generic.c |  10 -
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |  15 -
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  17 -
 arch/powerpc/platforms/85xx/twr_p102x.c   |  15 -
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-qeic.c| 627 ++
 drivers/soc/fsl/qe/Makefile   |   2 +-
 drivers/soc/fsl/qe/qe_ic.c| 512 -
 drivers/soc/fsl/qe/qe_ic.h| 103 -
 include/soc/fsl/qe/qe_ic.h| 139 --
 16 files changed, 629 insertions(+), 833 deletions(-)
 create mode 100644 drivers/irqchip/irq-qeic.c
 delete mode 100644 drivers/soc/fsl/qe/qe_ic.c
 delete mode 100644 drivers/soc/fsl/qe/qe_ic.h
 delete mode 100644 include/soc/fsl/qe/qe_ic.h

-- 
2.1.0.27.g96db324



[PATCH v8 2/4] irqchip/qeic: merge qeic init code from platforms to a common function

2017-03-13 Thread Zhao Qiang
The codes of qe_ic init from a variety of platforms are redundant,
merge them to a common function and put it to irqchip/irq-qeic.c

For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0,
qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of
"qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);".

qe_ic_cascade_muxed_mpic was used for boards has the same interrupt
number for low interrupt and high interrupt, qe_ic_init has checked
if "low interrupt == high interrupt"

Signed-off-by: Zhao Qiang 
---
 arch/powerpc/platforms/83xx/misc.c| 15 ---
 arch/powerpc/platforms/85xx/corenet_generic.c |  9 -
 arch/powerpc/platforms/85xx/mpc85xx_mds.c | 14 --
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 
 arch/powerpc/platforms/85xx/twr_p102x.c   | 14 --
 drivers/irqchip/irq-qeic.c| 11 +++
 6 files changed, 11 insertions(+), 68 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/misc.c 
b/arch/powerpc/platforms/83xx/misc.c
index d75c981..c09a135 100644
--- a/arch/powerpc/platforms/83xx/misc.c
+++ b/arch/powerpc/platforms/83xx/misc.c
@@ -93,24 +93,9 @@ void __init mpc83xx_ipic_init_IRQ(void)
 }
 
 #ifdef CONFIG_QUICC_ENGINE
-void __init mpc83xx_qe_init_IRQ(void)
-{
-   struct device_node *np;
-
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (!np) {
-   np = of_find_node_by_type(NULL, "qeic");
-   if (!np)
-   return;
-   }
-   qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
-   of_node_put(np);
-}
-
 void __init mpc83xx_ipic_and_qe_init_IRQ(void)
 {
mpc83xx_ipic_init_IRQ();
-   mpc83xx_qe_init_IRQ();
 }
 #endif /* CONFIG_QUICC_ENGINE */
 
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c
index ac191a7..1b385ac 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -41,8 +41,6 @@ void __init corenet_gen_pic_init(void)
unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
MPIC_NO_RESET;
 
-   struct device_node *np;
-
if (ppc_md.get_irq == mpic_get_coreint_irq)
flags |= MPIC_ENABLE_COREINT;
 
@@ -50,13 +48,6 @@ void __init corenet_gen_pic_init(void)
BUG_ON(mpic == NULL);
 
mpic_init(mpic);
-
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (np) {
-   qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
-   qe_ic_cascade_high_mpic);
-   of_node_put(np);
-   }
 }
 
 /*
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index d7e440e..06f34a9 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -283,20 +283,6 @@ static void __init mpc85xx_mds_qeic_init(void)
of_node_put(np);
return;
}
-
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (!np) {
-   np = of_find_node_by_type(NULL, "qeic");
-   if (!np)
-   return;
-   }
-
-   if (machine_is(p1021_mds))
-   qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
-   qe_ic_cascade_high_mpic);
-   else
-   qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);
-   of_node_put(np);
 }
 #else
 static void __init mpc85xx_mds_qe_init(void) { }
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 1006950..000d385 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -48,10 +48,6 @@ void __init mpc85xx_rdb_pic_init(void)
 {
struct mpic *mpic;
 
-#ifdef CONFIG_QUICC_ENGINE
-   struct device_node *np;
-#endif
-
if (of_machine_is_compatible("fsl,MPC85XXRDB-CAMP")) {
mpic = mpic_alloc(NULL, 0, MPIC_NO_RESET |
MPIC_BIG_ENDIAN |
@@ -66,18 +62,6 @@ void __init mpc85xx_rdb_pic_init(void)
 
BUG_ON(mpic == NULL);
mpic_init(mpic);
-
-#ifdef CONFIG_QUICC_ENGINE
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (np) {
-   qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
-   qe_ic_cascade_high_mpic);
-   of_node_put(np);
-
-   } else
-   pr_err("%s: Could not find qe-ic node\n", __func__);
-#endif
-
 }
 
 /*
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c 
b/arch/powerpc/platforms/85xx/twr_p102x.c
index 360f625..6be9b33 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -35,26 +35,12 @@ static void __init twr_p1025_pic_init(void)
 {
struct mpic *mpic;
 
-#ifdef CONFIG_QUICC_ENGINE
-   struct 

[PATCH v8 2/4] irqchip/qeic: merge qeic init code from platforms to a common function

2017-03-13 Thread Zhao Qiang
The codes of qe_ic init from a variety of platforms are redundant,
merge them to a common function and put it to irqchip/irq-qeic.c

For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0,
qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of
"qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);".

qe_ic_cascade_muxed_mpic was used for boards has the same interrupt
number for low interrupt and high interrupt, qe_ic_init has checked
if "low interrupt == high interrupt"

Signed-off-by: Zhao Qiang 
---
 arch/powerpc/platforms/83xx/misc.c| 15 ---
 arch/powerpc/platforms/85xx/corenet_generic.c |  9 -
 arch/powerpc/platforms/85xx/mpc85xx_mds.c | 14 --
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 
 arch/powerpc/platforms/85xx/twr_p102x.c   | 14 --
 drivers/irqchip/irq-qeic.c| 11 +++
 6 files changed, 11 insertions(+), 68 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/misc.c 
b/arch/powerpc/platforms/83xx/misc.c
index d75c981..c09a135 100644
--- a/arch/powerpc/platforms/83xx/misc.c
+++ b/arch/powerpc/platforms/83xx/misc.c
@@ -93,24 +93,9 @@ void __init mpc83xx_ipic_init_IRQ(void)
 }
 
 #ifdef CONFIG_QUICC_ENGINE
-void __init mpc83xx_qe_init_IRQ(void)
-{
-   struct device_node *np;
-
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (!np) {
-   np = of_find_node_by_type(NULL, "qeic");
-   if (!np)
-   return;
-   }
-   qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
-   of_node_put(np);
-}
-
 void __init mpc83xx_ipic_and_qe_init_IRQ(void)
 {
mpc83xx_ipic_init_IRQ();
-   mpc83xx_qe_init_IRQ();
 }
 #endif /* CONFIG_QUICC_ENGINE */
 
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c
index ac191a7..1b385ac 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -41,8 +41,6 @@ void __init corenet_gen_pic_init(void)
unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
MPIC_NO_RESET;
 
-   struct device_node *np;
-
if (ppc_md.get_irq == mpic_get_coreint_irq)
flags |= MPIC_ENABLE_COREINT;
 
@@ -50,13 +48,6 @@ void __init corenet_gen_pic_init(void)
BUG_ON(mpic == NULL);
 
mpic_init(mpic);
-
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (np) {
-   qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
-   qe_ic_cascade_high_mpic);
-   of_node_put(np);
-   }
 }
 
 /*
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index d7e440e..06f34a9 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -283,20 +283,6 @@ static void __init mpc85xx_mds_qeic_init(void)
of_node_put(np);
return;
}
-
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (!np) {
-   np = of_find_node_by_type(NULL, "qeic");
-   if (!np)
-   return;
-   }
-
-   if (machine_is(p1021_mds))
-   qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
-   qe_ic_cascade_high_mpic);
-   else
-   qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);
-   of_node_put(np);
 }
 #else
 static void __init mpc85xx_mds_qe_init(void) { }
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 1006950..000d385 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -48,10 +48,6 @@ void __init mpc85xx_rdb_pic_init(void)
 {
struct mpic *mpic;
 
-#ifdef CONFIG_QUICC_ENGINE
-   struct device_node *np;
-#endif
-
if (of_machine_is_compatible("fsl,MPC85XXRDB-CAMP")) {
mpic = mpic_alloc(NULL, 0, MPIC_NO_RESET |
MPIC_BIG_ENDIAN |
@@ -66,18 +62,6 @@ void __init mpc85xx_rdb_pic_init(void)
 
BUG_ON(mpic == NULL);
mpic_init(mpic);
-
-#ifdef CONFIG_QUICC_ENGINE
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (np) {
-   qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
-   qe_ic_cascade_high_mpic);
-   of_node_put(np);
-
-   } else
-   pr_err("%s: Could not find qe-ic node\n", __func__);
-#endif
-
 }
 
 /*
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c 
b/arch/powerpc/platforms/85xx/twr_p102x.c
index 360f625..6be9b33 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -35,26 +35,12 @@ static void __init twr_p1025_pic_init(void)
 {
struct mpic *mpic;
 
-#ifdef CONFIG_QUICC_ENGINE
-   struct device_node *np;
-#endif

[PATCH v8 0/4] this patchset is to remove PPCisms for QEIC

2017-03-13 Thread Zhao Qiang
QEIC is supported more than just powerpc boards, so remove PPCisms.

changelog:
Changes for v8:
- use IRQCHIP_DECLARE() instead of subsys_initcall in qeic driver
- remove include/soc/fsl/qe/qe_ic.h

Zhao Qiang (4):
  irqchip/qeic: move qeic driver from drivers/soc/fsl/qe
Changes for v2:
- modify the subject and commit msg
Changes for v3:
- merge .h file to .c, rename it with irq-qeic.c
Changes for v4:
- modify comments
Changes for v5:
- disable rename detection
Changes for v6:
- rebase
Changes for v7:
- na

  irqchip/qeic: merge qeic init code from platforms to a common function
Changes for v2:
- modify subject and commit msg
- add check for qeic by type
Changes for v3:
- na
Changes for v4:
- na
Changes for v5:
- na
Changes for v6:
- rebase
Changes for v7:
- na
Changes for v8:
- use IRQCHIP_DECLARE() instead of subsys_initcall

  irqchip/qeic: merge qeic_of_init into qe_ic_init
Changes for v2:
- modify subject and commit msg
- return 0 and add put node when return in qe_ic_init
Changes for v3:
- na
Changes for v4:
- na
Changes for v5:
- na
Changes for v6:
- rebase
Changes for v7:
- na

  irqchip/qeic: remove PPCisms for QEIC
Changes for v6:
- new added
Changes for v7:
- fix warning
Changes for v8:
- remove include/soc/fsl/qe/qe_ic.h

 arch/powerpc/platforms/83xx/km83xx.c  |   1 -
 arch/powerpc/platforms/83xx/misc.c|  16 -
 arch/powerpc/platforms/83xx/mpc832x_mds.c |   1 -
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |   1 -
 arch/powerpc/platforms/83xx/mpc836x_mds.c |   1 -
 arch/powerpc/platforms/83xx/mpc836x_rdk.c |   1 -
 arch/powerpc/platforms/85xx/corenet_generic.c |  10 -
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |  15 -
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  17 -
 arch/powerpc/platforms/85xx/twr_p102x.c   |  15 -
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-qeic.c| 627 ++
 drivers/soc/fsl/qe/Makefile   |   2 +-
 drivers/soc/fsl/qe/qe_ic.c| 512 -
 drivers/soc/fsl/qe/qe_ic.h| 103 -
 include/soc/fsl/qe/qe_ic.h| 139 --
 16 files changed, 629 insertions(+), 833 deletions(-)
 create mode 100644 drivers/irqchip/irq-qeic.c
 delete mode 100644 drivers/soc/fsl/qe/qe_ic.c
 delete mode 100644 drivers/soc/fsl/qe/qe_ic.h
 delete mode 100644 include/soc/fsl/qe/qe_ic.h

-- 
2.1.0.27.g96db324



[Patch V2 1/2] x86/mm/numa: trivial fix on typo and error message

2017-03-13 Thread Wei Yang
When allocating pg_data in alloc_node_data(), it will try to allocate from
local node first and then from any node. If it fails at the second trial,
it means there is not available memory on any node.

This patch fixes the error message and correct one typo.

Signed-off-by: Wei Yang 

---
v2:
   * also print the original nid in the error message, based on Borislav's
 comment
---
 arch/x86/mm/numa.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 12dcad7297a5..ac632e5397aa 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -201,7 +201,7 @@ static void __init alloc_node_data(int nid)
nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
  MEMBLOCK_ALLOC_ACCESSIBLE);
if (!nd_pa) {
-   pr_err("Cannot find %zu bytes in node %d\n",
+   pr_err("Cannot find %zu bytes in any node(initial node: 
%d)\n",
   nd_size, nid);
return;
}
@@ -225,7 +225,7 @@ static void __init alloc_node_data(int nid)
  * numa_cleanup_meminfo - Cleanup a numa_meminfo
  * @mi: numa_meminfo to clean up
  *
- * Sanitize @mi by merging and removing unncessary memblks.  Also check for
+ * Sanitize @mi by merging and removing unnecessary memblks.  Also check for
  * conflicts and clear unused memblks.
  *
  * RETURNS:
-- 
2.11.0



Re: [PATCH] kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file()

2017-03-13 Thread Greg Kroah-Hartman
On Tue, Mar 14, 2017 at 08:17:00AM +0530, Vaibhav Jain wrote:
> Recently started seeing a kernel oops when a module tries removing a
> memory mapped sysfs bin_attribute. On closer investigation the root
> cause seems to be kernfs_release_file() trying to call
> kernfs_op.release() callback that's NULL for such sysfs
> bin_attributes. The oops occurs when kernfs_release_file() is called from
> kernfs_drain_open_files() to cleanup any open handles with active
> memory mappings.
> 
> The patch fixes this by checking for flag KERNFS_HAS_RELEASE before
> calling kernfs_release_file() in function kernfs_drain_open_files().
> 
> On ppc64-le arch with cxl module the oops back-trace is of the
> form below:
> [  861.381126] Unable to handle kernel paging request for instruction fetch
> [  861.381360] Faulting instruction address: 0x
> [  861.381428] Oops: Kernel access of bad area, sig: 11 [#1]
> 
> [  861.382481] NIP:  LR: c0362c60 CTR:
> 
> 
> Call Trace:
> [c00f1680b750] [c0362c34] kernfs_drain_open_files+0x104/0x1d0 
> (unreliable)
> [c00f1680b790] [c035fa00] __kernfs_remove+0x260/0x2c0
> [c00f1680b820] [c0360da0] kernfs_remove_by_name_ns+0x60/0xe0
> [c00f1680b8b0] [c03638f4] sysfs_remove_bin_file+0x24/0x40
> [c00f1680b8d0] [c062a164] device_remove_bin_file+0x24/0x40
> [c00f1680b8f0] [d9b7b22c] cxl_sysfs_afu_remove+0x144/0x170 [cxl]
> [c00f1680b940] [d9b7c7e4] cxl_remove+0x6c/0x1a0 [cxl]
> [c00f1680b990] [c052f694] pci_device_remove+0x64/0x110
> [c00f1680b9d0] [c06321d4] 
> device_release_driver_internal+0x1f4/0x2b0
> [c00f1680ba20] [c0525cb0] pci_stop_bus_device+0xa0/0xd0
> [c00f1680ba60] [c0525e80] pci_stop_and_remove_bus_device+0x20/0x40
> [c00f1680ba90] [c004a6c4] pci_hp_remove_devices+0x84/0xc0
> [c00f1680bad0] [c004a688] pci_hp_remove_devices+0x48/0xc0
> [c00f1680bb10] [c09dfda4] eeh_reset_device+0xb0/0x290
> [c00f1680bbb0] [c0032b4c] eeh_handle_normal_event+0x47c/0x530
> [c00f1680bc60] [c0032e64] eeh_handle_event+0x174/0x350
> [c00f1680bd10] [c0033228] eeh_event_handler+0x1e8/0x1f0
> [c00f1680bdc0] [c00d384c] kthread+0x14c/0x190
> [c00f1680be30] [c000b5a0] ret_from_kernel_thread+0x5c/0xbc
> 
> Fixes: f83f3c515654("kernfs: fix locking around kernfs_ops->release()
> callback")
> Signed-off-by: Vaibhav Jain 
> ---
>  fs/kernfs/file.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
> index 8e4dc7a..ac2dfe0 100644
> --- a/fs/kernfs/file.c
> +++ b/fs/kernfs/file.c
> @@ -809,7 +809,8 @@ void kernfs_drain_open_files(struct kernfs_node *kn)
>   if (kn->flags & KERNFS_HAS_MMAP)
>   unmap_mapping_range(inode->i_mapping, 0, 0, 1);
>  
> - kernfs_release_file(kn, of);
> + if (kn->flags & KERNFS_HAS_RELEASE)
> + kernfs_release_file(kn, of);
>   }
>  
>   mutex_unlock(_open_file_mutex);
> -- 
> 2.9.3

Tejun, want to take this through your tree, or at the least, give me an
ack for this?

thanks,

greg k-h


[Patch V2 1/2] x86/mm/numa: trivial fix on typo and error message

2017-03-13 Thread Wei Yang
When allocating pg_data in alloc_node_data(), it will try to allocate from
local node first and then from any node. If it fails at the second trial,
it means there is not available memory on any node.

This patch fixes the error message and correct one typo.

Signed-off-by: Wei Yang 

---
v2:
   * also print the original nid in the error message, based on Borislav's
 comment
---
 arch/x86/mm/numa.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 12dcad7297a5..ac632e5397aa 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -201,7 +201,7 @@ static void __init alloc_node_data(int nid)
nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
  MEMBLOCK_ALLOC_ACCESSIBLE);
if (!nd_pa) {
-   pr_err("Cannot find %zu bytes in node %d\n",
+   pr_err("Cannot find %zu bytes in any node(initial node: 
%d)\n",
   nd_size, nid);
return;
}
@@ -225,7 +225,7 @@ static void __init alloc_node_data(int nid)
  * numa_cleanup_meminfo - Cleanup a numa_meminfo
  * @mi: numa_meminfo to clean up
  *
- * Sanitize @mi by merging and removing unncessary memblks.  Also check for
+ * Sanitize @mi by merging and removing unnecessary memblks.  Also check for
  * conflicts and clear unused memblks.
  *
  * RETURNS:
-- 
2.11.0



Re: [PATCH] kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file()

2017-03-13 Thread Greg Kroah-Hartman
On Tue, Mar 14, 2017 at 08:17:00AM +0530, Vaibhav Jain wrote:
> Recently started seeing a kernel oops when a module tries removing a
> memory mapped sysfs bin_attribute. On closer investigation the root
> cause seems to be kernfs_release_file() trying to call
> kernfs_op.release() callback that's NULL for such sysfs
> bin_attributes. The oops occurs when kernfs_release_file() is called from
> kernfs_drain_open_files() to cleanup any open handles with active
> memory mappings.
> 
> The patch fixes this by checking for flag KERNFS_HAS_RELEASE before
> calling kernfs_release_file() in function kernfs_drain_open_files().
> 
> On ppc64-le arch with cxl module the oops back-trace is of the
> form below:
> [  861.381126] Unable to handle kernel paging request for instruction fetch
> [  861.381360] Faulting instruction address: 0x
> [  861.381428] Oops: Kernel access of bad area, sig: 11 [#1]
> 
> [  861.382481] NIP:  LR: c0362c60 CTR:
> 
> 
> Call Trace:
> [c00f1680b750] [c0362c34] kernfs_drain_open_files+0x104/0x1d0 
> (unreliable)
> [c00f1680b790] [c035fa00] __kernfs_remove+0x260/0x2c0
> [c00f1680b820] [c0360da0] kernfs_remove_by_name_ns+0x60/0xe0
> [c00f1680b8b0] [c03638f4] sysfs_remove_bin_file+0x24/0x40
> [c00f1680b8d0] [c062a164] device_remove_bin_file+0x24/0x40
> [c00f1680b8f0] [d9b7b22c] cxl_sysfs_afu_remove+0x144/0x170 [cxl]
> [c00f1680b940] [d9b7c7e4] cxl_remove+0x6c/0x1a0 [cxl]
> [c00f1680b990] [c052f694] pci_device_remove+0x64/0x110
> [c00f1680b9d0] [c06321d4] 
> device_release_driver_internal+0x1f4/0x2b0
> [c00f1680ba20] [c0525cb0] pci_stop_bus_device+0xa0/0xd0
> [c00f1680ba60] [c0525e80] pci_stop_and_remove_bus_device+0x20/0x40
> [c00f1680ba90] [c004a6c4] pci_hp_remove_devices+0x84/0xc0
> [c00f1680bad0] [c004a688] pci_hp_remove_devices+0x48/0xc0
> [c00f1680bb10] [c09dfda4] eeh_reset_device+0xb0/0x290
> [c00f1680bbb0] [c0032b4c] eeh_handle_normal_event+0x47c/0x530
> [c00f1680bc60] [c0032e64] eeh_handle_event+0x174/0x350
> [c00f1680bd10] [c0033228] eeh_event_handler+0x1e8/0x1f0
> [c00f1680bdc0] [c00d384c] kthread+0x14c/0x190
> [c00f1680be30] [c000b5a0] ret_from_kernel_thread+0x5c/0xbc
> 
> Fixes: f83f3c515654("kernfs: fix locking around kernfs_ops->release()
> callback")
> Signed-off-by: Vaibhav Jain 
> ---
>  fs/kernfs/file.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
> index 8e4dc7a..ac2dfe0 100644
> --- a/fs/kernfs/file.c
> +++ b/fs/kernfs/file.c
> @@ -809,7 +809,8 @@ void kernfs_drain_open_files(struct kernfs_node *kn)
>   if (kn->flags & KERNFS_HAS_MMAP)
>   unmap_mapping_range(inode->i_mapping, 0, 0, 1);
>  
> - kernfs_release_file(kn, of);
> + if (kn->flags & KERNFS_HAS_RELEASE)
> + kernfs_release_file(kn, of);
>   }
>  
>   mutex_unlock(_open_file_mutex);
> -- 
> 2.9.3

Tejun, want to take this through your tree, or at the least, give me an
ack for this?

thanks,

greg k-h


[Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

2017-03-13 Thread Wei Yang
numa_nodemask_from_meminfo() is called to set bit according to
numa_meminfo. While the only two places for this call is used to set proper
bit to a copy of numa_nodes_parsed from numa_meminfo. With current code
path, those numa node information in numa_meminfo is a subset of
numa_nodes_parsed. So it is not necessary to set the bits again.

The following is a code path analysis to prove the numa node information in
numa_meminfo is a subset of numa_nodes_parsed.

x86_numa_init()
numa_init()
Case 1
acpi_numa_init()
acpi_parse_memory_affinity()
numa_add_memblk()
node_set(numa_nodes_parsed)
acpi_parse_slit()
numa_nodemask_from_meminfo()

Case 2
amd_numa_init()
numa_add_memblk()
node_set(numa_nodes_parsed)

Case 3
dummy_numa_init()
node_set(numa_nodes_parsed)
numa_add_memblk()

numa_register_memblks()
numa_nodemask_from_meminfo()

>From the code path analysis, we can see each time a memblk is added, the
proper bit is set in numa_nodes_parsed, which means it is not necessary to
set it again in numa_nodemask_from_meminfo() for a copy of
numa_nodes_parsed.

This patch removes numa_nodemask_from_meminfo().

Signed-off-by: Wei Yang 
---
 arch/x86/mm/numa.c | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index ac632e5397aa..5ecc5a745c51 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -314,20 +314,6 @@ int __init numa_cleanup_meminfo(struct numa_meminfo *mi)
return 0;
 }
 
-/*
- * Set nodes, which have memory in @mi, in *@nodemask.
- */
-static void __init numa_nodemask_from_meminfo(nodemask_t *nodemask,
- const struct numa_meminfo *mi)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(mi->blk); i++)
-   if (mi->blk[i].start != mi->blk[i].end &&
-   mi->blk[i].nid != NUMA_NO_NODE)
-   node_set(mi->blk[i].nid, *nodemask);
-}
-
 /**
  * numa_reset_distance - Reset NUMA distance table
  *
@@ -347,16 +333,12 @@ void __init numa_reset_distance(void)
 
 static int __init numa_alloc_distance(void)
 {
-   nodemask_t nodes_parsed;
size_t size;
int i, j, cnt = 0;
u64 phys;
 
/* size the new table and allocate it */
-   nodes_parsed = numa_nodes_parsed;
-   numa_nodemask_from_meminfo(_parsed, _meminfo);
-
-   for_each_node_mask(i, nodes_parsed)
+   for_each_node_mask(i, numa_nodes_parsed)
cnt = i;
cnt++;
size = cnt * cnt * sizeof(numa_distance[0]);
@@ -535,7 +517,6 @@ static int __init numa_register_memblks(struct numa_meminfo 
*mi)
 
/* Account for nodes with cpus and no memory */
node_possible_map = numa_nodes_parsed;
-   numa_nodemask_from_meminfo(_possible_map, mi);
if (WARN_ON(nodes_empty(node_possible_map)))
return -EINVAL;
 
-- 
2.11.0



[Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

2017-03-13 Thread Wei Yang
numa_nodemask_from_meminfo() is called to set bit according to
numa_meminfo. While the only two places for this call is used to set proper
bit to a copy of numa_nodes_parsed from numa_meminfo. With current code
path, those numa node information in numa_meminfo is a subset of
numa_nodes_parsed. So it is not necessary to set the bits again.

The following is a code path analysis to prove the numa node information in
numa_meminfo is a subset of numa_nodes_parsed.

x86_numa_init()
numa_init()
Case 1
acpi_numa_init()
acpi_parse_memory_affinity()
numa_add_memblk()
node_set(numa_nodes_parsed)
acpi_parse_slit()
numa_nodemask_from_meminfo()

Case 2
amd_numa_init()
numa_add_memblk()
node_set(numa_nodes_parsed)

Case 3
dummy_numa_init()
node_set(numa_nodes_parsed)
numa_add_memblk()

numa_register_memblks()
numa_nodemask_from_meminfo()

>From the code path analysis, we can see each time a memblk is added, the
proper bit is set in numa_nodes_parsed, which means it is not necessary to
set it again in numa_nodemask_from_meminfo() for a copy of
numa_nodes_parsed.

This patch removes numa_nodemask_from_meminfo().

Signed-off-by: Wei Yang 
---
 arch/x86/mm/numa.c | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index ac632e5397aa..5ecc5a745c51 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -314,20 +314,6 @@ int __init numa_cleanup_meminfo(struct numa_meminfo *mi)
return 0;
 }
 
-/*
- * Set nodes, which have memory in @mi, in *@nodemask.
- */
-static void __init numa_nodemask_from_meminfo(nodemask_t *nodemask,
- const struct numa_meminfo *mi)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(mi->blk); i++)
-   if (mi->blk[i].start != mi->blk[i].end &&
-   mi->blk[i].nid != NUMA_NO_NODE)
-   node_set(mi->blk[i].nid, *nodemask);
-}
-
 /**
  * numa_reset_distance - Reset NUMA distance table
  *
@@ -347,16 +333,12 @@ void __init numa_reset_distance(void)
 
 static int __init numa_alloc_distance(void)
 {
-   nodemask_t nodes_parsed;
size_t size;
int i, j, cnt = 0;
u64 phys;
 
/* size the new table and allocate it */
-   nodes_parsed = numa_nodes_parsed;
-   numa_nodemask_from_meminfo(_parsed, _meminfo);
-
-   for_each_node_mask(i, nodes_parsed)
+   for_each_node_mask(i, numa_nodes_parsed)
cnt = i;
cnt++;
size = cnt * cnt * sizeof(numa_distance[0]);
@@ -535,7 +517,6 @@ static int __init numa_register_memblks(struct numa_meminfo 
*mi)
 
/* Account for nodes with cpus and no memory */
node_possible_map = numa_nodes_parsed;
-   numa_nodemask_from_meminfo(_possible_map, mi);
if (WARN_ON(nodes_empty(node_possible_map)))
return -EINVAL;
 
-- 
2.11.0



Re: [PATCH] PM / QOS: Remove the global notifiers

2017-03-13 Thread Viresh Kumar
On 13-03-17, 14:32, Kevin Hilman wrote:
> Ulf Hansson  writes:
> 
> > On 13 March 2017 at 17:01, Ulf Hansson  wrote:
> >> On 22 February 2017 at 09:28, Viresh Kumar  wrote:
> >>> They were never used in the kernel, not sure why they got merged into
> >>> the kernel though. Get rid of them.
> >>
> >> commit b66213cdb002b08b29603d488c451dfe25e2ca20
> >> Author: Jean Pihet 
> >> Date:   Thu Aug 25 15:35:47 2011 +0200
> >>
> >> PM QoS: Add global notification mechanism for device constraints
> >>
> >> Add a global notification chain that gets called upon changes to the
> >> aggregated constraint value for any device.
> >> The notification callbacks are passing the full constraint request data
> >> in order for the callees to have access to it. The current use is for 
> >> the
> >> platform low-level code to access the target device of the constraint.
> >>
> >> Signed-off-by: Jean Pihet 
> >> Reviewed-by: Kevin Hilman 
> >> Signed-off-by: Rafael J. Wysocki 
> >>
> >> It was a while ago since they were added, but it seems like
> >
> > Slipped on the keyboard, sorry for the noise.
> >
> > I was about to say, that it was a while ago these were added, but
> > still not being used. Thus let's remove them.
> >
> > Acked-by: Ulf Hansson 
> 
> Agreed.  If we still have no users, let's remove them.
> 
> Acked-by: Kevin Hilman 

Its in Linus's tree for sometime now :)

Thanks for your Acks though

-- 
viresh


Re: [PATCH] lockdep: call time_hardirqs_off after clearing hardirqs_enabled

2017-03-13 Thread Steven Rostedt
On Tue, 14 Mar 2017 10:00:07 +0800
Qi Hou  wrote:

> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 577f026..e8b35e4 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2627,8 +2627,6 @@ __visible void trace_hardirqs_off_caller(unsigned long 
> ip)
>  {
>   struct task_struct *curr = current;
>  
> - time_hardirqs_off(CALLER_ADDR0, ip);
> -
>   if (unlikely(!debug_locks || current->lockdep_recursion))
>   return;

You do realize that this breaks irqsoff tracing if lockdep ever
triggers. Right?

-- Steve

>  
> @@ -2649,6 +2647,8 @@ __visible void trace_hardirqs_off_caller(unsigned long 
> ip)
>   debug_atomic_inc(hardirqs_off_events);
>   } else
>   debug_atomic_inc(redundant_hardirqs_off);
> +
> + time_hardirqs_off(CALLER_ADDR0, ip);
>  }
>  EXPORT_SYMBOL(trace_hardirqs_off_caller);
>  



Re: [PATCH v2] mm: fix condition for throttle_direct_reclaim

2017-03-13 Thread Hillf Danton

On March 14, 2017 6:19 AM Shakeel Butt wrote: 
> 
> Recently kswapd has been modified to give up after MAX_RECLAIM_RETRIES
> number of unsucessful iterations. Before going to sleep, kswapd thread
> will unconditionally wakeup all threads sleeping on pfmemalloc_wait.
> However the awoken threads will recheck the watermarks and wake the
> kswapd thread and sleep again on pfmemalloc_wait. There is a chance
> of continuous back and forth between kswapd and direct reclaiming
> threads if the kswapd keep failing and thus defeat the purpose of
> adding backoff mechanism to kswapd. So, add kswapd_failures check
> on the throttle_direct_reclaim condition.
> 
> Signed-off-by: Shakeel Butt 
> Suggested-by: Michal Hocko 
> Suggested-by: Johannes Weiner 
> ---

Acked-by: Hillf Danton 



Re: [PATCH] PM / QOS: Remove the global notifiers

2017-03-13 Thread Viresh Kumar
On 13-03-17, 14:32, Kevin Hilman wrote:
> Ulf Hansson  writes:
> 
> > On 13 March 2017 at 17:01, Ulf Hansson  wrote:
> >> On 22 February 2017 at 09:28, Viresh Kumar  wrote:
> >>> They were never used in the kernel, not sure why they got merged into
> >>> the kernel though. Get rid of them.
> >>
> >> commit b66213cdb002b08b29603d488c451dfe25e2ca20
> >> Author: Jean Pihet 
> >> Date:   Thu Aug 25 15:35:47 2011 +0200
> >>
> >> PM QoS: Add global notification mechanism for device constraints
> >>
> >> Add a global notification chain that gets called upon changes to the
> >> aggregated constraint value for any device.
> >> The notification callbacks are passing the full constraint request data
> >> in order for the callees to have access to it. The current use is for 
> >> the
> >> platform low-level code to access the target device of the constraint.
> >>
> >> Signed-off-by: Jean Pihet 
> >> Reviewed-by: Kevin Hilman 
> >> Signed-off-by: Rafael J. Wysocki 
> >>
> >> It was a while ago since they were added, but it seems like
> >
> > Slipped on the keyboard, sorry for the noise.
> >
> > I was about to say, that it was a while ago these were added, but
> > still not being used. Thus let's remove them.
> >
> > Acked-by: Ulf Hansson 
> 
> Agreed.  If we still have no users, let's remove them.
> 
> Acked-by: Kevin Hilman 

Its in Linus's tree for sometime now :)

Thanks for your Acks though

-- 
viresh


Re: [PATCH] lockdep: call time_hardirqs_off after clearing hardirqs_enabled

2017-03-13 Thread Steven Rostedt
On Tue, 14 Mar 2017 10:00:07 +0800
Qi Hou  wrote:

> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 577f026..e8b35e4 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2627,8 +2627,6 @@ __visible void trace_hardirqs_off_caller(unsigned long 
> ip)
>  {
>   struct task_struct *curr = current;
>  
> - time_hardirqs_off(CALLER_ADDR0, ip);
> -
>   if (unlikely(!debug_locks || current->lockdep_recursion))
>   return;

You do realize that this breaks irqsoff tracing if lockdep ever
triggers. Right?

-- Steve

>  
> @@ -2649,6 +2647,8 @@ __visible void trace_hardirqs_off_caller(unsigned long 
> ip)
>   debug_atomic_inc(hardirqs_off_events);
>   } else
>   debug_atomic_inc(redundant_hardirqs_off);
> +
> + time_hardirqs_off(CALLER_ADDR0, ip);
>  }
>  EXPORT_SYMBOL(trace_hardirqs_off_caller);
>  



Re: [PATCH v2] mm: fix condition for throttle_direct_reclaim

2017-03-13 Thread Hillf Danton

On March 14, 2017 6:19 AM Shakeel Butt wrote: 
> 
> Recently kswapd has been modified to give up after MAX_RECLAIM_RETRIES
> number of unsucessful iterations. Before going to sleep, kswapd thread
> will unconditionally wakeup all threads sleeping on pfmemalloc_wait.
> However the awoken threads will recheck the watermarks and wake the
> kswapd thread and sleep again on pfmemalloc_wait. There is a chance
> of continuous back and forth between kswapd and direct reclaiming
> threads if the kswapd keep failing and thus defeat the purpose of
> adding backoff mechanism to kswapd. So, add kswapd_failures check
> on the throttle_direct_reclaim condition.
> 
> Signed-off-by: Shakeel Butt 
> Suggested-by: Michal Hocko 
> Suggested-by: Johannes Weiner 
> ---

Acked-by: Hillf Danton 



Re: [PATCH 4.10 00/75] 4.10.3-stable review

2017-03-13 Thread Greg Kroah-Hartman
On Mon, Mar 13, 2017 at 07:11:12AM -0700, kernelci.org bot wrote:
> stable-rc boot: 530 boots: 5 failed, 516 passed with 9 offline 
> (v4.10.2-76-g43100e143367)

These are ok, right?  And 4.9 seems to not be doing many boots, is the
build farm just busy?

thanks,

greg k-h


Re: [PATCH 4.10 00/75] 4.10.3-stable review

2017-03-13 Thread Greg Kroah-Hartman
On Mon, Mar 13, 2017 at 07:11:12AM -0700, kernelci.org bot wrote:
> stable-rc boot: 530 boots: 5 failed, 516 passed with 9 offline 
> (v4.10.2-76-g43100e143367)

These are ok, right?  And 4.9 seems to not be doing many boots, is the
build farm just busy?

thanks,

greg k-h


Re: [PATCH] lockdep: call time_hardirqs_off after clearing hardirqs_enabled

2017-03-13 Thread Paul Gortmaker
Please stop sending "guesswork" patches.  This message to you is not
new.   I am running out of avenues where I can ask you to cease and
desist;  spamming maintainers like this is not acceptable.  You are
one step away from being in a kill-file.

On Mon, Mar 13, 2017 at 10:00 PM, Qi Hou  wrote:
> The current order of calls within trace_hardirqs_off_caller() would provoke
> an "unannotated irqs-off" WARNING.
>
> This warning was reported by check_flags() when it found that the hardirqs has
> been disabled but the irq-flags state, "hardirqs_enabled", has not been 
> cleared.
>
> Check_flags() is called via trace_hardirqs_off(), and trace_hardirqs_off() 
> will
> be called by functions kind of local_irq_disable() if CONFIG_TRACE_IRQFLAGS 
> has
> been enabled.
>
> The calltrace from functions kind of local_irq_diasble() to check_flags()
> simplied as below:
>
> local_irq_disable()
>  |- trace_hardirqs_off()
>  |- trace_hardirqs_off_caller()
>  |- time_hardirqs_off()
>  |- trace_preemptirqsoff_hist_rcuidle()
> |- __DO_TRACE()
>|- rcu_dereference_sched()
>   |- rcu_read_lock_sched_held()
>   |- lock_is_held()
>   |- check_flags()
>
> The order of calls within trace_hardirqs_off_caller() simplified as below:
>
> local_irq_disable()
>  |- raw_local_irq_disable()
>  |- trace_hardirqs_off()
>  |- trace_hardirqs_off_caller()
>  |- time_hardirqs_off() -->check_flags()
>  |- hardirqs_enabled = 0
>
> We could find that the call to check_flags() has been made between disabling
> hardirqs and clearing hardirqs_enabled. That will definitely cause an
> "unannotated irqs-off" warning.
>
> To fix this "unannotated irqs-off" warning, we must call time_hardirqs_off()
> after that we clear hardirqs_enabled.
>
> Signed-off-by: Qi Hou 
> ---
>  kernel/locking/lockdep.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 577f026..e8b35e4 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2627,8 +2627,6 @@ __visible void trace_hardirqs_off_caller(unsigned long 
> ip)
>  {
> struct task_struct *curr = current;
>
> -   time_hardirqs_off(CALLER_ADDR0, ip);
> -
> if (unlikely(!debug_locks || current->lockdep_recursion))
> return;
>
> @@ -2649,6 +2647,8 @@ __visible void trace_hardirqs_off_caller(unsigned long 
> ip)
> debug_atomic_inc(hardirqs_off_events);
> } else
> debug_atomic_inc(redundant_hardirqs_off);
> +
> +   time_hardirqs_off(CALLER_ADDR0, ip);
>  }
>  EXPORT_SYMBOL(trace_hardirqs_off_caller);
>
> --
> 1.9.1
>


Re: [PATCH] lockdep: call time_hardirqs_off after clearing hardirqs_enabled

2017-03-13 Thread Paul Gortmaker
Please stop sending "guesswork" patches.  This message to you is not
new.   I am running out of avenues where I can ask you to cease and
desist;  spamming maintainers like this is not acceptable.  You are
one step away from being in a kill-file.

On Mon, Mar 13, 2017 at 10:00 PM, Qi Hou  wrote:
> The current order of calls within trace_hardirqs_off_caller() would provoke
> an "unannotated irqs-off" WARNING.
>
> This warning was reported by check_flags() when it found that the hardirqs has
> been disabled but the irq-flags state, "hardirqs_enabled", has not been 
> cleared.
>
> Check_flags() is called via trace_hardirqs_off(), and trace_hardirqs_off() 
> will
> be called by functions kind of local_irq_disable() if CONFIG_TRACE_IRQFLAGS 
> has
> been enabled.
>
> The calltrace from functions kind of local_irq_diasble() to check_flags()
> simplied as below:
>
> local_irq_disable()
>  |- trace_hardirqs_off()
>  |- trace_hardirqs_off_caller()
>  |- time_hardirqs_off()
>  |- trace_preemptirqsoff_hist_rcuidle()
> |- __DO_TRACE()
>|- rcu_dereference_sched()
>   |- rcu_read_lock_sched_held()
>   |- lock_is_held()
>   |- check_flags()
>
> The order of calls within trace_hardirqs_off_caller() simplified as below:
>
> local_irq_disable()
>  |- raw_local_irq_disable()
>  |- trace_hardirqs_off()
>  |- trace_hardirqs_off_caller()
>  |- time_hardirqs_off() -->check_flags()
>  |- hardirqs_enabled = 0
>
> We could find that the call to check_flags() has been made between disabling
> hardirqs and clearing hardirqs_enabled. That will definitely cause an
> "unannotated irqs-off" warning.
>
> To fix this "unannotated irqs-off" warning, we must call time_hardirqs_off()
> after that we clear hardirqs_enabled.
>
> Signed-off-by: Qi Hou 
> ---
>  kernel/locking/lockdep.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 577f026..e8b35e4 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2627,8 +2627,6 @@ __visible void trace_hardirqs_off_caller(unsigned long 
> ip)
>  {
> struct task_struct *curr = current;
>
> -   time_hardirqs_off(CALLER_ADDR0, ip);
> -
> if (unlikely(!debug_locks || current->lockdep_recursion))
> return;
>
> @@ -2649,6 +2647,8 @@ __visible void trace_hardirqs_off_caller(unsigned long 
> ip)
> debug_atomic_inc(hardirqs_off_events);
> } else
> debug_atomic_inc(redundant_hardirqs_off);
> +
> +   time_hardirqs_off(CALLER_ADDR0, ip);
>  }
>  EXPORT_SYMBOL(trace_hardirqs_off_caller);
>
> --
> 1.9.1
>


Re: [PATCH 4.10 00/75] 4.10.3-stable review

2017-03-13 Thread Greg Kroah-Hartman
On Mon, Mar 13, 2017 at 03:38:11PM -0700, Guenter Roeck wrote:
> On Mon, Mar 13, 2017 at 04:43:09PM +0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.3 release.
> > There are 75 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Mar 15 08:33:49 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 149 fail: 0
> Qemu test results:
>   total: 122 pass: 122 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h


Re: [PATCH 4.10 00/75] 4.10.3-stable review

2017-03-13 Thread Greg Kroah-Hartman
On Mon, Mar 13, 2017 at 03:38:11PM -0700, Guenter Roeck wrote:
> On Mon, Mar 13, 2017 at 04:43:09PM +0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.3 release.
> > There are 75 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Mar 15 08:33:49 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 149 fail: 0
> Qemu test results:
>   total: 122 pass: 122 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h


Re: [scsi] scsi: ufs: don't check unsigned type for a negative value

2017-03-13 Thread Martin K. Petersen
> "Tomas" == Tomas Winkler  writes:

Tomas> Fix compilation warning drivers/scsi/ufs/ufshcd.c:7645:13:
Tomas> warning: comparison of unsigned expression < 0 is always false
Tomas> [-Wtype-limits] if ((value < UFS_PM_LVL_0) || (value >=
Tomas> UFS_PM_LVL_MAX))

Applied to 4.11/scsi-fixes, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [scsi] scsi: ufs: don't check unsigned type for a negative value

2017-03-13 Thread Martin K. Petersen
> "Tomas" == Tomas Winkler  writes:

Tomas> Fix compilation warning drivers/scsi/ufs/ufshcd.c:7645:13:
Tomas> warning: comparison of unsigned expression < 0 is always false
Tomas> [-Wtype-limits] if ((value < UFS_PM_LVL_0) || (value >=
Tomas> UFS_PM_LVL_MAX))

Applied to 4.11/scsi-fixes, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH v1 2/2] dmaengine: Add DW AXI DMAC driver

2017-03-13 Thread Vinod Koul
On Tue, Feb 21, 2017 at 11:38:04PM +0300, Eugeniy Paltsev wrote:

> +static struct axi_dma_desc *axi_desc_get(struct axi_dma_chan *chan)
> +{
> + struct dw_axi_dma *dw = chan->chip->dw;
> + struct axi_dma_desc *desc;
> + dma_addr_t phys;
> +
> + desc = dma_pool_zalloc(dw->desc_pool, GFP_ATOMIC, );

GFP_NOWAIT please

> +static void axi_desc_put(struct axi_dma_desc *desc)
> +{
> + struct axi_dma_chan *chan = desc->chan;
> + struct dw_axi_dma *dw = chan->chip->dw;
> + struct axi_dma_desc *child, *_next;
> + unsigned int descs_put = 0;
> +
> + list_for_each_entry_safe(child, _next, >xfer_list, xfer_list) {
> + list_del(>xfer_list);
> + dma_pool_free(dw->desc_pool, child, child->vd.tx.phys);
> + descs_put++;
> + }
> +
> + dma_pool_free(dw->desc_pool, desc, desc->vd.tx.phys);
> + descs_put++;
> +
> + chan->descs_allocated -= descs_put;

why not decrement chan->descs_allocated?

> +
> + dev_vdbg(chan2dev(chan), "%s: %d descs put, %d still allocated\n",
> + axi_chan_name(chan), descs_put, chan->descs_allocated);
> +}
> +
> +static void vchan_desc_put(struct virt_dma_desc *vdesc)
> +{
> + axi_desc_put(vd_to_axi_desc(vdesc));
> +}

well this has no logic and becomes a dummy fn, so why do we need it.

> +
> +static enum dma_status
> +dma_chan_tx_status(struct dma_chan *dchan, dma_cookie_t cookie,
> +   struct dma_tx_state *txstate)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> + enum dma_status ret;
> +
> + ret = dma_cookie_status(dchan, cookie, txstate);
> +
> + if (chan->is_paused && ret == DMA_IN_PROGRESS)
> + return DMA_PAUSED;

no residue calculation?

> +static void axi_chan_start_first_queued(struct axi_dma_chan *chan)
> +{
> + struct axi_dma_desc *desc;
> + struct virt_dma_desc *vd;
> +
> + vd = vchan_next_desc(>vc);

unnecessary empty line

> +static void dma_chan_free_chan_resources(struct dma_chan *dchan)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> +
> + /* ASSERT: channel is idle */
> + if (axi_chan_is_hw_enable(chan))
> + dev_err(dchan2dev(dchan), "%s is non-idle!\n",
> + axi_chan_name(chan));
> +
> + axi_chan_disable(chan);
> + axi_chan_irq_disable(chan, DWAXIDMAC_IRQ_ALL);
> +
> + vchan_free_chan_resources(>vc);
> +
> + dev_vdbg(dchan2dev(dchan), "%s: %s: descriptor still allocated: %u\n",
> + __func__, axi_chan_name(chan), chan->descs_allocated);
> +
> + pm_runtime_put_sync_suspend(chan->chip->dev);

any reason why sync variant is used?

> +static struct dma_async_tx_descriptor *
> +dma_chan_prep_dma_sg(struct dma_chan *dchan,
> +  struct scatterlist *dst_sg, unsigned int dst_nents,
> +  struct scatterlist *src_sg, unsigned int src_nents,
> +  unsigned long flags)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> + struct axi_dma_desc *first = NULL, *desc = NULL, *prev = NULL;
> + size_t dst_len = 0, src_len = 0, xfer_len = 0;
> + dma_addr_t dst_adr = 0, src_adr = 0;
> + u32 src_width, dst_width;
> + size_t block_ts, max_block_ts;
> + u32 reg;
> + u8 lms = 0;
> +
> + dev_vdbg(chan2dev(chan), "%s: %s: sn: %d dn: %d flags: 0x%lx",
> + __func__, axi_chan_name(chan), src_nents, dst_nents, flags);
> +
> + if (unlikely(dst_nents == 0 || src_nents == 0))
> + return NULL;
> +
> + if (unlikely(dst_sg == NULL || src_sg == NULL))
> + return NULL;
> +
> + max_block_ts = chan->chip->dw->hdata->block_size[chan->id];
> +
> + /*
> +  * Loop until there is either no more source or no more destination
> +  * scatterlist entry.
> +  */
> + while ((dst_len || (dst_sg && dst_nents)) &&
> +(src_len || (src_sg && src_nents))) {
> + if (dst_len == 0) {
> + dst_adr = sg_dma_address(dst_sg);
> + dst_len = sg_dma_len(dst_sg);
> +
> + dst_sg = sg_next(dst_sg);
> + dst_nents--;
> + }
> +
> + /* Process src sg list */
> + if (src_len == 0) {
> + src_adr = sg_dma_address(src_sg);
> + src_len = sg_dma_len(src_sg);
> +
> + src_sg = sg_next(src_sg);
> + src_nents--;
> + }
> +
> + /* Min of src and dest length will be this xfer length */
> + xfer_len = min_t(size_t, src_len, dst_len);
> + if (xfer_len == 0)
> + continue;
> +
> + /* Take care for the alignment */
> + src_width = axi_chan_get_xfer_width(chan, src_adr,
> + dst_adr, xfer_len);
> + /*
> +  * Actually src_width and dst_width can be different, but 

Re: [PATCH v1 2/2] dmaengine: Add DW AXI DMAC driver

2017-03-13 Thread Vinod Koul
On Tue, Feb 21, 2017 at 11:38:04PM +0300, Eugeniy Paltsev wrote:

> +static struct axi_dma_desc *axi_desc_get(struct axi_dma_chan *chan)
> +{
> + struct dw_axi_dma *dw = chan->chip->dw;
> + struct axi_dma_desc *desc;
> + dma_addr_t phys;
> +
> + desc = dma_pool_zalloc(dw->desc_pool, GFP_ATOMIC, );

GFP_NOWAIT please

> +static void axi_desc_put(struct axi_dma_desc *desc)
> +{
> + struct axi_dma_chan *chan = desc->chan;
> + struct dw_axi_dma *dw = chan->chip->dw;
> + struct axi_dma_desc *child, *_next;
> + unsigned int descs_put = 0;
> +
> + list_for_each_entry_safe(child, _next, >xfer_list, xfer_list) {
> + list_del(>xfer_list);
> + dma_pool_free(dw->desc_pool, child, child->vd.tx.phys);
> + descs_put++;
> + }
> +
> + dma_pool_free(dw->desc_pool, desc, desc->vd.tx.phys);
> + descs_put++;
> +
> + chan->descs_allocated -= descs_put;

why not decrement chan->descs_allocated?

> +
> + dev_vdbg(chan2dev(chan), "%s: %d descs put, %d still allocated\n",
> + axi_chan_name(chan), descs_put, chan->descs_allocated);
> +}
> +
> +static void vchan_desc_put(struct virt_dma_desc *vdesc)
> +{
> + axi_desc_put(vd_to_axi_desc(vdesc));
> +}

well this has no logic and becomes a dummy fn, so why do we need it.

> +
> +static enum dma_status
> +dma_chan_tx_status(struct dma_chan *dchan, dma_cookie_t cookie,
> +   struct dma_tx_state *txstate)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> + enum dma_status ret;
> +
> + ret = dma_cookie_status(dchan, cookie, txstate);
> +
> + if (chan->is_paused && ret == DMA_IN_PROGRESS)
> + return DMA_PAUSED;

no residue calculation?

> +static void axi_chan_start_first_queued(struct axi_dma_chan *chan)
> +{
> + struct axi_dma_desc *desc;
> + struct virt_dma_desc *vd;
> +
> + vd = vchan_next_desc(>vc);

unnecessary empty line

> +static void dma_chan_free_chan_resources(struct dma_chan *dchan)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> +
> + /* ASSERT: channel is idle */
> + if (axi_chan_is_hw_enable(chan))
> + dev_err(dchan2dev(dchan), "%s is non-idle!\n",
> + axi_chan_name(chan));
> +
> + axi_chan_disable(chan);
> + axi_chan_irq_disable(chan, DWAXIDMAC_IRQ_ALL);
> +
> + vchan_free_chan_resources(>vc);
> +
> + dev_vdbg(dchan2dev(dchan), "%s: %s: descriptor still allocated: %u\n",
> + __func__, axi_chan_name(chan), chan->descs_allocated);
> +
> + pm_runtime_put_sync_suspend(chan->chip->dev);

any reason why sync variant is used?

> +static struct dma_async_tx_descriptor *
> +dma_chan_prep_dma_sg(struct dma_chan *dchan,
> +  struct scatterlist *dst_sg, unsigned int dst_nents,
> +  struct scatterlist *src_sg, unsigned int src_nents,
> +  unsigned long flags)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> + struct axi_dma_desc *first = NULL, *desc = NULL, *prev = NULL;
> + size_t dst_len = 0, src_len = 0, xfer_len = 0;
> + dma_addr_t dst_adr = 0, src_adr = 0;
> + u32 src_width, dst_width;
> + size_t block_ts, max_block_ts;
> + u32 reg;
> + u8 lms = 0;
> +
> + dev_vdbg(chan2dev(chan), "%s: %s: sn: %d dn: %d flags: 0x%lx",
> + __func__, axi_chan_name(chan), src_nents, dst_nents, flags);
> +
> + if (unlikely(dst_nents == 0 || src_nents == 0))
> + return NULL;
> +
> + if (unlikely(dst_sg == NULL || src_sg == NULL))
> + return NULL;
> +
> + max_block_ts = chan->chip->dw->hdata->block_size[chan->id];
> +
> + /*
> +  * Loop until there is either no more source or no more destination
> +  * scatterlist entry.
> +  */
> + while ((dst_len || (dst_sg && dst_nents)) &&
> +(src_len || (src_sg && src_nents))) {
> + if (dst_len == 0) {
> + dst_adr = sg_dma_address(dst_sg);
> + dst_len = sg_dma_len(dst_sg);
> +
> + dst_sg = sg_next(dst_sg);
> + dst_nents--;
> + }
> +
> + /* Process src sg list */
> + if (src_len == 0) {
> + src_adr = sg_dma_address(src_sg);
> + src_len = sg_dma_len(src_sg);
> +
> + src_sg = sg_next(src_sg);
> + src_nents--;
> + }
> +
> + /* Min of src and dest length will be this xfer length */
> + xfer_len = min_t(size_t, src_len, dst_len);
> + if (xfer_len == 0)
> + continue;
> +
> + /* Take care for the alignment */
> + src_width = axi_chan_get_xfer_width(chan, src_adr,
> + dst_adr, xfer_len);
> + /*
> +  * Actually src_width and dst_width can be different, but 

Re: Compat 32-bit syscall entry from 64-bit task!?

2017-03-13 Thread Dmitry V. Levin
On Wed, Mar 08, 2017 at 08:39:55PM -0800, Andrew Lutomirski wrote:
> On Wed, Mar 8, 2017 at 3:41 PM, Dmitry V. Levin wrote:
[...]
> > Is there any progress with this (or any alternative) solution?
> >
> > I see the kernel side has changed a bit, and the strace part
> > is in a better shape than 5 years ago (although I'm biased of course),
> > but I don't see any kernel interface that would allow strace to reliably
> > recognize this 0x80 case.
> 
> I am strongly opposed to fudging registers to half-arsedly slightly
> improve the epicly crappy ptrace(2) interface for syscalls.
> 
> To fix this right, please just add PTRACE_GET_SYSCALL_INFO or similar
> to, in one shot, read out all the syscall details.  This means: arch,
> no, arg0..arg5, and *whether it's entry or exit*.  I propose returning
> this structure:
> 
> struct ptrace_syscall_info {
>   u8 op;  /* 0 for entry, 1 for exit */
>   u8 pad0;
>   u16 pad1;
>   u32 pad2;
>   union {
> struct seccomp_data syscall_entry;
> s64 syscall_exit_retval;
>   };
> };
> 
> because struct seccomp_data already gets this right.  There's plenty
> of opportunity to fine-tune this.  Now it works on all architectures.

Unfortunately, the API is missing.

Unlike syscall_get_nr(), syscall_get_arch() works with the current task
only so there is no API to get the arch identifier for the given task
that would work on all architectures.


-- 
ldv


pgpkmPAKkKJMR.pgp
Description: PGP signature


Re: Compat 32-bit syscall entry from 64-bit task!?

2017-03-13 Thread Dmitry V. Levin
On Wed, Mar 08, 2017 at 08:39:55PM -0800, Andrew Lutomirski wrote:
> On Wed, Mar 8, 2017 at 3:41 PM, Dmitry V. Levin wrote:
[...]
> > Is there any progress with this (or any alternative) solution?
> >
> > I see the kernel side has changed a bit, and the strace part
> > is in a better shape than 5 years ago (although I'm biased of course),
> > but I don't see any kernel interface that would allow strace to reliably
> > recognize this 0x80 case.
> 
> I am strongly opposed to fudging registers to half-arsedly slightly
> improve the epicly crappy ptrace(2) interface for syscalls.
> 
> To fix this right, please just add PTRACE_GET_SYSCALL_INFO or similar
> to, in one shot, read out all the syscall details.  This means: arch,
> no, arg0..arg5, and *whether it's entry or exit*.  I propose returning
> this structure:
> 
> struct ptrace_syscall_info {
>   u8 op;  /* 0 for entry, 1 for exit */
>   u8 pad0;
>   u16 pad1;
>   u32 pad2;
>   union {
> struct seccomp_data syscall_entry;
> s64 syscall_exit_retval;
>   };
> };
> 
> because struct seccomp_data already gets this right.  There's plenty
> of opportunity to fine-tune this.  Now it works on all architectures.

Unfortunately, the API is missing.

Unlike syscall_get_nr(), syscall_get_arch() works with the current task
only so there is no API to get the arch identifier for the given task
that would work on all architectures.


-- 
ldv


pgpkmPAKkKJMR.pgp
Description: PGP signature


fsx tests on DAX started to fail with msync failure on 0307 -next tree

2017-03-13 Thread Xiong Zhou
Hi,

xfstests cases:
generic/075 generic/112 generic/127 generic/231 generic/263

fail with DAX, pass without it. Both xfs and ext4.

It was okay on 0306 -next tree.

+ ./check generic/075
FSTYP -- xfs (non-debug)
PLATFORM  -- Linux/x86_64 hp-dl360g9-12 
4.11.0-rc1-linux-next-5be4921-next-20170310
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem0p2
MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:nfs_t:s0 /dev/pmem0p2 
/daxsch

generic/075 4s ... [failed, exit status 1] - output mismatch (see 
/root/xfstests/results//generic/075.out.bad)
--- tests/generic/075.out   2016-12-13 14:38:25.984557426 +0800
+++ /root/xfstests/results//generic/075.out.bad 2017-03-14 
10:40:23.083052839 +0800
@@ -4,15 +4,4 @@
 ---
 fsx.0 : -d -N numops -S 0
 ---
-

-fsx.1 : -d -N numops -S 0 -x

...
(Run 'diff -u tests/generic/075.out 
/root/xfstests/results//generic/075.out.bad'  to see the entire diff)
..

$ diff -u xfstests/tests/generic/075.out 
/root/xfstests/results//generic/075.out.bad
--- xfstests/tests/generic/075.out  2016-12-13 14:38:25.984557426 +0800
+++ /root/xfstests/results//generic/075.out.bad 2017-03-14 10:40:23.083052839 
+0800
@@ -4,15 +4,4 @@
 ---
 fsx.0 : -d -N numops -S 0
 ---
-

-fsx.1 : -d -N numops -S 0 -x

-

-fsx.2 : -d -N numops -l filelen -S 0

-

-fsx.3 : -d -N numops -l filelen -S 0 -x

+fsx (-d -N 1000 -S 0) failed, 0 - compare 
/root/xfstests/results//generic/075.0.{good,bad,fsxlog}

$ diff -u /root/xfstests/results//generic/075.0.{good,fsxlog} | tail -20
-03cb30 f903 da03 1103 7503 5403 8903 9f03 6b03
-03cb40 bb03 fb03 5603 7e03 c503 ca03 0103 9603
-03cb50 7f03 7c03 0c03 5103 ed03 dc03 a403 5c03
-03cb60 5403 b903 4403 3c03 4b03 a903 2303 1a03
-03cb70 2b03 5f03 fd03 ee03 1303 9703 2903 d303
-03cb80 4e03 9903 f903 8003 b803 2503 2203 c903
-03cb90 6803 7a03 0f03 6303 de03 ba03 6e03 6503
-03cba0 db03
-03cba2
+skipping zero size read
+skipping insert range behind EOF
+3 mapwrite 0x2e836 thru0x3cba1 (0xe36c bytes)
+domapwrite: msync: Invalid argument
+LOG DUMP (3 total operations):
+1(  1 mod 256): SKIPPED (no operation)
+2(  2 mod 256): SKIPPED (no operation)
+3(  3 mod 256): MAPWRITE 0x2e836 thru 0x3cba1  (0xe36c bytes)
+Log of operations saved to "075.0.fsxops"; replay with --replay-ops
+Correct content saved for comparison
+(maybe hexdump "075.0" vs "075.0.fsxgood")

https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/generic/075
https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/ltp/fsx.c


fsx tests on DAX started to fail with msync failure on 0307 -next tree

2017-03-13 Thread Xiong Zhou
Hi,

xfstests cases:
generic/075 generic/112 generic/127 generic/231 generic/263

fail with DAX, pass without it. Both xfs and ext4.

It was okay on 0306 -next tree.

+ ./check generic/075
FSTYP -- xfs (non-debug)
PLATFORM  -- Linux/x86_64 hp-dl360g9-12 
4.11.0-rc1-linux-next-5be4921-next-20170310
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem0p2
MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:nfs_t:s0 /dev/pmem0p2 
/daxsch

generic/075 4s ... [failed, exit status 1] - output mismatch (see 
/root/xfstests/results//generic/075.out.bad)
--- tests/generic/075.out   2016-12-13 14:38:25.984557426 +0800
+++ /root/xfstests/results//generic/075.out.bad 2017-03-14 
10:40:23.083052839 +0800
@@ -4,15 +4,4 @@
 ---
 fsx.0 : -d -N numops -S 0
 ---
-

-fsx.1 : -d -N numops -S 0 -x

...
(Run 'diff -u tests/generic/075.out 
/root/xfstests/results//generic/075.out.bad'  to see the entire diff)
..

$ diff -u xfstests/tests/generic/075.out 
/root/xfstests/results//generic/075.out.bad
--- xfstests/tests/generic/075.out  2016-12-13 14:38:25.984557426 +0800
+++ /root/xfstests/results//generic/075.out.bad 2017-03-14 10:40:23.083052839 
+0800
@@ -4,15 +4,4 @@
 ---
 fsx.0 : -d -N numops -S 0
 ---
-

-fsx.1 : -d -N numops -S 0 -x

-

-fsx.2 : -d -N numops -l filelen -S 0

-

-fsx.3 : -d -N numops -l filelen -S 0 -x

+fsx (-d -N 1000 -S 0) failed, 0 - compare 
/root/xfstests/results//generic/075.0.{good,bad,fsxlog}

$ diff -u /root/xfstests/results//generic/075.0.{good,fsxlog} | tail -20
-03cb30 f903 da03 1103 7503 5403 8903 9f03 6b03
-03cb40 bb03 fb03 5603 7e03 c503 ca03 0103 9603
-03cb50 7f03 7c03 0c03 5103 ed03 dc03 a403 5c03
-03cb60 5403 b903 4403 3c03 4b03 a903 2303 1a03
-03cb70 2b03 5f03 fd03 ee03 1303 9703 2903 d303
-03cb80 4e03 9903 f903 8003 b803 2503 2203 c903
-03cb90 6803 7a03 0f03 6303 de03 ba03 6e03 6503
-03cba0 db03
-03cba2
+skipping zero size read
+skipping insert range behind EOF
+3 mapwrite 0x2e836 thru0x3cba1 (0xe36c bytes)
+domapwrite: msync: Invalid argument
+LOG DUMP (3 total operations):
+1(  1 mod 256): SKIPPED (no operation)
+2(  2 mod 256): SKIPPED (no operation)
+3(  3 mod 256): MAPWRITE 0x2e836 thru 0x3cba1  (0xe36c bytes)
+Log of operations saved to "075.0.fsxops"; replay with --replay-ops
+Correct content saved for comparison
+(maybe hexdump "075.0" vs "075.0.fsxgood")

https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/generic/075
https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/ltp/fsx.c


Re: [RFC PATCH kernel] gcc-goto.sh: Allow to pass with CONFIG_DEBUG_INFO_SPLIT=y

2017-03-13 Thread Alexey Kardashevskiy
On 03/03/17 11:51, Alexey Kardashevskiy wrote:
> With just CONFIG_DEBUG_INFO=y, the makefile adds "-g" to
> KBUILD_CFLAGS/KBUILD_AFLAGS and the test passes.
> 
> However, if CONFIG_DEBUG_INFO_SPLIT is also enabled, the makefile
> adds "-gsplit-dwarf" instead which makes the test fail with $?==1
> because of objcopy trying to split the debug info:
> 
> objcopy: Warning: '/dev/null' is not an ordinary file
> 
> This changes the output to $(mktemp) which fixes the problem.
> 
> I am pretty sure there better ways, this is just to demonstrate the bug.
> 
> gcc 5.4.1, ppc64le (does not really matter).
> 
> Cc: Jason Baron 


Ping?



> Signed-off-by: Alexey Kardashevskiy 
> ---
>  scripts/gcc-goto.sh | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
> index c9469d34ecc6..ab21216ab68d 100755
> --- a/scripts/gcc-goto.sh
> +++ b/scripts/gcc-goto.sh
> @@ -2,7 +2,8 @@
>  # Test for gcc 'asm goto' support
>  # Copyright (C) 2010, Jason Baron 
>  
> -cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
> +TMPOUT=$(mktemp)
> +cat << "END" | $@ -x c - -c -o $TMPOUT >/dev/null 2>&1 && echo "y"
>  int main(void)
>  {
>  #if defined(__arm__) || defined(__aarch64__)
> @@ -19,3 +20,5 @@ entry:
>   return 0;
>  }
>  END
> +
> +rm $TMPOUT 2>/dev/null 2>&1
> 


-- 
Alexey


Re: [RFC PATCH kernel] gcc-goto.sh: Allow to pass with CONFIG_DEBUG_INFO_SPLIT=y

2017-03-13 Thread Alexey Kardashevskiy
On 03/03/17 11:51, Alexey Kardashevskiy wrote:
> With just CONFIG_DEBUG_INFO=y, the makefile adds "-g" to
> KBUILD_CFLAGS/KBUILD_AFLAGS and the test passes.
> 
> However, if CONFIG_DEBUG_INFO_SPLIT is also enabled, the makefile
> adds "-gsplit-dwarf" instead which makes the test fail with $?==1
> because of objcopy trying to split the debug info:
> 
> objcopy: Warning: '/dev/null' is not an ordinary file
> 
> This changes the output to $(mktemp) which fixes the problem.
> 
> I am pretty sure there better ways, this is just to demonstrate the bug.
> 
> gcc 5.4.1, ppc64le (does not really matter).
> 
> Cc: Jason Baron 


Ping?



> Signed-off-by: Alexey Kardashevskiy 
> ---
>  scripts/gcc-goto.sh | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
> index c9469d34ecc6..ab21216ab68d 100755
> --- a/scripts/gcc-goto.sh
> +++ b/scripts/gcc-goto.sh
> @@ -2,7 +2,8 @@
>  # Test for gcc 'asm goto' support
>  # Copyright (C) 2010, Jason Baron 
>  
> -cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
> +TMPOUT=$(mktemp)
> +cat << "END" | $@ -x c - -c -o $TMPOUT >/dev/null 2>&1 && echo "y"
>  int main(void)
>  {
>  #if defined(__arm__) || defined(__aarch64__)
> @@ -19,3 +20,5 @@ entry:
>   return 0;
>  }
>  END
> +
> +rm $TMPOUT 2>/dev/null 2>&1
> 


-- 
Alexey


Re: [PATCH 1/2] x86/mm/numa: trivial fix on typo and error message

2017-03-13 Thread Wei Yang
On Mon, Mar 13, 2017 at 02:00:10PM +0100, Borislav Petkov wrote:
>On Mon, Feb 06, 2017 at 11:35:28PM +0800, Wei Yang wrote:
>> When allocating pg_data in alloc_node_data(), it will try to allocate from
>> local node first and then from any node. If it fails at the second trial,
>> it means there is not available memory on any node.
>> 
>> This patch fixes the error message and correct one typo.
>> 
>> Signed-off-by: Wei Yang 
>> ---
>>  arch/x86/mm/numa.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
>> index 4366242356c5..3e9110b34147 100644
>> --- a/arch/x86/mm/numa.c
>> +++ b/arch/x86/mm/numa.c
>> @@ -201,8 +201,8 @@ static void __init alloc_node_data(int nid)
>>  nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
>>MEMBLOCK_ALLOC_ACCESSIBLE);
>>  if (!nd_pa) {
>> -pr_err("Cannot find %zu bytes in node %d\n",
>> -   nd_size, nid);
>> +pr_err("Cannot find %zu bytes in any node\n",
>> +   nd_size);
>>  return;
>>  }
>
>Actually, the best would be:
>
>   pr_err("Cannot find %zu bytes in any node (initial node: %d)\n", 
> nd_size, nid);
>
>or something like that. This way you say
>
>a) the initial node %nid failed
>b) the fallback to any node failed too
>
>so that people trying to debug code can have the complete info in the
>logs.
>

You are right, your message is more clear.

I would send out v2 with this change.

Thanks :-)

>-- 
>Regards/Gruss,
>Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH 1/2] x86/mm/numa: trivial fix on typo and error message

2017-03-13 Thread Wei Yang
On Mon, Mar 13, 2017 at 02:00:10PM +0100, Borislav Petkov wrote:
>On Mon, Feb 06, 2017 at 11:35:28PM +0800, Wei Yang wrote:
>> When allocating pg_data in alloc_node_data(), it will try to allocate from
>> local node first and then from any node. If it fails at the second trial,
>> it means there is not available memory on any node.
>> 
>> This patch fixes the error message and correct one typo.
>> 
>> Signed-off-by: Wei Yang 
>> ---
>>  arch/x86/mm/numa.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
>> index 4366242356c5..3e9110b34147 100644
>> --- a/arch/x86/mm/numa.c
>> +++ b/arch/x86/mm/numa.c
>> @@ -201,8 +201,8 @@ static void __init alloc_node_data(int nid)
>>  nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
>>MEMBLOCK_ALLOC_ACCESSIBLE);
>>  if (!nd_pa) {
>> -pr_err("Cannot find %zu bytes in node %d\n",
>> -   nd_size, nid);
>> +pr_err("Cannot find %zu bytes in any node\n",
>> +   nd_size);
>>  return;
>>  }
>
>Actually, the best would be:
>
>   pr_err("Cannot find %zu bytes in any node (initial node: %d)\n", 
> nd_size, nid);
>
>or something like that. This way you say
>
>a) the initial node %nid failed
>b) the fallback to any node failed too
>
>so that people trying to debug code can have the complete info in the
>logs.
>

You are right, your message is more clear.

I would send out v2 with this change.

Thanks :-)

>-- 
>Regards/Gruss,
>Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

2017-03-13 Thread Wei Yang
On Mon, Mar 13, 2017 at 02:30:46PM +0100, Borislav Petkov wrote:
>On Mon, Feb 06, 2017 at 11:35:29PM +0800, Wei Yang wrote:
>> numa_nodemask_from_meminfo() is called to set bit according to
>> numa_meminfo. While the only two places for this call is used to set proper
>> bit to a copy of numa_nodes_parsed from numa_meminfo. With current code
>> path, those numa node information in numa_meminfo is a subset of
>> numa_nodes_parsed. So it is not necessary to set the bits again.
>> 
>> The following is a code path analysis to prove the numa node information in
>> numa_meminfo is a subset of numa_nodes_parsed.
>> 
>> x86_numa_init()
>> numa_init()
>> Case 1
>> acpi_numa_init()
>> acpi_parse_memory_affinity()
>> numa_add_memblk()
>> node_set(numa_nodes_parsed)
>> acpi_parse_slit()
>> numa_nodemask_from_meminfo()
>> 
>> Case 2
>> amd_numa_init()
>> numa_add_memblk()
>> node_set(numa_nodes_parsed)
>> 
>> Case 3
>> dummy_numa_init()
>> node_set(numa_nodes_parsed)
>> numa_add_memblk()
>> 
>> numa_register_memblks()
>> numa_nodemask_from_meminfo()
>
>What about of_numa_parse_memory_nodes() ?
>

Hi, Borislav

Glad to see your comment.

Here is the only place who will invoke of_numa_parse_memory_nodes()

arm64_numa_init()
of_numa_init()
of_numa_parse_memory_nodes()

So this is an arm64 specific function.

In this patch, these numa_nodemask_from_meminfo only affects x86.

>-- 
>Regards/Gruss,
>Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

2017-03-13 Thread Wei Yang
On Mon, Mar 13, 2017 at 02:30:46PM +0100, Borislav Petkov wrote:
>On Mon, Feb 06, 2017 at 11:35:29PM +0800, Wei Yang wrote:
>> numa_nodemask_from_meminfo() is called to set bit according to
>> numa_meminfo. While the only two places for this call is used to set proper
>> bit to a copy of numa_nodes_parsed from numa_meminfo. With current code
>> path, those numa node information in numa_meminfo is a subset of
>> numa_nodes_parsed. So it is not necessary to set the bits again.
>> 
>> The following is a code path analysis to prove the numa node information in
>> numa_meminfo is a subset of numa_nodes_parsed.
>> 
>> x86_numa_init()
>> numa_init()
>> Case 1
>> acpi_numa_init()
>> acpi_parse_memory_affinity()
>> numa_add_memblk()
>> node_set(numa_nodes_parsed)
>> acpi_parse_slit()
>> numa_nodemask_from_meminfo()
>> 
>> Case 2
>> amd_numa_init()
>> numa_add_memblk()
>> node_set(numa_nodes_parsed)
>> 
>> Case 3
>> dummy_numa_init()
>> node_set(numa_nodes_parsed)
>> numa_add_memblk()
>> 
>> numa_register_memblks()
>> numa_nodemask_from_meminfo()
>
>What about of_numa_parse_memory_nodes() ?
>

Hi, Borislav

Glad to see your comment.

Here is the only place who will invoke of_numa_parse_memory_nodes()

arm64_numa_init()
of_numa_init()
of_numa_parse_memory_nodes()

So this is an arm64 specific function.

In this patch, these numa_nodemask_from_meminfo only affects x86.

>-- 
>Regards/Gruss,
>Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >