[PATCH] Support TrackStick of Thinkpad L570

2017-11-19 Thread Masaki Ota
From: Masaki Ota 
- The issue is that Thinkpad L570 TrackStick does not work. Because the main 
interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 interface 
Firmware setting of TrackStick. The detail is that TrackStick otp bit is 
disabled.
- Add the code that checks 0xD7 address value. This value is device number 
information, so we can identify the device by checking this value.
- If we check 0xD7 value, we need to enable Command mode and after check the 
value we need to disable Command mode, then we have to enable the device(0xF4 
command).
- Thinkpad L570 device number is 0x0C or 0x1D. If it is TRUE, enable 
ALPS_DUALPOINT flag.

Signed-off-by: Masaki Ota 
---
 drivers/input/mouse/alps.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 850b00e3ad8e..cce52104ed5a 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -2541,13 +2541,28 @@ static int alps_update_btn_info_ss4_v2(unsigned char 
otp[][4],
 }
 
 static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
-  struct alps_data *priv)
+  struct alps_data *priv,
+   struct psmouse *psmouse)
 {
bool is_dual = false;
+   int reg_val = 0;
+   struct ps2dev *ps2dev = >ps2dev;
 
-   if (IS_SS4PLUS_DEV(priv->dev_id))
+   if (IS_SS4PLUS_DEV(priv->dev_id)) {
is_dual = (otp[0][0] >> 4) & 0x01;
 
+   /* For support TrackStick of Thinkpad L570 device */
+   if (alps_exit_command_mode(psmouse) == 0 &&
+   alps_enter_command_mode(psmouse) == 0) {
+   reg_val = alps_command_mode_read_reg(psmouse, 0xD7);
+   }
+   alps_exit_command_mode(psmouse);
+   ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE);
+
+   if (reg_val == 0x0C || reg_val == 0x1D)
+   is_dual = true;
+   }
+
if (is_dual)
priv->flags |= ALPS_DUALPOINT |
ALPS_DUALPOINT_WITH_PRESSURE;
@@ -2570,7 +2585,7 @@ static int alps_set_defaults_ss4_v2(struct psmouse 
*psmouse,
 
alps_update_btn_info_ss4_v2(otp, priv);
 
-   alps_update_dual_info_ss4_v2(otp, priv);
+   alps_update_dual_info_ss4_v2(otp, priv, psmouse);
 
return 0;
 }
-- 
2.14.1



[PATCH] Support TrackStick of Thinkpad L570

2017-11-19 Thread Masaki Ota
From: Masaki Ota 
- The issue is that Thinkpad L570 TrackStick does not work. Because the main 
interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 interface 
Firmware setting of TrackStick. The detail is that TrackStick otp bit is 
disabled.
- Add the code that checks 0xD7 address value. This value is device number 
information, so we can identify the device by checking this value.
- If we check 0xD7 value, we need to enable Command mode and after check the 
value we need to disable Command mode, then we have to enable the device(0xF4 
command).
- Thinkpad L570 device number is 0x0C or 0x1D. If it is TRUE, enable 
ALPS_DUALPOINT flag.

Signed-off-by: Masaki Ota 
---
 drivers/input/mouse/alps.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 850b00e3ad8e..cce52104ed5a 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -2541,13 +2541,28 @@ static int alps_update_btn_info_ss4_v2(unsigned char 
otp[][4],
 }
 
 static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
-  struct alps_data *priv)
+  struct alps_data *priv,
+   struct psmouse *psmouse)
 {
bool is_dual = false;
+   int reg_val = 0;
+   struct ps2dev *ps2dev = >ps2dev;
 
-   if (IS_SS4PLUS_DEV(priv->dev_id))
+   if (IS_SS4PLUS_DEV(priv->dev_id)) {
is_dual = (otp[0][0] >> 4) & 0x01;
 
+   /* For support TrackStick of Thinkpad L570 device */
+   if (alps_exit_command_mode(psmouse) == 0 &&
+   alps_enter_command_mode(psmouse) == 0) {
+   reg_val = alps_command_mode_read_reg(psmouse, 0xD7);
+   }
+   alps_exit_command_mode(psmouse);
+   ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE);
+
+   if (reg_val == 0x0C || reg_val == 0x1D)
+   is_dual = true;
+   }
+
if (is_dual)
priv->flags |= ALPS_DUALPOINT |
ALPS_DUALPOINT_WITH_PRESSURE;
@@ -2570,7 +2585,7 @@ static int alps_set_defaults_ss4_v2(struct psmouse 
*psmouse,
 
alps_update_btn_info_ss4_v2(otp, priv);
 
-   alps_update_dual_info_ss4_v2(otp, priv);
+   alps_update_dual_info_ss4_v2(otp, priv, psmouse);
 
return 0;
 }
-- 
2.14.1



[PATCH v2] staging: comedi: add missing MODULE_DESCRIPTION/LICENSE

2017-11-19 Thread Jesse Chan
This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in 
drivers/staging/comedi/drivers/ni_atmio.o
see include/linux/module.h for more information

This adds the license as "GPL", which matches the header of the file.

MODULE_DESCRIPTION is also added.

Signed-off-by: Jesse Chan 
---
 drivers/staging/comedi/drivers/ni_atmio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/comedi/drivers/ni_atmio.c 
b/drivers/staging/comedi/drivers/ni_atmio.c
index 2d62a8c57332..b61d56367773 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -361,3 +361,6 @@ static struct comedi_driver ni_atmio_driver = {
.detach = ni_atmio_detach,
 };
 module_comedi_driver(ni_atmio_driver);
+
+MODULE_DESCRIPTION("Comedi low-level driver");
+MODULE_LICENSE("GPL");
-- 
2.14.1



[PATCH v2] staging: comedi: add missing MODULE_DESCRIPTION/LICENSE

2017-11-19 Thread Jesse Chan
This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in 
drivers/staging/comedi/drivers/ni_atmio.o
see include/linux/module.h for more information

This adds the license as "GPL", which matches the header of the file.

MODULE_DESCRIPTION is also added.

Signed-off-by: Jesse Chan 
---
 drivers/staging/comedi/drivers/ni_atmio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/comedi/drivers/ni_atmio.c 
b/drivers/staging/comedi/drivers/ni_atmio.c
index 2d62a8c57332..b61d56367773 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -361,3 +361,6 @@ static struct comedi_driver ni_atmio_driver = {
.detach = ni_atmio_detach,
 };
 module_comedi_driver(ni_atmio_driver);
+
+MODULE_DESCRIPTION("Comedi low-level driver");
+MODULE_LICENSE("GPL");
-- 
2.14.1



[PATCH v2] net/9p: trans_xen: add missing MODULE_AUTHOR/DESCRIPTION/LICENSE

2017-11-19 Thread Jesse Chan
This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in net/9p/9pnet_xen.o
see include/linux/module.h for more information

This adds the license as "Dual MIT/GPL", which matches the header of the file.

MODULE_DESCRIPTION and MODULE_AUTHOR are also added.

Signed-off-by: Jesse Chan 
---
 net/9p/trans_xen.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 6ad3e043c617..90402e744fbf 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -543,3 +543,7 @@ static void p9_trans_xen_exit(void)
return xenbus_unregister_driver(_9pfs_front_driver);
 }
 module_exit(p9_trans_xen_exit);
+
+MODULE_AUTHOR("Stefano Stabellini ");
+MODULE_DESCRIPTION("Xen Transport for 9P");
+MODULE_LICENSE("Dual MIT/GPL");
-- 
2.14.1



[PATCH v2] net/9p: trans_xen: add missing MODULE_AUTHOR/DESCRIPTION/LICENSE

2017-11-19 Thread Jesse Chan
This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in net/9p/9pnet_xen.o
see include/linux/module.h for more information

This adds the license as "Dual MIT/GPL", which matches the header of the file.

MODULE_DESCRIPTION and MODULE_AUTHOR are also added.

Signed-off-by: Jesse Chan 
---
 net/9p/trans_xen.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 6ad3e043c617..90402e744fbf 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -543,3 +543,7 @@ static void p9_trans_xen_exit(void)
return xenbus_unregister_driver(_9pfs_front_driver);
 }
 module_exit(p9_trans_xen_exit);
+
+MODULE_AUTHOR("Stefano Stabellini ");
+MODULE_DESCRIPTION("Xen Transport for 9P");
+MODULE_LICENSE("Dual MIT/GPL");
-- 
2.14.1



Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

2017-11-19 Thread Daniel Vetter
On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote:
> For personal reasons, Mark Yao will leave rockchip,
> can not continue maintain drm/rockchip, Sandy Huang
> will take over the drm/rockchip.
> 
> Cc: Sandy Huang 
> Cc: Heiko Stuebner 
> 
> Signed-off-by: Mark Yao 

Since rockchip is in drm-misc that means we need a new maintainer who also
has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to be
the new maintainer we need to fix that.

Also, Heiko, are you interested in becoming co-maintainer? With commit
rights and all.
-Daniel

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0d77f22..31bf080 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4627,7 +4627,7 @@ F:  
> Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
>  F:   Documentation/devicetree/bindings/display/renesas,du.txt
>  
>  DRM DRIVERS FOR ROCKCHIP
> -M:   Mark Yao 
> +M:   Sandy Huang 
>  L:   dri-de...@lists.freedesktop.org
>  S:   Maintained
>  F:   drivers/gpu/drm/rockchip/
> -- 
> 2.7.4
> 
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

2017-11-19 Thread Daniel Vetter
On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote:
> For personal reasons, Mark Yao will leave rockchip,
> can not continue maintain drm/rockchip, Sandy Huang
> will take over the drm/rockchip.
> 
> Cc: Sandy Huang 
> Cc: Heiko Stuebner 
> 
> Signed-off-by: Mark Yao 

Since rockchip is in drm-misc that means we need a new maintainer who also
has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to be
the new maintainer we need to fix that.

Also, Heiko, are you interested in becoming co-maintainer? With commit
rights and all.
-Daniel

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0d77f22..31bf080 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4627,7 +4627,7 @@ F:  
> Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
>  F:   Documentation/devicetree/bindings/display/renesas,du.txt
>  
>  DRM DRIVERS FOR ROCKCHIP
> -M:   Mark Yao 
> +M:   Sandy Huang 
>  L:   dri-de...@lists.freedesktop.org
>  S:   Maintained
>  F:   drivers/gpu/drm/rockchip/
> -- 
> 2.7.4
> 
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH v3] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

2017-11-19 Thread Jesse Chan
This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in 
drivers/media/platform/mtk-vcodec/mtk-vcodec-common.o
see include/linux/module.h for more information

This adds the license as "GPL v2", which matches the header of the file.

MODULE_DESCRIPTION is also added.

Signed-off-by: Jesse Chan 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
index 46768c056193..0c28d0b995cc 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
@@ -115,3 +115,6 @@ struct mtk_vcodec_ctx *mtk_vcodec_get_curr_ctx(struct 
mtk_vcodec_dev *dev)
return ctx;
 }
 EXPORT_SYMBOL(mtk_vcodec_get_curr_ctx);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Mediatek video codec driver");
-- 
2.14.1



[PATCH v3] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

2017-11-19 Thread Jesse Chan
This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in 
drivers/media/platform/mtk-vcodec/mtk-vcodec-common.o
see include/linux/module.h for more information

This adds the license as "GPL v2", which matches the header of the file.

MODULE_DESCRIPTION is also added.

Signed-off-by: Jesse Chan 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
index 46768c056193..0c28d0b995cc 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
@@ -115,3 +115,6 @@ struct mtk_vcodec_ctx *mtk_vcodec_get_curr_ctx(struct 
mtk_vcodec_dev *dev)
return ctx;
 }
 EXPORT_SYMBOL(mtk_vcodec_get_curr_ctx);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Mediatek video codec driver");
-- 
2.14.1



[PATCH v2] ASoC: pcm512x-spi: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

2017-11-19 Thread Jesse Chan
This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in 
sound/soc/codecs/snd-soc-pcm512x-spi.o
see include/linux/module.h for more information

This adds the license as "GPL v2", which matches the header of the file.

MODULE_DESCRIPTION and MODULE_AUTHOR are also added.

Signed-off-by: Jesse Chan 
---
 sound/soc/codecs/pcm512x-spi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/soc/codecs/pcm512x-spi.c b/sound/soc/codecs/pcm512x-spi.c
index 25c63510ae15..7cdd2dc4fd79 100644
--- a/sound/soc/codecs/pcm512x-spi.c
+++ b/sound/soc/codecs/pcm512x-spi.c
@@ -70,3 +70,7 @@ static struct spi_driver pcm512x_spi_driver = {
 };
 
 module_spi_driver(pcm512x_spi_driver);
+
+MODULE_DESCRIPTION("ASoC PCM512x codec driver - SPI");
+MODULE_AUTHOR("Mark Brown ");
+MODULE_LICENSE("GPL v2");
-- 
2.14.1



[PATCH v2] ASoC: pcm512x-spi: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

2017-11-19 Thread Jesse Chan
This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in 
sound/soc/codecs/snd-soc-pcm512x-spi.o
see include/linux/module.h for more information

This adds the license as "GPL v2", which matches the header of the file.

MODULE_DESCRIPTION and MODULE_AUTHOR are also added.

Signed-off-by: Jesse Chan 
---
 sound/soc/codecs/pcm512x-spi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/soc/codecs/pcm512x-spi.c b/sound/soc/codecs/pcm512x-spi.c
index 25c63510ae15..7cdd2dc4fd79 100644
--- a/sound/soc/codecs/pcm512x-spi.c
+++ b/sound/soc/codecs/pcm512x-spi.c
@@ -70,3 +70,7 @@ static struct spi_driver pcm512x_spi_driver = {
 };
 
 module_spi_driver(pcm512x_spi_driver);
+
+MODULE_DESCRIPTION("ASoC PCM512x codec driver - SPI");
+MODULE_AUTHOR("Mark Brown ");
+MODULE_LICENSE("GPL v2");
-- 
2.14.1



Re: [PATCH] perf report/top: Add a tip about source line matching

2017-11-19 Thread Jiri Olsa
On Sat, Nov 18, 2017 at 04:01:19PM +0900, Hyeim Yang wrote:
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Cc: Taeung Song 
> ---
>  tools/perf/Documentation/tips.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/Documentation/tips.txt 
> b/tools/perf/Documentation/tips.txt
> index db0ca30..b60616a 100644
> --- a/tools/perf/Documentation/tips.txt
> +++ b/tools/perf/Documentation/tips.txt
> @@ -32,3 +32,4 @@ Order by the overhead of source file name and line number: 
> perf report -s srclin
>  System-wide collection from all CPUs: perf record -a
>  Show current config key-value pairs: perf config --list
>  Show user configuration overrides: perf config --user --list
> +Print matching source lines (may be slow): perf annotate --print-line 
> 

this works only in stdio, so we need to add --stdio option as well

jirka


Re: [PATCH] perf report/top: Add a tip about source line matching

2017-11-19 Thread Jiri Olsa
On Sat, Nov 18, 2017 at 04:01:19PM +0900, Hyeim Yang wrote:
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Cc: Taeung Song 
> ---
>  tools/perf/Documentation/tips.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/Documentation/tips.txt 
> b/tools/perf/Documentation/tips.txt
> index db0ca30..b60616a 100644
> --- a/tools/perf/Documentation/tips.txt
> +++ b/tools/perf/Documentation/tips.txt
> @@ -32,3 +32,4 @@ Order by the overhead of source file name and line number: 
> perf report -s srclin
>  System-wide collection from all CPUs: perf record -a
>  Show current config key-value pairs: perf config --list
>  Show user configuration overrides: perf config --user --list
> +Print matching source lines (may be slow): perf annotate --print-line 
> 

this works only in stdio, so we need to add --stdio option as well

jirka


Re: linux-next: manual merge of the devicetree tree with the drm tree

2017-11-19 Thread Daniel Vetter
On Mon, Nov 13, 2017 at 09:51:29PM +0200, Jyri Sarha wrote:
> On 11/13/17 20:43, Frank Rowand wrote:
> > Hi Jyri,
> > 
> > On 11/13/17 07:40, Jyri Sarha wrote:
> >> On 11/13/17 07:58, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> On Mon, 30 Oct 2017 20:37:56 + Mark Brown  wrote:
>  Today's linux-next merge of the devicetree tree got a conflict in:
> 
>    drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
> 
>  between commit:
> 
>    44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag 
>  setting")
> 
>  from the drm tree and commit:
> 
>    f948d6d8b792bb ("of: overlay: avoid race condition between applying 
>  multiple overlays")
> 
>  from the devicetree tree.
> 
>  I fixed it up (see below) and can carry the fix as necessary. This
>  is now fixed as far as linux-next is concerned, but any non trivial
>  conflicts should be mentioned to your upstream maintainer when your tree
>  is submitted for merging.  You may also want to consider cooperating
>  with the maintainer of the conflicting tree to minimise any particularly
>  complex conflicts.
> 
>  diff --cc drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  index 482299a6f3b0,54025af534d4..
>  --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  @@@ -163,12 -162,8 +162,6 @@@ static struct device_node * __init tilc
>   return NULL;
>   }
>    
>  -ret = of_resolve_phandles(overlay);
>  -if (ret) {
>  -pr_err("%s: Failed to resolve phandles: %d\n", 
>  __func__, ret);
>  -return NULL;
>  -}
>   -   of_node_set_flag(overlay, OF_DETACHED);
>  --
>   return overlay;
>    }
>    
> >>> Just a reminder that this conflict still exists.
> >>>
> >> After some consideration, I think we can drop the dts backward
> >> compatibility code from drm/tilcdc. It seems that it is causing a lot of
> >> trouble and I do not even know if anybody uses it anymore. Here is a
> >> patch for dropping it:
> >>
> >> https://lists.freedesktop.org/archives/dri-devel/2017-November/157394.html
> >>
> >> I did not plan to merge it before v4.16, but if this is a bigger problem
> >> I can push is right now for v4.15.
> >>
> >> Best regards,
> >> Jyri
> >>
> > The dropping patch is much appreciated.
> > 
> > It would make life easier for me if the patch gets into v4.15-rc.
> 
> Dave, Daniel? Would you take this late addition to v4.15 still, if I
> would send a pull request now?
> 
> The patch is pretty much orthogonal to the rest of drm as it is only
> dealing with device tree stuff.

Seems like a reasonable thing to include in the merge window -fixes pull
Dave usually does, just make sure all the acks are recorded.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: linux-next: manual merge of the devicetree tree with the drm tree

2017-11-19 Thread Daniel Vetter
On Mon, Nov 13, 2017 at 09:51:29PM +0200, Jyri Sarha wrote:
> On 11/13/17 20:43, Frank Rowand wrote:
> > Hi Jyri,
> > 
> > On 11/13/17 07:40, Jyri Sarha wrote:
> >> On 11/13/17 07:58, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> On Mon, 30 Oct 2017 20:37:56 + Mark Brown  wrote:
>  Today's linux-next merge of the devicetree tree got a conflict in:
> 
>    drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
> 
>  between commit:
> 
>    44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag 
>  setting")
> 
>  from the drm tree and commit:
> 
>    f948d6d8b792bb ("of: overlay: avoid race condition between applying 
>  multiple overlays")
> 
>  from the devicetree tree.
> 
>  I fixed it up (see below) and can carry the fix as necessary. This
>  is now fixed as far as linux-next is concerned, but any non trivial
>  conflicts should be mentioned to your upstream maintainer when your tree
>  is submitted for merging.  You may also want to consider cooperating
>  with the maintainer of the conflicting tree to minimise any particularly
>  complex conflicts.
> 
>  diff --cc drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  index 482299a6f3b0,54025af534d4..
>  --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  @@@ -163,12 -162,8 +162,6 @@@ static struct device_node * __init tilc
>   return NULL;
>   }
>    
>  -ret = of_resolve_phandles(overlay);
>  -if (ret) {
>  -pr_err("%s: Failed to resolve phandles: %d\n", 
>  __func__, ret);
>  -return NULL;
>  -}
>   -   of_node_set_flag(overlay, OF_DETACHED);
>  --
>   return overlay;
>    }
>    
> >>> Just a reminder that this conflict still exists.
> >>>
> >> After some consideration, I think we can drop the dts backward
> >> compatibility code from drm/tilcdc. It seems that it is causing a lot of
> >> trouble and I do not even know if anybody uses it anymore. Here is a
> >> patch for dropping it:
> >>
> >> https://lists.freedesktop.org/archives/dri-devel/2017-November/157394.html
> >>
> >> I did not plan to merge it before v4.16, but if this is a bigger problem
> >> I can push is right now for v4.15.
> >>
> >> Best regards,
> >> Jyri
> >>
> > The dropping patch is much appreciated.
> > 
> > It would make life easier for me if the patch gets into v4.15-rc.
> 
> Dave, Daniel? Would you take this late addition to v4.15 still, if I
> would send a pull request now?
> 
> The patch is pretty much orthogonal to the rest of drm as it is only
> dealing with device tree stuff.

Seems like a reasonable thing to include in the merge window -fixes pull
Dave usually does, just make sure all the acks are recorded.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH] ASoC: bells: Use common error handling code in bells_set_bias_level_post()

2017-11-19 Thread Krzysztof Kozlowski
On Sun, Nov 19, 2017 at 3:08 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Sun, 19 Nov 2017 15:00:22 +0100
>
> * Add a jump target so that a specific error message is stored only once
>   at the end of this function implementation.
>
> * Replace two calls of the macro "pr_err" by goto statements.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  sound/soc/samsung/bells.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/sound/soc/samsung/bells.c b/sound/soc/samsung/bells.c
> index 34deba461ae1..fc9a71523b3e 100644
> --- a/sound/soc/samsung/bells.c
> +++ b/sound/soc/samsung/bells.c
> @@ -120,18 +120,14 @@ static int bells_set_bias_level_post(struct 
> snd_soc_card *card,
> switch (level) {
> case SND_SOC_BIAS_STANDBY:
> ret = snd_soc_codec_set_pll(codec, WM5102_FLL1, 0, 0, 0);
> -   if (ret < 0) {
> -   pr_err("Failed to stop FLL: %d\n", ret);
> -   return ret;
> -   }
> +   if (ret < 0)
> +   goto report_failure;
>

No. The same as previously - just for error path code this makes code
less readable.

Best regards,
Krzysztof


Re: [PATCH] ASoC: bells: Use common error handling code in bells_set_bias_level_post()

2017-11-19 Thread Krzysztof Kozlowski
On Sun, Nov 19, 2017 at 3:08 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Sun, 19 Nov 2017 15:00:22 +0100
>
> * Add a jump target so that a specific error message is stored only once
>   at the end of this function implementation.
>
> * Replace two calls of the macro "pr_err" by goto statements.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  sound/soc/samsung/bells.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/sound/soc/samsung/bells.c b/sound/soc/samsung/bells.c
> index 34deba461ae1..fc9a71523b3e 100644
> --- a/sound/soc/samsung/bells.c
> +++ b/sound/soc/samsung/bells.c
> @@ -120,18 +120,14 @@ static int bells_set_bias_level_post(struct 
> snd_soc_card *card,
> switch (level) {
> case SND_SOC_BIAS_STANDBY:
> ret = snd_soc_codec_set_pll(codec, WM5102_FLL1, 0, 0, 0);
> -   if (ret < 0) {
> -   pr_err("Failed to stop FLL: %d\n", ret);
> -   return ret;
> -   }
> +   if (ret < 0)
> +   goto report_failure;
>

No. The same as previously - just for error path code this makes code
less readable.

Best regards,
Krzysztof


Re: [Patch v6 07/22] CIFS: SMBD: Implement function to create a SMB Direct connection

2017-11-19 Thread Leif Sahlberg
Acked-by: Ronnie Sahlberg 


- Original Message -
From: "Long Li" 
To: "Steve French" , linux-c...@vger.kernel.org, 
samba-techni...@lists.samba.org, linux-kernel@vger.kernel.org, 
linux-r...@vger.kernel.org, "Christoph Hellwig" , "Tom 
Talpey" , "Matthew Wilcox" , 
"Stephen Hemminger" 
Cc: "Long Li" 
Sent: Sunday, 5 November, 2017 4:43:49 PM
Subject: [Patch v6 07/22] CIFS: SMBD: Implement function to create a SMB Direct 
connection

From: Long Li 

The upper layer calls this function to connect to peer through SMB Direct.
Each SMB Direct connection is based on a RDMA RC Queue Pair.

Signed-off-by: Long Li 
---
 fs/cifs/smbdirect.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c
index 7af49cd..47d999f 100644
--- a/fs/cifs/smbdirect.c
+++ b/fs/cifs/smbdirect.c
@@ -1652,3 +1652,20 @@ struct smbd_connection *_smbd_get_connection(
kfree(info);
return NULL;
 }
+
+struct smbd_connection *smbd_get_connection(
+   struct TCP_Server_Info *server, struct sockaddr *dstaddr)
+{
+   struct smbd_connection *ret;
+   int port = SMBD_PORT;
+
+try_again:
+   ret = _smbd_get_connection(server, dstaddr, port);
+
+   /* Try SMB_PORT if SMBD_PORT doesn't work */
+   if (!ret && port == SMBD_PORT) {
+   port = SMB_PORT;
+   goto try_again;
+   }
+   return ret;
+}
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Patch v6 07/22] CIFS: SMBD: Implement function to create a SMB Direct connection

2017-11-19 Thread Leif Sahlberg
Acked-by: Ronnie Sahlberg 


- Original Message -
From: "Long Li" 
To: "Steve French" , linux-c...@vger.kernel.org, 
samba-techni...@lists.samba.org, linux-kernel@vger.kernel.org, 
linux-r...@vger.kernel.org, "Christoph Hellwig" , "Tom 
Talpey" , "Matthew Wilcox" , 
"Stephen Hemminger" 
Cc: "Long Li" 
Sent: Sunday, 5 November, 2017 4:43:49 PM
Subject: [Patch v6 07/22] CIFS: SMBD: Implement function to create a SMB Direct 
connection

From: Long Li 

The upper layer calls this function to connect to peer through SMB Direct.
Each SMB Direct connection is based on a RDMA RC Queue Pair.

Signed-off-by: Long Li 
---
 fs/cifs/smbdirect.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c
index 7af49cd..47d999f 100644
--- a/fs/cifs/smbdirect.c
+++ b/fs/cifs/smbdirect.c
@@ -1652,3 +1652,20 @@ struct smbd_connection *_smbd_get_connection(
kfree(info);
return NULL;
 }
+
+struct smbd_connection *smbd_get_connection(
+   struct TCP_Server_Info *server, struct sockaddr *dstaddr)
+{
+   struct smbd_connection *ret;
+   int port = SMBD_PORT;
+
+try_again:
+   ret = _smbd_get_connection(server, dstaddr, port);
+
+   /* Try SMB_PORT if SMBD_PORT doesn't work */
+   if (!ret && port == SMBD_PORT) {
+   port = SMB_PORT;
+   goto try_again;
+   }
+   return ret;
+}
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ALSA: hda/realtek: Add headset mic support for Intel NUC Skull Canyon

2017-11-19 Thread Takashi Iwai
On Mon, 20 Nov 2017 08:29:13 +0100,
Kai-Heng Feng wrote:
> 
> Users have been using knob "model=dell-headset-multi" on Intel Skull
> Canyon for a while.
> 
> Add the equivalent quirk, ALC269_FIXUP_DELL1_MIC_NO_PRESENCE for Skull
> Canyon.
> 
> BugLink: https://bugs.launchpad.net/bugs/1732034
> Signed-off-by: Kai-Heng Feng 

Applied, thanks.


Takashi


Re: [Patch v7 06/22] CIFS: SMBD: export protocol initial values

2017-11-19 Thread Leif Sahlberg
Acked-by: Ronnie Sahlberg 


- Original Message -
From: "Long Li" 
To: "Steve French" , linux-c...@vger.kernel.org, 
samba-techni...@lists.samba.org, linux-kernel@vger.kernel.org, 
linux-r...@vger.kernel.org, "Christoph Hellwig" , "Tom 
Talpey" , "Matthew Wilcox" , 
"Stephen Hemminger" 
Cc: "Long Li" 
Sent: Tuesday, 7 November, 2017 7:54:58 PM
Subject: [Patch v7 06/22] CIFS: SMBD: export protocol initial values

From: Long Li 

For use-configurable SMB Direct protocol values, export them to /proc/fs/cifs.

Signed-off-by: Long Li 
---
 fs/cifs/cifs_debug.c | 79 
 1 file changed, 79 insertions(+)

diff --git a/fs/cifs/cifs_debug.c b/fs/cifs/cifs_debug.c
index ba0870d..7025d8d 100644
--- a/fs/cifs/cifs_debug.c
+++ b/fs/cifs/cifs_debug.c
@@ -30,6 +30,9 @@
 #include "cifsproto.h"
 #include "cifs_debug.h"
 #include "cifsfs.h"
+#ifdef CONFIG_CIFS_SMB_DIRECT
+#include "smbdirect.h"
+#endif
 
 void
 cifs_dump_mem(char *label, void *data, int length)
@@ -371,6 +374,54 @@ static const struct file_operations cifs_stats_proc_fops = 
{
 };
 #endif /* STATS */
 
+#ifdef CONFIG_CIFS_SMB_DIRECT
+#define PROC_FILE_DEFINE(name) \
+static ssize_t name##_write(struct file *file, const char __user *buffer, \
+   size_t count, loff_t *ppos) \
+{ \
+   int rc; \
+   rc = kstrtoint_from_user(buffer, count, 10, & name ); \
+   if (rc) \
+   return rc; \
+   return count; \
+} \
+static int name##_proc_show(struct seq_file *m, void *v) \
+{ \
+   seq_printf(m, "%d\n", name ); \
+   return 0; \
+} \
+static int name##_open(struct inode *inode, struct file *file) \
+{ \
+   return single_open(file, name##_proc_show, NULL); \
+} \
+\
+static const struct file_operations cifs_##name##_proc_fops = { \
+   .open   = name##_open, \
+   .read   = seq_read, \
+   .llseek = seq_lseek, \
+   .release= single_release, \
+   .write  = name##_write, \
+}
+
+extern int rdma_readwrite_threshold;
+extern int smbd_max_frmr_depth;
+extern int smbd_keep_alive_interval;
+extern int smbd_max_receive_size;
+extern int smbd_max_fragmented_recv_size;
+extern int smbd_max_send_size;
+extern int smbd_send_credit_target;
+extern int smbd_receive_credit_max;
+
+PROC_FILE_DEFINE(rdma_readwrite_threshold);
+PROC_FILE_DEFINE(smbd_max_frmr_depth);
+PROC_FILE_DEFINE(smbd_keep_alive_interval);
+PROC_FILE_DEFINE(smbd_max_receive_size);
+PROC_FILE_DEFINE(smbd_max_fragmented_recv_size);
+PROC_FILE_DEFINE(smbd_max_send_size);
+PROC_FILE_DEFINE(smbd_send_credit_target);
+PROC_FILE_DEFINE(smbd_receive_credit_max);
+#endif
+
 static struct proc_dir_entry *proc_fs_cifs;
 static const struct file_operations cifsFYI_proc_fops;
 static const struct file_operations cifs_lookup_cache_proc_fops;
@@ -398,6 +449,24 @@ cifs_proc_init(void)
_security_flags_proc_fops);
proc_create("LookupCacheEnabled", 0, proc_fs_cifs,
_lookup_cache_proc_fops);
+#ifdef CONFIG_CIFS_SMB_DIRECT
+   proc_create("rdma_readwrite_threshold", 0, proc_fs_cifs,
+   _rdma_readwrite_threshold_proc_fops);
+   proc_create("smbd_max_frmr_depth", 0, proc_fs_cifs,
+   _smbd_max_frmr_depth_proc_fops);
+   proc_create("smbd_keep_alive_interval", 0, proc_fs_cifs,
+   _smbd_keep_alive_interval_proc_fops);
+   proc_create("smbd_max_receive_size", 0, proc_fs_cifs,
+   _smbd_max_receive_size_proc_fops);
+   proc_create("smbd_max_fragmented_recv_size", 0, proc_fs_cifs,
+   _smbd_max_fragmented_recv_size_proc_fops);
+   proc_create("smbd_max_send_size", 0, proc_fs_cifs,
+   _smbd_max_send_size_proc_fops);
+   proc_create("smbd_send_credit_target", 0, proc_fs_cifs,
+   _smbd_send_credit_target_proc_fops);
+   proc_create("smbd_receive_credit_max", 0, proc_fs_cifs,
+   _smbd_receive_credit_max_proc_fops);
+#endif
 }
 
 void
@@ -415,6 +484,16 @@ cifs_proc_clean(void)
remove_proc_entry("SecurityFlags", proc_fs_cifs);
remove_proc_entry("LinuxExtensionsEnabled", proc_fs_cifs);
remove_proc_entry("LookupCacheEnabled", proc_fs_cifs);
+#ifdef CONFIG_CIFS_SMB_DIRECT
+   remove_proc_entry("rdma_readwrite_threshold", proc_fs_cifs);
+   remove_proc_entry("smbd_max_frmr_depth", proc_fs_cifs);
+   remove_proc_entry("smbd_keep_alive_interval", proc_fs_cifs);
+   remove_proc_entry("smbd_max_receive_size", proc_fs_cifs);
+   remove_proc_entry("smbd_max_fragmented_recv_size", proc_fs_cifs);
+   remove_proc_entry("smbd_max_send_size", proc_fs_cifs);
+   remove_proc_entry("smbd_send_credit_target", proc_fs_cifs);
+   

Re: [PATCH] ARM: exynos: add machine description for ODROID-XU3/4

2017-11-19 Thread Krzysztof Kozlowski
On Sun, Nov 19, 2017 at 6:21 PM, Tobias Jakobi
 wrote:
> I don't think this approach scales at all. DietPi can just read the devicetree
> through sysfs and retrieve the compatible and/or model of the base node.

Exactly, do not add new machines just for reading DT. Use
/sys/firmware/devicetree/base/compatible for this.

Best regards,
Krzysztof

> - Tobias
>
> Dongjin Kim wrote:
>> This patch is to add the machine descriptions for ODROID-XU3/4 boards
>> in order to present the hardware name at /proc/cputinfo rather than
>> "SAMSUNG EXYNOS (Flattened Device Tree)". An embedded open source project,
>> such as DietPi, reads the hardware name to run different features.
>>
>>   $ cat /proc/cpuinfo | grep Hardware
>>   Hardware: ODROID-XU4
>>
>> Signed-off-by: Dongjin Kim 
>> ---
>>  arch/arm/mach-exynos/exynos.c | 28 
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index c404c15ad07f..6197dbf9f48b 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -241,3 +241,31 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened 
>> Device Tree)")
>>   .dt_compat  = exynos_dt_compat,
>>   .dt_fixup   = exynos_dt_fixup,
>>  MACHINE_END
>> +
>> +#define ODROID_MACHINE_START(name, compat)   \
>> + DT_MACHINE_START(EXYNOS5422_ODROID_##name, "ODROID-"#name)  \
>> + .l2c_aux_val= 0x3c41,   \
>> + .l2c_aux_mask   = 0xc20f,   \
>> + .smp= smp_ops(exynos_smp_ops),  \
>> + .map_io = exynos_init_io,   \
>> + .init_early = exynos_firmware_init, \
>> + .init_irq   = exynos_init_irq,  \
>> + .init_machine   = exynos_dt_machine_init,   \
>> + .init_late  = exynos_init_late, \
>> + .dt_compat  = compat,   \
>> + .dt_fixup   = exynos_dt_fixup,  \
>> + MACHINE_END
>> +
>> +static char const *const exynos5422_odroidxu3_dt_compat[] __initconst = {
>> + "hardkernel,odroid-xu3",
>> + "hardkernel,odroid-xu3-lite",
>> + NULL,
>> +};
>> +
>> +static char const *const exynos5422_odroidxu4_dt_compat[] __initconst = {
>> + "hardkernel,odroid-xu4",
>> + NULL,
>> +};
>> +
>> +ODROID_MACHINE_START(XU3, exynos5422_odroidxu3_dt_compat)
>> +ODROID_MACHINE_START(XU4, exynos5422_odroidxu4_dt_compat)
>>
>


Re: [PATCH] ALSA: hda/realtek: Add headset mic support for Intel NUC Skull Canyon

2017-11-19 Thread Takashi Iwai
On Mon, 20 Nov 2017 08:29:13 +0100,
Kai-Heng Feng wrote:
> 
> Users have been using knob "model=dell-headset-multi" on Intel Skull
> Canyon for a while.
> 
> Add the equivalent quirk, ALC269_FIXUP_DELL1_MIC_NO_PRESENCE for Skull
> Canyon.
> 
> BugLink: https://bugs.launchpad.net/bugs/1732034
> Signed-off-by: Kai-Heng Feng 

Applied, thanks.


Takashi


Re: [Patch v7 06/22] CIFS: SMBD: export protocol initial values

2017-11-19 Thread Leif Sahlberg
Acked-by: Ronnie Sahlberg 


- Original Message -
From: "Long Li" 
To: "Steve French" , linux-c...@vger.kernel.org, 
samba-techni...@lists.samba.org, linux-kernel@vger.kernel.org, 
linux-r...@vger.kernel.org, "Christoph Hellwig" , "Tom 
Talpey" , "Matthew Wilcox" , 
"Stephen Hemminger" 
Cc: "Long Li" 
Sent: Tuesday, 7 November, 2017 7:54:58 PM
Subject: [Patch v7 06/22] CIFS: SMBD: export protocol initial values

From: Long Li 

For use-configurable SMB Direct protocol values, export them to /proc/fs/cifs.

Signed-off-by: Long Li 
---
 fs/cifs/cifs_debug.c | 79 
 1 file changed, 79 insertions(+)

diff --git a/fs/cifs/cifs_debug.c b/fs/cifs/cifs_debug.c
index ba0870d..7025d8d 100644
--- a/fs/cifs/cifs_debug.c
+++ b/fs/cifs/cifs_debug.c
@@ -30,6 +30,9 @@
 #include "cifsproto.h"
 #include "cifs_debug.h"
 #include "cifsfs.h"
+#ifdef CONFIG_CIFS_SMB_DIRECT
+#include "smbdirect.h"
+#endif
 
 void
 cifs_dump_mem(char *label, void *data, int length)
@@ -371,6 +374,54 @@ static const struct file_operations cifs_stats_proc_fops = 
{
 };
 #endif /* STATS */
 
+#ifdef CONFIG_CIFS_SMB_DIRECT
+#define PROC_FILE_DEFINE(name) \
+static ssize_t name##_write(struct file *file, const char __user *buffer, \
+   size_t count, loff_t *ppos) \
+{ \
+   int rc; \
+   rc = kstrtoint_from_user(buffer, count, 10, & name ); \
+   if (rc) \
+   return rc; \
+   return count; \
+} \
+static int name##_proc_show(struct seq_file *m, void *v) \
+{ \
+   seq_printf(m, "%d\n", name ); \
+   return 0; \
+} \
+static int name##_open(struct inode *inode, struct file *file) \
+{ \
+   return single_open(file, name##_proc_show, NULL); \
+} \
+\
+static const struct file_operations cifs_##name##_proc_fops = { \
+   .open   = name##_open, \
+   .read   = seq_read, \
+   .llseek = seq_lseek, \
+   .release= single_release, \
+   .write  = name##_write, \
+}
+
+extern int rdma_readwrite_threshold;
+extern int smbd_max_frmr_depth;
+extern int smbd_keep_alive_interval;
+extern int smbd_max_receive_size;
+extern int smbd_max_fragmented_recv_size;
+extern int smbd_max_send_size;
+extern int smbd_send_credit_target;
+extern int smbd_receive_credit_max;
+
+PROC_FILE_DEFINE(rdma_readwrite_threshold);
+PROC_FILE_DEFINE(smbd_max_frmr_depth);
+PROC_FILE_DEFINE(smbd_keep_alive_interval);
+PROC_FILE_DEFINE(smbd_max_receive_size);
+PROC_FILE_DEFINE(smbd_max_fragmented_recv_size);
+PROC_FILE_DEFINE(smbd_max_send_size);
+PROC_FILE_DEFINE(smbd_send_credit_target);
+PROC_FILE_DEFINE(smbd_receive_credit_max);
+#endif
+
 static struct proc_dir_entry *proc_fs_cifs;
 static const struct file_operations cifsFYI_proc_fops;
 static const struct file_operations cifs_lookup_cache_proc_fops;
@@ -398,6 +449,24 @@ cifs_proc_init(void)
_security_flags_proc_fops);
proc_create("LookupCacheEnabled", 0, proc_fs_cifs,
_lookup_cache_proc_fops);
+#ifdef CONFIG_CIFS_SMB_DIRECT
+   proc_create("rdma_readwrite_threshold", 0, proc_fs_cifs,
+   _rdma_readwrite_threshold_proc_fops);
+   proc_create("smbd_max_frmr_depth", 0, proc_fs_cifs,
+   _smbd_max_frmr_depth_proc_fops);
+   proc_create("smbd_keep_alive_interval", 0, proc_fs_cifs,
+   _smbd_keep_alive_interval_proc_fops);
+   proc_create("smbd_max_receive_size", 0, proc_fs_cifs,
+   _smbd_max_receive_size_proc_fops);
+   proc_create("smbd_max_fragmented_recv_size", 0, proc_fs_cifs,
+   _smbd_max_fragmented_recv_size_proc_fops);
+   proc_create("smbd_max_send_size", 0, proc_fs_cifs,
+   _smbd_max_send_size_proc_fops);
+   proc_create("smbd_send_credit_target", 0, proc_fs_cifs,
+   _smbd_send_credit_target_proc_fops);
+   proc_create("smbd_receive_credit_max", 0, proc_fs_cifs,
+   _smbd_receive_credit_max_proc_fops);
+#endif
 }
 
 void
@@ -415,6 +484,16 @@ cifs_proc_clean(void)
remove_proc_entry("SecurityFlags", proc_fs_cifs);
remove_proc_entry("LinuxExtensionsEnabled", proc_fs_cifs);
remove_proc_entry("LookupCacheEnabled", proc_fs_cifs);
+#ifdef CONFIG_CIFS_SMB_DIRECT
+   remove_proc_entry("rdma_readwrite_threshold", proc_fs_cifs);
+   remove_proc_entry("smbd_max_frmr_depth", proc_fs_cifs);
+   remove_proc_entry("smbd_keep_alive_interval", proc_fs_cifs);
+   remove_proc_entry("smbd_max_receive_size", proc_fs_cifs);
+   remove_proc_entry("smbd_max_fragmented_recv_size", proc_fs_cifs);
+   remove_proc_entry("smbd_max_send_size", proc_fs_cifs);
+   remove_proc_entry("smbd_send_credit_target", proc_fs_cifs);
+   remove_proc_entry("smbd_receive_credit_max", proc_fs_cifs);
+#endif
remove_proc_entry("fs/cifs", NULL);
 }
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to 

Re: [PATCH] ARM: exynos: add machine description for ODROID-XU3/4

2017-11-19 Thread Krzysztof Kozlowski
On Sun, Nov 19, 2017 at 6:21 PM, Tobias Jakobi
 wrote:
> I don't think this approach scales at all. DietPi can just read the devicetree
> through sysfs and retrieve the compatible and/or model of the base node.

Exactly, do not add new machines just for reading DT. Use
/sys/firmware/devicetree/base/compatible for this.

Best regards,
Krzysztof

> - Tobias
>
> Dongjin Kim wrote:
>> This patch is to add the machine descriptions for ODROID-XU3/4 boards
>> in order to present the hardware name at /proc/cputinfo rather than
>> "SAMSUNG EXYNOS (Flattened Device Tree)". An embedded open source project,
>> such as DietPi, reads the hardware name to run different features.
>>
>>   $ cat /proc/cpuinfo | grep Hardware
>>   Hardware: ODROID-XU4
>>
>> Signed-off-by: Dongjin Kim 
>> ---
>>  arch/arm/mach-exynos/exynos.c | 28 
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index c404c15ad07f..6197dbf9f48b 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -241,3 +241,31 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened 
>> Device Tree)")
>>   .dt_compat  = exynos_dt_compat,
>>   .dt_fixup   = exynos_dt_fixup,
>>  MACHINE_END
>> +
>> +#define ODROID_MACHINE_START(name, compat)   \
>> + DT_MACHINE_START(EXYNOS5422_ODROID_##name, "ODROID-"#name)  \
>> + .l2c_aux_val= 0x3c41,   \
>> + .l2c_aux_mask   = 0xc20f,   \
>> + .smp= smp_ops(exynos_smp_ops),  \
>> + .map_io = exynos_init_io,   \
>> + .init_early = exynos_firmware_init, \
>> + .init_irq   = exynos_init_irq,  \
>> + .init_machine   = exynos_dt_machine_init,   \
>> + .init_late  = exynos_init_late, \
>> + .dt_compat  = compat,   \
>> + .dt_fixup   = exynos_dt_fixup,  \
>> + MACHINE_END
>> +
>> +static char const *const exynos5422_odroidxu3_dt_compat[] __initconst = {
>> + "hardkernel,odroid-xu3",
>> + "hardkernel,odroid-xu3-lite",
>> + NULL,
>> +};
>> +
>> +static char const *const exynos5422_odroidxu4_dt_compat[] __initconst = {
>> + "hardkernel,odroid-xu4",
>> + NULL,
>> +};
>> +
>> +ODROID_MACHINE_START(XU3, exynos5422_odroidxu3_dt_compat)
>> +ODROID_MACHINE_START(XU4, exynos5422_odroidxu4_dt_compat)
>>
>


Re: [patches] Re: [PATCH v9 03/12] dt-bindings: RISC-V CPU Bindings

2017-11-19 Thread Jonathan Neuschäfer
Hi Palmer,

On Thu, Oct 05, 2017 at 11:16:33AM +0100, Mark Rutland wrote:
[...]
> I would *strongly* recommend that from day one, you determine the SMP
> bringup mechanism via an enable-method property, and document the
> contract with FW/bootloader somewhere in the kernel tree.

Somewhat, but not quite related: Please consider making the availability
of the Supervisor Binary Interface explicit in the devicetree.
I understand that the general plan is to make the SBI a mandatory
feature of every RISC-V system capable of running Linux, but I do want
to explore the possibility of running without run-time resident firmware
at some point in the future. Thus it would be nice if the devicetree
would indicate the presence of the SBI from the start, to avoid having
to invent a way to express its *absence* later on.

It could look something like this (modelled after qcom,scm):

/ {
firmware {
sbi {
compatible = "riscv,sbi";
};
};
};

This topic may warrant some discussion, because other people may have
different opinions, and there hasn't been a discussion about it, AFAICS.


Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature


Re: [patches] Re: [PATCH v9 03/12] dt-bindings: RISC-V CPU Bindings

2017-11-19 Thread Jonathan Neuschäfer
Hi Palmer,

On Thu, Oct 05, 2017 at 11:16:33AM +0100, Mark Rutland wrote:
[...]
> I would *strongly* recommend that from day one, you determine the SMP
> bringup mechanism via an enable-method property, and document the
> contract with FW/bootloader somewhere in the kernel tree.

Somewhat, but not quite related: Please consider making the availability
of the Supervisor Binary Interface explicit in the devicetree.
I understand that the general plan is to make the SBI a mandatory
feature of every RISC-V system capable of running Linux, but I do want
to explore the possibility of running without run-time resident firmware
at some point in the future. Thus it would be nice if the devicetree
would indicate the presence of the SBI from the start, to avoid having
to invent a way to express its *absence* later on.

It could look something like this (modelled after qcom,scm):

/ {
firmware {
sbi {
compatible = "riscv,sbi";
};
};
};

This topic may warrant some discussion, because other people may have
different opinions, and there hasn't been a discussion about it, AFAICS.


Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature


Re: [PATCH] perf parse events: Fix invalid precise_ip handling

2017-11-19 Thread Jiri Olsa
On Wed, Nov 15, 2017 at 09:00:03AM +0800, zhangmengting wrote:
> Hi Jiri, thanks for your detailed review, please see my comments inline.
> 
> 
> On 2017/11/10 18:39, Jiri Olsa wrote:
> > On Fri, Nov 10, 2017 at 04:28:37PM +0800, Mengting Zhang wrote:
> > 
> > SNIP
> > 
> > > diff --git a/tools/perf/util/parse-events.c 
> > > b/tools/perf/util/parse-events.c
> > > index 39b1596..25225f4 100644
> > > --- a/tools/perf/util/parse-events.c
> > > +++ b/tools/perf/util/parse-events.c
> > > @@ -1369,6 +1369,32 @@ struct event_modifier {
> > >   int pinned;
> > >   };
> > > +static int perf_get_max_precise_ip(void)
> > > +{
> > > +   int max_precise_ip = 0;
> > > +   struct perf_event_attr attr = {
> > > +   .type   = PERF_TYPE_HARDWARE,
> > > +   .config = PERF_COUNT_HW_CPU_CYCLES,
> > > +   };
> > > +
> > > +   event_attr_init();
> > > +
> > > +   attr.precise_ip = 3;
> > > +   attr.sample_period = 1;
> > > +
> > > +   while (attr.precise_ip != 0) {
> > > +   int fd = sys_perf_event_open(, 0, -1, -1, 0);
> > > +   if (fd != -1){
> > > +   close(fd);
> > > +   break;
> > > +   }
> > > +   --attr.precise_ip;
> > > +   }
> > > +   max_precise_ip = attr.precise_ip;
> > > +
> > > +   return max_precise_ip;
> > > +}
> > we already have a function for that, please check 
> > perf_event_attr__set_max_precise_ip
> Yeah, I've checked that function. But perf_event_attr__set_max_precise_ip()
> will change attr.precise_ip
> into the max precise ip available.
> 
> In this case, perf should only check whether the user-specified precise_ip
> is greater than the max
> precise_ip without changing it into maximum.  Here, introduce
> perf_get_max_precise_ip() to return
> the max precise ip and do not change attr.precise_ip.
> 
> But you reminds me that perf_get_max_precise_ip() can be simplied.

well both do the same.. probe kernel for max precise level,
so we can keep just one function for that

> > also I think the precise level is not generic for all the events,
> > so you should check it for specific perf_event_attr later, when
> > the attr is ready, not in modifier parsing
> You are right, and I would check it for specific perf_event_attr.
> 
> BTW, I have a question. If the user-specified precise_ip is greater than the
> max precise_ip, I wonder
> whether it is better to adjust the user-specified precise_ip to the maximum
> available.

no, I think that user defined precise level should stay the
way the user wants it.. we don't want more angry users ;-)

jirka


Re: [PATCH] perf parse events: Fix invalid precise_ip handling

2017-11-19 Thread Jiri Olsa
On Wed, Nov 15, 2017 at 09:00:03AM +0800, zhangmengting wrote:
> Hi Jiri, thanks for your detailed review, please see my comments inline.
> 
> 
> On 2017/11/10 18:39, Jiri Olsa wrote:
> > On Fri, Nov 10, 2017 at 04:28:37PM +0800, Mengting Zhang wrote:
> > 
> > SNIP
> > 
> > > diff --git a/tools/perf/util/parse-events.c 
> > > b/tools/perf/util/parse-events.c
> > > index 39b1596..25225f4 100644
> > > --- a/tools/perf/util/parse-events.c
> > > +++ b/tools/perf/util/parse-events.c
> > > @@ -1369,6 +1369,32 @@ struct event_modifier {
> > >   int pinned;
> > >   };
> > > +static int perf_get_max_precise_ip(void)
> > > +{
> > > +   int max_precise_ip = 0;
> > > +   struct perf_event_attr attr = {
> > > +   .type   = PERF_TYPE_HARDWARE,
> > > +   .config = PERF_COUNT_HW_CPU_CYCLES,
> > > +   };
> > > +
> > > +   event_attr_init();
> > > +
> > > +   attr.precise_ip = 3;
> > > +   attr.sample_period = 1;
> > > +
> > > +   while (attr.precise_ip != 0) {
> > > +   int fd = sys_perf_event_open(, 0, -1, -1, 0);
> > > +   if (fd != -1){
> > > +   close(fd);
> > > +   break;
> > > +   }
> > > +   --attr.precise_ip;
> > > +   }
> > > +   max_precise_ip = attr.precise_ip;
> > > +
> > > +   return max_precise_ip;
> > > +}
> > we already have a function for that, please check 
> > perf_event_attr__set_max_precise_ip
> Yeah, I've checked that function. But perf_event_attr__set_max_precise_ip()
> will change attr.precise_ip
> into the max precise ip available.
> 
> In this case, perf should only check whether the user-specified precise_ip
> is greater than the max
> precise_ip without changing it into maximum.  Here, introduce
> perf_get_max_precise_ip() to return
> the max precise ip and do not change attr.precise_ip.
> 
> But you reminds me that perf_get_max_precise_ip() can be simplied.

well both do the same.. probe kernel for max precise level,
so we can keep just one function for that

> > also I think the precise level is not generic for all the events,
> > so you should check it for specific perf_event_attr later, when
> > the attr is ready, not in modifier parsing
> You are right, and I would check it for specific perf_event_attr.
> 
> BTW, I have a question. If the user-specified precise_ip is greater than the
> max precise_ip, I wonder
> whether it is better to adjust the user-specified precise_ip to the maximum
> available.

no, I think that user defined precise level should stay the
way the user wants it.. we don't want more angry users ;-)

jirka


Re: [PATCH] nvme: fix spelling mistake: "requeing" -> "requeuing"

2017-11-19 Thread Christoph Hellwig
Thanks,

applied to nvme-4.15


Re: [PATCH] nvme: fix spelling mistake: "requeing" -> "requeuing"

2017-11-19 Thread Christoph Hellwig
Thanks,

applied to nvme-4.15


[PATCH] ALSA: hda/realtek: Add headset mic support for Intel NUC Skull Canyon

2017-11-19 Thread Kai-Heng Feng
Users have been using knob "model=dell-headset-multi" on Intel Skull
Canyon for a while.

Add the equivalent quirk, ALC269_FIXUP_DELL1_MIC_NO_PRESENCE for Skull
Canyon.

BugLink: https://bugs.launchpad.net/bugs/1732034
Signed-off-by: Kai-Heng Feng 
---
 sound/pci/hda/patch_realtek.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1797110cb096..5bb5623339dc 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6455,6 +6455,10 @@ static const struct snd_hda_pin_quirk 
alc269_pin_fixup_tbl[] = {
ALC225_STANDARD_PINS,
{0x12, 0xb7a60130},
{0x1b, 0x90170110}),
+   SND_HDA_PIN_QUIRK(0x10ec0233, 0x8086, "Intel NUC Skull Canyon", 
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
+   {0x1b, 0x0010},
+   {0x1e, 0x01451130},
+   {0x21, 0x02211020}),
SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", 
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
{0x12, 0x90a60140},
{0x14, 0x90170110},
-- 
2.14.1



[PATCH] ALSA: hda/realtek: Add headset mic support for Intel NUC Skull Canyon

2017-11-19 Thread Kai-Heng Feng
Users have been using knob "model=dell-headset-multi" on Intel Skull
Canyon for a while.

Add the equivalent quirk, ALC269_FIXUP_DELL1_MIC_NO_PRESENCE for Skull
Canyon.

BugLink: https://bugs.launchpad.net/bugs/1732034
Signed-off-by: Kai-Heng Feng 
---
 sound/pci/hda/patch_realtek.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1797110cb096..5bb5623339dc 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6455,6 +6455,10 @@ static const struct snd_hda_pin_quirk 
alc269_pin_fixup_tbl[] = {
ALC225_STANDARD_PINS,
{0x12, 0xb7a60130},
{0x1b, 0x90170110}),
+   SND_HDA_PIN_QUIRK(0x10ec0233, 0x8086, "Intel NUC Skull Canyon", 
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
+   {0x1b, 0x0010},
+   {0x1e, 0x01451130},
+   {0x21, 0x02211020}),
SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", 
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
{0x12, 0x90a60140},
{0x14, 0x90170110},
-- 
2.14.1



[PATCH] regmap: Remove the redundant config to select hwspinlock

2017-11-19 Thread Baolin Wang
The hwspinlock was changed to a bool by commit d048236dfdfe
("hwspinlock: Change hwspinlock to a bool"), so we do not need
the REGMAP_HWSPINLOCK config to select hwspinlock or not.

Signed-off-by: Baolin Wang 
---
 drivers/base/regmap/Kconfig  |  4 
 drivers/base/regmap/regmap.c | 11 ++-
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/base/regmap/Kconfig b/drivers/base/regmap/Kconfig
index 3a1535d..0368fd7 100644
--- a/drivers/base/regmap/Kconfig
+++ b/drivers/base/regmap/Kconfig
@@ -6,7 +6,6 @@
 config REGMAP
default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_W1 || 
REGMAP_AC97 || REGMAP_MMIO || REGMAP_IRQ)
select IRQ_DOMAIN if REGMAP_IRQ
-   select REGMAP_HWSPINLOCK if HWSPINLOCK=y
bool
 
 config REGCACHE_COMPRESSED
@@ -38,6 +37,3 @@ config REGMAP_MMIO
 
 config REGMAP_IRQ
bool
-
-config REGMAP_HWSPINLOCK
-   bool
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 8d516a9..f25ab18 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -414,7 +414,6 @@ static unsigned int regmap_parse_64_native(const void *buf)
 }
 #endif
 
-#ifdef REGMAP_HWSPINLOCK
 static void regmap_lock_hwlock(void *__map)
 {
struct regmap *map = __map;
@@ -457,7 +456,6 @@ static void regmap_unlock_hwlock_irqrestore(void *__map)
 
hwspin_unlock_irqrestore(map->hwlock, >spinlock_flags);
 }
-#endif
 
 static void regmap_lock_mutex(void *__map)
 {
@@ -674,7 +672,6 @@ struct regmap *__regmap_init(struct device *dev,
map->unlock = config->unlock;
map->lock_arg = config->lock_arg;
} else if (config->hwlock_id) {
-#ifdef REGMAP_HWSPINLOCK
map->hwlock = hwspin_lock_request_specific(config->hwlock_id);
if (!map->hwlock) {
ret = -ENXIO;
@@ -697,10 +694,6 @@ struct regmap *__regmap_init(struct device *dev,
}
 
map->lock_arg = map;
-#else
-   ret = -EINVAL;
-   goto err_map;
-#endif
} else {
if ((bus && bus->fast_io) ||
config->fast_io) {
@@ -1116,7 +1109,7 @@ struct regmap *__regmap_init(struct device *dev,
regmap_range_exit(map);
kfree(map->work_buf);
 err_hwlock:
-   if (IS_ENABLED(REGMAP_HWSPINLOCK) && map->hwlock)
+   if (map->hwlock)
hwspin_lock_free(map->hwlock);
 err_map:
kfree(map);
@@ -1305,7 +1298,7 @@ void regmap_exit(struct regmap *map)
kfree(async->work_buf);
kfree(async);
}
-   if (IS_ENABLED(REGMAP_HWSPINLOCK) && map->hwlock)
+   if (map->hwlock)
hwspin_lock_free(map->hwlock);
kfree(map);
 }
-- 
1.9.1



[PATCH] regmap: Remove the redundant config to select hwspinlock

2017-11-19 Thread Baolin Wang
The hwspinlock was changed to a bool by commit d048236dfdfe
("hwspinlock: Change hwspinlock to a bool"), so we do not need
the REGMAP_HWSPINLOCK config to select hwspinlock or not.

Signed-off-by: Baolin Wang 
---
 drivers/base/regmap/Kconfig  |  4 
 drivers/base/regmap/regmap.c | 11 ++-
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/base/regmap/Kconfig b/drivers/base/regmap/Kconfig
index 3a1535d..0368fd7 100644
--- a/drivers/base/regmap/Kconfig
+++ b/drivers/base/regmap/Kconfig
@@ -6,7 +6,6 @@
 config REGMAP
default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_W1 || 
REGMAP_AC97 || REGMAP_MMIO || REGMAP_IRQ)
select IRQ_DOMAIN if REGMAP_IRQ
-   select REGMAP_HWSPINLOCK if HWSPINLOCK=y
bool
 
 config REGCACHE_COMPRESSED
@@ -38,6 +37,3 @@ config REGMAP_MMIO
 
 config REGMAP_IRQ
bool
-
-config REGMAP_HWSPINLOCK
-   bool
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 8d516a9..f25ab18 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -414,7 +414,6 @@ static unsigned int regmap_parse_64_native(const void *buf)
 }
 #endif
 
-#ifdef REGMAP_HWSPINLOCK
 static void regmap_lock_hwlock(void *__map)
 {
struct regmap *map = __map;
@@ -457,7 +456,6 @@ static void regmap_unlock_hwlock_irqrestore(void *__map)
 
hwspin_unlock_irqrestore(map->hwlock, >spinlock_flags);
 }
-#endif
 
 static void regmap_lock_mutex(void *__map)
 {
@@ -674,7 +672,6 @@ struct regmap *__regmap_init(struct device *dev,
map->unlock = config->unlock;
map->lock_arg = config->lock_arg;
} else if (config->hwlock_id) {
-#ifdef REGMAP_HWSPINLOCK
map->hwlock = hwspin_lock_request_specific(config->hwlock_id);
if (!map->hwlock) {
ret = -ENXIO;
@@ -697,10 +694,6 @@ struct regmap *__regmap_init(struct device *dev,
}
 
map->lock_arg = map;
-#else
-   ret = -EINVAL;
-   goto err_map;
-#endif
} else {
if ((bus && bus->fast_io) ||
config->fast_io) {
@@ -1116,7 +1109,7 @@ struct regmap *__regmap_init(struct device *dev,
regmap_range_exit(map);
kfree(map->work_buf);
 err_hwlock:
-   if (IS_ENABLED(REGMAP_HWSPINLOCK) && map->hwlock)
+   if (map->hwlock)
hwspin_lock_free(map->hwlock);
 err_map:
kfree(map);
@@ -1305,7 +1298,7 @@ void regmap_exit(struct regmap *map)
kfree(async->work_buf);
kfree(async);
}
-   if (IS_ENABLED(REGMAP_HWSPINLOCK) && map->hwlock)
+   if (map->hwlock)
hwspin_lock_free(map->hwlock);
kfree(map);
 }
-- 
1.9.1



[tegra186]: emmc resume errors after booting from suspend

2017-11-19 Thread Pintu Kumar
Hi,

I am trying to verify suspend-to-disk on jetson-tx2 board (nvidia tegra186).
Suspend is working fine, but during resume emmc is failing to resume.
Kernel version: 4.4
Repo: https://nv-tegra.nvidia.com/gitweb/?p=linux-4.4.git;a=summary


It returns with:
mmc0: error -110 during resume (card was removed?)

Please see the complete logs below.

I tried to add some prints in mmc driver to check the cause.
It seems that mmc is not responding during resume.
[  137.125314] mmc_sleep: ERROR: mmc_wait_for_cmd, ret: -110

Do you have any pointers to fix/debug this issue?
When I see the linux kernel mainline kernel-4.14 (latest), I could see
that there are some patches in drivers/mmc/core/* which are missing in
jetson tx2 kernel version-4.4.
Do you think any of the latest patches may help to solve this issue?
If yes, can you point to some of relevant once?


Please help.


Thanks,
Pintu

LOGS:
---
## Booting ...
[ 117.079061] sdhci-tegra 340.sdhci: Tuning already done,
restoring the best tap value : 112
[ 117.081179] xhci-tegra 353.xhci: exiting ELPG
[ 117.081798] xhci-tegra 353.xhci: Firmware timestamp: 2016-09-01
11:32:41 UTC, Version: 55.05 release
[ 117.085202] xhci-tegra 353.xhci: exiting ELPG done
[ 117.085204] xhci-tegra 353.xhci: entering ELPG
[ 117.087770] xhci-tegra 353.xhci: entering ELPG done
[ 117.087775] Wake76 for irq=199
[ 117.08] Wake77 for irq=199
[ 117.087778] Wake78 for irq=199
[ 117.087779] Wake79 for irq=199
[ 117.087780] Wake80 for irq=199
[ 117.087781] Wake81 for irq=199
[ 117.087782] Wake82 for irq=199
[ 117.087784] Enabling wake76
[ 117.087785] Enabling wake77
[ 117.087786] Enabling wake78
[ 117.087787] Enabling wake79
[ 117.087788] Enabling wake80
[ 117.087789] Enabling wake81
[ 117.087790] Enabling wake82
[ 117.087891] tegra186-cam-rtcpu b00.rtcpu: sce gets halted
[ 117.090012] Wake24 for irq=241
[ 117.090015] Enabling wake24
[ 117.090598] nct1008_nct72 7-004c: success in disabling tmp451 VDD rail
[ 117.090654] gpio tegra-gpio-aon wake29 for gpio=56(FF:0)
[ 117.090655] Enabling wake29
[ 117.090774] gpio tegra-gpio wake53 for gpio=159(X:5)
[ 117.090775] Enabling wake53
[ 117.111219] tegradc 1521.nvdisplay: suspend
[ 117.111422] Wake73 for irq=42
[ 117.111424] Enabling wake73
[ 117.111597] bcm54xx_low_power_mode(): put phy in iddq-lp mode
[ 117.113533] gpio tegra-gpio wake71 for gpio=125(P:6)
[ 117.113535] Enabling wake71
[ 117.113632] PM: suspend of devices complete after 34.680 msecs
[ 117.114829] host1x 13e1.host1x: suspended
[ 117.114898] PM: late suspend of devices complete after 1.262 msecs
[ 117.133746] PM: noirq suspend of devices complete after 18.841 msecs
[ 117.133971] Disabling non-boot CPUs ...
[ 117.134249] CPU3: shutdown
[ 117.148582] psci: Retrying again to check for CPU kill
[ 117.148586] psci: CPU3 killed.
[ 117.149097] CPU4: shutdown
[ 117.164584] psci: Retrying again to check for CPU kill
[ 117.164589] psci: CPU4 killed.
[ 117.165041] CPU5: shutdown
[ 117.180572] psci: Retrying again to check for CPU kill
[ 117.180576] psci: CPU5 killed.
[ 117.180834] Entered SC7
[ 117.180834] Wake[31-0] level=0x4000
[ 117.180834] Wake[63-32] level=0x0
[ 117.180834] Wake[95-64] level=0x7f2a0
[ 117.180834] Wake[31-0] enable=0x2100
[ 117.180834] Wake[63-32] enable=0x20
[ 117.180834] Wake[95-64] enable=0x7f280
[ 117.180834] Wake[31-0] route=0x2100
[ 117.180834] Wake[63-32] route=0x20
[ 117.180834] Wake[95-64] route=0x7f280

[ 117.180834] Wake[32:0] status=0x0
[ 117.180834] Wake[64:32] status=0x0
[ 117.180834] Wake[96:64] status=0x0
[ 117.180834] Exited SC7
[ 117.180834] bpmp: waiting for handshake
[ 117.180834] bpmp: synchronizing channels
[ 117.180834] bpmp: channels synchronized
[ 117.180869] Enabling non-boot CPUs ...
[ 117.181067] CPU3: Booted secondary processor [411fd073]
[ 117.181198] CPU3 is up
[ 117.181353] CPU4: Booted secondary processor [411fd073]
[ 117.181455] CPU4 is up
[ 117.181609] CPU5: Booted secondary processor [411fd073]
[ 117.181721] CPU5 is up
[ 117.182740] xhci-tegra 353.xhci: exiting ELPG
[ 117.183221] xhci-tegra 353.xhci: Firmware timestamp: 2016-09-01
11:32:41 UTC, Version: 55.05 release
[ 117.381630] xhci-tegra 353.xhci: XHCI Controller not ready.
Falcon state: 0x10
[ 117.381633] xhci-tegra 353.xhci: exiting ELPG failed
[ 117.381643] dpm_run_callback(): tegra_xhci_resume_noirq+0x0/0x48 returns -14
[ 117.381653] PM: Device 353.xhci failed to resume noirq: error -14
[ 117.381724] PM: noirq resume of devices complete after 199.999 msecs
[ 117.383100] PM: early resume of devices complete after 1.236 msecs
[ 117.390964] gpio tegra-gpio wake71 for gpio=125(P:6)
[ 117.390966] Disabling wake71
[ 117.392317] pad_id 26: PMC_IMPL_E_33V_PWR_0 = [0x79]
[ 117.392317] sdhci-tegra 340.sdhci: Tuning already done,
restoring the best tap value : 112
[ 117.392380] sdhci-tegra 340.sdhci: Tuning already done,
restoring the best tap 

[tegra186]: emmc resume errors after booting from suspend

2017-11-19 Thread Pintu Kumar
Hi,

I am trying to verify suspend-to-disk on jetson-tx2 board (nvidia tegra186).
Suspend is working fine, but during resume emmc is failing to resume.
Kernel version: 4.4
Repo: https://nv-tegra.nvidia.com/gitweb/?p=linux-4.4.git;a=summary


It returns with:
mmc0: error -110 during resume (card was removed?)

Please see the complete logs below.

I tried to add some prints in mmc driver to check the cause.
It seems that mmc is not responding during resume.
[  137.125314] mmc_sleep: ERROR: mmc_wait_for_cmd, ret: -110

Do you have any pointers to fix/debug this issue?
When I see the linux kernel mainline kernel-4.14 (latest), I could see
that there are some patches in drivers/mmc/core/* which are missing in
jetson tx2 kernel version-4.4.
Do you think any of the latest patches may help to solve this issue?
If yes, can you point to some of relevant once?


Please help.


Thanks,
Pintu

LOGS:
---
## Booting ...
[ 117.079061] sdhci-tegra 340.sdhci: Tuning already done,
restoring the best tap value : 112
[ 117.081179] xhci-tegra 353.xhci: exiting ELPG
[ 117.081798] xhci-tegra 353.xhci: Firmware timestamp: 2016-09-01
11:32:41 UTC, Version: 55.05 release
[ 117.085202] xhci-tegra 353.xhci: exiting ELPG done
[ 117.085204] xhci-tegra 353.xhci: entering ELPG
[ 117.087770] xhci-tegra 353.xhci: entering ELPG done
[ 117.087775] Wake76 for irq=199
[ 117.08] Wake77 for irq=199
[ 117.087778] Wake78 for irq=199
[ 117.087779] Wake79 for irq=199
[ 117.087780] Wake80 for irq=199
[ 117.087781] Wake81 for irq=199
[ 117.087782] Wake82 for irq=199
[ 117.087784] Enabling wake76
[ 117.087785] Enabling wake77
[ 117.087786] Enabling wake78
[ 117.087787] Enabling wake79
[ 117.087788] Enabling wake80
[ 117.087789] Enabling wake81
[ 117.087790] Enabling wake82
[ 117.087891] tegra186-cam-rtcpu b00.rtcpu: sce gets halted
[ 117.090012] Wake24 for irq=241
[ 117.090015] Enabling wake24
[ 117.090598] nct1008_nct72 7-004c: success in disabling tmp451 VDD rail
[ 117.090654] gpio tegra-gpio-aon wake29 for gpio=56(FF:0)
[ 117.090655] Enabling wake29
[ 117.090774] gpio tegra-gpio wake53 for gpio=159(X:5)
[ 117.090775] Enabling wake53
[ 117.111219] tegradc 1521.nvdisplay: suspend
[ 117.111422] Wake73 for irq=42
[ 117.111424] Enabling wake73
[ 117.111597] bcm54xx_low_power_mode(): put phy in iddq-lp mode
[ 117.113533] gpio tegra-gpio wake71 for gpio=125(P:6)
[ 117.113535] Enabling wake71
[ 117.113632] PM: suspend of devices complete after 34.680 msecs
[ 117.114829] host1x 13e1.host1x: suspended
[ 117.114898] PM: late suspend of devices complete after 1.262 msecs
[ 117.133746] PM: noirq suspend of devices complete after 18.841 msecs
[ 117.133971] Disabling non-boot CPUs ...
[ 117.134249] CPU3: shutdown
[ 117.148582] psci: Retrying again to check for CPU kill
[ 117.148586] psci: CPU3 killed.
[ 117.149097] CPU4: shutdown
[ 117.164584] psci: Retrying again to check for CPU kill
[ 117.164589] psci: CPU4 killed.
[ 117.165041] CPU5: shutdown
[ 117.180572] psci: Retrying again to check for CPU kill
[ 117.180576] psci: CPU5 killed.
[ 117.180834] Entered SC7
[ 117.180834] Wake[31-0] level=0x4000
[ 117.180834] Wake[63-32] level=0x0
[ 117.180834] Wake[95-64] level=0x7f2a0
[ 117.180834] Wake[31-0] enable=0x2100
[ 117.180834] Wake[63-32] enable=0x20
[ 117.180834] Wake[95-64] enable=0x7f280
[ 117.180834] Wake[31-0] route=0x2100
[ 117.180834] Wake[63-32] route=0x20
[ 117.180834] Wake[95-64] route=0x7f280

[ 117.180834] Wake[32:0] status=0x0
[ 117.180834] Wake[64:32] status=0x0
[ 117.180834] Wake[96:64] status=0x0
[ 117.180834] Exited SC7
[ 117.180834] bpmp: waiting for handshake
[ 117.180834] bpmp: synchronizing channels
[ 117.180834] bpmp: channels synchronized
[ 117.180869] Enabling non-boot CPUs ...
[ 117.181067] CPU3: Booted secondary processor [411fd073]
[ 117.181198] CPU3 is up
[ 117.181353] CPU4: Booted secondary processor [411fd073]
[ 117.181455] CPU4 is up
[ 117.181609] CPU5: Booted secondary processor [411fd073]
[ 117.181721] CPU5 is up
[ 117.182740] xhci-tegra 353.xhci: exiting ELPG
[ 117.183221] xhci-tegra 353.xhci: Firmware timestamp: 2016-09-01
11:32:41 UTC, Version: 55.05 release
[ 117.381630] xhci-tegra 353.xhci: XHCI Controller not ready.
Falcon state: 0x10
[ 117.381633] xhci-tegra 353.xhci: exiting ELPG failed
[ 117.381643] dpm_run_callback(): tegra_xhci_resume_noirq+0x0/0x48 returns -14
[ 117.381653] PM: Device 353.xhci failed to resume noirq: error -14
[ 117.381724] PM: noirq resume of devices complete after 199.999 msecs
[ 117.383100] PM: early resume of devices complete after 1.236 msecs
[ 117.390964] gpio tegra-gpio wake71 for gpio=125(P:6)
[ 117.390966] Disabling wake71
[ 117.392317] pad_id 26: PMC_IMPL_E_33V_PWR_0 = [0x79]
[ 117.392317] sdhci-tegra 340.sdhci: Tuning already done,
restoring the best tap value : 112
[ 117.392380] sdhci-tegra 340.sdhci: Tuning already done,
restoring the best tap 

Re: [Xen-devel] [PATCH RFC v3 0/6] x86/idle: add halt poll support

2017-11-19 Thread Quan Xu



On 2017-11-16 05:31, Konrad Rzeszutek Wilk wrote:

On Mon, Nov 13, 2017 at 06:05:59PM +0800, Quan Xu wrote:

From: Yang Zhang 

Some latency-intensive workload have seen obviously performance
drop when running inside VM. The main reason is that the overhead
is amplified when running inside VM. The most cost I have seen is
inside idle path.

Meaning an VMEXIT b/c it is an 'halt' operation ? And then going
back in guest (VMRESUME) takes time. And hence your latency gets
all whacked b/c of this?

   Konrad, I can't follow 'b/c' here.. sorry.


So if I understand - you want to use your _full_ timeslice (of the guest)
without ever (or as much as possible) to go in the hypervisor?

    as much as possible.


Which means in effect you don't care about power-saving or CPUfreq
savings, you just want to eat the full CPU for snack?
  actually, we  care about power-saving. The poll duration is 
self-tuning, otherwise it is almost as the same as
  'halt=poll'. Also we always sent out with CPU usage of benchmark 
netperf/ctxsw. We got much more

  performance with limited promotion of CPU usage.



This patch introduces a new mechanism to poll for a while before
entering idle state. If schedule is needed during poll, then we
don't need to goes through the heavy overhead path.

Schedule of what? The guest or the host?

  rescheduled of guest scheduler..
  it is the guest.


Quan
Alibaba Cloud







Re: [Xen-devel] [PATCH RFC v3 0/6] x86/idle: add halt poll support

2017-11-19 Thread Quan Xu



On 2017-11-16 05:31, Konrad Rzeszutek Wilk wrote:

On Mon, Nov 13, 2017 at 06:05:59PM +0800, Quan Xu wrote:

From: Yang Zhang 

Some latency-intensive workload have seen obviously performance
drop when running inside VM. The main reason is that the overhead
is amplified when running inside VM. The most cost I have seen is
inside idle path.

Meaning an VMEXIT b/c it is an 'halt' operation ? And then going
back in guest (VMRESUME) takes time. And hence your latency gets
all whacked b/c of this?

   Konrad, I can't follow 'b/c' here.. sorry.


So if I understand - you want to use your _full_ timeslice (of the guest)
without ever (or as much as possible) to go in the hypervisor?

    as much as possible.


Which means in effect you don't care about power-saving or CPUfreq
savings, you just want to eat the full CPU for snack?
  actually, we  care about power-saving. The poll duration is 
self-tuning, otherwise it is almost as the same as
  'halt=poll'. Also we always sent out with CPU usage of benchmark 
netperf/ctxsw. We got much more

  performance with limited promotion of CPU usage.



This patch introduces a new mechanism to poll for a while before
entering idle state. If schedule is needed during poll, then we
don't need to goes through the heavy overhead path.

Schedule of what? The guest or the host?

  rescheduled of guest scheduler..
  it is the guest.


Quan
Alibaba Cloud







Re: [PATCH] staging: comedi: add missing MODULE_DESCRIPTION/LICENSE

2017-11-19 Thread Greg Kroah-Hartman
On Sun, Nov 19, 2017 at 11:02:52PM -0800, Jesse Chan wrote:
> Signed-off-by: Jesse Chan 

I can't take patches without any changelog text :(


Re: [PATCH] staging: comedi: add missing MODULE_DESCRIPTION/LICENSE

2017-11-19 Thread Greg Kroah-Hartman
On Sun, Nov 19, 2017 at 11:02:52PM -0800, Jesse Chan wrote:
> Signed-off-by: Jesse Chan 

I can't take patches without any changelog text :(


[PATCH] staging: comedi: add missing MODULE_DESCRIPTION/LICENSE

2017-11-19 Thread Jesse Chan
Signed-off-by: Jesse Chan 
---
 drivers/staging/comedi/drivers/ni_atmio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/comedi/drivers/ni_atmio.c 
b/drivers/staging/comedi/drivers/ni_atmio.c
index 2d62a8c57332..b61d56367773 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -361,3 +361,6 @@ static struct comedi_driver ni_atmio_driver = {
.detach = ni_atmio_detach,
 };
 module_comedi_driver(ni_atmio_driver);
+
+MODULE_DESCRIPTION("Comedi low-level driver");
+MODULE_LICENSE("GPL");
-- 
2.14.1



[PATCH] staging: comedi: add missing MODULE_DESCRIPTION/LICENSE

2017-11-19 Thread Jesse Chan
Signed-off-by: Jesse Chan 
---
 drivers/staging/comedi/drivers/ni_atmio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/comedi/drivers/ni_atmio.c 
b/drivers/staging/comedi/drivers/ni_atmio.c
index 2d62a8c57332..b61d56367773 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -361,3 +361,6 @@ static struct comedi_driver ni_atmio_driver = {
.detach = ni_atmio_detach,
 };
 module_comedi_driver(ni_atmio_driver);
+
+MODULE_DESCRIPTION("Comedi low-level driver");
+MODULE_LICENSE("GPL");
-- 
2.14.1



Re: [PATCH] USB: option: add Quectel BG96 2c7c:0296

2017-11-19 Thread Greg KH
On Sun, Nov 19, 2017 at 08:40:28PM +0100, ssjoh...@mac.com wrote:
> From: ssjoholm 
> 
> Signed-off-by: ssjoholm 

This goes at the bottom of the changelog text.

And we need a real name, I doubt you use this to sign legal documents.

> Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both CAT-M 
> and NB-IoT. Tested hardware is BG96 mounted on Quectel development board 
> (EVB). The USB id is added to option.c to allow DIAG,GPS,AT and modem 
> communication with the BG96.

Please also line-wrap your text at 72 columns, like your editor is
asking you to :)

thanks,

greg k-h


Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

2017-11-19 Thread Quan Xu



On 2017-11-16 17:45, Daniel Lezcano wrote:

On 16/11/2017 10:12, Quan Xu wrote:


On 2017-11-16 06:03, Thomas Gleixner wrote:

On Wed, 15 Nov 2017, Peter Zijlstra wrote:


On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote:

From: Yang Zhang 

Implement a generic idle poll which resembles the functionality
found in arch/. Provide weak arch_cpu_idle_poll function which
can be overridden by the architecture code if needed.

No, we want less of those magic hooks, not more.


Interrupts arrive which may not cause a reschedule in idle loops.
In KVM guest, this costs several VM-exit/VM-entry cycles, VM-entry
for interrupts and VM-exit immediately. Also this becomes more
expensive than bare metal. Add a generic idle poll before enter
real idle path. When a reschedule event is pending, we can bypass
the real idle path.

Why not do a HV specific idle driver?

If I understand the problem correctly then he wants to avoid the heavy
lifting in tick_nohz_idle_enter() in the first place, but there is
already
an interesting quirk there which makes it exit early.  See commit
3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this
commit
looks similar. But lets not proliferate that. I'd rather see that go
away.

agreed.

Even we can get more benifit than commit 3c5d92a0cfb5 ("nohz: Introduce
arch_needs_cpu")
in kvm guest. I won't proliferate that..


But the irq_timings stuff is heading into the same direction, with a more
complex prediction logic which should tell you pretty good how long that
idle period is going to be and in case of an interrupt heavy workload
this
would skip the extra work of stopping and restarting the tick and
provide a
very good input into a polling decision.


interesting. I have tested with IRQ_TIMINGS related code, which seems
not working so far.

I don't know how you tested it, can you elaborate what you meant by
"seems not working so far" ?


Daniel, I tried to enable IRQ_TIMINGS* manually. used 
irq_timings_next_event()

to return estimation of the earliest interrupt. However I got a constant.


There are still some work to do to be more efficient. The prediction
based on the irq timings is all right if the interrupts have a simple
periodicity. But as soon as there is a pattern, the current code can't
handle it properly and does bad predictions.

I'm working on a self-learning pattern detection which is too heavy for
the kernel, and with it we should be able to detect properly the
patterns and re-ajust the period if it changes. I'm in the process of
making it suitable for kernel code (both math and perf).

One improvement which can be done right now and which can help you is
the interrupts rate on the CPU. It is possible to compute it and that
will give an accurate information for the polling decision.


As tglx said, talk to each other / work together to make it usable for 
all use cases.
could you share how to enable it to get the interrupts rate on the CPU? 
I can try it

in cloud scenario. of course, I'd like to work with you to improve it.

Quan
Alibaba Cloud



Re: [PATCH] USB: option: add Quectel BG96 2c7c:0296

2017-11-19 Thread Greg KH
On Sun, Nov 19, 2017 at 08:40:28PM +0100, ssjoh...@mac.com wrote:
> From: ssjoholm 
> 
> Signed-off-by: ssjoholm 

This goes at the bottom of the changelog text.

And we need a real name, I doubt you use this to sign legal documents.

> Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both CAT-M 
> and NB-IoT. Tested hardware is BG96 mounted on Quectel development board 
> (EVB). The USB id is added to option.c to allow DIAG,GPS,AT and modem 
> communication with the BG96.

Please also line-wrap your text at 72 columns, like your editor is
asking you to :)

thanks,

greg k-h


Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

2017-11-19 Thread Quan Xu



On 2017-11-16 17:45, Daniel Lezcano wrote:

On 16/11/2017 10:12, Quan Xu wrote:


On 2017-11-16 06:03, Thomas Gleixner wrote:

On Wed, 15 Nov 2017, Peter Zijlstra wrote:


On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote:

From: Yang Zhang 

Implement a generic idle poll which resembles the functionality
found in arch/. Provide weak arch_cpu_idle_poll function which
can be overridden by the architecture code if needed.

No, we want less of those magic hooks, not more.


Interrupts arrive which may not cause a reschedule in idle loops.
In KVM guest, this costs several VM-exit/VM-entry cycles, VM-entry
for interrupts and VM-exit immediately. Also this becomes more
expensive than bare metal. Add a generic idle poll before enter
real idle path. When a reschedule event is pending, we can bypass
the real idle path.

Why not do a HV specific idle driver?

If I understand the problem correctly then he wants to avoid the heavy
lifting in tick_nohz_idle_enter() in the first place, but there is
already
an interesting quirk there which makes it exit early.  See commit
3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this
commit
looks similar. But lets not proliferate that. I'd rather see that go
away.

agreed.

Even we can get more benifit than commit 3c5d92a0cfb5 ("nohz: Introduce
arch_needs_cpu")
in kvm guest. I won't proliferate that..


But the irq_timings stuff is heading into the same direction, with a more
complex prediction logic which should tell you pretty good how long that
idle period is going to be and in case of an interrupt heavy workload
this
would skip the extra work of stopping and restarting the tick and
provide a
very good input into a polling decision.


interesting. I have tested with IRQ_TIMINGS related code, which seems
not working so far.

I don't know how you tested it, can you elaborate what you meant by
"seems not working so far" ?


Daniel, I tried to enable IRQ_TIMINGS* manually. used 
irq_timings_next_event()

to return estimation of the earliest interrupt. However I got a constant.


There are still some work to do to be more efficient. The prediction
based on the irq timings is all right if the interrupts have a simple
periodicity. But as soon as there is a pattern, the current code can't
handle it properly and does bad predictions.

I'm working on a self-learning pattern detection which is too heavy for
the kernel, and with it we should be able to detect properly the
patterns and re-ajust the period if it changes. I'm in the process of
making it suitable for kernel code (both math and perf).

One improvement which can be done right now and which can help you is
the interrupts rate on the CPU. It is possible to compute it and that
will give an accurate information for the polling decision.


As tglx said, talk to each other / work together to make it usable for 
all use cases.
could you share how to enable it to get the interrupts rate on the CPU? 
I can try it

in cloud scenario. of course, I'd like to work with you to improve it.

Quan
Alibaba Cloud



Re: [PATCH 00/10] x86: Add support for running as secondary Jailhouse guest

2017-11-19 Thread Jan Kiszka
On 2017-11-18 22:15, H. Peter Anvin wrote:
> On 11/15/17 23:26, Jan Kiszka wrote:
>> This series paves the way to run Linux in so-called non-root cells
>> (guest partitions) of the Jailhouse hypervisor.
>>
>> Jailhouse [1] was started 4 years ago as an open-source (GPL) leight-
>> weight hypervisor that statically partitions SMP systems. It's unique in
>> that it uses one Linux instance, the root cell, as boot loader and
>> management console. Jailhouse targets use cases for hard real-time and
>> safety-critical systems that KVM cannot cater due to its inherent
>> complexity.
>>
>> Jaihouse can run bare-metal, free and closed-source RTOSes as secondary
>> guests and, with this series, also x86 Linux instances. While ARM and
>> ARM64 non-root Linux guests are feasible without extra patches, thanks
>> to the high configurability via device trees, x86 requires special
>> platform support, mostly to step away from non-existing resources in a
>> non-root Jailhouse cell.
>>
> 
> Could you please write a single summary about the virtualization holes
> in Jailhouse that you are papering over?

Actually, we are not virtualizing any full device in Jailhouse. That is
an architectural decision that allows to keep the critical code base
very small (9200 LOC on Intel right now). So, anything that is not there
multiple times is not exposed or problematic state modifications are
blocked.

That leaves the non-root cells with:
- local CPU resources (processor, LAPIC etc.)
- exclusive memory regions
- exclusive PCI devices (or functions)
- read access to the PM timer (as clocksource)
- exclusively assigned pins on the IOAPIC (if any - it's not
  recommended to partition it)
- virtual shared memory devices for inter-cell communication

Thus, the list of non-existing x86 resources and features:
- LPC with all its legacy devices like PIT, PIC, RTC, SMBus etc.
  (unless you decide to pass one through exclusively)
- HPET
- normal PCI bus topology
- BIOS / UEFI firmware services, including ACPI enumeration (that lacks
  means to describe absence of PC platform devices anyway)
- mass storage or network virtualization - sharing such devices is not
  in the scope of the hypervisor
- no restart interface

Deviations and restrictions:
- CPU start address is configurable, typically set to 0 - but that's
  handled by the boot loader (comes with Jailhouse)
- LAPIC can only be operated in flat mode, and the content of LDR is
  frozen

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


Re: [PATCH 00/10] x86: Add support for running as secondary Jailhouse guest

2017-11-19 Thread Jan Kiszka
On 2017-11-18 22:15, H. Peter Anvin wrote:
> On 11/15/17 23:26, Jan Kiszka wrote:
>> This series paves the way to run Linux in so-called non-root cells
>> (guest partitions) of the Jailhouse hypervisor.
>>
>> Jailhouse [1] was started 4 years ago as an open-source (GPL) leight-
>> weight hypervisor that statically partitions SMP systems. It's unique in
>> that it uses one Linux instance, the root cell, as boot loader and
>> management console. Jailhouse targets use cases for hard real-time and
>> safety-critical systems that KVM cannot cater due to its inherent
>> complexity.
>>
>> Jaihouse can run bare-metal, free and closed-source RTOSes as secondary
>> guests and, with this series, also x86 Linux instances. While ARM and
>> ARM64 non-root Linux guests are feasible without extra patches, thanks
>> to the high configurability via device trees, x86 requires special
>> platform support, mostly to step away from non-existing resources in a
>> non-root Jailhouse cell.
>>
> 
> Could you please write a single summary about the virtualization holes
> in Jailhouse that you are papering over?

Actually, we are not virtualizing any full device in Jailhouse. That is
an architectural decision that allows to keep the critical code base
very small (9200 LOC on Intel right now). So, anything that is not there
multiple times is not exposed or problematic state modifications are
blocked.

That leaves the non-root cells with:
- local CPU resources (processor, LAPIC etc.)
- exclusive memory regions
- exclusive PCI devices (or functions)
- read access to the PM timer (as clocksource)
- exclusively assigned pins on the IOAPIC (if any - it's not
  recommended to partition it)
- virtual shared memory devices for inter-cell communication

Thus, the list of non-existing x86 resources and features:
- LPC with all its legacy devices like PIT, PIC, RTC, SMBus etc.
  (unless you decide to pass one through exclusively)
- HPET
- normal PCI bus topology
- BIOS / UEFI firmware services, including ACPI enumeration (that lacks
  means to describe absence of PC platform devices anyway)
- mass storage or network virtualization - sharing such devices is not
  in the scope of the hypervisor
- no restart interface

Deviations and restrictions:
- CPU start address is configurable, typically set to 0 - but that's
  handled by the boot loader (comes with Jailhouse)
- LAPIC can only be operated in flat mode, and the content of LDR is
  frozen

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


Re: [PATCH net,stable] net: qmi_wwan: add Quectel BG96 2c7c:0296

2017-11-19 Thread Bjørn Mork


On November 20, 2017 5:19:21 AM GMT+01:00, ssjoh...@mac.com wrote:
>From: ssjoholm 
>
>Signed-off-by: ssjoholm 
>
>Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
>CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
>development board (EVB).
>The USB id is added to qmi_wwan.c to allow QMI communication with the
>BG96.
>---
> drivers/net/usb/qmi_wwan.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
>index 720a3a248070..c750cf7c042b 100644
>--- a/drivers/net/usb/qmi_wwan.c
>+++ b/drivers/net/usb/qmi_wwan.c
>@@ -1239,6 +1239,7 @@ static const struct usb_device_id products[] = {
>   {QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
>   {QMI_QUIRK_SET_DTR(0x2c7c, 0x0125, 4)}, /* Quectel EC25, EC20 R2.0 
>Mini PCIe */
>   {QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
>+  {QMI_FIXED_INTF(0x2c7c, 0x0296, 4)},/* Quectel BG96 */
> 
>   /* 4. Gobi 1000 devices */
>   {QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */

Patch looks fine. But you need to use your full name in the tags. 
See the part about identity;
https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup

And the SOB and other tags go after the rest of the commit message. Your SOB 
should always be the last line. 



Bjørn 


Re: [PATCH net,stable] net: qmi_wwan: add Quectel BG96 2c7c:0296

2017-11-19 Thread Bjørn Mork


On November 20, 2017 5:19:21 AM GMT+01:00, ssjoh...@mac.com wrote:
>From: ssjoholm 
>
>Signed-off-by: ssjoholm 
>
>Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
>CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
>development board (EVB).
>The USB id is added to qmi_wwan.c to allow QMI communication with the
>BG96.
>---
> drivers/net/usb/qmi_wwan.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
>index 720a3a248070..c750cf7c042b 100644
>--- a/drivers/net/usb/qmi_wwan.c
>+++ b/drivers/net/usb/qmi_wwan.c
>@@ -1239,6 +1239,7 @@ static const struct usb_device_id products[] = {
>   {QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
>   {QMI_QUIRK_SET_DTR(0x2c7c, 0x0125, 4)}, /* Quectel EC25, EC20 R2.0 
>Mini PCIe */
>   {QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
>+  {QMI_FIXED_INTF(0x2c7c, 0x0296, 4)},/* Quectel BG96 */
> 
>   /* 4. Gobi 1000 devices */
>   {QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */

Patch looks fine. But you need to use your full name in the tags. 
See the part about identity;
https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup

And the SOB and other tags go after the rest of the commit message. Your SOB 
should always be the last line. 



Bjørn 


[PATCH v3] mfd: syscon: Add hardware spinlock support

2017-11-19 Thread Baolin Wang
Some system control registers need hardware spinlock to synchronize
between the multiple subsystems, so we should add hardware spinlock
support for syscon.

Signed-off-by: Baolin Wang 
Acked-by: Rob Herring 
---
Changes since v2:
 - Add acked tag from Rob.

Changes since v1:
 - Remove timeout configuration.
 - Modify the binding file to add hwlocks.

Note: The hwspinlock support in regmap was merged by commit:
(8698b9364710: "regmap: Add hardware spinlock support")
The hwspinlock was changed to a bool by commit:
(d048236dfdfe: "hwspinlock: Change hwspinlock to a bool")
---
 Documentation/devicetree/bindings/mfd/syscon.txt | 1 +
 drivers/mfd/syscon.c | 7 +++
 2 files changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt 
b/Documentation/devicetree/bindings/mfd/syscon.txt
index 8b92d45..f464cc8 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.txt
+++ b/Documentation/devicetree/bindings/mfd/syscon.txt
@@ -16,6 +16,7 @@ Required properties:
 Optional property:
 - reg-io-width: the size (in bytes) of the IO accesses that should be
   performed on the device.
+- hwlocks: reference to a phandle of a hardware spinlock provider node.
 
 Examples:
 gpr: iomuxc-gpr@20e {
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index b93fe4c..f1dccce 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -87,6 +88,12 @@ static struct syscon *of_syscon_register(struct device_node 
*np)
if (ret)
reg_io_width = 4;
 
+   ret = of_hwspin_lock_get_id(np, 0);
+   if (ret > 0) {
+   syscon_config.hwlock_id = ret;
+   syscon_config.hwlock_mode = HWLOCK_IRQSTATE;
+   }
+
syscon_config.reg_stride = reg_io_width;
syscon_config.val_bits = reg_io_width * 8;
syscon_config.max_register = resource_size() - reg_io_width;
-- 
1.9.1



[PATCH v3] mfd: syscon: Add hardware spinlock support

2017-11-19 Thread Baolin Wang
Some system control registers need hardware spinlock to synchronize
between the multiple subsystems, so we should add hardware spinlock
support for syscon.

Signed-off-by: Baolin Wang 
Acked-by: Rob Herring 
---
Changes since v2:
 - Add acked tag from Rob.

Changes since v1:
 - Remove timeout configuration.
 - Modify the binding file to add hwlocks.

Note: The hwspinlock support in regmap was merged by commit:
(8698b9364710: "regmap: Add hardware spinlock support")
The hwspinlock was changed to a bool by commit:
(d048236dfdfe: "hwspinlock: Change hwspinlock to a bool")
---
 Documentation/devicetree/bindings/mfd/syscon.txt | 1 +
 drivers/mfd/syscon.c | 7 +++
 2 files changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt 
b/Documentation/devicetree/bindings/mfd/syscon.txt
index 8b92d45..f464cc8 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.txt
+++ b/Documentation/devicetree/bindings/mfd/syscon.txt
@@ -16,6 +16,7 @@ Required properties:
 Optional property:
 - reg-io-width: the size (in bytes) of the IO accesses that should be
   performed on the device.
+- hwlocks: reference to a phandle of a hardware spinlock provider node.
 
 Examples:
 gpr: iomuxc-gpr@20e {
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index b93fe4c..f1dccce 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -87,6 +88,12 @@ static struct syscon *of_syscon_register(struct device_node 
*np)
if (ret)
reg_io_width = 4;
 
+   ret = of_hwspin_lock_get_id(np, 0);
+   if (ret > 0) {
+   syscon_config.hwlock_id = ret;
+   syscon_config.hwlock_mode = HWLOCK_IRQSTATE;
+   }
+
syscon_config.reg_stride = reg_io_width;
syscon_config.val_bits = reg_io_width * 8;
syscon_config.max_register = resource_size() - reg_io_width;
-- 
1.9.1



Re: [GIT PULL] NTB bug fixes for v4.15

2017-11-19 Thread Logan Gunthorpe


On 19/11/17 11:37 PM, Linus Torvalds wrote:
> Gaah. I guess I can take the pull request.

Many thanks.

> I do want to protest the timing and the lack of linux-next coverage.
> If it has really been ready for months, why hasn't it been in
> linux-next at all?

Understood. I can't speak for Jon, but in the future if I have patches
in the queue, I will definitely remind him to send it to Stephen for the
linux-next tree. And I'll make sure it gets there ahead of the merge window.

Logan


Re: [GIT PULL] NTB bug fixes for v4.15

2017-11-19 Thread Logan Gunthorpe


On 19/11/17 11:37 PM, Linus Torvalds wrote:
> Gaah. I guess I can take the pull request.

Many thanks.

> I do want to protest the timing and the lack of linux-next coverage.
> If it has really been ready for months, why hasn't it been in
> linux-next at all?

Understood. I can't speak for Jon, but in the future if I have patches
in the queue, I will definitely remind him to send it to Stephen for the
linux-next tree. And I'll make sure it gets there ahead of the merge window.

Logan


[PATCH v1 5/9] perf util: Remove a set of shadow stats static variables

2017-11-19 Thread Jin Yao
In previous patches, we have reconstructed the code and let
it not access the static variables directly.

This patch removes these static variables.

Signed-off-by: Jin Yao 
---
 tools/perf/util/stat-shadow.c | 64 ++-
 tools/perf/util/stat.h|  1 +
 2 files changed, 16 insertions(+), 49 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 6f28782..74bcc4d 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -16,28 +16,6 @@
  * AGGR_NONE: Use matching CPU
  * AGGR_THREAD: Not supported?
  */
-static struct stats runtime_nsecs_stats[MAX_NR_CPUS];
-static struct stats runtime_cycles_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_stalled_cycles_front_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_stalled_cycles_back_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_branches_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_cacherefs_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_l1_dcache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_l1_icache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_ll_cache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_itlb_cache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_dtlb_cache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_cycles_in_tx_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_transaction_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_elision_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_total_slots[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_slots_issued[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_slots_retired[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_fetch_bubbles[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_recovery_bubbles[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_smi_num_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_aperf_stats[NUM_CTX][MAX_NR_CPUS];
-static struct rblist runtime_saved_values;
 static bool have_frontend_stalled;
 
 static struct runtime_stat rt_stat;
@@ -191,36 +169,13 @@ static int evsel_context(struct perf_evsel *evsel)
return ctx;
 }
 
-void perf_stat__reset_shadow_stats(void)
+static void reset_stat(struct runtime_stat *stat)
 {
+   struct rblist *rblist;
struct rb_node *pos, *next;
 
-   memset(runtime_nsecs_stats, 0, sizeof(runtime_nsecs_stats));
-   memset(runtime_cycles_stats, 0, sizeof(runtime_cycles_stats));
-   memset(runtime_stalled_cycles_front_stats, 0, 
sizeof(runtime_stalled_cycles_front_stats));
-   memset(runtime_stalled_cycles_back_stats, 0, 
sizeof(runtime_stalled_cycles_back_stats));
-   memset(runtime_branches_stats, 0, sizeof(runtime_branches_stats));
-   memset(runtime_cacherefs_stats, 0, sizeof(runtime_cacherefs_stats));
-   memset(runtime_l1_dcache_stats, 0, sizeof(runtime_l1_dcache_stats));
-   memset(runtime_l1_icache_stats, 0, sizeof(runtime_l1_icache_stats));
-   memset(runtime_ll_cache_stats, 0, sizeof(runtime_ll_cache_stats));
-   memset(runtime_itlb_cache_stats, 0, sizeof(runtime_itlb_cache_stats));
-   memset(runtime_dtlb_cache_stats, 0, sizeof(runtime_dtlb_cache_stats));
-   memset(runtime_cycles_in_tx_stats, 0,
-   sizeof(runtime_cycles_in_tx_stats));
-   memset(runtime_transaction_stats, 0,
-   sizeof(runtime_transaction_stats));
-   memset(runtime_elision_stats, 0, sizeof(runtime_elision_stats));
-   memset(_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
-   memset(runtime_topdown_total_slots, 0, 
sizeof(runtime_topdown_total_slots));
-   memset(runtime_topdown_slots_retired, 0, 
sizeof(runtime_topdown_slots_retired));
-   memset(runtime_topdown_slots_issued, 0, 
sizeof(runtime_topdown_slots_issued));
-   memset(runtime_topdown_fetch_bubbles, 0, 
sizeof(runtime_topdown_fetch_bubbles));
-   memset(runtime_topdown_recovery_bubbles, 0, 
sizeof(runtime_topdown_recovery_bubbles));
-   memset(runtime_smi_num_stats, 0, sizeof(runtime_smi_num_stats));
-   memset(runtime_aperf_stats, 0, sizeof(runtime_aperf_stats));
-
-   next = rb_first(_saved_values.entries);
+   rblist = >value_list;
+   next = rb_first(>entries);
while (next) {
pos = next;
next = rb_next(pos);
@@ -230,6 +185,17 @@ void perf_stat__reset_shadow_stats(void)
}
 }
 
+void perf_stat__reset_shadow_stats(void)
+{
+   reset_stat(_stat);
+   memset(_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+}
+
+void perf_stat__reset_shadow_per_stat(struct runtime_stat *stat)
+{
+   reset_stat(stat);
+}
+
 static void update_runtime_stat(struct runtime_stat *stat,
enum stat_type type,
int ctx, int cpu, u64 count)
diff --git 

[PATCH v1 2/9] perf util: Define a structure for runtime shadow metrics stats

2017-11-19 Thread Jin Yao
Perf has a set of static variables to record the runtime shadow
metrics stats.

While if we want to record the runtime shadow stats for per-thread,
it will be the limitation. This patch creates a structure and the
next patches will use this structure to update the runtime shadow
stats for per-thread.

Signed-off-by: Jin Yao 
---
 tools/perf/util/stat-shadow.c | 11 ---
 tools/perf/util/stat.h| 46 ++-
 2 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 855e35c..5853901 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -9,17 +9,6 @@
 #include "expr.h"
 #include "metricgroup.h"
 
-enum {
-   CTX_BIT_USER= 1 << 0,
-   CTX_BIT_KERNEL  = 1 << 1,
-   CTX_BIT_HV  = 1 << 2,
-   CTX_BIT_HOST= 1 << 3,
-   CTX_BIT_IDLE= 1 << 4,
-   CTX_BIT_MAX = 1 << 5,
-};
-
-#define NUM_CTX CTX_BIT_MAX
-
 /*
  * AGGR_GLOBAL: Use CPU 0
  * AGGR_SOCKET: Use first CPU of socket
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index eefca5c..61fd2e0 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -5,6 +5,8 @@
 #include 
 #include 
 #include "xyarray.h"
+#include "evsel.h"
+#include "rblist.h"
 
 struct stats
 {
@@ -43,11 +45,54 @@ enum aggr_mode {
AGGR_UNSET,
 };
 
+enum {
+   CTX_BIT_USER= 1 << 0,
+   CTX_BIT_KERNEL  = 1 << 1,
+   CTX_BIT_HV  = 1 << 2,
+   CTX_BIT_HOST= 1 << 3,
+   CTX_BIT_IDLE= 1 << 4,
+   CTX_BIT_MAX = 1 << 5,
+};
+
+#define NUM_CTX CTX_BIT_MAX
+
+enum stat_type {
+   STAT_NONE = 0,
+   STAT_NSECS,
+   STAT_CYCLES,
+   STAT_STALLED_CYCLES_FRONT,
+   STAT_STALLED_CYCLES_BACK,
+   STAT_BRANCHES,
+   STAT_CACHEREFS,
+   STAT_L1_DCACHE,
+   STAT_L1_ICACHE,
+   STAT_LL_CACHE,
+   STAT_ITLB_CACHE,
+   STAT_DTLB_CACHE,
+   STAT_CYCLES_IN_TX,
+   STAT_TRANSACTION,
+   STAT_ELISION,
+   STAT_TOPDOWN_TOTAL_SLOTS,
+   STAT_TOPDOWN_SLOTS_ISSUED,
+   STAT_TOPDOWN_SLOTS_RETIRED,
+   STAT_TOPDOWN_FETCH_BUBBLES,
+   STAT_TOPDOWN_RECOVERY_BUBBLES,
+   STAT_SMI_NUM,
+   STAT_APERF,
+   STAT_MAX
+};
+
+struct runtime_stat {
+   struct rblist value_list;
+};
+
 struct perf_stat_config {
enum aggr_mode  aggr_mode;
boolscale;
FILE*output;
unsigned intinterval;
+   struct runtime_stat *stats;
+   int stat_num;
 };
 
 void update_stats(struct stats *stats, u64 val);
@@ -92,7 +137,6 @@ struct perf_stat_output_ctx {
bool force_header;
 };
 
-struct rblist;
 void perf_stat__print_shadow_stats(struct perf_evsel *evsel,
   double avg, int cpu,
   struct perf_stat_output_ctx *out,
-- 
2.7.4



[PATCH v1 5/9] perf util: Remove a set of shadow stats static variables

2017-11-19 Thread Jin Yao
In previous patches, we have reconstructed the code and let
it not access the static variables directly.

This patch removes these static variables.

Signed-off-by: Jin Yao 
---
 tools/perf/util/stat-shadow.c | 64 ++-
 tools/perf/util/stat.h|  1 +
 2 files changed, 16 insertions(+), 49 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 6f28782..74bcc4d 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -16,28 +16,6 @@
  * AGGR_NONE: Use matching CPU
  * AGGR_THREAD: Not supported?
  */
-static struct stats runtime_nsecs_stats[MAX_NR_CPUS];
-static struct stats runtime_cycles_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_stalled_cycles_front_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_stalled_cycles_back_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_branches_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_cacherefs_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_l1_dcache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_l1_icache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_ll_cache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_itlb_cache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_dtlb_cache_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_cycles_in_tx_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_transaction_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_elision_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_total_slots[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_slots_issued[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_slots_retired[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_fetch_bubbles[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_topdown_recovery_bubbles[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_smi_num_stats[NUM_CTX][MAX_NR_CPUS];
-static struct stats runtime_aperf_stats[NUM_CTX][MAX_NR_CPUS];
-static struct rblist runtime_saved_values;
 static bool have_frontend_stalled;
 
 static struct runtime_stat rt_stat;
@@ -191,36 +169,13 @@ static int evsel_context(struct perf_evsel *evsel)
return ctx;
 }
 
-void perf_stat__reset_shadow_stats(void)
+static void reset_stat(struct runtime_stat *stat)
 {
+   struct rblist *rblist;
struct rb_node *pos, *next;
 
-   memset(runtime_nsecs_stats, 0, sizeof(runtime_nsecs_stats));
-   memset(runtime_cycles_stats, 0, sizeof(runtime_cycles_stats));
-   memset(runtime_stalled_cycles_front_stats, 0, 
sizeof(runtime_stalled_cycles_front_stats));
-   memset(runtime_stalled_cycles_back_stats, 0, 
sizeof(runtime_stalled_cycles_back_stats));
-   memset(runtime_branches_stats, 0, sizeof(runtime_branches_stats));
-   memset(runtime_cacherefs_stats, 0, sizeof(runtime_cacherefs_stats));
-   memset(runtime_l1_dcache_stats, 0, sizeof(runtime_l1_dcache_stats));
-   memset(runtime_l1_icache_stats, 0, sizeof(runtime_l1_icache_stats));
-   memset(runtime_ll_cache_stats, 0, sizeof(runtime_ll_cache_stats));
-   memset(runtime_itlb_cache_stats, 0, sizeof(runtime_itlb_cache_stats));
-   memset(runtime_dtlb_cache_stats, 0, sizeof(runtime_dtlb_cache_stats));
-   memset(runtime_cycles_in_tx_stats, 0,
-   sizeof(runtime_cycles_in_tx_stats));
-   memset(runtime_transaction_stats, 0,
-   sizeof(runtime_transaction_stats));
-   memset(runtime_elision_stats, 0, sizeof(runtime_elision_stats));
-   memset(_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
-   memset(runtime_topdown_total_slots, 0, 
sizeof(runtime_topdown_total_slots));
-   memset(runtime_topdown_slots_retired, 0, 
sizeof(runtime_topdown_slots_retired));
-   memset(runtime_topdown_slots_issued, 0, 
sizeof(runtime_topdown_slots_issued));
-   memset(runtime_topdown_fetch_bubbles, 0, 
sizeof(runtime_topdown_fetch_bubbles));
-   memset(runtime_topdown_recovery_bubbles, 0, 
sizeof(runtime_topdown_recovery_bubbles));
-   memset(runtime_smi_num_stats, 0, sizeof(runtime_smi_num_stats));
-   memset(runtime_aperf_stats, 0, sizeof(runtime_aperf_stats));
-
-   next = rb_first(_saved_values.entries);
+   rblist = >value_list;
+   next = rb_first(>entries);
while (next) {
pos = next;
next = rb_next(pos);
@@ -230,6 +185,17 @@ void perf_stat__reset_shadow_stats(void)
}
 }
 
+void perf_stat__reset_shadow_stats(void)
+{
+   reset_stat(_stat);
+   memset(_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+}
+
+void perf_stat__reset_shadow_per_stat(struct runtime_stat *stat)
+{
+   reset_stat(stat);
+}
+
 static void update_runtime_stat(struct runtime_stat *stat,
enum stat_type type,
int ctx, int cpu, u64 count)
diff --git a/tools/perf/util/stat.h 

[PATCH v1 2/9] perf util: Define a structure for runtime shadow metrics stats

2017-11-19 Thread Jin Yao
Perf has a set of static variables to record the runtime shadow
metrics stats.

While if we want to record the runtime shadow stats for per-thread,
it will be the limitation. This patch creates a structure and the
next patches will use this structure to update the runtime shadow
stats for per-thread.

Signed-off-by: Jin Yao 
---
 tools/perf/util/stat-shadow.c | 11 ---
 tools/perf/util/stat.h| 46 ++-
 2 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 855e35c..5853901 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -9,17 +9,6 @@
 #include "expr.h"
 #include "metricgroup.h"
 
-enum {
-   CTX_BIT_USER= 1 << 0,
-   CTX_BIT_KERNEL  = 1 << 1,
-   CTX_BIT_HV  = 1 << 2,
-   CTX_BIT_HOST= 1 << 3,
-   CTX_BIT_IDLE= 1 << 4,
-   CTX_BIT_MAX = 1 << 5,
-};
-
-#define NUM_CTX CTX_BIT_MAX
-
 /*
  * AGGR_GLOBAL: Use CPU 0
  * AGGR_SOCKET: Use first CPU of socket
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index eefca5c..61fd2e0 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -5,6 +5,8 @@
 #include 
 #include 
 #include "xyarray.h"
+#include "evsel.h"
+#include "rblist.h"
 
 struct stats
 {
@@ -43,11 +45,54 @@ enum aggr_mode {
AGGR_UNSET,
 };
 
+enum {
+   CTX_BIT_USER= 1 << 0,
+   CTX_BIT_KERNEL  = 1 << 1,
+   CTX_BIT_HV  = 1 << 2,
+   CTX_BIT_HOST= 1 << 3,
+   CTX_BIT_IDLE= 1 << 4,
+   CTX_BIT_MAX = 1 << 5,
+};
+
+#define NUM_CTX CTX_BIT_MAX
+
+enum stat_type {
+   STAT_NONE = 0,
+   STAT_NSECS,
+   STAT_CYCLES,
+   STAT_STALLED_CYCLES_FRONT,
+   STAT_STALLED_CYCLES_BACK,
+   STAT_BRANCHES,
+   STAT_CACHEREFS,
+   STAT_L1_DCACHE,
+   STAT_L1_ICACHE,
+   STAT_LL_CACHE,
+   STAT_ITLB_CACHE,
+   STAT_DTLB_CACHE,
+   STAT_CYCLES_IN_TX,
+   STAT_TRANSACTION,
+   STAT_ELISION,
+   STAT_TOPDOWN_TOTAL_SLOTS,
+   STAT_TOPDOWN_SLOTS_ISSUED,
+   STAT_TOPDOWN_SLOTS_RETIRED,
+   STAT_TOPDOWN_FETCH_BUBBLES,
+   STAT_TOPDOWN_RECOVERY_BUBBLES,
+   STAT_SMI_NUM,
+   STAT_APERF,
+   STAT_MAX
+};
+
+struct runtime_stat {
+   struct rblist value_list;
+};
+
 struct perf_stat_config {
enum aggr_mode  aggr_mode;
boolscale;
FILE*output;
unsigned intinterval;
+   struct runtime_stat *stats;
+   int stat_num;
 };
 
 void update_stats(struct stats *stats, u64 val);
@@ -92,7 +137,6 @@ struct perf_stat_output_ctx {
bool force_header;
 };
 
-struct rblist;
 void perf_stat__print_shadow_stats(struct perf_evsel *evsel,
   double avg, int cpu,
   struct perf_stat_output_ctx *out,
-- 
2.7.4



[PATCH v1 3/9] perf util: Reconstruct rblist for supporting per-thread shadow stats

2017-11-19 Thread Jin Yao
In current stat-shadow.c, the rblist deleting is ignored.

The patch reconstructs the codes of rblist init/free, and adds
the implementation to node_delete method of rblist.

This patch also does:

1. Add the ctx/type/stat into rbtree keys because we will
use this rbtree to maintain shadow metrics to replace original
a couple of static arrays for supporting per-thread shadow stats.

2. Create a static runtime_stat variable 'rt_stat' which
will log the shadow metrics by default.

Signed-off-by: Jin Yao 
---
 tools/perf/util/stat-shadow.c | 62 ---
 tools/perf/util/stat.h|  2 ++
 2 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 5853901..045e129 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -40,12 +40,16 @@ static struct stats 
runtime_aperf_stats[NUM_CTX][MAX_NR_CPUS];
 static struct rblist runtime_saved_values;
 static bool have_frontend_stalled;
 
+static struct runtime_stat rt_stat;
 struct stats walltime_nsecs_stats;
 
 struct saved_value {
struct rb_node rb_node;
struct perf_evsel *evsel;
+   enum stat_type type;
+   int ctx;
int cpu;
+   struct runtime_stat *stat;
struct stats stats;
 };
 
@@ -58,6 +62,23 @@ static int saved_value_cmp(struct rb_node *rb_node, const 
void *entry)
 
if (a->cpu != b->cpu)
return a->cpu - b->cpu;
+
+   if (a->type != b->type)
+   return a->type - b->type;
+
+   if (a->ctx != b->ctx)
+   return a->ctx - b->ctx;
+
+   if (a->evsel == NULL && b->evsel == NULL) {
+   if (a->stat == b->stat)
+   return 0;
+
+   if ((char *)a->stat < (char *)b->stat)
+   return -1;
+
+   return 1;
+   }
+
if (a->evsel == b->evsel)
return 0;
if ((char *)a->evsel < (char *)b->evsel)
@@ -76,6 +97,17 @@ static struct rb_node *saved_value_new(struct rblist *rblist 
__maybe_unused,
return >rb_node;
 }
 
+static void saved_value_delete(struct rblist *rblist __maybe_unused,
+  struct rb_node *rb_node)
+{
+   struct saved_value *v = container_of(rb_node,
+struct saved_value,
+rb_node);
+
+   if (v)
+   free(v);
+}
+
 static struct saved_value *saved_value_lookup(struct perf_evsel *evsel,
  int cpu,
  bool create)
@@ -97,13 +129,35 @@ static struct saved_value *saved_value_lookup(struct 
perf_evsel *evsel,
return NULL;
 }
 
+static void init_saved_rblist(struct rblist *rblist)
+{
+   rblist__init(rblist);
+   rblist->node_cmp = saved_value_cmp;
+   rblist->node_new = saved_value_new;
+   rblist->node_delete = saved_value_delete;
+}
+
+static void free_saved_rblist(struct rblist *rblist)
+{
+   rblist__reset(rblist);
+}
+
+void perf_stat__init_runtime_stat(struct runtime_stat *stat)
+{
+   memset(stat, 0, sizeof(struct runtime_stat));
+   init_saved_rblist(>value_list);
+}
+
+void perf_stat__free_runtime_stat(struct runtime_stat *stat)
+{
+   free_saved_rblist(>value_list);
+}
+
 void perf_stat__init_shadow_stats(void)
 {
have_frontend_stalled = pmu_have_event("cpu", 
"stalled-cycles-frontend");
-   rblist__init(_saved_values);
-   runtime_saved_values.node_cmp = saved_value_cmp;
-   runtime_saved_values.node_new = saved_value_new;
-   /* No delete for now */
+   memset(_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+   perf_stat__init_runtime_stat(_stat);
 }
 
 static int evsel_context(struct perf_evsel *evsel)
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index 61fd2e0..4eb081d 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -126,6 +126,8 @@ typedef void (*print_metric_t)(void *ctx, const char 
*color, const char *unit,
   const char *fmt, double val);
 typedef void (*new_line_t )(void *ctx);
 
+void perf_stat__init_runtime_stat(struct runtime_stat *stat);
+void perf_stat__free_runtime_stat(struct runtime_stat *stat);
 void perf_stat__init_shadow_stats(void);
 void perf_stat__reset_shadow_stats(void);
 void perf_stat__update_shadow_stats(struct perf_evsel *counter, u64 count,
-- 
2.7.4



[PATCH v1 3/9] perf util: Reconstruct rblist for supporting per-thread shadow stats

2017-11-19 Thread Jin Yao
In current stat-shadow.c, the rblist deleting is ignored.

The patch reconstructs the codes of rblist init/free, and adds
the implementation to node_delete method of rblist.

This patch also does:

1. Add the ctx/type/stat into rbtree keys because we will
use this rbtree to maintain shadow metrics to replace original
a couple of static arrays for supporting per-thread shadow stats.

2. Create a static runtime_stat variable 'rt_stat' which
will log the shadow metrics by default.

Signed-off-by: Jin Yao 
---
 tools/perf/util/stat-shadow.c | 62 ---
 tools/perf/util/stat.h|  2 ++
 2 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 5853901..045e129 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -40,12 +40,16 @@ static struct stats 
runtime_aperf_stats[NUM_CTX][MAX_NR_CPUS];
 static struct rblist runtime_saved_values;
 static bool have_frontend_stalled;
 
+static struct runtime_stat rt_stat;
 struct stats walltime_nsecs_stats;
 
 struct saved_value {
struct rb_node rb_node;
struct perf_evsel *evsel;
+   enum stat_type type;
+   int ctx;
int cpu;
+   struct runtime_stat *stat;
struct stats stats;
 };
 
@@ -58,6 +62,23 @@ static int saved_value_cmp(struct rb_node *rb_node, const 
void *entry)
 
if (a->cpu != b->cpu)
return a->cpu - b->cpu;
+
+   if (a->type != b->type)
+   return a->type - b->type;
+
+   if (a->ctx != b->ctx)
+   return a->ctx - b->ctx;
+
+   if (a->evsel == NULL && b->evsel == NULL) {
+   if (a->stat == b->stat)
+   return 0;
+
+   if ((char *)a->stat < (char *)b->stat)
+   return -1;
+
+   return 1;
+   }
+
if (a->evsel == b->evsel)
return 0;
if ((char *)a->evsel < (char *)b->evsel)
@@ -76,6 +97,17 @@ static struct rb_node *saved_value_new(struct rblist *rblist 
__maybe_unused,
return >rb_node;
 }
 
+static void saved_value_delete(struct rblist *rblist __maybe_unused,
+  struct rb_node *rb_node)
+{
+   struct saved_value *v = container_of(rb_node,
+struct saved_value,
+rb_node);
+
+   if (v)
+   free(v);
+}
+
 static struct saved_value *saved_value_lookup(struct perf_evsel *evsel,
  int cpu,
  bool create)
@@ -97,13 +129,35 @@ static struct saved_value *saved_value_lookup(struct 
perf_evsel *evsel,
return NULL;
 }
 
+static void init_saved_rblist(struct rblist *rblist)
+{
+   rblist__init(rblist);
+   rblist->node_cmp = saved_value_cmp;
+   rblist->node_new = saved_value_new;
+   rblist->node_delete = saved_value_delete;
+}
+
+static void free_saved_rblist(struct rblist *rblist)
+{
+   rblist__reset(rblist);
+}
+
+void perf_stat__init_runtime_stat(struct runtime_stat *stat)
+{
+   memset(stat, 0, sizeof(struct runtime_stat));
+   init_saved_rblist(>value_list);
+}
+
+void perf_stat__free_runtime_stat(struct runtime_stat *stat)
+{
+   free_saved_rblist(>value_list);
+}
+
 void perf_stat__init_shadow_stats(void)
 {
have_frontend_stalled = pmu_have_event("cpu", 
"stalled-cycles-frontend");
-   rblist__init(_saved_values);
-   runtime_saved_values.node_cmp = saved_value_cmp;
-   runtime_saved_values.node_new = saved_value_new;
-   /* No delete for now */
+   memset(_nsecs_stats, 0, sizeof(walltime_nsecs_stats));
+   perf_stat__init_runtime_stat(_stat);
 }
 
 static int evsel_context(struct perf_evsel *evsel)
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index 61fd2e0..4eb081d 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -126,6 +126,8 @@ typedef void (*print_metric_t)(void *ctx, const char 
*color, const char *unit,
   const char *fmt, double val);
 typedef void (*new_line_t )(void *ctx);
 
+void perf_stat__init_runtime_stat(struct runtime_stat *stat);
+void perf_stat__free_runtime_stat(struct runtime_stat *stat);
 void perf_stat__init_shadow_stats(void);
 void perf_stat__reset_shadow_stats(void);
 void perf_stat__update_shadow_stats(struct perf_evsel *counter, u64 count,
-- 
2.7.4



[PATCH v1 9/9] perf stat: Resort '--per-thread' result

2017-11-19 Thread Jin Yao
There are many threads reported if we enable '--per-thread'
globally.

1. Most of the threads are not counted or counting value 0.
This patch removes these threads.

2. We also resort the threads in display according to the
counting value. It's useful for user to see the hottest
threads easily.

For example, the new results would be:

root@skl:/tmp# perf stat --per-thread
^C
 Performance counter stats for 'system wide':

perf-24165  4.302433  cpu-clock (msec)  #   
 0.001 CPUs utilized
  vmstat-23127  1.562215  cpu-clock (msec)  #   
 0.000 CPUs utilized
  irqbalance-2780   0.827851  cpu-clock (msec)  #   
 0.000 CPUs utilized
sshd-23111  0.278308  cpu-clock (msec)  #   
 0.000 CPUs utilized
thermald-2841   0.230880  cpu-clock (msec)  #   
 0.000 CPUs utilized
sshd-23058  0.207306  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/0:2-19991  0.133983  cpu-clock (msec)  #   
 0.000 CPUs utilized
   kworker/u16:1-18249  0.125636  cpu-clock (msec)  #   
 0.000 CPUs utilized
   rcu_sched-8  0.085533  cpu-clock (msec)  #   
 0.000 CPUs utilized
   kworker/u16:2-23146  0.077139  cpu-clock (msec)  #   
 0.000 CPUs utilized
   gmain-2700   0.041789  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/4:1-15354  0.028370  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/6:0-17528  0.023895  cpu-clock (msec)  #   
 0.000 CPUs utilized
kworker/4:1H-1887   0.013209  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/5:2-31362  0.011627  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/0-11 0.010892  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/3:2-12870  0.010220  cpu-clock (msec)  #   
 0.000 CPUs utilized
 ksoftirqd/0-7  0.008869  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/1-14 0.008476  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/7-50 0.002944  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/3-26 0.002893  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/4-32 0.002759  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/2-20 0.002429  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/6-44 0.001491  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/5-38 0.001477  cpu-clock (msec)  #   
 0.000 CPUs utilized
   rcu_sched-810  context-switches  #   
 0.117 M/sec
   kworker/u16:1-18249 7  context-switches  #   
 0.056 M/sec
sshd-23111 4  context-switches  #   
 0.014 M/sec
  vmstat-23127 4  context-switches  #   
 0.003 M/sec
perf-24165 4  context-switches  #   
 0.930 K/sec
 kworker/0:2-19991 3  context-switches  #   
 0.022 M/sec
   kworker/u16:2-23146 3  context-switches  #   
 0.039 M/sec
 kworker/4:1-15354 2  context-switches  #   
 0.070 M/sec
 kworker/6:0-17528 2  context-switches  #   
 0.084 M/sec
sshd-23058 2  context-switches  #   
 0.010 M/sec
 ksoftirqd/0-7 1  context-switches  #   
 0.113 M/sec
  watchdog/0-111  context-switches  #   
 0.092 M/sec
  watchdog/1-141  context-switches  #   
 0.118 M/sec
  watchdog/2-201  context-switches  #   
 0.412 M/sec
  watchdog/3-261  context-switches  #   
 0.346 M/sec
  watchdog/4-321  context-switches  #   
 0.362 M/sec
  watchdog/5-381  context-switches  #   
 0.677 M/sec
  watchdog/6-441  context-switches  #   
 0.671 M/sec
  watchdog/7-501  context-switches  #   
 0.340 M/sec
kworker/4:1H-1887  1  context-switches  #   
 0.076 M/sec
thermald-2841  1  context-switches  #   
 0.004 M/sec
   gmain-2700  1  

[PATCH v1 9/9] perf stat: Resort '--per-thread' result

2017-11-19 Thread Jin Yao
There are many threads reported if we enable '--per-thread'
globally.

1. Most of the threads are not counted or counting value 0.
This patch removes these threads.

2. We also resort the threads in display according to the
counting value. It's useful for user to see the hottest
threads easily.

For example, the new results would be:

root@skl:/tmp# perf stat --per-thread
^C
 Performance counter stats for 'system wide':

perf-24165  4.302433  cpu-clock (msec)  #   
 0.001 CPUs utilized
  vmstat-23127  1.562215  cpu-clock (msec)  #   
 0.000 CPUs utilized
  irqbalance-2780   0.827851  cpu-clock (msec)  #   
 0.000 CPUs utilized
sshd-23111  0.278308  cpu-clock (msec)  #   
 0.000 CPUs utilized
thermald-2841   0.230880  cpu-clock (msec)  #   
 0.000 CPUs utilized
sshd-23058  0.207306  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/0:2-19991  0.133983  cpu-clock (msec)  #   
 0.000 CPUs utilized
   kworker/u16:1-18249  0.125636  cpu-clock (msec)  #   
 0.000 CPUs utilized
   rcu_sched-8  0.085533  cpu-clock (msec)  #   
 0.000 CPUs utilized
   kworker/u16:2-23146  0.077139  cpu-clock (msec)  #   
 0.000 CPUs utilized
   gmain-2700   0.041789  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/4:1-15354  0.028370  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/6:0-17528  0.023895  cpu-clock (msec)  #   
 0.000 CPUs utilized
kworker/4:1H-1887   0.013209  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/5:2-31362  0.011627  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/0-11 0.010892  cpu-clock (msec)  #   
 0.000 CPUs utilized
 kworker/3:2-12870  0.010220  cpu-clock (msec)  #   
 0.000 CPUs utilized
 ksoftirqd/0-7  0.008869  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/1-14 0.008476  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/7-50 0.002944  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/3-26 0.002893  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/4-32 0.002759  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/2-20 0.002429  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/6-44 0.001491  cpu-clock (msec)  #   
 0.000 CPUs utilized
  watchdog/5-38 0.001477  cpu-clock (msec)  #   
 0.000 CPUs utilized
   rcu_sched-810  context-switches  #   
 0.117 M/sec
   kworker/u16:1-18249 7  context-switches  #   
 0.056 M/sec
sshd-23111 4  context-switches  #   
 0.014 M/sec
  vmstat-23127 4  context-switches  #   
 0.003 M/sec
perf-24165 4  context-switches  #   
 0.930 K/sec
 kworker/0:2-19991 3  context-switches  #   
 0.022 M/sec
   kworker/u16:2-23146 3  context-switches  #   
 0.039 M/sec
 kworker/4:1-15354 2  context-switches  #   
 0.070 M/sec
 kworker/6:0-17528 2  context-switches  #   
 0.084 M/sec
sshd-23058 2  context-switches  #   
 0.010 M/sec
 ksoftirqd/0-7 1  context-switches  #   
 0.113 M/sec
  watchdog/0-111  context-switches  #   
 0.092 M/sec
  watchdog/1-141  context-switches  #   
 0.118 M/sec
  watchdog/2-201  context-switches  #   
 0.412 M/sec
  watchdog/3-261  context-switches  #   
 0.346 M/sec
  watchdog/4-321  context-switches  #   
 0.362 M/sec
  watchdog/5-381  context-switches  #   
 0.677 M/sec
  watchdog/6-441  context-switches  #   
 0.671 M/sec
  watchdog/7-501  context-switches  #   
 0.340 M/sec
kworker/4:1H-1887  1  context-switches  #   
 0.076 M/sec
thermald-2841  1  context-switches  #   
 0.004 M/sec
   gmain-2700  1  

[PATCH v1 8/9] perf stat: Remove --per-thread pid/tid limitation

2017-11-19 Thread Jin Yao
Currently, if we execute 'perf stat --per-thread' without specifying
pid/tid, perf will return error.

root@skl:/tmp# perf stat --per-thread
The --per-thread option is only available when monitoring via -p -t options.
-p, --pidstat events on existing process id
-t, --tidstat events on existing thread id

This patch removes this limitation. If no pid/tid specified, it returns
all threads (get threads from /proc).

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-stat.c | 23 +++
 tools/perf/util/target.h  |  7 +++
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 9eec145..2d718f7 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -277,7 +277,7 @@ static int create_perf_stat_counter(struct perf_evsel 
*evsel)
attr->enable_on_exec = 1;
}
 
-   if (target__has_cpu())
+   if (target__has_cpu() && !target__has_per_thread())
return perf_evsel__open_per_cpu(evsel, perf_evsel__cpus(evsel));
 
return perf_evsel__open_per_thread(evsel, evsel_list->threads);
@@ -340,7 +340,7 @@ static int read_counter(struct perf_evsel *counter)
int nthreads = thread_map__nr(evsel_list->threads);
int ncpus, cpu, thread;
 
-   if (target__has_cpu())
+   if (target__has_cpu() && !target__has_per_thread())
ncpus = perf_evsel__nr_cpus(counter);
else
ncpus = 1;
@@ -2791,12 +2791,16 @@ int cmd_stat(int argc, const char **argv)
run_count = 1;
}
 
-   if ((stat_config.aggr_mode == AGGR_THREAD) && 
!target__has_task()) {
-   fprintf(stderr, "The --per-thread option is only available "
-   "when monitoring via -p -t options.\n");
-   parse_options_usage(NULL, stat_options, "p", 1);
-   parse_options_usage(NULL, stat_options, "t", 1);
-   goto out;
+   if ((stat_config.aggr_mode == AGGR_THREAD) &&
+   !target__has_task()) {
+   if (!target.system_wide || target.cpu_list) {
+   fprintf(stderr, "The --per-thread option is only "
+   "available when monitoring via -p -t "
+   "options.\n");
+   parse_options_usage(NULL, stat_options, "p", 1);
+   parse_options_usage(NULL, stat_options, "t", 1);
+   goto out;
+   }
}
 
/*
@@ -2820,6 +2824,9 @@ int cmd_stat(int argc, const char **argv)
 
target__validate();
 
+   if ((stat_config.aggr_mode == AGGR_THREAD) && (target.system_wide))
+   target.per_thread = true;
+
if (perf_evlist__create_maps(evsel_list, ) < 0) {
if (target__has_task()) {
pr_err("Problems finding threads of monitor\n");
diff --git a/tools/perf/util/target.h b/tools/perf/util/target.h
index 446aa7a..6ef01a8 100644
--- a/tools/perf/util/target.h
+++ b/tools/perf/util/target.h
@@ -64,6 +64,11 @@ static inline bool target__none(struct target *target)
return !target__has_task(target) && !target__has_cpu(target);
 }
 
+static inline bool target__has_per_thread(struct target *target)
+{
+   return target->system_wide && target->per_thread;
+}
+
 static inline bool target__uses_dummy_map(struct target *target)
 {
bool use_dummy = false;
@@ -73,6 +78,8 @@ static inline bool target__uses_dummy_map(struct target 
*target)
else if (target__has_task(target) ||
 (!target__has_cpu(target) && !target->uses_mmap))
use_dummy = true;
+   else if (target__has_per_thread(target))
+   use_dummy = true;
 
return use_dummy;
 }
-- 
2.7.4



[PATCH v1 8/9] perf stat: Remove --per-thread pid/tid limitation

2017-11-19 Thread Jin Yao
Currently, if we execute 'perf stat --per-thread' without specifying
pid/tid, perf will return error.

root@skl:/tmp# perf stat --per-thread
The --per-thread option is only available when monitoring via -p -t options.
-p, --pidstat events on existing process id
-t, --tidstat events on existing thread id

This patch removes this limitation. If no pid/tid specified, it returns
all threads (get threads from /proc).

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-stat.c | 23 +++
 tools/perf/util/target.h  |  7 +++
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 9eec145..2d718f7 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -277,7 +277,7 @@ static int create_perf_stat_counter(struct perf_evsel 
*evsel)
attr->enable_on_exec = 1;
}
 
-   if (target__has_cpu())
+   if (target__has_cpu() && !target__has_per_thread())
return perf_evsel__open_per_cpu(evsel, perf_evsel__cpus(evsel));
 
return perf_evsel__open_per_thread(evsel, evsel_list->threads);
@@ -340,7 +340,7 @@ static int read_counter(struct perf_evsel *counter)
int nthreads = thread_map__nr(evsel_list->threads);
int ncpus, cpu, thread;
 
-   if (target__has_cpu())
+   if (target__has_cpu() && !target__has_per_thread())
ncpus = perf_evsel__nr_cpus(counter);
else
ncpus = 1;
@@ -2791,12 +2791,16 @@ int cmd_stat(int argc, const char **argv)
run_count = 1;
}
 
-   if ((stat_config.aggr_mode == AGGR_THREAD) && 
!target__has_task()) {
-   fprintf(stderr, "The --per-thread option is only available "
-   "when monitoring via -p -t options.\n");
-   parse_options_usage(NULL, stat_options, "p", 1);
-   parse_options_usage(NULL, stat_options, "t", 1);
-   goto out;
+   if ((stat_config.aggr_mode == AGGR_THREAD) &&
+   !target__has_task()) {
+   if (!target.system_wide || target.cpu_list) {
+   fprintf(stderr, "The --per-thread option is only "
+   "available when monitoring via -p -t "
+   "options.\n");
+   parse_options_usage(NULL, stat_options, "p", 1);
+   parse_options_usage(NULL, stat_options, "t", 1);
+   goto out;
+   }
}
 
/*
@@ -2820,6 +2824,9 @@ int cmd_stat(int argc, const char **argv)
 
target__validate();
 
+   if ((stat_config.aggr_mode == AGGR_THREAD) && (target.system_wide))
+   target.per_thread = true;
+
if (perf_evlist__create_maps(evsel_list, ) < 0) {
if (target__has_task()) {
pr_err("Problems finding threads of monitor\n");
diff --git a/tools/perf/util/target.h b/tools/perf/util/target.h
index 446aa7a..6ef01a8 100644
--- a/tools/perf/util/target.h
+++ b/tools/perf/util/target.h
@@ -64,6 +64,11 @@ static inline bool target__none(struct target *target)
return !target__has_task(target) && !target__has_cpu(target);
 }
 
+static inline bool target__has_per_thread(struct target *target)
+{
+   return target->system_wide && target->per_thread;
+}
+
 static inline bool target__uses_dummy_map(struct target *target)
 {
bool use_dummy = false;
@@ -73,6 +78,8 @@ static inline bool target__uses_dummy_map(struct target 
*target)
else if (target__has_task(target) ||
 (!target__has_cpu(target) && !target->uses_mmap))
use_dummy = true;
+   else if (target__has_per_thread(target))
+   use_dummy = true;
 
return use_dummy;
 }
-- 
2.7.4



[PATCH v1 7/9] perf util: Reuse thread_map__new_by_uid to enumerate threads from /proc

2017-11-19 Thread Jin Yao
Perf already has a function thread_map__new_by_uid() which can
enumerate all threads from /proc by uid.

This patch creates a static function enumerate_threads() which
reuses the common code in thread_map__new_by_uid() to enumerate
threads from /proc.

The enumerate_threads() is shared by thread_map__new_by_uid()
and a new function thread_map__new_threads().

The new function thread_map__new_threads() is called to enumerate
all threads from /proc.

Signed-off-by: Jin Yao 
---
 tools/perf/tests/thread-map.c |  2 +-
 tools/perf/util/evlist.c  |  3 ++-
 tools/perf/util/thread_map.c  | 19 ---
 tools/perf/util/thread_map.h  |  3 ++-
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/tools/perf/tests/thread-map.c b/tools/perf/tests/thread-map.c
index dbcb6a1..4de1939 100644
--- a/tools/perf/tests/thread-map.c
+++ b/tools/perf/tests/thread-map.c
@@ -105,7 +105,7 @@ int test__thread_map_remove(struct test *test 
__maybe_unused, int subtest __mayb
TEST_ASSERT_VAL("failed to allocate map string",
asprintf(, "%d,%d", getpid(), getppid()) >= 0);
 
-   threads = thread_map__new_str(str, NULL, 0);
+   threads = thread_map__new_str(str, NULL, 0, false);
 
TEST_ASSERT_VAL("failed to allocate thread_map",
threads);
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 199bb82..05b8f2b 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1102,7 +1102,8 @@ int perf_evlist__create_maps(struct perf_evlist *evlist, 
struct target *target)
struct cpu_map *cpus;
struct thread_map *threads;
 
-   threads = thread_map__new_str(target->pid, target->tid, target->uid);
+   threads = thread_map__new_str(target->pid, target->tid, target->uid,
+ target->per_thread);
 
if (!threads)
return -1;
diff --git a/tools/perf/util/thread_map.c b/tools/perf/util/thread_map.c
index be0d5a7..5672268 100644
--- a/tools/perf/util/thread_map.c
+++ b/tools/perf/util/thread_map.c
@@ -92,7 +92,7 @@ struct thread_map *thread_map__new_by_tid(pid_t tid)
return threads;
 }
 
-struct thread_map *thread_map__new_by_uid(uid_t uid)
+static struct thread_map *enumerate_threads(uid_t uid)
 {
DIR *proc;
int max_threads = 32, items, i;
@@ -124,7 +124,7 @@ struct thread_map *thread_map__new_by_uid(uid_t uid)
if (stat(path, ) != 0)
continue;
 
-   if (st.st_uid != uid)
+   if ((uid != UINT_MAX) && (st.st_uid != uid))
continue;
 
snprintf(path, sizeof(path), "/proc/%d/task", pid);
@@ -178,6 +178,16 @@ struct thread_map *thread_map__new_by_uid(uid_t uid)
goto out_closedir;
 }
 
+struct thread_map *thread_map__new_by_uid(uid_t uid)
+{
+   return enumerate_threads(uid);
+}
+
+struct thread_map *thread_map__new_threads(void)
+{
+   return enumerate_threads(UINT_MAX);
+}
+
 struct thread_map *thread_map__new(pid_t pid, pid_t tid, uid_t uid)
 {
if (pid != -1)
@@ -313,7 +323,7 @@ struct thread_map *thread_map__new_by_tid_str(const char 
*tid_str)
 }
 
 struct thread_map *thread_map__new_str(const char *pid, const char *tid,
-  uid_t uid)
+  uid_t uid, bool per_thread)
 {
if (pid)
return thread_map__new_by_pid_str(pid);
@@ -321,6 +331,9 @@ struct thread_map *thread_map__new_str(const char *pid, 
const char *tid,
if (!tid && uid != UINT_MAX)
return thread_map__new_by_uid(uid);
 
+   if (per_thread)
+   return thread_map__new_threads();
+
return thread_map__new_by_tid_str(tid);
 }
 
diff --git a/tools/perf/util/thread_map.h b/tools/perf/util/thread_map.h
index f158039..dc07543 100644
--- a/tools/perf/util/thread_map.h
+++ b/tools/perf/util/thread_map.h
@@ -23,6 +23,7 @@ struct thread_map *thread_map__new_dummy(void);
 struct thread_map *thread_map__new_by_pid(pid_t pid);
 struct thread_map *thread_map__new_by_tid(pid_t tid);
 struct thread_map *thread_map__new_by_uid(uid_t uid);
+struct thread_map *thread_map__new_threads(void);
 struct thread_map *thread_map__new(pid_t pid, pid_t tid, uid_t uid);
 struct thread_map *thread_map__new_event(struct thread_map_event *event);
 
@@ -30,7 +31,7 @@ struct thread_map *thread_map__get(struct thread_map *map);
 void thread_map__put(struct thread_map *map);
 
 struct thread_map *thread_map__new_str(const char *pid,
-   const char *tid, uid_t uid);
+   const char *tid, uid_t uid, bool per_thread);
 
 struct thread_map *thread_map__new_by_tid_str(const char *tid_str);
 
-- 
2.7.4



[PATCH v1 1/9] perf util: Create rblist__reset() function

2017-11-19 Thread Jin Yao
Currently we have a rblist__delete() which is used to delete a rblist.
While rblist__delete() will free the pointer of rblist at the end.

It's inconvenience for user to delete a rblist which is not allocated
by something like malloc(). For example, the rblist is defined in a
data structure.

This patch creates a new function rblist__reset() which function is
similar as rblist__delete() but it will not free the rblist.

Signed-off-by: Jin Yao 
---
 tools/perf/util/rblist.c | 24 +---
 tools/perf/util/rblist.h |  1 +
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/rblist.c b/tools/perf/util/rblist.c
index 0dfe27d..eafa663 100644
--- a/tools/perf/util/rblist.c
+++ b/tools/perf/util/rblist.c
@@ -101,20 +101,30 @@ void rblist__init(struct rblist *rblist)
return;
 }
 
+static void remove_nodes(struct rblist *rblist)
+{
+   struct rb_node *pos, *next = rb_first(>entries);
+
+   while (next) {
+   pos = next;
+   next = rb_next(pos);
+   rblist__remove_node(rblist, pos);
+   }
+}
+
 void rblist__delete(struct rblist *rblist)
 {
if (rblist != NULL) {
-   struct rb_node *pos, *next = rb_first(>entries);
-
-   while (next) {
-   pos = next;
-   next = rb_next(pos);
-   rblist__remove_node(rblist, pos);
-   }
+   remove_nodes(rblist);
free(rblist);
}
 }
 
+void rblist__reset(struct rblist *rblist)
+{
+   remove_nodes(rblist);
+}
+
 struct rb_node *rblist__entry(const struct rblist *rblist, unsigned int idx)
 {
struct rb_node *node;
diff --git a/tools/perf/util/rblist.h b/tools/perf/util/rblist.h
index 4c8638a..048c285 100644
--- a/tools/perf/util/rblist.h
+++ b/tools/perf/util/rblist.h
@@ -35,6 +35,7 @@ void rblist__remove_node(struct rblist *rblist, struct 
rb_node *rb_node);
 struct rb_node *rblist__find(struct rblist *rblist, const void *entry);
 struct rb_node *rblist__findnew(struct rblist *rblist, const void *entry);
 struct rb_node *rblist__entry(const struct rblist *rblist, unsigned int idx);
+void rblist__reset(struct rblist *rblist);
 
 static inline bool rblist__empty(const struct rblist *rblist)
 {
-- 
2.7.4



[PATCH v1 4/9] perf util: Update and print per-thread shadow stats

2017-11-19 Thread Jin Yao
The functions perf_stat__update_shadow_stats() and
perf_stat__print_shadow_statss() are called to update
and print the shadow stats on a set of static variables.

But the static variables are the limitations to support
per-thread shadow stats.

This patch lets the perf_stat__update_shadow_stats() support
to update the shadow stats on a input parameter 'stat' and
uses update_runtime_stat() to update the stats. It will not
directly update the static variables as before.

And this patch also lets the perf_stat__print_shadow_stats()
support to print the shadow stats from a input parameter 'stat'.

It will not directly get value from static variable. Instead, it now
uses runtime_stat_avg() and runtime_stat_n() to get and compute the
values.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-stat.c |  25 ++--
 tools/perf/util/stat-shadow.c | 296 +++---
 tools/perf/util/stat.c|  15 ++-
 tools/perf/util/stat.h|   5 +-
 4 files changed, 222 insertions(+), 119 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 59af5a8..2ad5f4a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1151,7 +1151,8 @@ static void abs_printout(int id, int nr, struct 
perf_evsel *evsel, double avg)
 }
 
 static void printout(int id, int nr, struct perf_evsel *counter, double uval,
-char *prefix, u64 run, u64 ena, double noise)
+char *prefix, u64 run, u64 ena, double noise,
+struct runtime_stat *stat)
 {
struct perf_stat_output_ctx out;
struct outstate os = {
@@ -1244,7 +1245,8 @@ static void printout(int id, int nr, struct perf_evsel 
*counter, double uval,
 
perf_stat__print_shadow_stats(counter, uval,
first_shadow_cpu(counter, id),
-   , _events);
+   , _events,
+   stat);
if (!csv_output && !metric_only) {
print_noise(counter, noise);
print_running(run, ena);
@@ -1268,7 +1270,7 @@ static void aggr_update_shadow(void)
val += perf_counts(counter->counts, cpu, 
0)->val;
}
perf_stat__update_shadow_stats(counter, val,
-  
first_shadow_cpu(counter, id));
+   first_shadow_cpu(counter, id), NULL);
}
}
 }
@@ -1388,7 +1390,8 @@ static void print_aggr(char *prefix)
fprintf(output, "%s", prefix);
 
uval = val * counter->scale;
-   printout(id, nr, counter, uval, prefix, run, ena, 1.0);
+   printout(id, nr, counter, uval, prefix, run, ena, 1.0,
+NULL);
if (!metric_only)
fputc('\n', output);
}
@@ -1418,7 +1421,8 @@ static void print_aggr_thread(struct perf_evsel *counter, 
char *prefix)
fprintf(output, "%s", prefix);
 
uval = val * counter->scale;
-   printout(thread, 0, counter, uval, prefix, run, ena, 1.0);
+   printout(thread, 0, counter, uval, prefix, run, ena, 1.0,
+_config.stats[thread]);
fputc('\n', output);
}
 }
@@ -1455,7 +1459,8 @@ static void print_counter_aggr(struct perf_evsel 
*counter, char *prefix)
fprintf(output, "%s", prefix);
 
uval = cd.avg * counter->scale;
-   printout(-1, 0, counter, uval, prefix, cd.avg_running, cd.avg_enabled, 
cd.avg);
+   printout(-1, 0, counter, uval, prefix, cd.avg_running, cd.avg_enabled,
+cd.avg, NULL);
if (!metric_only)
fprintf(output, "\n");
 }
@@ -1494,7 +1499,7 @@ static void print_counter(struct perf_evsel *counter, 
char *prefix)
fprintf(output, "%s", prefix);
 
uval = val * counter->scale;
-   printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
+   printout(cpu, 0, counter, uval, prefix, run, ena, 1.0, NULL);
 
fputc('\n', output);
}
@@ -1526,7 +1531,8 @@ static void print_no_aggr_metric(char *prefix)
run = perf_counts(counter->counts, cpu, 0)->run;
 
uval = val * counter->scale;
-   printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
+   printout(cpu, 0, counter, uval, prefix, run, ena, 1.0,
+NULL);
}
fputc('\n', stat_config.output);
}
@@ -1582,7 +1588,8 @@ static void print_metric_headers(const char *prefix, bool 
no_indent)
perf_stat__print_shadow_stats(counter, 0,
   

[PATCH v1 6/9] perf stat: Allocate shadow stats buffer for threads

2017-11-19 Thread Jin Yao
After perf_evlist__create_maps() being executed, we can get all
threads from /proc. And via thread_map__nr(), we can also get
the number of threads.

With the number of threads, the patch allocates a buffer which
will record the shadow stats for these threads.

The buffer pointer is saved in stat_config.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-stat.c | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 2ad5f4a..9eec145 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -214,8 +214,13 @@ static inline void diff_timespec(struct timespec *r, 
struct timespec *a,
 
 static void perf_stat__reset_stats(void)
 {
+   int i;
+
perf_evlist__reset_stats(evsel_list);
perf_stat__reset_shadow_stats();
+
+   for (i = 0; i < stat_config.stat_num; i++)
+   perf_stat__reset_shadow_per_stat(_config.stats[i]);
 }
 
 static int create_perf_stat_counter(struct perf_evsel *evsel)
@@ -2548,6 +2553,35 @@ int process_cpu_map_event(struct perf_tool *tool,
return set_maps(st);
 }
 
+static int runtime_stat_alloc(struct perf_stat_config *config, int nthreads)
+{
+   int i;
+
+   config->stats = calloc(nthreads, sizeof(struct runtime_stat));
+   if (!config->stats)
+   return -1;
+
+   config->stat_num = nthreads;
+
+   for (i = 0; i < nthreads; i++)
+   perf_stat__init_runtime_stat(>stats[i]);
+
+   return 0;
+}
+
+static void runtime_stat_free(struct perf_stat_config *config)
+{
+   int i;
+
+   if (!config->stats)
+   return;
+
+   for (i = 0; i < config->stat_num; i++)
+   perf_stat__free_runtime_stat(>stats[i]);
+
+   free(config->stats);
+}
+
 static const char * const stat_report_usage[] = {
"perf stat report []",
NULL,
@@ -2803,8 +2837,15 @@ int cmd_stat(int argc, const char **argv)
 * Initialize thread_map with comm names,
 * so we could print it out on output.
 */
-   if (stat_config.aggr_mode == AGGR_THREAD)
+   if (stat_config.aggr_mode == AGGR_THREAD) {
thread_map__read_comms(evsel_list->threads);
+   if (target.system_wide) {
+   if (runtime_stat_alloc(_config,
+   thread_map__nr(evsel_list->threads))) {
+   goto out;
+   }
+   }
+   }
 
if (interval && interval < 100) {
if (interval < 10) {
@@ -2894,5 +2935,8 @@ int cmd_stat(int argc, const char **argv)
sysfs__write_int(FREEZE_ON_SMI_PATH, 0);
 
perf_evlist__delete(evsel_list);
+
+   runtime_stat_free(_config);
+
return status;
 }
-- 
2.7.4



[PATCH v1 7/9] perf util: Reuse thread_map__new_by_uid to enumerate threads from /proc

2017-11-19 Thread Jin Yao
Perf already has a function thread_map__new_by_uid() which can
enumerate all threads from /proc by uid.

This patch creates a static function enumerate_threads() which
reuses the common code in thread_map__new_by_uid() to enumerate
threads from /proc.

The enumerate_threads() is shared by thread_map__new_by_uid()
and a new function thread_map__new_threads().

The new function thread_map__new_threads() is called to enumerate
all threads from /proc.

Signed-off-by: Jin Yao 
---
 tools/perf/tests/thread-map.c |  2 +-
 tools/perf/util/evlist.c  |  3 ++-
 tools/perf/util/thread_map.c  | 19 ---
 tools/perf/util/thread_map.h  |  3 ++-
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/tools/perf/tests/thread-map.c b/tools/perf/tests/thread-map.c
index dbcb6a1..4de1939 100644
--- a/tools/perf/tests/thread-map.c
+++ b/tools/perf/tests/thread-map.c
@@ -105,7 +105,7 @@ int test__thread_map_remove(struct test *test 
__maybe_unused, int subtest __mayb
TEST_ASSERT_VAL("failed to allocate map string",
asprintf(, "%d,%d", getpid(), getppid()) >= 0);
 
-   threads = thread_map__new_str(str, NULL, 0);
+   threads = thread_map__new_str(str, NULL, 0, false);
 
TEST_ASSERT_VAL("failed to allocate thread_map",
threads);
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 199bb82..05b8f2b 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1102,7 +1102,8 @@ int perf_evlist__create_maps(struct perf_evlist *evlist, 
struct target *target)
struct cpu_map *cpus;
struct thread_map *threads;
 
-   threads = thread_map__new_str(target->pid, target->tid, target->uid);
+   threads = thread_map__new_str(target->pid, target->tid, target->uid,
+ target->per_thread);
 
if (!threads)
return -1;
diff --git a/tools/perf/util/thread_map.c b/tools/perf/util/thread_map.c
index be0d5a7..5672268 100644
--- a/tools/perf/util/thread_map.c
+++ b/tools/perf/util/thread_map.c
@@ -92,7 +92,7 @@ struct thread_map *thread_map__new_by_tid(pid_t tid)
return threads;
 }
 
-struct thread_map *thread_map__new_by_uid(uid_t uid)
+static struct thread_map *enumerate_threads(uid_t uid)
 {
DIR *proc;
int max_threads = 32, items, i;
@@ -124,7 +124,7 @@ struct thread_map *thread_map__new_by_uid(uid_t uid)
if (stat(path, ) != 0)
continue;
 
-   if (st.st_uid != uid)
+   if ((uid != UINT_MAX) && (st.st_uid != uid))
continue;
 
snprintf(path, sizeof(path), "/proc/%d/task", pid);
@@ -178,6 +178,16 @@ struct thread_map *thread_map__new_by_uid(uid_t uid)
goto out_closedir;
 }
 
+struct thread_map *thread_map__new_by_uid(uid_t uid)
+{
+   return enumerate_threads(uid);
+}
+
+struct thread_map *thread_map__new_threads(void)
+{
+   return enumerate_threads(UINT_MAX);
+}
+
 struct thread_map *thread_map__new(pid_t pid, pid_t tid, uid_t uid)
 {
if (pid != -1)
@@ -313,7 +323,7 @@ struct thread_map *thread_map__new_by_tid_str(const char 
*tid_str)
 }
 
 struct thread_map *thread_map__new_str(const char *pid, const char *tid,
-  uid_t uid)
+  uid_t uid, bool per_thread)
 {
if (pid)
return thread_map__new_by_pid_str(pid);
@@ -321,6 +331,9 @@ struct thread_map *thread_map__new_str(const char *pid, 
const char *tid,
if (!tid && uid != UINT_MAX)
return thread_map__new_by_uid(uid);
 
+   if (per_thread)
+   return thread_map__new_threads();
+
return thread_map__new_by_tid_str(tid);
 }
 
diff --git a/tools/perf/util/thread_map.h b/tools/perf/util/thread_map.h
index f158039..dc07543 100644
--- a/tools/perf/util/thread_map.h
+++ b/tools/perf/util/thread_map.h
@@ -23,6 +23,7 @@ struct thread_map *thread_map__new_dummy(void);
 struct thread_map *thread_map__new_by_pid(pid_t pid);
 struct thread_map *thread_map__new_by_tid(pid_t tid);
 struct thread_map *thread_map__new_by_uid(uid_t uid);
+struct thread_map *thread_map__new_threads(void);
 struct thread_map *thread_map__new(pid_t pid, pid_t tid, uid_t uid);
 struct thread_map *thread_map__new_event(struct thread_map_event *event);
 
@@ -30,7 +31,7 @@ struct thread_map *thread_map__get(struct thread_map *map);
 void thread_map__put(struct thread_map *map);
 
 struct thread_map *thread_map__new_str(const char *pid,
-   const char *tid, uid_t uid);
+   const char *tid, uid_t uid, bool per_thread);
 
 struct thread_map *thread_map__new_by_tid_str(const char *tid_str);
 
-- 
2.7.4



[PATCH v1 1/9] perf util: Create rblist__reset() function

2017-11-19 Thread Jin Yao
Currently we have a rblist__delete() which is used to delete a rblist.
While rblist__delete() will free the pointer of rblist at the end.

It's inconvenience for user to delete a rblist which is not allocated
by something like malloc(). For example, the rblist is defined in a
data structure.

This patch creates a new function rblist__reset() which function is
similar as rblist__delete() but it will not free the rblist.

Signed-off-by: Jin Yao 
---
 tools/perf/util/rblist.c | 24 +---
 tools/perf/util/rblist.h |  1 +
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/rblist.c b/tools/perf/util/rblist.c
index 0dfe27d..eafa663 100644
--- a/tools/perf/util/rblist.c
+++ b/tools/perf/util/rblist.c
@@ -101,20 +101,30 @@ void rblist__init(struct rblist *rblist)
return;
 }
 
+static void remove_nodes(struct rblist *rblist)
+{
+   struct rb_node *pos, *next = rb_first(>entries);
+
+   while (next) {
+   pos = next;
+   next = rb_next(pos);
+   rblist__remove_node(rblist, pos);
+   }
+}
+
 void rblist__delete(struct rblist *rblist)
 {
if (rblist != NULL) {
-   struct rb_node *pos, *next = rb_first(>entries);
-
-   while (next) {
-   pos = next;
-   next = rb_next(pos);
-   rblist__remove_node(rblist, pos);
-   }
+   remove_nodes(rblist);
free(rblist);
}
 }
 
+void rblist__reset(struct rblist *rblist)
+{
+   remove_nodes(rblist);
+}
+
 struct rb_node *rblist__entry(const struct rblist *rblist, unsigned int idx)
 {
struct rb_node *node;
diff --git a/tools/perf/util/rblist.h b/tools/perf/util/rblist.h
index 4c8638a..048c285 100644
--- a/tools/perf/util/rblist.h
+++ b/tools/perf/util/rblist.h
@@ -35,6 +35,7 @@ void rblist__remove_node(struct rblist *rblist, struct 
rb_node *rb_node);
 struct rb_node *rblist__find(struct rblist *rblist, const void *entry);
 struct rb_node *rblist__findnew(struct rblist *rblist, const void *entry);
 struct rb_node *rblist__entry(const struct rblist *rblist, unsigned int idx);
+void rblist__reset(struct rblist *rblist);
 
 static inline bool rblist__empty(const struct rblist *rblist)
 {
-- 
2.7.4



[PATCH v1 4/9] perf util: Update and print per-thread shadow stats

2017-11-19 Thread Jin Yao
The functions perf_stat__update_shadow_stats() and
perf_stat__print_shadow_statss() are called to update
and print the shadow stats on a set of static variables.

But the static variables are the limitations to support
per-thread shadow stats.

This patch lets the perf_stat__update_shadow_stats() support
to update the shadow stats on a input parameter 'stat' and
uses update_runtime_stat() to update the stats. It will not
directly update the static variables as before.

And this patch also lets the perf_stat__print_shadow_stats()
support to print the shadow stats from a input parameter 'stat'.

It will not directly get value from static variable. Instead, it now
uses runtime_stat_avg() and runtime_stat_n() to get and compute the
values.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-stat.c |  25 ++--
 tools/perf/util/stat-shadow.c | 296 +++---
 tools/perf/util/stat.c|  15 ++-
 tools/perf/util/stat.h|   5 +-
 4 files changed, 222 insertions(+), 119 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 59af5a8..2ad5f4a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1151,7 +1151,8 @@ static void abs_printout(int id, int nr, struct 
perf_evsel *evsel, double avg)
 }
 
 static void printout(int id, int nr, struct perf_evsel *counter, double uval,
-char *prefix, u64 run, u64 ena, double noise)
+char *prefix, u64 run, u64 ena, double noise,
+struct runtime_stat *stat)
 {
struct perf_stat_output_ctx out;
struct outstate os = {
@@ -1244,7 +1245,8 @@ static void printout(int id, int nr, struct perf_evsel 
*counter, double uval,
 
perf_stat__print_shadow_stats(counter, uval,
first_shadow_cpu(counter, id),
-   , _events);
+   , _events,
+   stat);
if (!csv_output && !metric_only) {
print_noise(counter, noise);
print_running(run, ena);
@@ -1268,7 +1270,7 @@ static void aggr_update_shadow(void)
val += perf_counts(counter->counts, cpu, 
0)->val;
}
perf_stat__update_shadow_stats(counter, val,
-  
first_shadow_cpu(counter, id));
+   first_shadow_cpu(counter, id), NULL);
}
}
 }
@@ -1388,7 +1390,8 @@ static void print_aggr(char *prefix)
fprintf(output, "%s", prefix);
 
uval = val * counter->scale;
-   printout(id, nr, counter, uval, prefix, run, ena, 1.0);
+   printout(id, nr, counter, uval, prefix, run, ena, 1.0,
+NULL);
if (!metric_only)
fputc('\n', output);
}
@@ -1418,7 +1421,8 @@ static void print_aggr_thread(struct perf_evsel *counter, 
char *prefix)
fprintf(output, "%s", prefix);
 
uval = val * counter->scale;
-   printout(thread, 0, counter, uval, prefix, run, ena, 1.0);
+   printout(thread, 0, counter, uval, prefix, run, ena, 1.0,
+_config.stats[thread]);
fputc('\n', output);
}
 }
@@ -1455,7 +1459,8 @@ static void print_counter_aggr(struct perf_evsel 
*counter, char *prefix)
fprintf(output, "%s", prefix);
 
uval = cd.avg * counter->scale;
-   printout(-1, 0, counter, uval, prefix, cd.avg_running, cd.avg_enabled, 
cd.avg);
+   printout(-1, 0, counter, uval, prefix, cd.avg_running, cd.avg_enabled,
+cd.avg, NULL);
if (!metric_only)
fprintf(output, "\n");
 }
@@ -1494,7 +1499,7 @@ static void print_counter(struct perf_evsel *counter, 
char *prefix)
fprintf(output, "%s", prefix);
 
uval = val * counter->scale;
-   printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
+   printout(cpu, 0, counter, uval, prefix, run, ena, 1.0, NULL);
 
fputc('\n', output);
}
@@ -1526,7 +1531,8 @@ static void print_no_aggr_metric(char *prefix)
run = perf_counts(counter->counts, cpu, 0)->run;
 
uval = val * counter->scale;
-   printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
+   printout(cpu, 0, counter, uval, prefix, run, ena, 1.0,
+NULL);
}
fputc('\n', stat_config.output);
}
@@ -1582,7 +1588,8 @@ static void print_metric_headers(const char *prefix, bool 
no_indent)
perf_stat__print_shadow_stats(counter, 0,
  0,
   

[PATCH v1 6/9] perf stat: Allocate shadow stats buffer for threads

2017-11-19 Thread Jin Yao
After perf_evlist__create_maps() being executed, we can get all
threads from /proc. And via thread_map__nr(), we can also get
the number of threads.

With the number of threads, the patch allocates a buffer which
will record the shadow stats for these threads.

The buffer pointer is saved in stat_config.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-stat.c | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 2ad5f4a..9eec145 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -214,8 +214,13 @@ static inline void diff_timespec(struct timespec *r, 
struct timespec *a,
 
 static void perf_stat__reset_stats(void)
 {
+   int i;
+
perf_evlist__reset_stats(evsel_list);
perf_stat__reset_shadow_stats();
+
+   for (i = 0; i < stat_config.stat_num; i++)
+   perf_stat__reset_shadow_per_stat(_config.stats[i]);
 }
 
 static int create_perf_stat_counter(struct perf_evsel *evsel)
@@ -2548,6 +2553,35 @@ int process_cpu_map_event(struct perf_tool *tool,
return set_maps(st);
 }
 
+static int runtime_stat_alloc(struct perf_stat_config *config, int nthreads)
+{
+   int i;
+
+   config->stats = calloc(nthreads, sizeof(struct runtime_stat));
+   if (!config->stats)
+   return -1;
+
+   config->stat_num = nthreads;
+
+   for (i = 0; i < nthreads; i++)
+   perf_stat__init_runtime_stat(>stats[i]);
+
+   return 0;
+}
+
+static void runtime_stat_free(struct perf_stat_config *config)
+{
+   int i;
+
+   if (!config->stats)
+   return;
+
+   for (i = 0; i < config->stat_num; i++)
+   perf_stat__free_runtime_stat(>stats[i]);
+
+   free(config->stats);
+}
+
 static const char * const stat_report_usage[] = {
"perf stat report []",
NULL,
@@ -2803,8 +2837,15 @@ int cmd_stat(int argc, const char **argv)
 * Initialize thread_map with comm names,
 * so we could print it out on output.
 */
-   if (stat_config.aggr_mode == AGGR_THREAD)
+   if (stat_config.aggr_mode == AGGR_THREAD) {
thread_map__read_comms(evsel_list->threads);
+   if (target.system_wide) {
+   if (runtime_stat_alloc(_config,
+   thread_map__nr(evsel_list->threads))) {
+   goto out;
+   }
+   }
+   }
 
if (interval && interval < 100) {
if (interval < 10) {
@@ -2894,5 +2935,8 @@ int cmd_stat(int argc, const char **argv)
sysfs__write_int(FREEZE_ON_SMI_PATH, 0);
 
perf_evlist__delete(evsel_list);
+
+   runtime_stat_free(_config);
+
return status;
 }
-- 
2.7.4



[PATCH v1 0/9] perf stat: Enable '--per-thread' on all threads

2017-11-19 Thread Jin Yao
perf stat --per-thread is useful to break down data per thread.
But it currently requires specifying --pid/--tid to limit it to a process.

For analysis it would be useful to do it globally for the whole system.

1. Currently, if we perform 'perf stat --per-thread' without pid/tid,
perf returns error:

root@skl:/tmp# perf stat --per-thread
The --per-thread option is only available when monitoring via -p -t options.
-p, --pidstat events on existing process id
-t, --tidstat events on existing thread id

2. With this patch series, it returns data per thread with shadow metrics.
   (run "vmstat 1" in following example)

root@skl:/tmp# perf stat --per-thread
^C
 Performance counter stats for 'system wide':

perf-24165  4.302433  cpu-clock (msec)  
#0.001 CPUs utilized
  vmstat-23127  1.562215  cpu-clock (msec)  
#0.000 CPUs utilized
  irqbalance-2780   0.827851  cpu-clock (msec)  
#0.000 CPUs utilized
sshd-23111  0.278308  cpu-clock (msec)  
#0.000 CPUs utilized
thermald-2841   0.230880  cpu-clock (msec)  
#0.000 CPUs utilized
sshd-23058  0.207306  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/0:2-19991  0.133983  cpu-clock (msec)  
#0.000 CPUs utilized
   kworker/u16:1-18249  0.125636  cpu-clock (msec)  
#0.000 CPUs utilized
   rcu_sched-8  0.085533  cpu-clock (msec)  
#0.000 CPUs utilized
   kworker/u16:2-23146  0.077139  cpu-clock (msec)  
#0.000 CPUs utilized
   gmain-2700   0.041789  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/4:1-15354  0.028370  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/6:0-17528  0.023895  cpu-clock (msec)  
#0.000 CPUs utilized
kworker/4:1H-1887   0.013209  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/5:2-31362  0.011627  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/0-11 0.010892  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/3:2-12870  0.010220  cpu-clock (msec)  
#0.000 CPUs utilized
 ksoftirqd/0-7  0.008869  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/1-14 0.008476  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/7-50 0.002944  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/3-26 0.002893  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/4-32 0.002759  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/2-20 0.002429  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/6-44 0.001491  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/5-38 0.001477  cpu-clock (msec)  
#0.000 CPUs utilized
   rcu_sched-810  context-switches  
#0.117 M/sec
   kworker/u16:1-18249 7  context-switches  
#0.056 M/sec
sshd-23111 4  context-switches  
#0.014 M/sec
  vmstat-23127 4  context-switches  
#0.003 M/sec
perf-24165 4  context-switches  
#0.930 K/sec
 kworker/0:2-19991 3  context-switches  
#0.022 M/sec
   kworker/u16:2-23146 3  context-switches  
#0.039 M/sec
 kworker/4:1-15354 2  context-switches  
#0.070 M/sec
 kworker/6:0-17528 2  context-switches  
#0.084 M/sec
sshd-23058 2  context-switches  
#0.010 M/sec
 ksoftirqd/0-7 1  context-switches  
#0.113 M/sec
  watchdog/0-111  context-switches  
#0.092 M/sec
  watchdog/1-141  context-switches  
#0.118 M/sec
  watchdog/2-201  context-switches  
#0.412 M/sec
  watchdog/3-261  context-switches  
#0.346 M/sec
  watchdog/4-321  context-switches  
#0.362 M/sec
  watchdog/5-38  

[PATCH v1 0/9] perf stat: Enable '--per-thread' on all threads

2017-11-19 Thread Jin Yao
perf stat --per-thread is useful to break down data per thread.
But it currently requires specifying --pid/--tid to limit it to a process.

For analysis it would be useful to do it globally for the whole system.

1. Currently, if we perform 'perf stat --per-thread' without pid/tid,
perf returns error:

root@skl:/tmp# perf stat --per-thread
The --per-thread option is only available when monitoring via -p -t options.
-p, --pidstat events on existing process id
-t, --tidstat events on existing thread id

2. With this patch series, it returns data per thread with shadow metrics.
   (run "vmstat 1" in following example)

root@skl:/tmp# perf stat --per-thread
^C
 Performance counter stats for 'system wide':

perf-24165  4.302433  cpu-clock (msec)  
#0.001 CPUs utilized
  vmstat-23127  1.562215  cpu-clock (msec)  
#0.000 CPUs utilized
  irqbalance-2780   0.827851  cpu-clock (msec)  
#0.000 CPUs utilized
sshd-23111  0.278308  cpu-clock (msec)  
#0.000 CPUs utilized
thermald-2841   0.230880  cpu-clock (msec)  
#0.000 CPUs utilized
sshd-23058  0.207306  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/0:2-19991  0.133983  cpu-clock (msec)  
#0.000 CPUs utilized
   kworker/u16:1-18249  0.125636  cpu-clock (msec)  
#0.000 CPUs utilized
   rcu_sched-8  0.085533  cpu-clock (msec)  
#0.000 CPUs utilized
   kworker/u16:2-23146  0.077139  cpu-clock (msec)  
#0.000 CPUs utilized
   gmain-2700   0.041789  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/4:1-15354  0.028370  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/6:0-17528  0.023895  cpu-clock (msec)  
#0.000 CPUs utilized
kworker/4:1H-1887   0.013209  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/5:2-31362  0.011627  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/0-11 0.010892  cpu-clock (msec)  
#0.000 CPUs utilized
 kworker/3:2-12870  0.010220  cpu-clock (msec)  
#0.000 CPUs utilized
 ksoftirqd/0-7  0.008869  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/1-14 0.008476  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/7-50 0.002944  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/3-26 0.002893  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/4-32 0.002759  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/2-20 0.002429  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/6-44 0.001491  cpu-clock (msec)  
#0.000 CPUs utilized
  watchdog/5-38 0.001477  cpu-clock (msec)  
#0.000 CPUs utilized
   rcu_sched-810  context-switches  
#0.117 M/sec
   kworker/u16:1-18249 7  context-switches  
#0.056 M/sec
sshd-23111 4  context-switches  
#0.014 M/sec
  vmstat-23127 4  context-switches  
#0.003 M/sec
perf-24165 4  context-switches  
#0.930 K/sec
 kworker/0:2-19991 3  context-switches  
#0.022 M/sec
   kworker/u16:2-23146 3  context-switches  
#0.039 M/sec
 kworker/4:1-15354 2  context-switches  
#0.070 M/sec
 kworker/6:0-17528 2  context-switches  
#0.084 M/sec
sshd-23058 2  context-switches  
#0.010 M/sec
 ksoftirqd/0-7 1  context-switches  
#0.113 M/sec
  watchdog/0-111  context-switches  
#0.092 M/sec
  watchdog/1-141  context-switches  
#0.118 M/sec
  watchdog/2-201  context-switches  
#0.412 M/sec
  watchdog/3-261  context-switches  
#0.346 M/sec
  watchdog/4-321  context-switches  
#0.362 M/sec
  watchdog/5-38  

Re: [PATCH v7 04/13] slimbus: core: Add slim controllers support

2017-11-19 Thread Srinivas Kandagatla



On 17/11/17 08:13, Greg KH wrote:

On Fri, Nov 17, 2017 at 10:12:22AM +0530, Vinod Koul wrote:

On Thu, Nov 16, 2017 at 05:29:35PM +, Srinivas Kandagatla wrote:

thanks for the comments.


On 16/11/17 16:42, Vinod Koul wrote:

On Wed, Nov 15, 2017 at 02:10:34PM +,srinivas.kandaga...@linaro.org  wrote:


+static void slim_dev_release(struct device *dev)
+{
+   struct slim_device *sbdev = to_slim_device(dev);
+
+   put_device(sbdev->ctrl->dev);

which device would that be?

This is controller device


+static int slim_add_device(struct slim_controller *ctrl,
+  struct slim_device *sbdev,
+  struct device_node *node)
+{
+   sbdev->dev.bus = _bus;
+   sbdev->dev.parent = ctrl->dev;
+   sbdev->dev.release = slim_dev_release;
+   sbdev->dev.driver = NULL;
+   sbdev->ctrl = ctrl;
+
+   dev_set_name(>dev, "%x:%x:%x:%x",
+ sbdev->e_addr.manf_id,
+ sbdev->e_addr.prod_code,
+ sbdev->e_addr.dev_index,
+ sbdev->e_addr.instance);
+
+   get_device(ctrl->dev);

is this controller device and you ensuring it doesnt go away while you have
slaves on it?

Yes.

I thought since you are marking ctrl->dev as parent, the device core should
ensure that parent doesn't go off when you have child device?

Greg, is that understanding correct, if so we may not need these calls.

That understanding should be correct, as the reference count is
incremented on the parent when a child is added.

It would be trivial for this to be tested, and yes, I am pretty sure you
don't need this call.



Thanks for suggestion, I will remove this in next version.


thanks,
srini


Re: [PATCH v7 04/13] slimbus: core: Add slim controllers support

2017-11-19 Thread Srinivas Kandagatla



On 17/11/17 08:13, Greg KH wrote:

On Fri, Nov 17, 2017 at 10:12:22AM +0530, Vinod Koul wrote:

On Thu, Nov 16, 2017 at 05:29:35PM +, Srinivas Kandagatla wrote:

thanks for the comments.


On 16/11/17 16:42, Vinod Koul wrote:

On Wed, Nov 15, 2017 at 02:10:34PM +,srinivas.kandaga...@linaro.org  wrote:


+static void slim_dev_release(struct device *dev)
+{
+   struct slim_device *sbdev = to_slim_device(dev);
+
+   put_device(sbdev->ctrl->dev);

which device would that be?

This is controller device


+static int slim_add_device(struct slim_controller *ctrl,
+  struct slim_device *sbdev,
+  struct device_node *node)
+{
+   sbdev->dev.bus = _bus;
+   sbdev->dev.parent = ctrl->dev;
+   sbdev->dev.release = slim_dev_release;
+   sbdev->dev.driver = NULL;
+   sbdev->ctrl = ctrl;
+
+   dev_set_name(>dev, "%x:%x:%x:%x",
+ sbdev->e_addr.manf_id,
+ sbdev->e_addr.prod_code,
+ sbdev->e_addr.dev_index,
+ sbdev->e_addr.instance);
+
+   get_device(ctrl->dev);

is this controller device and you ensuring it doesnt go away while you have
slaves on it?

Yes.

I thought since you are marking ctrl->dev as parent, the device core should
ensure that parent doesn't go off when you have child device?

Greg, is that understanding correct, if so we may not need these calls.

That understanding should be correct, as the reference count is
incremented on the parent when a child is added.

It would be trivial for this to be tested, and yes, I am pretty sure you
don't need this call.



Thanks for suggestion, I will remove this in next version.


thanks,
srini


Re: [PATCH v7 06/13] slimbus: Add messaging APIs to slimbus framework

2017-11-19 Thread Srinivas Kandagatla

thanks for the comments,

On 17/11/17 07:48, Vinod Koul wrote:

On Wed, Nov 15, 2017 at 02:10:36PM +, srinivas.kandaga...@linaro.org wrote:


+void slim_msg_response(struct slim_controller *ctrl, u8 *reply, u8 tid, u8 len)
+{
+   struct slim_msg_txn *txn;
+   struct slim_val_inf *msg;
+   unsigned long flags;
+
+   spin_lock_irqsave(>txn_lock, flags);


Do you need this to be a _irqsave variant? What is the context of io
transfers in this case
Yes, On Qcom controller driver it is called in Interrupt context, but it 
depends on caller (controller driver) which could be in process context too.





+/**
+ * slim_do_transfer() - Process a slimbus-messaging transaction
+ *
+ * @ctrl: Controller handle
+ * @txn: Transaction to be sent over SLIMbus
+ *
+ * Called by controller to transmit messaging transactions not dealing with
+ * Interface/Value elements. (e.g. transmittting a message to assign logical
+ * address to a slave device
+ *
+ * Return: -ETIMEDOUT: If transmission of this message timed out
+ * (e.g. due to bus lines not being clocked or driven by controller)
+ * -ENOTCONN: If the transmitted message was not ACKed by destination
+ * device.


I am preferring ENODATA in SDW for this case, as Slaves didnt respond or
ACK.

Isn't that a timeout error then.

ENODATA is for "No data available", reporting ENODATA would be misleading.



ENOTCONN is defined as /* Transport endpoint is not connected */ which is
not the case here, connected yes but not responded.


Code as it is would not return this, so i will be deleting ENOTCONN from 
kernel doc.





+static int slim_val_inf_sanity(struct slim_controller *ctrl,
+  struct slim_val_inf *msg, u8 mc)
+{
+   if (!msg || msg->num_bytes > 16 ||
+   (msg->start_offset + msg->num_bytes) > 0xC00)
+   goto reterr;
+   switch (mc) {
+   case SLIM_MSG_MC_REQUEST_VALUE:
+   case SLIM_MSG_MC_REQUEST_INFORMATION:
+   if (msg->rbuf != NULL)
+   return 0;
+   break;


empty line here and after each break make it look better

Yep, will remove this in next version.



+   case SLIM_MSG_MC_CHANGE_VALUE:
+   case SLIM_MSG_MC_CLEAR_INFORMATION:
+   if (msg->wbuf != NULL)
+   return 0;
+   break;
+   case SLIM_MSG_MC_REQUEST_CHANGE_VALUE:
+   case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
+   if (msg->rbuf != NULL && msg->wbuf != NULL)
+   return 0;
+   break;
+   default:
+   break;


this seems superflous and we can just fall thru to error below.


Agree..
will fix it in next version.

+   }
+reterr:
+   dev_err(ctrl->dev, "Sanity check failed:msg:offset:0x%x, mc:%d\n",
+   msg->start_offset, mc);
+   return -EINVAL;


...


+static int slim_xfer_msg(struct slim_controller *ctrl,
+struct slim_device *sbdev,
+struct slim_val_inf *msg, u8 mc)
+{
+   DEFINE_SLIM_LDEST_TXN(txn_stack, mc, 6, sbdev->laddr, msg);
+   struct slim_msg_txn *txn = _stack;
+   int ret;
+   u16 sl;
+
+   ret = slim_val_inf_sanity(ctrl, msg, mc);
+   if (ret)
+   return ret;
+
+   sl = slim_slicesize(msg->num_bytes);
+
+   dev_dbg(ctrl->dev, "SB xfer msg:os:%x, len:%d, MC:%x, sl:%x\n",
+   msg->start_offset, msg->num_bytes, mc, sl);


better to add tracing support for these debug prints


Will explore tracing side of it..

+
+   txn->ec = ((sl | (1 << 3)) | ((msg->start_offset & 0xFFF) << 4));
+
+   switch (mc) {
+   case SLIM_MSG_MC_REQUEST_CHANGE_VALUE:
+   case SLIM_MSG_MC_CHANGE_VALUE:
+   case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
+int slim_request_change_val_element(struct slim_device *sb,
+   struct slim_val_inf *msg)
+{
+   struct slim_controller *ctrl = sb->ctrl;
+
+   if (!ctrl)
+   return -EINVAL;
+
+   return slim_xfer_msg(ctrl, sb, msg, SLIM_MSG_MC_REQUEST_CHANGE_VALUE);
+}
+EXPORT_SYMBOL_GPL(slim_request_change_val_element);


looking at this, does it really help to have different APIs for SLIM_MSG_XXX
why not slim_xfer_msg() be an exported one..


I did think about this cleanup, and it makes sense.

I will have a go at removing this and just leaving slim_readb/writeb() 
slim_read/write() and slim_xfer_msg() API's in next version.


We can discuss to add this in future incase its required.





+int slim_write(struct slim_device *sdev, u32 addr, size_t count, u8 *val)
+{
+   struct slim_val_inf msg;
+   int ret;
+
+   slim_fill_msg(, addr, count,  val, NULL);
+   ret = slim_change_val_element(sdev, );


return slim_change_val_element()

Makes sense.




+
+   return ret;
+
+}


...


+/* Destination type Values */
+#define SLIM_MSG_DEST_LOGICALADDR  0
+#define SLIM_MSG_DEST_ENUMADDR 1
+#define

Re: [PATCH v7 06/13] slimbus: Add messaging APIs to slimbus framework

2017-11-19 Thread Srinivas Kandagatla

thanks for the comments,

On 17/11/17 07:48, Vinod Koul wrote:

On Wed, Nov 15, 2017 at 02:10:36PM +, srinivas.kandaga...@linaro.org wrote:


+void slim_msg_response(struct slim_controller *ctrl, u8 *reply, u8 tid, u8 len)
+{
+   struct slim_msg_txn *txn;
+   struct slim_val_inf *msg;
+   unsigned long flags;
+
+   spin_lock_irqsave(>txn_lock, flags);


Do you need this to be a _irqsave variant? What is the context of io
transfers in this case
Yes, On Qcom controller driver it is called in Interrupt context, but it 
depends on caller (controller driver) which could be in process context too.





+/**
+ * slim_do_transfer() - Process a slimbus-messaging transaction
+ *
+ * @ctrl: Controller handle
+ * @txn: Transaction to be sent over SLIMbus
+ *
+ * Called by controller to transmit messaging transactions not dealing with
+ * Interface/Value elements. (e.g. transmittting a message to assign logical
+ * address to a slave device
+ *
+ * Return: -ETIMEDOUT: If transmission of this message timed out
+ * (e.g. due to bus lines not being clocked or driven by controller)
+ * -ENOTCONN: If the transmitted message was not ACKed by destination
+ * device.


I am preferring ENODATA in SDW for this case, as Slaves didnt respond or
ACK.

Isn't that a timeout error then.

ENODATA is for "No data available", reporting ENODATA would be misleading.



ENOTCONN is defined as /* Transport endpoint is not connected */ which is
not the case here, connected yes but not responded.


Code as it is would not return this, so i will be deleting ENOTCONN from 
kernel doc.





+static int slim_val_inf_sanity(struct slim_controller *ctrl,
+  struct slim_val_inf *msg, u8 mc)
+{
+   if (!msg || msg->num_bytes > 16 ||
+   (msg->start_offset + msg->num_bytes) > 0xC00)
+   goto reterr;
+   switch (mc) {
+   case SLIM_MSG_MC_REQUEST_VALUE:
+   case SLIM_MSG_MC_REQUEST_INFORMATION:
+   if (msg->rbuf != NULL)
+   return 0;
+   break;


empty line here and after each break make it look better

Yep, will remove this in next version.



+   case SLIM_MSG_MC_CHANGE_VALUE:
+   case SLIM_MSG_MC_CLEAR_INFORMATION:
+   if (msg->wbuf != NULL)
+   return 0;
+   break;
+   case SLIM_MSG_MC_REQUEST_CHANGE_VALUE:
+   case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
+   if (msg->rbuf != NULL && msg->wbuf != NULL)
+   return 0;
+   break;
+   default:
+   break;


this seems superflous and we can just fall thru to error below.


Agree..
will fix it in next version.

+   }
+reterr:
+   dev_err(ctrl->dev, "Sanity check failed:msg:offset:0x%x, mc:%d\n",
+   msg->start_offset, mc);
+   return -EINVAL;


...


+static int slim_xfer_msg(struct slim_controller *ctrl,
+struct slim_device *sbdev,
+struct slim_val_inf *msg, u8 mc)
+{
+   DEFINE_SLIM_LDEST_TXN(txn_stack, mc, 6, sbdev->laddr, msg);
+   struct slim_msg_txn *txn = _stack;
+   int ret;
+   u16 sl;
+
+   ret = slim_val_inf_sanity(ctrl, msg, mc);
+   if (ret)
+   return ret;
+
+   sl = slim_slicesize(msg->num_bytes);
+
+   dev_dbg(ctrl->dev, "SB xfer msg:os:%x, len:%d, MC:%x, sl:%x\n",
+   msg->start_offset, msg->num_bytes, mc, sl);


better to add tracing support for these debug prints


Will explore tracing side of it..

+
+   txn->ec = ((sl | (1 << 3)) | ((msg->start_offset & 0xFFF) << 4));
+
+   switch (mc) {
+   case SLIM_MSG_MC_REQUEST_CHANGE_VALUE:
+   case SLIM_MSG_MC_CHANGE_VALUE:
+   case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
+int slim_request_change_val_element(struct slim_device *sb,
+   struct slim_val_inf *msg)
+{
+   struct slim_controller *ctrl = sb->ctrl;
+
+   if (!ctrl)
+   return -EINVAL;
+
+   return slim_xfer_msg(ctrl, sb, msg, SLIM_MSG_MC_REQUEST_CHANGE_VALUE);
+}
+EXPORT_SYMBOL_GPL(slim_request_change_val_element);


looking at this, does it really help to have different APIs for SLIM_MSG_XXX
why not slim_xfer_msg() be an exported one..


I did think about this cleanup, and it makes sense.

I will have a go at removing this and just leaving slim_readb/writeb() 
slim_read/write() and slim_xfer_msg() API's in next version.


We can discuss to add this in future incase its required.





+int slim_write(struct slim_device *sdev, u32 addr, size_t count, u8 *val)
+{
+   struct slim_val_inf msg;
+   int ret;
+
+   slim_fill_msg(, addr, count,  val, NULL);
+   ret = slim_change_val_element(sdev, );


return slim_change_val_element()

Makes sense.




+
+   return ret;
+
+}


...


+/* Destination type Values */
+#define SLIM_MSG_DEST_LOGICALADDR  0
+#define SLIM_MSG_DEST_ENUMADDR 1
+#define

Re: [PATCH 4/6 v3] mmc: sdhci-spear: Handle return value of platform_get_irq

2017-11-19 Thread Viresh Kumar
On 19-11-17, 10:22, Arvind Yadav wrote:
> platform_get_irq() can fail here and we must check its return value.
> 
> Signed-off-by: Arvind Yadav 
> ---
> changes in v2 :
>   Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
>   return -EINVAL instead of host->irq.
> 
>  drivers/mmc/host/sdhci-spear.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
> index 8c0f884..e04485e 100644
> --- a/drivers/mmc/host/sdhci-spear.c
> +++ b/drivers/mmc/host/sdhci-spear.c
> @@ -82,6 +82,10 @@ static int sdhci_probe(struct platform_device *pdev)
>   host->hw_name = "sdhci";
>   host->ops = _pltfm_ops;
>   host->irq = platform_get_irq(pdev, 0);
> + if (host->irq <= 0) {
> + ret = -EINVAL;
> + goto err_host;
> + }
>   host->quirks = SDHCI_QUIRK_BROKEN_ADMA;
>  
>   sdhci = sdhci_priv(host);

Hope this is the last one to Ack :)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH 4/6 v3] mmc: sdhci-spear: Handle return value of platform_get_irq

2017-11-19 Thread Viresh Kumar
On 19-11-17, 10:22, Arvind Yadav wrote:
> platform_get_irq() can fail here and we must check its return value.
> 
> Signed-off-by: Arvind Yadav 
> ---
> changes in v2 :
>   Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
>   return -EINVAL instead of host->irq.
> 
>  drivers/mmc/host/sdhci-spear.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
> index 8c0f884..e04485e 100644
> --- a/drivers/mmc/host/sdhci-spear.c
> +++ b/drivers/mmc/host/sdhci-spear.c
> @@ -82,6 +82,10 @@ static int sdhci_probe(struct platform_device *pdev)
>   host->hw_name = "sdhci";
>   host->ops = _pltfm_ops;
>   host->irq = platform_get_irq(pdev, 0);
> + if (host->irq <= 0) {
> + ret = -EINVAL;
> + goto err_host;
> + }
>   host->quirks = SDHCI_QUIRK_BROKEN_ADMA;
>  
>   sdhci = sdhci_priv(host);

Hope this is the last one to Ack :)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH 4/6 v2] mmc: sdhci-spear: Handle return value of platform_get_irq

2017-11-19 Thread Arvind Yadav

Hi viresh,

Could you please acknowledge a latest version(v3) of this patch.

Thanks,


On Monday 20 November 2017 11:14 AM, Viresh Kumar wrote:

On 18-11-17, 15:03, Arvind Yadav wrote:

platform_get_irq() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
changes in v2 :
   Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.

  drivers/mmc/host/sdhci-spear.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
index 8c0f884..900838b 100644
--- a/drivers/mmc/host/sdhci-spear.c
+++ b/drivers/mmc/host/sdhci-spear.c
@@ -82,6 +82,10 @@ static int sdhci_probe(struct platform_device *pdev)
host->hw_name = "sdhci";
host->ops = _pltfm_ops;
host->irq = platform_get_irq(pdev, 0);
+   if (host->irq <= 0) {
+   ret = host->irq;
+   goto err_host;
+   }
host->quirks = SDHCI_QUIRK_BROKEN_ADMA;
  
  	sdhci = sdhci_priv(host);

Acked-by: Viresh Kumar 





Re: [PATCH 4/6 v2] mmc: sdhci-spear: Handle return value of platform_get_irq

2017-11-19 Thread Arvind Yadav

Hi viresh,

Could you please acknowledge a latest version(v3) of this patch.

Thanks,


On Monday 20 November 2017 11:14 AM, Viresh Kumar wrote:

On 18-11-17, 15:03, Arvind Yadav wrote:

platform_get_irq() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
changes in v2 :
   Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.

  drivers/mmc/host/sdhci-spear.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
index 8c0f884..900838b 100644
--- a/drivers/mmc/host/sdhci-spear.c
+++ b/drivers/mmc/host/sdhci-spear.c
@@ -82,6 +82,10 @@ static int sdhci_probe(struct platform_device *pdev)
host->hw_name = "sdhci";
host->ops = _pltfm_ops;
host->irq = platform_get_irq(pdev, 0);
+   if (host->irq <= 0) {
+   ret = host->irq;
+   goto err_host;
+   }
host->quirks = SDHCI_QUIRK_BROKEN_ADMA;
  
  	sdhci = sdhci_priv(host);

Acked-by: Viresh Kumar 





Re: [PATCH 4/6] mmc: sdhci-spear: Handle return value of platform_get_irq

2017-11-19 Thread Arvind Yadav

Hi viresh,

Could you please acknowledge a latest version of this patch.

Thanks,


On Monday 20 November 2017 11:13 AM, Viresh Kumar wrote:

On 18-11-17, 01:58, Arvind Yadav wrote:

platform_get_irq() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
  drivers/mmc/host/sdhci-spear.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
index 8c0f884..900838b 100644
--- a/drivers/mmc/host/sdhci-spear.c
+++ b/drivers/mmc/host/sdhci-spear.c
@@ -82,6 +82,10 @@ static int sdhci_probe(struct platform_device *pdev)
host->hw_name = "sdhci";
host->ops = _pltfm_ops;
host->irq = platform_get_irq(pdev, 0);
+   if (host->irq < 0) {
+   ret = host->irq;
+   goto err_host;
+   }
host->quirks = SDHCI_QUIRK_BROKEN_ADMA;
  
  	sdhci = sdhci_priv(host);

Acked-by: Viresh Kumar 





Re: [PATCH 4/6] mmc: sdhci-spear: Handle return value of platform_get_irq

2017-11-19 Thread Arvind Yadav

Hi viresh,

Could you please acknowledge a latest version of this patch.

Thanks,


On Monday 20 November 2017 11:13 AM, Viresh Kumar wrote:

On 18-11-17, 01:58, Arvind Yadav wrote:

platform_get_irq() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
  drivers/mmc/host/sdhci-spear.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
index 8c0f884..900838b 100644
--- a/drivers/mmc/host/sdhci-spear.c
+++ b/drivers/mmc/host/sdhci-spear.c
@@ -82,6 +82,10 @@ static int sdhci_probe(struct platform_device *pdev)
host->hw_name = "sdhci";
host->ops = _pltfm_ops;
host->irq = platform_get_irq(pdev, 0);
+   if (host->irq < 0) {
+   ret = host->irq;
+   goto err_host;
+   }
host->quirks = SDHCI_QUIRK_BROKEN_ADMA;
  
  	sdhci = sdhci_priv(host);

Acked-by: Viresh Kumar 





[PATCH v2] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

2017-11-19 Thread Jesse Chan
Signed-off-by: Jesse Chan 
---
Change in v2:
- fix a mistake

 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
index 46768c056193..0c28d0b995cc 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
@@ -115,3 +115,6 @@ struct mtk_vcodec_ctx *mtk_vcodec_get_curr_ctx(struct 
mtk_vcodec_dev *dev)
return ctx;
 }
 EXPORT_SYMBOL(mtk_vcodec_get_curr_ctx);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Mediatek video codec driver");
-- 
2.14.1



[PATCH v2] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

2017-11-19 Thread Jesse Chan
Signed-off-by: Jesse Chan 
---
Change in v2:
- fix a mistake

 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
index 46768c056193..0c28d0b995cc 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
@@ -115,3 +115,6 @@ struct mtk_vcodec_ctx *mtk_vcodec_get_curr_ctx(struct 
mtk_vcodec_dev *dev)
return ctx;
 }
 EXPORT_SYMBOL(mtk_vcodec_get_curr_ctx);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Mediatek video codec driver");
-- 
2.14.1



Re: [GIT PULL] NTB bug fixes for v4.15

2017-11-19 Thread Linus Torvalds
On Sun, Nov 19, 2017 at 8:25 PM, Logan Gunthorpe  wrote:
>
>
> On 19/11/17 11:12 AM, Linus Torvalds wrote:
>> I am now traveling, and am not inclined to pull stuff that hasn't been
>> in linux-next unless it's just obviously bug-fixes.
>
> Sigh. This work has been held up for two cycles due to issues with the
> process.
>
> If it's of any consideration, my Switchtec NTB patches were in one of my
> repos which is subscribed to the kbuild test robot. I did receive a
> build success notification email on it a few months ago. It's also an
> isolated driver which shouldn't have any effect on any other systems.

Gaah. I guess I can take the pull request.

I do want to protest the timing and the lack of linux-next coverage.
If it has really been ready for months, why hasn't it been in
linux-next at all?

 Linus


Re: [GIT PULL] NTB bug fixes for v4.15

2017-11-19 Thread Linus Torvalds
On Sun, Nov 19, 2017 at 8:25 PM, Logan Gunthorpe  wrote:
>
>
> On 19/11/17 11:12 AM, Linus Torvalds wrote:
>> I am now traveling, and am not inclined to pull stuff that hasn't been
>> in linux-next unless it's just obviously bug-fixes.
>
> Sigh. This work has been held up for two cycles due to issues with the
> process.
>
> If it's of any consideration, my Switchtec NTB patches were in one of my
> repos which is subscribed to the kbuild test robot. I did receive a
> build success notification email on it a few months ago. It's also an
> isolated driver which shouldn't have any effect on any other systems.

Gaah. I guess I can take the pull request.

I do want to protest the timing and the lack of linux-next coverage.
If it has really been ready for months, why hasn't it been in
linux-next at all?

 Linus


Re: [GIT pull] printk updates for 4.15

2017-11-19 Thread Linus Torvalds
On Sun, Nov 19, 2017 at 8:20 PM, Kevin Easton  wrote:
>
> As a comment from the userspace peanut gallery, I personally hope this
> does pass muster.  The existing POSIX wording implies that MONOTONIC
> doesn't stop counting over suspend, and that's what you need when you
> want to know the time elapsed between two external events.

Well, people testing the patch (being aware of Thomas' warning) would be good.

It would be particularly good to test suspending when a lot of timers
are active, particularly on a machine that isn't so beefy as to hide
any big load spikes etc.

Traditionally that tends to be networking but also lots of graphical
programs with animations..

  Linus


Re: [GIT pull] printk updates for 4.15

2017-11-19 Thread Linus Torvalds
On Sun, Nov 19, 2017 at 8:20 PM, Kevin Easton  wrote:
>
> As a comment from the userspace peanut gallery, I personally hope this
> does pass muster.  The existing POSIX wording implies that MONOTONIC
> doesn't stop counting over suspend, and that's what you need when you
> want to know the time elapsed between two external events.

Well, people testing the patch (being aware of Thomas' warning) would be good.

It would be particularly good to test suspending when a lot of timers
are active, particularly on a machine that isn't so beefy as to hide
any big load spikes etc.

Traditionally that tends to be networking but also lots of graphical
programs with animations..

  Linus


Re: [PATCH 4.4 00/59] 4.4.100-stable review

2017-11-19 Thread Naresh Kamboju
On 19 November 2017 at 20:02, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 4.4.100 release.
> There are 59 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 Tue Nov 21 14:31:34 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.100-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
Also as per usual the HiKey results are reported separate because the
platform support isn’t in tree.

Summary


kernel: 4.4.100-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 803704b287d89efcd70fade9e650176282a1d766
git describe: v4.4.99-60-g803704b287d8
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.99-60-g803704b287d8


No regressions (compared to build v4.4.99)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - fail: 13, pass: 31, skip: 8
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 936, skip: 159
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - fail: 10, pass: 27, skip: 12
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1035, skip: 67
* ltp-timers-tests - pass: 12,

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - fail: 15, pass: 42, skip: 10
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 18,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 956, skip: 164
* ltp-timers-tests - pass: 12,

And the hikey results.

Summary


kernel: 4.4.100-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.100-rc1-hikey-20171119
git commit: 13a8ba2ce732f7f1b59b72a6ccb2f5246008f4f1
git describe: 4.4.100-rc1-hikey-20171119
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.100-rc1-hikey-20171119

No regressions (compared to build 4.4.99-rc1-hikey-20171116)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - fail: 13, pass: 31, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 979, skip: 124
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Signed-off-by: Naresh Kamboju <naresh.kamb...@linaro.org>


Re: [PATCH 4.4 00/59] 4.4.100-stable review

2017-11-19 Thread Naresh Kamboju
On 19 November 2017 at 20:02, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.4.100 release.
> There are 59 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 Tue Nov 21 14:31:34 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.100-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
Also as per usual the HiKey results are reported separate because the
platform support isn’t in tree.

Summary


kernel: 4.4.100-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 803704b287d89efcd70fade9e650176282a1d766
git describe: v4.4.99-60-g803704b287d8
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.99-60-g803704b287d8


No regressions (compared to build v4.4.99)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - fail: 13, pass: 31, skip: 8
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 936, skip: 159
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - fail: 10, pass: 27, skip: 12
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1035, skip: 67
* ltp-timers-tests - pass: 12,

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - fail: 15, pass: 42, skip: 10
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 18,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 956, skip: 164
* ltp-timers-tests - pass: 12,

And the hikey results.

Summary


kernel: 4.4.100-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.100-rc1-hikey-20171119
git commit: 13a8ba2ce732f7f1b59b72a6ccb2f5246008f4f1
git describe: 4.4.100-rc1-hikey-20171119
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.100-rc1-hikey-20171119

No regressions (compared to build 4.4.99-rc1-hikey-20171116)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - fail: 13, pass: 31, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 979, skip: 124
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Signed-off-by: Naresh Kamboju 


Re: [PATCH] platform/x86: Add Acer Wireless Radio Control driver

2017-11-19 Thread Chris Chiu
On Fri, Nov 17, 2017 at 10:25 PM, Andy Shevchenko
 wrote:
> On Thu, Nov 16, 2017 at 3:44 PM, Chris Chiu  wrote:
>> New Acer laptops in 2018 will have a separate ACPI device for
>> notifications from the airplane mode hotkey. The device name in
>> the DSDT is SMKB and its ACPI _HID is 10251229.
>>
>> For these models, when the airplane mode hotkey (Fn+F3) pressed,
>> a query 0x02 is started in the Embedded Controller, and all this
>> query does is a notify SMKB with the value 0x80.
>>
>> Scope (_SB.PCI0.LPCB.EC0)
>> {
>> (...)
>> Method (_Q02, 0, NotSerialized)  // _Qxx: EC Query
>> {
>> HKEV (0x2, One)
>> Notify (SMKB, 0x80) // Status Change
>> }
>> }
>>
>> Based on code from asus-wireless
>
> Thanks for the patch! Overall looks good, comment below.
>
>
>> +#include 
>
>> +#include 
>> +#include 
>
> Either from that, not both.
>
>> +#include 
>> +#include 
>> +#include 
>
>> +#include 
>
> Why do you need this one?
> Okay, you are using Vendor ID from there.
>
> Besides above, please keep them in alphabetical order.
>
>> +
>> +struct acer_wireless_data {
>> +   struct input_dev *idev;
>
>> +   struct acpi_device *adev;
>
> Do you need this one?
> I suppose whenever you need struct device out of it you may find it
> via input->parent. Right?
>

But I think it would make life easier to have the following line in
.notify callback
struct acer_wireless_data * data = acpi_driver_data(adev);

I can get its parent acer_wireless_data and point to input_dev easier.

>> +};
>> +
>> +static const struct acpi_device_id device_ids[] = {
>
> acer_wireless_acpi_ids
>
>> +   {"10251229", 0},
>> +   {"", 0},
>> +};
>> +MODULE_DEVICE_TABLE(acpi, device_ids);
>> +
>> +static void acer_wireless_notify(struct acpi_device *adev, u32 event)
>> +{
>> +   struct acer_wireless_data *data = acpi_driver_data(adev);
>> +
>
>> +   dev_dbg(>dev, "event=%#x\n", event);
>
> This makes sense after the check, otherwise you will get two messages in a 
> row.
>
>> +   if (event != 0x80) {
>> +   dev_notice(>dev, "Unknown SMKB event: %#x\n", event);
>> +   return;
>> +   }
>
>> +   input_report_key(data->idev, KEY_RFKILL, 1);
>> +   input_report_key(data->idev, KEY_RFKILL, 0);
>
>
>> +   data->idev = devm_input_allocate_device(>dev);
>> +   if (!data->idev)
>> +   return -ENOMEM;
>> +   data->idev->name = "Acer Wireless Radio Control";
>> +   data->idev->phys = "acer-wireless/input0";
>> +   data->idev->id.bustype = BUS_HOST;
>> +   data->idev->id.vendor = PCI_VENDOR_ID_AI;
>
> Where is product ID?
>
> I suppose you can use ACPI ID (which is basically PCI one in ACPI
> table) and split it.
>
> u32 id = simple_strtoul(...ACPI ID..., 16);
>
> vendor = id >> 16;
> product = id & 0x;
>
> Or just hard code product ID for now.
>

Thanks. I will hard code the product ID for now with
data->idev->id.vendor = 0x1229;

>> +static int acer_wireless_remove(struct acpi_device *adev)
>> +{
>> +   return 0;
>> +}
>> +
>
> No need UI suppose.
>

You mean remove this acer_wireless_remove which does nothing? Will do.

>> +MODULE_LICENSE("GPL");
>
> GPL v2 ?
>
> --
> With Best Regards,
> Andy Shevchenko


Re: [PATCH] platform/x86: Add Acer Wireless Radio Control driver

2017-11-19 Thread Chris Chiu
On Fri, Nov 17, 2017 at 10:25 PM, Andy Shevchenko
 wrote:
> On Thu, Nov 16, 2017 at 3:44 PM, Chris Chiu  wrote:
>> New Acer laptops in 2018 will have a separate ACPI device for
>> notifications from the airplane mode hotkey. The device name in
>> the DSDT is SMKB and its ACPI _HID is 10251229.
>>
>> For these models, when the airplane mode hotkey (Fn+F3) pressed,
>> a query 0x02 is started in the Embedded Controller, and all this
>> query does is a notify SMKB with the value 0x80.
>>
>> Scope (_SB.PCI0.LPCB.EC0)
>> {
>> (...)
>> Method (_Q02, 0, NotSerialized)  // _Qxx: EC Query
>> {
>> HKEV (0x2, One)
>> Notify (SMKB, 0x80) // Status Change
>> }
>> }
>>
>> Based on code from asus-wireless
>
> Thanks for the patch! Overall looks good, comment below.
>
>
>> +#include 
>
>> +#include 
>> +#include 
>
> Either from that, not both.
>
>> +#include 
>> +#include 
>> +#include 
>
>> +#include 
>
> Why do you need this one?
> Okay, you are using Vendor ID from there.
>
> Besides above, please keep them in alphabetical order.
>
>> +
>> +struct acer_wireless_data {
>> +   struct input_dev *idev;
>
>> +   struct acpi_device *adev;
>
> Do you need this one?
> I suppose whenever you need struct device out of it you may find it
> via input->parent. Right?
>

But I think it would make life easier to have the following line in
.notify callback
struct acer_wireless_data * data = acpi_driver_data(adev);

I can get its parent acer_wireless_data and point to input_dev easier.

>> +};
>> +
>> +static const struct acpi_device_id device_ids[] = {
>
> acer_wireless_acpi_ids
>
>> +   {"10251229", 0},
>> +   {"", 0},
>> +};
>> +MODULE_DEVICE_TABLE(acpi, device_ids);
>> +
>> +static void acer_wireless_notify(struct acpi_device *adev, u32 event)
>> +{
>> +   struct acer_wireless_data *data = acpi_driver_data(adev);
>> +
>
>> +   dev_dbg(>dev, "event=%#x\n", event);
>
> This makes sense after the check, otherwise you will get two messages in a 
> row.
>
>> +   if (event != 0x80) {
>> +   dev_notice(>dev, "Unknown SMKB event: %#x\n", event);
>> +   return;
>> +   }
>
>> +   input_report_key(data->idev, KEY_RFKILL, 1);
>> +   input_report_key(data->idev, KEY_RFKILL, 0);
>
>
>> +   data->idev = devm_input_allocate_device(>dev);
>> +   if (!data->idev)
>> +   return -ENOMEM;
>> +   data->idev->name = "Acer Wireless Radio Control";
>> +   data->idev->phys = "acer-wireless/input0";
>> +   data->idev->id.bustype = BUS_HOST;
>> +   data->idev->id.vendor = PCI_VENDOR_ID_AI;
>
> Where is product ID?
>
> I suppose you can use ACPI ID (which is basically PCI one in ACPI
> table) and split it.
>
> u32 id = simple_strtoul(...ACPI ID..., 16);
>
> vendor = id >> 16;
> product = id & 0x;
>
> Or just hard code product ID for now.
>

Thanks. I will hard code the product ID for now with
data->idev->id.vendor = 0x1229;

>> +static int acer_wireless_remove(struct acpi_device *adev)
>> +{
>> +   return 0;
>> +}
>> +
>
> No need UI suppose.
>

You mean remove this acer_wireless_remove which does nothing? Will do.

>> +MODULE_LICENSE("GPL");
>
> GPL v2 ?
>
> --
> With Best Regards,
> Andy Shevchenko


Re: [GIT pull] printk updates for 4.15

2017-11-19 Thread Kevin Easton
On Sat, Nov 18, 2017 at 01:26:07AM +0100, Thomas Gleixner wrote:
> On Thu, 16 Nov 2017, Thomas Gleixner wrote:
> > I hope that I can find a few spare cycles to whip up a POC patch which does
> > not make stuff fall apart immediately.
> 
> Here you go. It survived suspend resume in a VM.
> 
> Thanks,
> 
>   tglx
> 
> 8<
> Subject: timekeeping: Make monotonic behave like boottime
> From: Thomas Gleixner 
> Date: Fri, 17 Nov 2017 11:46:48 +0100
> 
> Clock MONOTONIC is not fast forwarded by the time spent in suspend on
> resume. This is only done for BOOTTIME.
> 
> It would be desired to get rid of that difference, but the difference
> between clock MONOTONIC and clock BOOTTIME is well documented so there
> might be applications which depend on that behaviour.

As a comment from the userspace peanut gallery, I personally hope this
does pass muster.  The existing POSIX wording implies that MONOTONIC
doesn't stop counting over suspend, and that's what you need when you
want to know the time elapsed between two external events.

- Kevin
> 



Re: [GIT pull] printk updates for 4.15

2017-11-19 Thread Kevin Easton
On Sat, Nov 18, 2017 at 01:26:07AM +0100, Thomas Gleixner wrote:
> On Thu, 16 Nov 2017, Thomas Gleixner wrote:
> > I hope that I can find a few spare cycles to whip up a POC patch which does
> > not make stuff fall apart immediately.
> 
> Here you go. It survived suspend resume in a VM.
> 
> Thanks,
> 
>   tglx
> 
> 8<
> Subject: timekeeping: Make monotonic behave like boottime
> From: Thomas Gleixner 
> Date: Fri, 17 Nov 2017 11:46:48 +0100
> 
> Clock MONOTONIC is not fast forwarded by the time spent in suspend on
> resume. This is only done for BOOTTIME.
> 
> It would be desired to get rid of that difference, but the difference
> between clock MONOTONIC and clock BOOTTIME is well documented so there
> might be applications which depend on that behaviour.

As a comment from the userspace peanut gallery, I personally hope this
does pass muster.  The existing POSIX wording implies that MONOTONIC
doesn't stop counting over suspend, and that's what you need when you
want to know the time elapsed between two external events.

- Kevin
> 



[PATCH] net/9p: trans_xen: add missing MODULE_AUTHOR/DESCRIPTION/LICENSE

2017-11-19 Thread Jesse Chan
Signed-off-by: Jesse Chan 
---
 net/9p/trans_xen.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 6ad3e043c617..90402e744fbf 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -543,3 +543,7 @@ static void p9_trans_xen_exit(void)
return xenbus_unregister_driver(_9pfs_front_driver);
 }
 module_exit(p9_trans_xen_exit);
+
+MODULE_AUTHOR("Stefano Stabellini ");
+MODULE_DESCRIPTION("Xen Transport for 9P");
+MODULE_LICENSE("Dual MIT/GPL");
-- 
2.14.1



[PATCH] net/9p: trans_xen: add missing MODULE_AUTHOR/DESCRIPTION/LICENSE

2017-11-19 Thread Jesse Chan
Signed-off-by: Jesse Chan 
---
 net/9p/trans_xen.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 6ad3e043c617..90402e744fbf 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -543,3 +543,7 @@ static void p9_trans_xen_exit(void)
return xenbus_unregister_driver(_9pfs_front_driver);
 }
 module_exit(p9_trans_xen_exit);
+
+MODULE_AUTHOR("Stefano Stabellini ");
+MODULE_DESCRIPTION("Xen Transport for 9P");
+MODULE_LICENSE("Dual MIT/GPL");
-- 
2.14.1



  1   2   3   4   5   6   7   8   9   10   >