[PATCH 1/2] staging: bcm2835-audio: Removed spaces before ')'

[Abhijit Naik]

bcm2835-vchiq.c and vc_vchi_audioserv_defs.h:
fixing ERROR: space prohibited before that close parenthesis

Signed-off-by: Abhijit Naik 
---
 drivers/staging/bcm2835-audio/bcm2835-vchiq.c  | 16 
 drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-vchiq.c 
b/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
index e8fd9c79bcfc..99dc8c4e0185 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
@@ -44,15 +44,15 @@

 /* Logging macros (for remapping to other logging mechanisms, i.e., printf) */
 #ifdef AUDIO_DEBUG_ENABLE
-#define LOG_ERR( fmt, arg... )   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_WARN( fmt, arg... )  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_INFO( fmt, arg... )  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_DBG( fmt, arg... )   pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_ERR( fmt, arg...)   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_WARN( fmt, arg...)  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_INFO( fmt, arg...)  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_DBG( fmt, arg...)   pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
 #else
-#define LOG_ERR( fmt, arg... )   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_WARN( fmt, arg... )
-#define LOG_INFO( fmt, arg... )
-#define LOG_DBG( fmt, arg... )
+#define LOG_ERR( fmt, arg...)   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_WARN( fmt, arg...)
+#define LOG_INFO( fmt, arg...)
+#define LOG_DBG( fmt, arg...)
 #endif

 struct bcm2835_audio_instance {
diff --git a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h 
b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
index 09f07fd891bb..f88c5632918b 100644
--- a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
+++ b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
@@ -22,7 +22,7 @@
 #define VC_AUDIO_SERVER_NAME  MAKE_FOURCC("AUDS")

 /* Maximum message length */
-#define VC_AUDIO_MAX_MSG_LEN  (sizeof( VC_AUDIO_MSG_T ))
+#define VC_AUDIO_MAX_MSG_LEN  (sizeof( VC_AUDIO_MSG_T))

 /*
  *  List of screens that are currently supported
--
2.11.0

[PATCH 2/2] staging: bcm2835-audio: Removed space after '('

[Abhijit Naik]

bcm2835-vchiq.c and vc_vchi_audioserv_defs.h:
fixing ERROR: space prohibited after that open parenthesis '('

Signed-off-by: Abhijit Naik 
---
 drivers/staging/bcm2835-audio/bcm2835-vchiq.c  | 16 
 drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-vchiq.c 
b/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
index 99dc8c4e0185..043c79593691 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
@@ -44,15 +44,15 @@

 /* Logging macros (for remapping to other logging mechanisms, i.e., printf) */
 #ifdef AUDIO_DEBUG_ENABLE
-#define LOG_ERR( fmt, arg...)   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_WARN( fmt, arg...)  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_INFO( fmt, arg...)  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_DBG( fmt, arg...)   pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_ERR(fmt, arg...)   pr_err("%s:%d " fmt, __func__, __LINE__, ##arg)
+#define LOG_WARN(fmt, arg...)  pr_info("%s:%d " fmt, __func__, __LINE__, ##arg)
+#define LOG_INFO(fmt, arg...)  pr_info("%s:%d " fmt, __func__, __LINE__, ##arg)
+#define LOG_DBG(fmt, arg...)   pr_info("%s:%d " fmt, __func__, __LINE__, ##arg)
 #else
-#define LOG_ERR( fmt, arg...)   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_WARN( fmt, arg...)
-#define LOG_INFO( fmt, arg...)
-#define LOG_DBG( fmt, arg...)
+#define LOG_ERR(fmt, arg...)   pr_err("%s:%d " fmt, __func__, __LINE__, ##arg)
+#define LOG_WARN(fmt, arg...)
+#define LOG_INFO(fmt, arg...)
+#define LOG_DBG(fmt, arg...)
 #endif

 struct bcm2835_audio_instance {
diff --git a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h 
b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
index f88c5632918b..928dd6009510 100644
--- a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
+++ b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
@@ -22,7 +22,7 @@
 #define VC_AUDIO_SERVER_NAME  MAKE_FOURCC("AUDS")

 /* Maximum message length */
-#define VC_AUDIO_MAX_MSG_LEN  (sizeof( VC_AUDIO_MSG_T))
+#define VC_AUDIO_MAX_MSG_LEN  (sizeof(VC_AUDIO_MSG_T))

 /*
  *  List of screens that are currently supported
--
2.11.0

[PATCH 1/2] staging: bcm2835-audio: Removed spaces before ')'

[Abhijit Naik]

bcm2835-vchiq.c and vc_vchi_audioserv_defs.h:
fixing ERROR: space prohibited before that close parenthesis

Signed-off-by: Abhijit Naik 
---
 drivers/staging/bcm2835-audio/bcm2835-vchiq.c  | 16 
 drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-vchiq.c 
b/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
index e8fd9c79bcfc..99dc8c4e0185 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
@@ -44,15 +44,15 @@

 /* Logging macros (for remapping to other logging mechanisms, i.e., printf) */
 #ifdef AUDIO_DEBUG_ENABLE
-#define LOG_ERR( fmt, arg... )   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_WARN( fmt, arg... )  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_INFO( fmt, arg... )  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_DBG( fmt, arg... )   pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_ERR( fmt, arg...)   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_WARN( fmt, arg...)  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_INFO( fmt, arg...)  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_DBG( fmt, arg...)   pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
 #else
-#define LOG_ERR( fmt, arg... )   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_WARN( fmt, arg... )
-#define LOG_INFO( fmt, arg... )
-#define LOG_DBG( fmt, arg... )
+#define LOG_ERR( fmt, arg...)   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_WARN( fmt, arg...)
+#define LOG_INFO( fmt, arg...)
+#define LOG_DBG( fmt, arg...)
 #endif

 struct bcm2835_audio_instance {
diff --git a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h 
b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
index 09f07fd891bb..f88c5632918b 100644
--- a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
+++ b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
@@ -22,7 +22,7 @@
 #define VC_AUDIO_SERVER_NAME  MAKE_FOURCC("AUDS")

 /* Maximum message length */
-#define VC_AUDIO_MAX_MSG_LEN  (sizeof( VC_AUDIO_MSG_T ))
+#define VC_AUDIO_MAX_MSG_LEN  (sizeof( VC_AUDIO_MSG_T))

 /*
  *  List of screens that are currently supported
--
2.11.0

[PATCH 2/2] staging: bcm2835-audio: Removed space after '('

[Abhijit Naik]

bcm2835-vchiq.c and vc_vchi_audioserv_defs.h:
fixing ERROR: space prohibited after that open parenthesis '('

Signed-off-by: Abhijit Naik 
---
 drivers/staging/bcm2835-audio/bcm2835-vchiq.c  | 16 
 drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-vchiq.c 
b/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
index 99dc8c4e0185..043c79593691 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-vchiq.c
@@ -44,15 +44,15 @@

 /* Logging macros (for remapping to other logging mechanisms, i.e., printf) */
 #ifdef AUDIO_DEBUG_ENABLE
-#define LOG_ERR( fmt, arg...)   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_WARN( fmt, arg...)  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_INFO( fmt, arg...)  pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_DBG( fmt, arg...)   pr_info( "%s:%d " fmt, __func__, __LINE__, 
##arg)
+#define LOG_ERR(fmt, arg...)   pr_err("%s:%d " fmt, __func__, __LINE__, ##arg)
+#define LOG_WARN(fmt, arg...)  pr_info("%s:%d " fmt, __func__, __LINE__, ##arg)
+#define LOG_INFO(fmt, arg...)  pr_info("%s:%d " fmt, __func__, __LINE__, ##arg)
+#define LOG_DBG(fmt, arg...)   pr_info("%s:%d " fmt, __func__, __LINE__, ##arg)
 #else
-#define LOG_ERR( fmt, arg...)   pr_err( "%s:%d " fmt, __func__, __LINE__, 
##arg)
-#define LOG_WARN( fmt, arg...)
-#define LOG_INFO( fmt, arg...)
-#define LOG_DBG( fmt, arg...)
+#define LOG_ERR(fmt, arg...)   pr_err("%s:%d " fmt, __func__, __LINE__, ##arg)
+#define LOG_WARN(fmt, arg...)
+#define LOG_INFO(fmt, arg...)
+#define LOG_DBG(fmt, arg...)
 #endif

 struct bcm2835_audio_instance {
diff --git a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h 
b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
index f88c5632918b..928dd6009510 100644
--- a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
+++ b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
@@ -22,7 +22,7 @@
 #define VC_AUDIO_SERVER_NAME  MAKE_FOURCC("AUDS")

 /* Maximum message length */
-#define VC_AUDIO_MAX_MSG_LEN  (sizeof( VC_AUDIO_MSG_T))
+#define VC_AUDIO_MAX_MSG_LEN  (sizeof(VC_AUDIO_MSG_T))

 /*
  *  List of screens that are currently supported
--
2.11.0

cc1: error: '-march=r3000' requires '-mfp32'

[kbuild test robot]

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   4 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3000' requires '-mfp32'

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


.config.gz
Description: application/gzip

cc1: error: '-march=r3000' requires '-mfp32'

[kbuild test robot]

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   4 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3000' requires '-mfp32'

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


.config.gz
Description: application/gzip

Re: [PATCH v4 0/8] Add sun8i A33 audio driver

[Maxime Ripard]

On Thu, Feb 02, 2017 at 10:24:14AM +0100, Mylène Josserand wrote:
> Hello everyone,
> 
> This a V4 of my Allwinner A33 (sun8i) audio codec driver.
> 
> Tested on "for-next" branch of ASoC repository with some patches
> to apply before this series:
> https://patchwork.kernel.org/patch/9447631/
> https://patchwork.kernel.org/patch/9423999/
> and one of my previous patch (from V2):
> https://patchwork.kernel.org/patch/9521121/
> 
> Changes since V3:
>   - Rebased my patches under Mark Brown's repo on "for-next" branch.
>   - Removed the .owner from sun8i-codec driver, reported by KBuild robot
>   - Updated patch 05/08 according to Rob Herring's review.
> 
> Changes since V2:
>   - Removed patches from v2 already merged:
>   commit ebad64d193779 ("ASoC: sun4i-i2s: Increase DMA max burst to 8")
>   commit 603a0c8af9cb2 ("clk: sunxi-ng: a33: Add CLK_SET_RATE_PARENT to 
> ac-dig")
>   - Removed "reset-names" from sun4i-i2s driver
>   - Fixed the build warning from sun8i-codec
>   - Fixed some various topics such as subject line
>   for dt bindings patch, renamed the simple-card
>   and disabled the simple-card.
> 
> Changes since V1:
>   - Remove the analog codec driver as a better version has been
>   committed by Chen-Yu Tsai and is already merged.
>   - Remove the audio-card as simple-card can be used
>   - The DMA maxburst is set to 8 in the sun4i-i2s instead of
>   adding the maxburst of 4 in Sun6i dma engine.
>   - Create a new compatible for sun4i-i2s to handle the reset
>   line.
>   - Fix various problems in sun8i-codec driver according to V1's
>   reviews
>   - Add the pm_runtime hooks in sun8i-codec driver to prepare/
>   unprepare clocks.
>   - Update the DTS according to Chen-Yu's analog codec driver.
>   - Rename sun8i-codec's clocks to "bus" and "mod"
>   - The first "delay" issue from V1 is fixed by using a delay
>   when enabling the headphone amplifier to let the amplifier
>   being up.
> 
> Patches 1 and 2 add a new compatible "allwinner,sun6i-a31-i2s"
> to handle the reset line for sun4i-i2s driver. It uses a quirk to
> use a version with or without reset lines.
> 
> Patch 3 adds the sun8i codec driver which represents the digital part
> of the A33 codec. It supports only playback features.
> 
> Path 4 fixes the previous issue of a "first time delay" in V1 (see cover
> letter). Do not hesitate if you have comments on this patch.
> 
> Patches 5 adds the dt-bindings documentation for new audio driver
> added in this serie (sun8i-codec).
> 
> Patch 6 adds the cpu DAI, codec and audio nodes to sun8i-a33 device tree.
> 
> Patches 7 and 8 enable the audio on Parrot and Sinlinx's boards.
> 
> The DAI for this A33 codec is the same than for A20: "sun4i-i2s".
> Currently, the sun8i-a33 codec driver handles only the playback feature.
> The other ones (such as capture) and all other interfaces except
> headphone are not supported. I will send a patch to handle the
> capture with microphones in next few weeks.
> 
> Examples of amixer commands:
>   amixer set 'Headphone' 75%
>   amixer set 'Headphone' on
>   amixer set 'DAC' on
>   amixer set 'Right DAC Mixer RSlot 0' on
>   amixer set 'Left DAC Mixer LSlot 0' on
> 
> It was tested on Parrot and Sinlinx boards.
> 
> Let me know if you have any comments on this serie.
> 
> Thank you in advance,
> Best regards,
> 
> Mylène Josserand (8):
>   ASoC: sun4i-i2s: Update binding documentation to include A31
>   ASoC: sun4i-i2s: Add quirks to handle a31 compatible
>   ASoC: Add sun8i digital audio codec
>   ASoC: sun8i-codec-analog: Add amplifier event to fix first delay
>   ASoC: codecs: Add sun8i-a33 binding documentation
>   ARM: dts: sun8i: Add audio codec, dai and card for A33
>   ARM: dts: sun8i: parrot: Enable audio nodes
>   ARM: dts: sun8i: sinlinx: Enable audio nodes

Applied the last three. There was a conflict in the last one that I
fixed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v4 0/8] Add sun8i A33 audio driver

[Maxime Ripard]

On Thu, Feb 02, 2017 at 10:24:14AM +0100, Mylène Josserand wrote:
> Hello everyone,
> 
> This a V4 of my Allwinner A33 (sun8i) audio codec driver.
> 
> Tested on "for-next" branch of ASoC repository with some patches
> to apply before this series:
> https://patchwork.kernel.org/patch/9447631/
> https://patchwork.kernel.org/patch/9423999/
> and one of my previous patch (from V2):
> https://patchwork.kernel.org/patch/9521121/
> 
> Changes since V3:
>   - Rebased my patches under Mark Brown's repo on "for-next" branch.
>   - Removed the .owner from sun8i-codec driver, reported by KBuild robot
>   - Updated patch 05/08 according to Rob Herring's review.
> 
> Changes since V2:
>   - Removed patches from v2 already merged:
>   commit ebad64d193779 ("ASoC: sun4i-i2s: Increase DMA max burst to 8")
>   commit 603a0c8af9cb2 ("clk: sunxi-ng: a33: Add CLK_SET_RATE_PARENT to 
> ac-dig")
>   - Removed "reset-names" from sun4i-i2s driver
>   - Fixed the build warning from sun8i-codec
>   - Fixed some various topics such as subject line
>   for dt bindings patch, renamed the simple-card
>   and disabled the simple-card.
> 
> Changes since V1:
>   - Remove the analog codec driver as a better version has been
>   committed by Chen-Yu Tsai and is already merged.
>   - Remove the audio-card as simple-card can be used
>   - The DMA maxburst is set to 8 in the sun4i-i2s instead of
>   adding the maxburst of 4 in Sun6i dma engine.
>   - Create a new compatible for sun4i-i2s to handle the reset
>   line.
>   - Fix various problems in sun8i-codec driver according to V1's
>   reviews
>   - Add the pm_runtime hooks in sun8i-codec driver to prepare/
>   unprepare clocks.
>   - Update the DTS according to Chen-Yu's analog codec driver.
>   - Rename sun8i-codec's clocks to "bus" and "mod"
>   - The first "delay" issue from V1 is fixed by using a delay
>   when enabling the headphone amplifier to let the amplifier
>   being up.
> 
> Patches 1 and 2 add a new compatible "allwinner,sun6i-a31-i2s"
> to handle the reset line for sun4i-i2s driver. It uses a quirk to
> use a version with or without reset lines.
> 
> Patch 3 adds the sun8i codec driver which represents the digital part
> of the A33 codec. It supports only playback features.
> 
> Path 4 fixes the previous issue of a "first time delay" in V1 (see cover
> letter). Do not hesitate if you have comments on this patch.
> 
> Patches 5 adds the dt-bindings documentation for new audio driver
> added in this serie (sun8i-codec).
> 
> Patch 6 adds the cpu DAI, codec and audio nodes to sun8i-a33 device tree.
> 
> Patches 7 and 8 enable the audio on Parrot and Sinlinx's boards.
> 
> The DAI for this A33 codec is the same than for A20: "sun4i-i2s".
> Currently, the sun8i-a33 codec driver handles only the playback feature.
> The other ones (such as capture) and all other interfaces except
> headphone are not supported. I will send a patch to handle the
> capture with microphones in next few weeks.
> 
> Examples of amixer commands:
>   amixer set 'Headphone' 75%
>   amixer set 'Headphone' on
>   amixer set 'DAC' on
>   amixer set 'Right DAC Mixer RSlot 0' on
>   amixer set 'Left DAC Mixer LSlot 0' on
> 
> It was tested on Parrot and Sinlinx boards.
> 
> Let me know if you have any comments on this serie.
> 
> Thank you in advance,
> Best regards,
> 
> Mylène Josserand (8):
>   ASoC: sun4i-i2s: Update binding documentation to include A31
>   ASoC: sun4i-i2s: Add quirks to handle a31 compatible
>   ASoC: Add sun8i digital audio codec
>   ASoC: sun8i-codec-analog: Add amplifier event to fix first delay
>   ASoC: codecs: Add sun8i-a33 binding documentation
>   ARM: dts: sun8i: Add audio codec, dai and card for A33
>   ARM: dts: sun8i: parrot: Enable audio nodes
>   ARM: dts: sun8i: sinlinx: Enable audio nodes

Applied the last three. There was a conflict in the last one that I
fixed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH 2/2] Documentation/kconfig: add search jump feature description

[changbin . du]

From: Changbin Du 

Kernel menuconfig support direct jumping function from the search
result. This is a very convenient feature but not documented. So
add a short description to the kconfig documentation to let more
developer know it.

Signed-off-by: Changbin Du 
---
 Documentation/kbuild/kconfig.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index bbc99c0..9916318 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -178,6 +178,10 @@ Searching in menuconfig:
first (and in alphabetical order), then come all other symbols,
sorted in alphabetical order.
 
+   In the search result textbox, each symbol has a jump number on
+   left side if the symbol is jumpable. You can type the nubmer
+   to jump to target menu to configurate that symbol.
+
 __
 User interface options for 'menuconfig'
 
-- 
2.7.4

[PATCH 0/2] kconfig/mconf: propagate jumping function in search result view

[changbin . du]

From: Changbin Du 

While I am searching something in menuconfig, I hope if I can jump to interested
items directly. I even try to add this feature. When I check the code just 
found 
it has already been there but not documented. So why let more developers know 
it?

Changbin Du (2):
  kconfig/mconf: add jumping tip in title of search result textbox
  Documentation/kconfig: add search jump feature description

 Documentation/kbuild/kconfig.txt | 4 
 scripts/kconfig/mconf.c  | 8 
 2 files changed, 8 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH 2/2] Documentation/kconfig: add search jump feature description

[changbin . du]

From: Changbin Du 

Kernel menuconfig support direct jumping function from the search
result. This is a very convenient feature but not documented. So
add a short description to the kconfig documentation to let more
developer know it.

Signed-off-by: Changbin Du 
---
 Documentation/kbuild/kconfig.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index bbc99c0..9916318 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -178,6 +178,10 @@ Searching in menuconfig:
first (and in alphabetical order), then come all other symbols,
sorted in alphabetical order.
 
+   In the search result textbox, each symbol has a jump number on
+   left side if the symbol is jumpable. You can type the nubmer
+   to jump to target menu to configurate that symbol.
+
 __
 User interface options for 'menuconfig'
 
-- 
2.7.4

[PATCH 0/2] kconfig/mconf: propagate jumping function in search result view

[changbin . du]

From: Changbin Du 

While I am searching something in menuconfig, I hope if I can jump to interested
items directly. I even try to add this feature. When I check the code just 
found 
it has already been there but not documented. So why let more developers know 
it?

Changbin Du (2):
  kconfig/mconf: add jumping tip in title of search result textbox
  Documentation/kconfig: add search jump feature description

 Documentation/kbuild/kconfig.txt | 4 
 scripts/kconfig/mconf.c  | 8 
 2 files changed, 8 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH 1/2] kconfig/mconf: add jumping tip in title of search result textbox

[changbin . du]

From: Changbin Du 

Prompt user how to quickly jump to the item he/she is interested in.

Signed-off-by: Changbin Du 
---
 scripts/kconfig/mconf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 315ce2c..23d5681 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -443,10 +443,10 @@ static void search_conf(void)
 
res = get_relations_str(sym_arr, );
set_subtitle();
-   dres = show_textbox_ext(_("Search Results"), (char *)
-   str_get(), 0, 0, keys, ,
-   , _text, (void *)
-   );
+   dres = show_textbox_ext(
+   _("Search Results (type the number to jump)"),
+   (char *)str_get(), 0, 0, keys, ,
+   , _text, (void *));
again = false;
for (i = 0; i < JUMP_NB && keys[i]; i++)
if (dres == keys[i]) {
-- 
2.7.4

[PATCH 1/2] kconfig/mconf: add jumping tip in title of search result textbox

[changbin . du]

From: Changbin Du 

Prompt user how to quickly jump to the item he/she is interested in.

Signed-off-by: Changbin Du 
---
 scripts/kconfig/mconf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 315ce2c..23d5681 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -443,10 +443,10 @@ static void search_conf(void)
 
res = get_relations_str(sym_arr, );
set_subtitle();
-   dres = show_textbox_ext(_("Search Results"), (char *)
-   str_get(), 0, 0, keys, ,
-   , _text, (void *)
-   );
+   dres = show_textbox_ext(
+   _("Search Results (type the number to jump)"),
+   (char *)str_get(), 0, 0, keys, ,
+   , _text, (void *));
again = false;
for (i = 0; i < JUMP_NB && keys[i]; i++)
if (dres == keys[i]) {
-- 
2.7.4

Re: [PATCH v2 2/2] arm: dts: mt2701: add nor flash node

[Boris Brezillon]

Hi Guochun,

On Sun, 5 Feb 2017 12:00:49 +0800
Guochun Mao  wrote:


> >  
> > +   nor_flash: spi@11014000 {
> > +   compatible = "mediatek,mt2701-nor",
> > +"mediatek,mt8173-nor";
> > +   reg = <0 0x11014000 0 0xe0>;
> > +   clocks = < CLK_PERI_FLASH>,
> > +< CLK_TOP_FLASH_SEL>;
> > +   clock-names = "spi", "sf";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   status = "disabled";
> > +   };
> > +
> > mmsys: syscon@1400 {
> > compatible = "mediatek,mt2701-mmsys", "syscon";
> > reg = <0 0x1400 0 0x1000>;  
> 
> Hi,
> mtk-quadspi.txt had been updated as suggested.
> Is there suggestion about this patch?

It should probably go through the Mediatek tree. Matthias, any opinion?

Regards,

Boris

Re: [PATCH v2 2/2] arm: dts: mt2701: add nor flash node

[Boris Brezillon]

Hi Guochun,

On Sun, 5 Feb 2017 12:00:49 +0800
Guochun Mao  wrote:


> >  
> > +   nor_flash: spi@11014000 {
> > +   compatible = "mediatek,mt2701-nor",
> > +"mediatek,mt8173-nor";
> > +   reg = <0 0x11014000 0 0xe0>;
> > +   clocks = < CLK_PERI_FLASH>,
> > +< CLK_TOP_FLASH_SEL>;
> > +   clock-names = "spi", "sf";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   status = "disabled";
> > +   };
> > +
> > mmsys: syscon@1400 {
> > compatible = "mediatek,mt2701-mmsys", "syscon";
> > reg = <0 0x1400 0 0x1000>;  
> 
> Hi,
> mtk-quadspi.txt had been updated as suggested.
> Is there suggestion about this patch?

It should probably go through the Mediatek tree. Matthias, any opinion?

Regards,

Boris

Re: [PATCH v3 03/14] mm: use pmd lock instead of racy checks in zap_pmd_range()

[Naoya Horiguchi]

On Sun, Feb 05, 2017 at 11:12:41AM -0500, Zi Yan wrote:
> From: Zi Yan 
> 
> Originally, zap_pmd_range() checks pmd value without taking pmd lock.
> This can cause pmd_protnone entry not being freed.
> 
> Because there are two steps in changing a pmd entry to a pmd_protnone
> entry. First, the pmd entry is cleared to a pmd_none entry, then,
> the pmd_none entry is changed into a pmd_protnone entry.
> The racy check, even with barrier, might only see the pmd_none entry
> in zap_pmd_range(), thus, the mapping is neither split nor zapped.
> 
> Later, in free_pmd_range(), pmd_none_or_clear() will see the
> pmd_protnone entry and clear it as a pmd_bad entry. Furthermore,
> since the pmd_protnone entry is not properly freed, the corresponding
> deposited pte page table is not freed either.
> 
> This causes memory leak or kernel crashing, if VM_BUG_ON() is enabled.
> 
> This patch relies on __split_huge_pmd_locked() and
> __zap_huge_pmd_locked().
> 
> Signed-off-by: Zi Yan 
> ---
>  mm/memory.c | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index 3929b015faf7..7cfdd5208ef5 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1233,33 +1233,31 @@ static inline unsigned long zap_pmd_range(struct 
> mmu_gather *tlb,
>   struct zap_details *details)
>  {
>   pmd_t *pmd;
> + spinlock_t *ptl;
>   unsigned long next;
>  
>   pmd = pmd_offset(pud, addr);
> + ptl = pmd_lock(vma->vm_mm, pmd);

If USE_SPLIT_PMD_PTLOCKS is true, pmd_lock() returns different ptl for
each pmd. The following code runs over pmds within [addr, end) with
a single ptl (of the first pmd,) so I suspect this locking really works.
Maybe pmd_lock() should be called inside while loop?

Thanks,
Naoya Horiguchi

>   do {
>   next = pmd_addr_end(addr, end);
>   if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd)) {
>   if (next - addr != HPAGE_PMD_SIZE) {
>   VM_BUG_ON_VMA(vma_is_anonymous(vma) &&
>   !rwsem_is_locked(>mm->mmap_sem), vma);
> - __split_huge_pmd(vma, pmd, addr, false, NULL);
> - } else if (zap_huge_pmd(tlb, vma, pmd, addr))
> - goto next;
> + __split_huge_pmd_locked(vma, pmd, addr, false);
> + } else if (__zap_huge_pmd_locked(tlb, vma, pmd, addr))
> + continue;
>   /* fall through */
>   }
> - /*
> -  * Here there can be other concurrent MADV_DONTNEED or
> -  * trans huge page faults running, and if the pmd is
> -  * none or trans huge it can change under us. This is
> -  * because MADV_DONTNEED holds the mmap_sem in read
> -  * mode.
> -  */
> - if (pmd_none_or_trans_huge_or_clear_bad(pmd))
> - goto next;
> +
> + if (pmd_none_or_clear_bad(pmd))
> + continue;
> + spin_unlock(ptl);
>   next = zap_pte_range(tlb, vma, pmd, addr, next, details);
> -next:
>   cond_resched();
> + spin_lock(ptl);
>   } while (pmd++, addr = next, addr != end);
> + spin_unlock(ptl);
>  
>   return addr;
>  }
> -- 
> 2.11.0
> 

Re: [PATCH v3 03/14] mm: use pmd lock instead of racy checks in zap_pmd_range()

[Naoya Horiguchi]

On Sun, Feb 05, 2017 at 11:12:41AM -0500, Zi Yan wrote:
> From: Zi Yan 
> 
> Originally, zap_pmd_range() checks pmd value without taking pmd lock.
> This can cause pmd_protnone entry not being freed.
> 
> Because there are two steps in changing a pmd entry to a pmd_protnone
> entry. First, the pmd entry is cleared to a pmd_none entry, then,
> the pmd_none entry is changed into a pmd_protnone entry.
> The racy check, even with barrier, might only see the pmd_none entry
> in zap_pmd_range(), thus, the mapping is neither split nor zapped.
> 
> Later, in free_pmd_range(), pmd_none_or_clear() will see the
> pmd_protnone entry and clear it as a pmd_bad entry. Furthermore,
> since the pmd_protnone entry is not properly freed, the corresponding
> deposited pte page table is not freed either.
> 
> This causes memory leak or kernel crashing, if VM_BUG_ON() is enabled.
> 
> This patch relies on __split_huge_pmd_locked() and
> __zap_huge_pmd_locked().
> 
> Signed-off-by: Zi Yan 
> ---
>  mm/memory.c | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index 3929b015faf7..7cfdd5208ef5 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1233,33 +1233,31 @@ static inline unsigned long zap_pmd_range(struct 
> mmu_gather *tlb,
>   struct zap_details *details)
>  {
>   pmd_t *pmd;
> + spinlock_t *ptl;
>   unsigned long next;
>  
>   pmd = pmd_offset(pud, addr);
> + ptl = pmd_lock(vma->vm_mm, pmd);

If USE_SPLIT_PMD_PTLOCKS is true, pmd_lock() returns different ptl for
each pmd. The following code runs over pmds within [addr, end) with
a single ptl (of the first pmd,) so I suspect this locking really works.
Maybe pmd_lock() should be called inside while loop?

Thanks,
Naoya Horiguchi

>   do {
>   next = pmd_addr_end(addr, end);
>   if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd)) {
>   if (next - addr != HPAGE_PMD_SIZE) {
>   VM_BUG_ON_VMA(vma_is_anonymous(vma) &&
>   !rwsem_is_locked(>mm->mmap_sem), vma);
> - __split_huge_pmd(vma, pmd, addr, false, NULL);
> - } else if (zap_huge_pmd(tlb, vma, pmd, addr))
> - goto next;
> + __split_huge_pmd_locked(vma, pmd, addr, false);
> + } else if (__zap_huge_pmd_locked(tlb, vma, pmd, addr))
> + continue;
>   /* fall through */
>   }
> - /*
> -  * Here there can be other concurrent MADV_DONTNEED or
> -  * trans huge page faults running, and if the pmd is
> -  * none or trans huge it can change under us. This is
> -  * because MADV_DONTNEED holds the mmap_sem in read
> -  * mode.
> -  */
> - if (pmd_none_or_trans_huge_or_clear_bad(pmd))
> - goto next;
> +
> + if (pmd_none_or_clear_bad(pmd))
> + continue;
> + spin_unlock(ptl);
>   next = zap_pte_range(tlb, vma, pmd, addr, next, details);
> -next:
>   cond_resched();
> + spin_lock(ptl);
>   } while (pmd++, addr = next, addr != end);
> + spin_unlock(ptl);
>  
>   return addr;
>  }
> -- 
> 2.11.0
> 

[tip:WIP.sched/core 118/162] arch/mips/sgi-ip27/ip27-berr.c:60:17: error: dereferencing pointer to incomplete type 'struct pt_regs'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.sched/core
head:   38c7fc1c938c469af27c032bf4eab0c4aaf4eba1
commit: d8c081caed34b16d17d639fa49889d2b7b22c9b0 [118/162] sched/headers: 
Remove  from 
config: mips-ip27_defconfig (attached as .config)
compiler: mips64-linux-gnuabi64-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d8c081caed34b16d17d639fa49889d2b7b22c9b0
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   arch/mips/sgi-ip27/ip27-berr.c: In function 'ip27_be_handler':
>> arch/mips/sgi-ip27/ip27-berr.c:60:17: error: dereferencing pointer to 
>> incomplete type 'struct pt_regs'
 int data = regs->cp0_cause & 4;
^~
   arch/mips/sgi-ip27/ip27-berr.c:76:2: error: implicit declaration of function 
'force_sig' [-Werror=implicit-function-declaration]
 force_sig(SIGBUS, current);
 ^
   cc1: all warnings being treated as errors

vim +60 arch/mips/sgi-ip27/ip27-berr.c

^1da177e Linus Torvalds 2005-04-16  44  printk("Hub error address is 
%08lx\n",
^1da177e Linus Torvalds 2005-04-16  45 (errst0 & 
PI_ERR_ST0_ADDR_MASK) >> (PI_ERR_ST0_ADDR_SHFT - 3));
^1da177e Linus Torvalds 2005-04-16  46  printk("Incoming message 
command 0x%lx\n",
^1da177e Linus Torvalds 2005-04-16  47 (errst0 & 
PI_ERR_ST0_CMD_MASK) >> PI_ERR_ST0_CMD_SHFT);
^1da177e Linus Torvalds 2005-04-16  48  printk("Supplemental field of 
incoming message is 0x%lx\n",
^1da177e Linus Torvalds 2005-04-16  49 (errst0 & 
PI_ERR_ST0_SUPPL_MASK) >> PI_ERR_ST0_SUPPL_SHFT);
^1da177e Linus Torvalds 2005-04-16  50  printk("T5 Rn (for RRB only) is 
0x%lx\n",
^1da177e Linus Torvalds 2005-04-16  51 (errst0 & 
PI_ERR_ST0_REQNUM_MASK) >> PI_ERR_ST0_REQNUM_SHFT);
^1da177e Linus Torvalds 2005-04-16  52  printk("Error type is %s\n", 
err_type[wrb]
^1da177e Linus Torvalds 2005-04-16  53 [(errst0 & 
PI_ERR_ST0_TYPE_MASK) >> PI_ERR_ST0_TYPE_SHFT]
^1da177e Linus Torvalds 2005-04-16  54  ? : "invalid");
^1da177e Linus Torvalds 2005-04-16  55  }
^1da177e Linus Torvalds 2005-04-16  56  
^1da177e Linus Torvalds 2005-04-16  57  int ip27_be_handler(struct pt_regs 
*regs, int is_fixup)
^1da177e Linus Torvalds 2005-04-16  58  {
^1da177e Linus Torvalds 2005-04-16  59  unsigned long errst0, errst1;
^1da177e Linus Torvalds 2005-04-16 @60  int data = regs->cp0_cause & 4;
^1da177e Linus Torvalds 2005-04-16  61  int cpu = 
LOCAL_HUB_L(PI_CPU_NUM);
^1da177e Linus Torvalds 2005-04-16  62  
^1da177e Linus Torvalds 2005-04-16  63  if (is_fixup)
^1da177e Linus Torvalds 2005-04-16  64  return MIPS_BE_FIXUP;
^1da177e Linus Torvalds 2005-04-16  65  
^1da177e Linus Torvalds 2005-04-16  66  printk("Slice %c got %cbe at 
0x%lx\n", 'A' + cpu, data ? 'd' : 'i',
^1da177e Linus Torvalds 2005-04-16  67 regs->cp0_epc);
^1da177e Linus Torvalds 2005-04-16  68  printk("Hub information:\n");

:: The code at line 60 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

[tip:WIP.sched/core 118/162] arch/mips/sgi-ip27/ip27-berr.c:60:17: error: dereferencing pointer to incomplete type 'struct pt_regs'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.sched/core
head:   38c7fc1c938c469af27c032bf4eab0c4aaf4eba1
commit: d8c081caed34b16d17d639fa49889d2b7b22c9b0 [118/162] sched/headers: 
Remove  from 
config: mips-ip27_defconfig (attached as .config)
compiler: mips64-linux-gnuabi64-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d8c081caed34b16d17d639fa49889d2b7b22c9b0
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   arch/mips/sgi-ip27/ip27-berr.c: In function 'ip27_be_handler':
>> arch/mips/sgi-ip27/ip27-berr.c:60:17: error: dereferencing pointer to 
>> incomplete type 'struct pt_regs'
 int data = regs->cp0_cause & 4;
^~
   arch/mips/sgi-ip27/ip27-berr.c:76:2: error: implicit declaration of function 
'force_sig' [-Werror=implicit-function-declaration]
 force_sig(SIGBUS, current);
 ^
   cc1: all warnings being treated as errors

vim +60 arch/mips/sgi-ip27/ip27-berr.c

^1da177e Linus Torvalds 2005-04-16  44  printk("Hub error address is 
%08lx\n",
^1da177e Linus Torvalds 2005-04-16  45 (errst0 & 
PI_ERR_ST0_ADDR_MASK) >> (PI_ERR_ST0_ADDR_SHFT - 3));
^1da177e Linus Torvalds 2005-04-16  46  printk("Incoming message 
command 0x%lx\n",
^1da177e Linus Torvalds 2005-04-16  47 (errst0 & 
PI_ERR_ST0_CMD_MASK) >> PI_ERR_ST0_CMD_SHFT);
^1da177e Linus Torvalds 2005-04-16  48  printk("Supplemental field of 
incoming message is 0x%lx\n",
^1da177e Linus Torvalds 2005-04-16  49 (errst0 & 
PI_ERR_ST0_SUPPL_MASK) >> PI_ERR_ST0_SUPPL_SHFT);
^1da177e Linus Torvalds 2005-04-16  50  printk("T5 Rn (for RRB only) is 
0x%lx\n",
^1da177e Linus Torvalds 2005-04-16  51 (errst0 & 
PI_ERR_ST0_REQNUM_MASK) >> PI_ERR_ST0_REQNUM_SHFT);
^1da177e Linus Torvalds 2005-04-16  52  printk("Error type is %s\n", 
err_type[wrb]
^1da177e Linus Torvalds 2005-04-16  53 [(errst0 & 
PI_ERR_ST0_TYPE_MASK) >> PI_ERR_ST0_TYPE_SHFT]
^1da177e Linus Torvalds 2005-04-16  54  ? : "invalid");
^1da177e Linus Torvalds 2005-04-16  55  }
^1da177e Linus Torvalds 2005-04-16  56  
^1da177e Linus Torvalds 2005-04-16  57  int ip27_be_handler(struct pt_regs 
*regs, int is_fixup)
^1da177e Linus Torvalds 2005-04-16  58  {
^1da177e Linus Torvalds 2005-04-16  59  unsigned long errst0, errst1;
^1da177e Linus Torvalds 2005-04-16 @60  int data = regs->cp0_cause & 4;
^1da177e Linus Torvalds 2005-04-16  61  int cpu = 
LOCAL_HUB_L(PI_CPU_NUM);
^1da177e Linus Torvalds 2005-04-16  62  
^1da177e Linus Torvalds 2005-04-16  63  if (is_fixup)
^1da177e Linus Torvalds 2005-04-16  64  return MIPS_BE_FIXUP;
^1da177e Linus Torvalds 2005-04-16  65  
^1da177e Linus Torvalds 2005-04-16  66  printk("Slice %c got %cbe at 
0x%lx\n", 'A' + cpu, data ? 'd' : 'i',
^1da177e Linus Torvalds 2005-04-16  67 regs->cp0_epc);
^1da177e Linus Torvalds 2005-04-16  68  printk("Hub information:\n");

:: The code at line 60 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

Re: [PATCH v9 3/3] iio: adc: add support for Allwinner SoCs ADC

[Quentin Schulz]

Hi Jonathan,

On 14/01/2017 20:28, Jonathan Cameron wrote:
> 
> 
> On 14 January 2017 19:19:58 GMT+00:00, Quentin Schulz 
>  wrote:
>> Hi Jonathan,
>>
>> On 08/01/2017 12:17, Jonathan Cameron wrote:
>>> On 30/12/16 14:40, Jonathan Cameron wrote:
 On 13/12/16 14:33, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a
>> touchscreen
> controller and a thermal sensor. This patch adds the ADC driver
>> which is
> based on the MFD for the same SoCs ADC.
>
> This also registers the thermal adc channel in the iio map array so
> iio_hwmon could use it without modifying the Device Tree. This
>> registers
> the driver in the thermal framework.
>
> The thermal sensor requires the IP to be in touchscreen mode to
>> return
> correct values. Therefore, if the user is continuously reading the
>> ADC
> channel(s), the thermal framework in which the thermal sensor is
> registered will switch the IP in touchscreen mode to get a
>> temperature
> value and requires a delay of 100ms (because of the mode
>> switching),
> then the ADC will switch back to ADC mode and requires also a delay
>> of
> 100ms. If the ADC readings are critical to user and the SoC
>> temperature
> is not, this driver is capable of not registering the thermal
>> sensor in
> the thermal framework and thus, "quicken" the ADC readings.
>
> This driver probes on three different platform_device_id to take
>> into
> account slight differences (registers bit and temperature
>> computation)
> between Allwinner SoCs ADCs.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 
> Acked-by: Jonathan Cameron 
> Acked-for-MFD-by: Lee Jones 
 One comment inline but not a blocker.

 I would ideally like an ack from the thermal side.  The relevant
>> code
 is small, but best to be sure and keep them in the loop as well.

 It does feel a little convoluted to have both this directly
>> providing
 a thermal zone and being able to create one indirectly through hwmon
>> as
 well but this solution works for me I think...

 Cc'd Zang and Eduardo.
>>> Nothing seems to have come through on that front.
>>>
>>> I need to get a pull request out to Greg and rebase my tree before I
>> have
>>> the precursor patch in place. Give me a bump if you haven't heard
>> anything by
>>> the time next week.
>>>
>>
>> Kindly "giving you a bump" you as requested since I haven't heard from
>> you for a week.
> Greg hasn't pulled yet, so may be a few more days.
> 
> J

I haven't received any news from you on the merging of this patch series
for a month, so kindly pinging.

Thanks,
Quentin

>>
>> Thanks,
>> Quentin
>>
>>> Thanks,
>>>
>>> Jonathan

 Jonathan
> ---
>
> v9:
>  - clarify comment on why we have to use the parent node as node
>> for
>  registering in thermal framework, (backward compatibility)
>  - clarify comment on why we can disable CONFIG_THERMAL_OF,
>  - clarify Kconfig help to say that CONFIG_THERMAL_OF can be
>> disabled
>  but should not in most cases,
>  - make return value of devm_thermal_zone_of_sensor_register a
>> local
>  variable of the condition block,
>  - correct scale from _PLUS_MICRO to _PLUS_NANO for ADC raw
>> readings
>  scale,
>
> v8:
>  - remove Kconfig depends on !TOUCHSCREEN_SUN4I (moved to
> MFD_SUN4I_GPADC),
>  - fix return values of regmap_irq_get_virq and
>> platform_get_irq_byname
> stored in an unsigned int and then check if negative,
>  - fix uninitialized ret value when an error occurs while
>> registering
> the thermal sensor in the framework,
>
> v7:
>  - add Kconfig depends on !TOUCHSCREEN_SUN4I,
>  - remove Kconfig selects THERMAL_OF,
>  - do not register thermal sensor if CONFIG_THERMAL_OF is disabled,
>  - disable irq in irq_handler rather than in read_raw,
>  - add delay when switching the IP's mode or channel (delay
>> empirically found),
>  - quicken thermal sensor interrupt period,
>  - add masks for channel bits,
>  - fix deadlock in sun4i_gpadc_read if regmap_read/write fails,
>  - move some logic from sun4i_gpadc_read to sun4i_prepare_for_irq,
>  - mark last busy for runtime_pm only on success in
>> sun4i_gpadc_read,
>  - remove cached values,
>  - increase wait_for_completion_timeout timeout to 1s to be sure to
>> not miss the
>  thermal interrupt,
>  - add voltage scale,
>  - use devm_iio_device_register,
>
> v6:
>  - remove "-mfd" from filenames and variables inside MFD driver,
>  - use DEFINE_RES_IRQ_NAMED instead of setting resources manually,
>  - cosmetic changes,
>  - use IDs and switch over ID to get cells specific to an
>> 

Re: [PATCH v9 3/3] iio: adc: add support for Allwinner SoCs ADC

[Quentin Schulz]

Hi Jonathan,

On 14/01/2017 20:28, Jonathan Cameron wrote:
> 
> 
> On 14 January 2017 19:19:58 GMT+00:00, Quentin Schulz 
>  wrote:
>> Hi Jonathan,
>>
>> On 08/01/2017 12:17, Jonathan Cameron wrote:
>>> On 30/12/16 14:40, Jonathan Cameron wrote:
 On 13/12/16 14:33, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a
>> touchscreen
> controller and a thermal sensor. This patch adds the ADC driver
>> which is
> based on the MFD for the same SoCs ADC.
>
> This also registers the thermal adc channel in the iio map array so
> iio_hwmon could use it without modifying the Device Tree. This
>> registers
> the driver in the thermal framework.
>
> The thermal sensor requires the IP to be in touchscreen mode to
>> return
> correct values. Therefore, if the user is continuously reading the
>> ADC
> channel(s), the thermal framework in which the thermal sensor is
> registered will switch the IP in touchscreen mode to get a
>> temperature
> value and requires a delay of 100ms (because of the mode
>> switching),
> then the ADC will switch back to ADC mode and requires also a delay
>> of
> 100ms. If the ADC readings are critical to user and the SoC
>> temperature
> is not, this driver is capable of not registering the thermal
>> sensor in
> the thermal framework and thus, "quicken" the ADC readings.
>
> This driver probes on three different platform_device_id to take
>> into
> account slight differences (registers bit and temperature
>> computation)
> between Allwinner SoCs ADCs.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 
> Acked-by: Jonathan Cameron 
> Acked-for-MFD-by: Lee Jones 
 One comment inline but not a blocker.

 I would ideally like an ack from the thermal side.  The relevant
>> code
 is small, but best to be sure and keep them in the loop as well.

 It does feel a little convoluted to have both this directly
>> providing
 a thermal zone and being able to create one indirectly through hwmon
>> as
 well but this solution works for me I think...

 Cc'd Zang and Eduardo.
>>> Nothing seems to have come through on that front.
>>>
>>> I need to get a pull request out to Greg and rebase my tree before I
>> have
>>> the precursor patch in place. Give me a bump if you haven't heard
>> anything by
>>> the time next week.
>>>
>>
>> Kindly "giving you a bump" you as requested since I haven't heard from
>> you for a week.
> Greg hasn't pulled yet, so may be a few more days.
> 
> J

I haven't received any news from you on the merging of this patch series
for a month, so kindly pinging.

Thanks,
Quentin

>>
>> Thanks,
>> Quentin
>>
>>> Thanks,
>>>
>>> Jonathan

 Jonathan
> ---
>
> v9:
>  - clarify comment on why we have to use the parent node as node
>> for
>  registering in thermal framework, (backward compatibility)
>  - clarify comment on why we can disable CONFIG_THERMAL_OF,
>  - clarify Kconfig help to say that CONFIG_THERMAL_OF can be
>> disabled
>  but should not in most cases,
>  - make return value of devm_thermal_zone_of_sensor_register a
>> local
>  variable of the condition block,
>  - correct scale from _PLUS_MICRO to _PLUS_NANO for ADC raw
>> readings
>  scale,
>
> v8:
>  - remove Kconfig depends on !TOUCHSCREEN_SUN4I (moved to
> MFD_SUN4I_GPADC),
>  - fix return values of regmap_irq_get_virq and
>> platform_get_irq_byname
> stored in an unsigned int and then check if negative,
>  - fix uninitialized ret value when an error occurs while
>> registering
> the thermal sensor in the framework,
>
> v7:
>  - add Kconfig depends on !TOUCHSCREEN_SUN4I,
>  - remove Kconfig selects THERMAL_OF,
>  - do not register thermal sensor if CONFIG_THERMAL_OF is disabled,
>  - disable irq in irq_handler rather than in read_raw,
>  - add delay when switching the IP's mode or channel (delay
>> empirically found),
>  - quicken thermal sensor interrupt period,
>  - add masks for channel bits,
>  - fix deadlock in sun4i_gpadc_read if regmap_read/write fails,
>  - move some logic from sun4i_gpadc_read to sun4i_prepare_for_irq,
>  - mark last busy for runtime_pm only on success in
>> sun4i_gpadc_read,
>  - remove cached values,
>  - increase wait_for_completion_timeout timeout to 1s to be sure to
>> not miss the
>  thermal interrupt,
>  - add voltage scale,
>  - use devm_iio_device_register,
>
> v6:
>  - remove "-mfd" from filenames and variables inside MFD driver,
>  - use DEFINE_RES_IRQ_NAMED instead of setting resources manually,
>  - cosmetic changes,
>  - use IDs and switch over ID to get cells specific to an
>> architecture, instead
>  of using cells direclty, in of_device_id.data,
>  - compute size of mfd_cells array instead of hardcoded one,
>
> 

Re: [PATCH 9/9] ARM: sun5i: gr8: Use common sun5i DTSI

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Most of the GR8 DTSI is duplicated with the common sun5i DTSI, and some of
> the extra nodes defined there actually apply to all of the sun5i family.
>
> Move those into the common DTSI so that all SoCs can benefit from it, and
> include the sun5i DTSI.
>
> Signed-off-by: Maxime Ripard 

I think it's possible to move the display-engine node over as well?

Acked-by: Chen-Yu Tsai 

Re: [PATCH 9/9] ARM: sun5i: gr8: Use common sun5i DTSI

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Most of the GR8 DTSI is duplicated with the common sun5i DTSI, and some of
> the extra nodes defined there actually apply to all of the sun5i family.
>
> Move those into the common DTSI so that all SoCs can benefit from it, and
> include the sun5i DTSI.
>
> Signed-off-by: Maxime Ripard 

I think it's possible to move the display-engine node over as well?

Acked-by: Chen-Yu Tsai 

linux-next: Tree for Feb 6

[Stephen Rothwell]

Hi all,

Changes since 20170203:

New trees: v4l-dvb-fixes, v4l-dvb-next

Undropped tree: vfs-miklos

The arm64 tree gained conflicts against the qcom tree.

The vfs-miklos tree lost its build failure.

The v4l-dvb tree lost its build failure.

The drm tree gained a conflict against the net-next tree.

The regulator tree lost its build failure.

The tty tree gained a build failure so I used the version from
next-20170203.

The staging tree gained a conflict against the v4l-dvb tree.

The scsi tree gained a build failure due to an interaction with the
block tree.  I applied a merge fix patch.

Non-merge commits (relative to Linus' tree): 7549
 8606 files changed, 316654 insertions(+), 159620 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 256 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (a572a1b99948 Merge branch 'irq-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (566cf877a1fc Linux 4.10-rc6)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (7892032cfe67 ip6_gre: fix ip6gre_err() invalid reads)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (a47b70ea86bd ravb: unmap descriptors when freeing 
rings)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (77fbffc2aa09 Revert "PCI: pciehp: Add runtime PM 
support for PCIe hotplug ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (a572a1b99948 Merge branch 'irq-urgent-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging 

linux-next: Tree for Feb 6

[Stephen Rothwell]

Hi all,

Changes since 20170203:

New trees: v4l-dvb-fixes, v4l-dvb-next

Undropped tree: vfs-miklos

The arm64 tree gained conflicts against the qcom tree.

The vfs-miklos tree lost its build failure.

The v4l-dvb tree lost its build failure.

The drm tree gained a conflict against the net-next tree.

The regulator tree lost its build failure.

The tty tree gained a build failure so I used the version from
next-20170203.

The staging tree gained a conflict against the v4l-dvb tree.

The scsi tree gained a build failure due to an interaction with the
block tree.  I applied a merge fix patch.

Non-merge commits (relative to Linus' tree): 7549
 8606 files changed, 316654 insertions(+), 159620 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 256 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (a572a1b99948 Merge branch 'irq-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (566cf877a1fc Linux 4.10-rc6)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (7892032cfe67 ip6_gre: fix ip6gre_err() invalid reads)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (a47b70ea86bd ravb: unmap descriptors when freeing 
rings)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (77fbffc2aa09 Revert "PCI: pciehp: Add runtime PM 
support for PCIe hotplug ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (a572a1b99948 Merge branch 'irq-urgent-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging 

[PATCH 2/3] perf diff: Add diff.order config option

[Namhyung Kim]

In many cases, I need to look at differences between two data so I often
used the -o option to sort the result base on the difference first.
It'd be nice to have a config option to set it by default.

The diff.order config option is to set the default value of -o/--order
option.

Cc: Taeung Song 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-config.txt |  7 +++
 tools/perf/Documentation/perf-diff.txt   |  6 +-
 tools/perf/builtin-diff.c| 14 ++
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-config.txt 
b/tools/perf/Documentation/perf-config.txt
index 9365b75fd04f..5b54d47ef713 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -498,6 +498,13 @@ Variables
But if this option is 'no-cache', it will not update the 
build-id cache.
'skip' skips post-processing and does not update the cache.
 
+diff.*::
+   diff.order::
+   This option sets the number of column to sort the result.
+   Default is 0 which means sorting by baseline.
+   Setting it to 1 will sort the result by delta (or other
+   compute method selected).
+
 SEE ALSO
 
 linkperf:perf[1]
diff --git a/tools/perf/Documentation/perf-diff.txt 
b/tools/perf/Documentation/perf-diff.txt
index af80284cd2f6..6ba3bf582d79 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -99,7 +99,11 @@ OPTIONS
 
 -o::
 --order::
-   Specify compute sorting column number.
+   Specify compute sorting column number.  0 means sorting by baseline
+   overhead (default) and 1 means sorting by computed value of column 1
+   (data from the first file other base baseline).  Values more than 1
+   can be used only if enough data files are provided.
+   Default value can be set using diff.order config option.
 
 --percentage::
Determine how to display the overhead percentage of filtered entries.
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 781c9e60bd21..181ff996e039 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -17,6 +17,7 @@
 #include "util/symbol.h"
 #include "util/util.h"
 #include "util/data.h"
+#include "util/config.h"
 
 #include 
 #include 
@@ -1291,6 +1292,17 @@ static int data_init(int argc, const char **argv)
return 0;
 }
 
+static int diff__config(const char *var, const char *value,
+   void *cb __maybe_unused)
+{
+   if (!strcmp(var, "diff.order")) {
+   sort_compute = perf_config_int(var, value);
+   return 0;
+   }
+
+   return 0;
+}
+
 int cmd_diff(int argc, const char **argv, const char *prefix __maybe_unused)
 {
int ret = hists__init();
@@ -1298,6 +1310,8 @@ int cmd_diff(int argc, const char **argv, const char 
*prefix __maybe_unused)
if (ret < 0)
return ret;
 
+   perf_config(diff__config, NULL);
+
argc = parse_options(argc, argv, options, diff_usage, 0);
 
if (symbol__init(NULL) < 0)
-- 
2.11.0

[PATCH 3/3] perf diff: Add diff.compute config option

[Namhyung Kim]

The diff.compute config variable is to set the default compute method of
perf diff command (-c option).  Possible values 'delta' (default),
'delta-abs', 'ratio' and 'wdiff'.

Cc: Taeung Song 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-config.txt |  5 +
 tools/perf/Documentation/perf-diff.txt   |  5 +++--
 tools/perf/builtin-diff.c| 16 +++-
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-config.txt 
b/tools/perf/Documentation/perf-config.txt
index 5b54d47ef713..f2d758dc1edc 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -505,6 +505,11 @@ Variables
Setting it to 1 will sort the result by delta (or other
compute method selected).
 
+   diff.compute::
+   This options sets the method of computing diff result.
+   Possible values are 'delta', 'delta-abs', 'ratio' and
+   'wdiff'.  Default is 'delta'.
+
 SEE ALSO
 
 linkperf:perf[1]
diff --git a/tools/perf/Documentation/perf-diff.txt 
b/tools/perf/Documentation/perf-diff.txt
index 6ba3bf582d79..70f490408262 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -86,8 +86,9 @@ OPTIONS
 
 -c::
 --compute::
-Differential computation selection - delta,ratio,wdiff,delta-abs 
(default is delta).
-See COMPARISON METHODS section for more info.
+Differential computation selection - delta,ratio,wdiff,delta-abs
+   (default is delta).  Default can be changed using diff.compute
+   config option.  See COMPARISON METHODS section for more info.
 
 -p::
 --period::
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 181ff996e039..4b4004d41c6a 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -86,7 +86,7 @@ const char *compute_names[COMPUTE_MAX] = {
[COMPUTE_WEIGHTED_DIFF] = "wdiff",
 };
 
-static int compute;
+static int compute = COMPUTE_DELTA;
 
 static int compute_2_hpp[COMPUTE_MAX] = {
[COMPUTE_DELTA] = PERF_HPP_DIFF__DELTA,
@@ -1299,6 +1299,20 @@ static int diff__config(const char *var, const char 
*value,
sort_compute = perf_config_int(var, value);
return 0;
}
+   if (!strcmp(var, "diff.compute")) {
+   if (!strcmp(value, "delta"))
+   compute = COMPUTE_DELTA;
+   else if (!strcmp(value, "delta-abs"))
+   compute = COMPUTE_DELTA_ABS;
+   else if (!strcmp(value, "ratio"))
+   compute = COMPUTE_RATIO;
+   else if (!strcmp(value, "wdiff"))
+   compute = COMPUTE_WEIGHTED_DIFF;
+   else {
+   pr_err("Invalid compute method: %s\n", value);
+   return -1;
+   }
+   }
 
return 0;
 }
-- 
2.11.0

[PATCH 2/3] perf diff: Add diff.order config option

[Namhyung Kim]

In many cases, I need to look at differences between two data so I often
used the -o option to sort the result base on the difference first.
It'd be nice to have a config option to set it by default.

The diff.order config option is to set the default value of -o/--order
option.

Cc: Taeung Song 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-config.txt |  7 +++
 tools/perf/Documentation/perf-diff.txt   |  6 +-
 tools/perf/builtin-diff.c| 14 ++
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-config.txt 
b/tools/perf/Documentation/perf-config.txt
index 9365b75fd04f..5b54d47ef713 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -498,6 +498,13 @@ Variables
But if this option is 'no-cache', it will not update the 
build-id cache.
'skip' skips post-processing and does not update the cache.
 
+diff.*::
+   diff.order::
+   This option sets the number of column to sort the result.
+   Default is 0 which means sorting by baseline.
+   Setting it to 1 will sort the result by delta (or other
+   compute method selected).
+
 SEE ALSO
 
 linkperf:perf[1]
diff --git a/tools/perf/Documentation/perf-diff.txt 
b/tools/perf/Documentation/perf-diff.txt
index af80284cd2f6..6ba3bf582d79 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -99,7 +99,11 @@ OPTIONS
 
 -o::
 --order::
-   Specify compute sorting column number.
+   Specify compute sorting column number.  0 means sorting by baseline
+   overhead (default) and 1 means sorting by computed value of column 1
+   (data from the first file other base baseline).  Values more than 1
+   can be used only if enough data files are provided.
+   Default value can be set using diff.order config option.
 
 --percentage::
Determine how to display the overhead percentage of filtered entries.
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 781c9e60bd21..181ff996e039 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -17,6 +17,7 @@
 #include "util/symbol.h"
 #include "util/util.h"
 #include "util/data.h"
+#include "util/config.h"
 
 #include 
 #include 
@@ -1291,6 +1292,17 @@ static int data_init(int argc, const char **argv)
return 0;
 }
 
+static int diff__config(const char *var, const char *value,
+   void *cb __maybe_unused)
+{
+   if (!strcmp(var, "diff.order")) {
+   sort_compute = perf_config_int(var, value);
+   return 0;
+   }
+
+   return 0;
+}
+
 int cmd_diff(int argc, const char **argv, const char *prefix __maybe_unused)
 {
int ret = hists__init();
@@ -1298,6 +1310,8 @@ int cmd_diff(int argc, const char **argv, const char 
*prefix __maybe_unused)
if (ret < 0)
return ret;
 
+   perf_config(diff__config, NULL);
+
argc = parse_options(argc, argv, options, diff_usage, 0);
 
if (symbol__init(NULL) < 0)
-- 
2.11.0

[PATCH 3/3] perf diff: Add diff.compute config option

[Namhyung Kim]

The diff.compute config variable is to set the default compute method of
perf diff command (-c option).  Possible values 'delta' (default),
'delta-abs', 'ratio' and 'wdiff'.

Cc: Taeung Song 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-config.txt |  5 +
 tools/perf/Documentation/perf-diff.txt   |  5 +++--
 tools/perf/builtin-diff.c| 16 +++-
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-config.txt 
b/tools/perf/Documentation/perf-config.txt
index 5b54d47ef713..f2d758dc1edc 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -505,6 +505,11 @@ Variables
Setting it to 1 will sort the result by delta (or other
compute method selected).
 
+   diff.compute::
+   This options sets the method of computing diff result.
+   Possible values are 'delta', 'delta-abs', 'ratio' and
+   'wdiff'.  Default is 'delta'.
+
 SEE ALSO
 
 linkperf:perf[1]
diff --git a/tools/perf/Documentation/perf-diff.txt 
b/tools/perf/Documentation/perf-diff.txt
index 6ba3bf582d79..70f490408262 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -86,8 +86,9 @@ OPTIONS
 
 -c::
 --compute::
-Differential computation selection - delta,ratio,wdiff,delta-abs 
(default is delta).
-See COMPARISON METHODS section for more info.
+Differential computation selection - delta,ratio,wdiff,delta-abs
+   (default is delta).  Default can be changed using diff.compute
+   config option.  See COMPARISON METHODS section for more info.
 
 -p::
 --period::
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 181ff996e039..4b4004d41c6a 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -86,7 +86,7 @@ const char *compute_names[COMPUTE_MAX] = {
[COMPUTE_WEIGHTED_DIFF] = "wdiff",
 };
 
-static int compute;
+static int compute = COMPUTE_DELTA;
 
 static int compute_2_hpp[COMPUTE_MAX] = {
[COMPUTE_DELTA] = PERF_HPP_DIFF__DELTA,
@@ -1299,6 +1299,20 @@ static int diff__config(const char *var, const char 
*value,
sort_compute = perf_config_int(var, value);
return 0;
}
+   if (!strcmp(var, "diff.compute")) {
+   if (!strcmp(value, "delta"))
+   compute = COMPUTE_DELTA;
+   else if (!strcmp(value, "delta-abs"))
+   compute = COMPUTE_DELTA_ABS;
+   else if (!strcmp(value, "ratio"))
+   compute = COMPUTE_RATIO;
+   else if (!strcmp(value, "wdiff"))
+   compute = COMPUTE_WEIGHTED_DIFF;
+   else {
+   pr_err("Invalid compute method: %s\n", value);
+   return -1;
+   }
+   }
 
return 0;
 }
-- 
2.11.0

Re: fs, net: deadlock between bind/splice on af_unix

[Cong Wang]

On Tue, Jan 31, 2017 at 10:14 AM, Mateusz Guzik  wrote:
> On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote:
>> Mind being more specific?
>
> Consider 2 threads which bind the same socket, but with different paths.
>
> Currently exactly one file will get created, the one used to bind.
>
> With your patch both threads can succeed creating their respective
> files, but only one will manage to bind. The other one must error out,
> but it already created a file it is unclear what to do with.

In this case, it simply puts the path back:

err = -EINVAL;
if (u->addr)
goto out_up;
[...]

out_up:
mutex_unlock(>bindlock);
out_put:
if (err)
path_put();
out:
return err;


Which is what unix_release_sock() does too:

if (path.dentry)
path_put();

Re: fs, net: deadlock between bind/splice on af_unix

[Cong Wang]

On Tue, Jan 31, 2017 at 10:14 AM, Mateusz Guzik  wrote:
> On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote:
>> Mind being more specific?
>
> Consider 2 threads which bind the same socket, but with different paths.
>
> Currently exactly one file will get created, the one used to bind.
>
> With your patch both threads can succeed creating their respective
> files, but only one will manage to bind. The other one must error out,
> but it already created a file it is unclear what to do with.

In this case, it simply puts the path back:

err = -EINVAL;
if (u->addr)
goto out_up;
[...]

out_up:
mutex_unlock(>bindlock);
out_put:
if (err)
path_put();
out:
return err;


Which is what unix_release_sock() does too:

if (path.dentry)
path_put();

Re: [PATCH 8/9] ARM: sun5i: r8: Merge common controllers into the common DTSI

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Some controllers found in the R8 DTSI actually apply to all of the sun5i
> family. Move those into the common DTSI so that all SoCs can benefit from
> it.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 8/9] ARM: sun5i: r8: Merge common controllers into the common DTSI

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Some controllers found in the R8 DTSI actually apply to all of the sun5i
> family. Move those into the common DTSI so that all SoCs can benefit from
> it.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 7/9] ARM: sun5i: a10s: Merge common controllers into the common DTSI

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Some controllers found in the A10s DTSI actually apply to all of the sun5i
> family. Move those into the common DTSI so that all SoCs can benefit from
> it.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 7/9] ARM: sun5i: a10s: Merge common controllers into the common DTSI

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Some controllers found in the A10s DTSI actually apply to all of the sun5i
> family. Move those into the common DTSI so that all SoCs can benefit from
> it.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

[PATCH 1/3] perf diff: Add 'delta-abs' compute method

[Namhyung Kim]

The 'delta-abs' compute method is same as 'delta' but shows entries with
bigger absolute delta first instead of sorting numerically.  This is
only useful together with -o option.

Below is default output (-c delta):

  $ perf diff -o 1 -c delta | grep -v ^# | head
42.22%   +4.97%  [kernel.kallsyms]  [k] cfb_imageblit
 0.62%   +1.23%  [kernel.kallsyms]  [k] mutex_lock
 +1.15%  [kernel.kallsyms]  [k] copy_user_generic_string
 2.40%   +0.95%  [kernel.kallsyms]  [k] bit_putcs
 0.31%   +0.79%  [kernel.kallsyms]  [k] link_path_walk
 +0.64%  [kernel.kallsyms]  [k] kmem_cache_alloc
 0.00%   +0.57%  [kernel.kallsyms]  [k] __rcu_read_unlock
 +0.45%  [kernel.kallsyms]  [k] alloc_set_pte
 0.16%   +0.45%  [kernel.kallsyms]  [k] menu_select
 +0.41%  ld-2.24.so [.] do_lookup_x

Now with 'delta-abs' it shows entries have bigger delta value either
positive or negative.

  $ perf diff -o 1 -c delta-abs | grep -v ^# | head
42.22%   +4.97%  [kernel.kallsyms]  [k] cfb_imageblit
12.72%   -3.01%  [kernel.kallsyms]  [k] intel_idle
 9.72%   -1.31%  [unknown]  [.] 0x00411343
 0.62%   +1.23%  [kernel.kallsyms]  [k] mutex_lock
 2.40%   +0.95%  [kernel.kallsyms]  [k] bit_putcs
 0.31%   +0.79%  [kernel.kallsyms]  [k] link_path_walk
 1.35%   -0.71%  [kernel.kallsyms]  [k] smp_call_function_single
 0.00%   +0.57%  [kernel.kallsyms]  [k] __rcu_read_unlock
 0.16%   +0.45%  [kernel.kallsyms]  [k] menu_select
 0.72%   -0.44%  [kernel.kallsyms]  [k] lookup_fast

Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-diff.txt |  6 -
 tools/perf/builtin-diff.c  | 46 --
 2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-diff.txt 
b/tools/perf/Documentation/perf-diff.txt
index 3e9490b9c533..af80284cd2f6 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -86,7 +86,7 @@ OPTIONS
 
 -c::
 --compute::
-Differential computation selection - delta,ratio,wdiff (default is 
delta).
+Differential computation selection - delta,ratio,wdiff,delta-abs 
(default is delta).
 See COMPARISON METHODS section for more info.
 
 -p::
@@ -181,6 +181,10 @@ delta
 relative to how entries are filtered.  Use --percentage=absolute to
 prevent such fluctuation.
 
+delta-abs
+~
+Same as 'delta` method, but sort the result with the absolute values.
+
 ratio
 ~
 If specified the 'Ratio' column is displayed with value 'r' computed as:
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 933aeec46f4a..781c9e60bd21 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -30,6 +30,7 @@ enum {
PERF_HPP_DIFF__RATIO,
PERF_HPP_DIFF__WEIGHTED_DIFF,
PERF_HPP_DIFF__FORMULA,
+   PERF_HPP_DIFF__DELTA_ABS,
 
PERF_HPP_DIFF__MAX_INDEX
 };
@@ -73,11 +74,13 @@ enum {
COMPUTE_DELTA,
COMPUTE_RATIO,
COMPUTE_WEIGHTED_DIFF,
+   COMPUTE_DELTA_ABS,
COMPUTE_MAX,
 };
 
 const char *compute_names[COMPUTE_MAX] = {
[COMPUTE_DELTA] = "delta",
+   [COMPUTE_DELTA_ABS] = "delta-abs",
[COMPUTE_RATIO] = "ratio",
[COMPUTE_WEIGHTED_DIFF] = "wdiff",
 };
@@ -86,6 +89,7 @@ static int compute;
 
 static int compute_2_hpp[COMPUTE_MAX] = {
[COMPUTE_DELTA] = PERF_HPP_DIFF__DELTA,
+   [COMPUTE_DELTA_ABS] = PERF_HPP_DIFF__DELTA_ABS,
[COMPUTE_RATIO] = PERF_HPP_DIFF__RATIO,
[COMPUTE_WEIGHTED_DIFF] = PERF_HPP_DIFF__WEIGHTED_DIFF,
 };
@@ -111,6 +115,10 @@ static struct header_column {
.name  = "Delta",
.width = 7,
},
+   [PERF_HPP_DIFF__DELTA_ABS] = {
+   .name  = "Delta Abs",
+   .width = 7,
+   },
[PERF_HPP_DIFF__RATIO] = {
.name  = "Ratio",
.width = 14,
@@ -298,6 +306,7 @@ static int formula_fprintf(struct hist_entry *he, struct 
hist_entry *pair,
 {
switch (compute) {
case COMPUTE_DELTA:
+   case COMPUTE_DELTA_ABS:
return formula_delta(he, pair, buf, size);
case COMPUTE_RATIO:
return formula_ratio(he, pair, buf, size);
@@ -461,6 +470,7 @@ static void hists__precompute(struct hists *hists)
 
switch (compute) {
case COMPUTE_DELTA:
+   case COMPUTE_DELTA_ABS:
compute_delta(he, pair);
break;
case COMPUTE_RATIO:
@@ -498,6 +508,13 @@ __hist_entry__cmp_compute(struct hist_entry *left, struct 
hist_entry *right,
 
return cmp_doubles(l, r);
}
+   case COMPUTE_DELTA_ABS:
+   {
+   double l = fabs(left->diff.period_ratio_delta);
+  

[PATCH 1/3] perf diff: Add 'delta-abs' compute method

[Namhyung Kim]

The 'delta-abs' compute method is same as 'delta' but shows entries with
bigger absolute delta first instead of sorting numerically.  This is
only useful together with -o option.

Below is default output (-c delta):

  $ perf diff -o 1 -c delta | grep -v ^# | head
42.22%   +4.97%  [kernel.kallsyms]  [k] cfb_imageblit
 0.62%   +1.23%  [kernel.kallsyms]  [k] mutex_lock
 +1.15%  [kernel.kallsyms]  [k] copy_user_generic_string
 2.40%   +0.95%  [kernel.kallsyms]  [k] bit_putcs
 0.31%   +0.79%  [kernel.kallsyms]  [k] link_path_walk
 +0.64%  [kernel.kallsyms]  [k] kmem_cache_alloc
 0.00%   +0.57%  [kernel.kallsyms]  [k] __rcu_read_unlock
 +0.45%  [kernel.kallsyms]  [k] alloc_set_pte
 0.16%   +0.45%  [kernel.kallsyms]  [k] menu_select
 +0.41%  ld-2.24.so [.] do_lookup_x

Now with 'delta-abs' it shows entries have bigger delta value either
positive or negative.

  $ perf diff -o 1 -c delta-abs | grep -v ^# | head
42.22%   +4.97%  [kernel.kallsyms]  [k] cfb_imageblit
12.72%   -3.01%  [kernel.kallsyms]  [k] intel_idle
 9.72%   -1.31%  [unknown]  [.] 0x00411343
 0.62%   +1.23%  [kernel.kallsyms]  [k] mutex_lock
 2.40%   +0.95%  [kernel.kallsyms]  [k] bit_putcs
 0.31%   +0.79%  [kernel.kallsyms]  [k] link_path_walk
 1.35%   -0.71%  [kernel.kallsyms]  [k] smp_call_function_single
 0.00%   +0.57%  [kernel.kallsyms]  [k] __rcu_read_unlock
 0.16%   +0.45%  [kernel.kallsyms]  [k] menu_select
 0.72%   -0.44%  [kernel.kallsyms]  [k] lookup_fast

Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-diff.txt |  6 -
 tools/perf/builtin-diff.c  | 46 --
 2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-diff.txt 
b/tools/perf/Documentation/perf-diff.txt
index 3e9490b9c533..af80284cd2f6 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -86,7 +86,7 @@ OPTIONS
 
 -c::
 --compute::
-Differential computation selection - delta,ratio,wdiff (default is 
delta).
+Differential computation selection - delta,ratio,wdiff,delta-abs 
(default is delta).
 See COMPARISON METHODS section for more info.
 
 -p::
@@ -181,6 +181,10 @@ delta
 relative to how entries are filtered.  Use --percentage=absolute to
 prevent such fluctuation.
 
+delta-abs
+~
+Same as 'delta` method, but sort the result with the absolute values.
+
 ratio
 ~
 If specified the 'Ratio' column is displayed with value 'r' computed as:
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 933aeec46f4a..781c9e60bd21 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -30,6 +30,7 @@ enum {
PERF_HPP_DIFF__RATIO,
PERF_HPP_DIFF__WEIGHTED_DIFF,
PERF_HPP_DIFF__FORMULA,
+   PERF_HPP_DIFF__DELTA_ABS,
 
PERF_HPP_DIFF__MAX_INDEX
 };
@@ -73,11 +74,13 @@ enum {
COMPUTE_DELTA,
COMPUTE_RATIO,
COMPUTE_WEIGHTED_DIFF,
+   COMPUTE_DELTA_ABS,
COMPUTE_MAX,
 };
 
 const char *compute_names[COMPUTE_MAX] = {
[COMPUTE_DELTA] = "delta",
+   [COMPUTE_DELTA_ABS] = "delta-abs",
[COMPUTE_RATIO] = "ratio",
[COMPUTE_WEIGHTED_DIFF] = "wdiff",
 };
@@ -86,6 +89,7 @@ static int compute;
 
 static int compute_2_hpp[COMPUTE_MAX] = {
[COMPUTE_DELTA] = PERF_HPP_DIFF__DELTA,
+   [COMPUTE_DELTA_ABS] = PERF_HPP_DIFF__DELTA_ABS,
[COMPUTE_RATIO] = PERF_HPP_DIFF__RATIO,
[COMPUTE_WEIGHTED_DIFF] = PERF_HPP_DIFF__WEIGHTED_DIFF,
 };
@@ -111,6 +115,10 @@ static struct header_column {
.name  = "Delta",
.width = 7,
},
+   [PERF_HPP_DIFF__DELTA_ABS] = {
+   .name  = "Delta Abs",
+   .width = 7,
+   },
[PERF_HPP_DIFF__RATIO] = {
.name  = "Ratio",
.width = 14,
@@ -298,6 +306,7 @@ static int formula_fprintf(struct hist_entry *he, struct 
hist_entry *pair,
 {
switch (compute) {
case COMPUTE_DELTA:
+   case COMPUTE_DELTA_ABS:
return formula_delta(he, pair, buf, size);
case COMPUTE_RATIO:
return formula_ratio(he, pair, buf, size);
@@ -461,6 +470,7 @@ static void hists__precompute(struct hists *hists)
 
switch (compute) {
case COMPUTE_DELTA:
+   case COMPUTE_DELTA_ABS:
compute_delta(he, pair);
break;
case COMPUTE_RATIO:
@@ -498,6 +508,13 @@ __hist_entry__cmp_compute(struct hist_entry *left, struct 
hist_entry *right,
 
return cmp_doubles(l, r);
}
+   case COMPUTE_DELTA_ABS:
+   {
+   double l = fabs(left->diff.period_ratio_delta);
+   double r = 

[PATCHSET 0/3] perf diff: Introduce delta-abs compute method

[Namhyung Kim]

Hello,

This patchset adds 'delta-abs' compute method to -c/--compute option.
The 'delta-abs' is same as 'delta' but shows entries with bigger
absolute delta first instead of sorting numerically.  This is only
useful together with -o option.

Below is default output (-c delta):

  $ perf diff -o 1 -c delta | grep -v ^# | head
42.22%   +4.97%  [kernel.kallsyms]  [k] cfb_imageblit
 0.62%   +1.23%  [kernel.kallsyms]  [k] mutex_lock
 +1.15%  [kernel.kallsyms]  [k] copy_user_generic_string
 2.40%   +0.95%  [kernel.kallsyms]  [k] bit_putcs
 0.31%   +0.79%  [kernel.kallsyms]  [k] link_path_walk
 +0.64%  [kernel.kallsyms]  [k] kmem_cache_alloc
 0.00%   +0.57%  [kernel.kallsyms]  [k] __rcu_read_unlock
 +0.45%  [kernel.kallsyms]  [k] alloc_set_pte
 0.16%   +0.45%  [kernel.kallsyms]  [k] menu_select
 +0.41%  ld-2.24.so [.] do_lookup_x

Now with 'delta-abs' it shows entries have bigger delta value either
positive or negative.

  $ perf diff -o 1 -c delta-abs | grep -v ^# | head
42.22%   +4.97%  [kernel.kallsyms]  [k] cfb_imageblit
12.72%   -3.01%  [kernel.kallsyms]  [k] intel_idle
 9.72%   -1.31%  [unknown]  [.] 0x00411343
 0.62%   +1.23%  [kernel.kallsyms]  [k] mutex_lock
 +1.15%  [kernel.kallsyms]  [k] copy_user_generic_string
 2.40%   +0.95%  [kernel.kallsyms]  [k] bit_putcs
 0.31%   +0.79%  [kernel.kallsyms]  [k] link_path_walk
 1.35%   -0.71%  [kernel.kallsyms]  [k] smp_call_function_single
 +0.64%  [kernel.kallsyms]  [k] kmem_cache_alloc
 0.00%   +0.57%  [kernel.kallsyms]  [k] __rcu_read_unlock

The patch 2 and 3 are to add config options to control the default
behavior of perf diff command.  I think that it's worth consider
changing the default to use 'delta-abs' method since users want to see
where the difference occurs actually (either positive or negative) IMHO.

The code is avaiable at 'perf/diff-delta-abs-v1' branch in

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung


Namhyung Kim (3):
  perf diff: Add 'delta-abs' compute method
  perf diff: Add diff.order config option
  perf diff: Add diff.compute config option

 tools/perf/Documentation/perf-config.txt | 12 +
 tools/perf/Documentation/perf-diff.txt   | 15 +--
 tools/perf/builtin-diff.c| 76 ++--
 3 files changed, 97 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCHSET 0/3] perf diff: Introduce delta-abs compute method

[Namhyung Kim]

Hello,

This patchset adds 'delta-abs' compute method to -c/--compute option.
The 'delta-abs' is same as 'delta' but shows entries with bigger
absolute delta first instead of sorting numerically.  This is only
useful together with -o option.

Below is default output (-c delta):

  $ perf diff -o 1 -c delta | grep -v ^# | head
42.22%   +4.97%  [kernel.kallsyms]  [k] cfb_imageblit
 0.62%   +1.23%  [kernel.kallsyms]  [k] mutex_lock
 +1.15%  [kernel.kallsyms]  [k] copy_user_generic_string
 2.40%   +0.95%  [kernel.kallsyms]  [k] bit_putcs
 0.31%   +0.79%  [kernel.kallsyms]  [k] link_path_walk
 +0.64%  [kernel.kallsyms]  [k] kmem_cache_alloc
 0.00%   +0.57%  [kernel.kallsyms]  [k] __rcu_read_unlock
 +0.45%  [kernel.kallsyms]  [k] alloc_set_pte
 0.16%   +0.45%  [kernel.kallsyms]  [k] menu_select
 +0.41%  ld-2.24.so [.] do_lookup_x

Now with 'delta-abs' it shows entries have bigger delta value either
positive or negative.

  $ perf diff -o 1 -c delta-abs | grep -v ^# | head
42.22%   +4.97%  [kernel.kallsyms]  [k] cfb_imageblit
12.72%   -3.01%  [kernel.kallsyms]  [k] intel_idle
 9.72%   -1.31%  [unknown]  [.] 0x00411343
 0.62%   +1.23%  [kernel.kallsyms]  [k] mutex_lock
 +1.15%  [kernel.kallsyms]  [k] copy_user_generic_string
 2.40%   +0.95%  [kernel.kallsyms]  [k] bit_putcs
 0.31%   +0.79%  [kernel.kallsyms]  [k] link_path_walk
 1.35%   -0.71%  [kernel.kallsyms]  [k] smp_call_function_single
 +0.64%  [kernel.kallsyms]  [k] kmem_cache_alloc
 0.00%   +0.57%  [kernel.kallsyms]  [k] __rcu_read_unlock

The patch 2 and 3 are to add config options to control the default
behavior of perf diff command.  I think that it's worth consider
changing the default to use 'delta-abs' method since users want to see
where the difference occurs actually (either positive or negative) IMHO.

The code is avaiable at 'perf/diff-delta-abs-v1' branch in

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung


Namhyung Kim (3):
  perf diff: Add 'delta-abs' compute method
  perf diff: Add diff.order config option
  perf diff: Add diff.compute config option

 tools/perf/Documentation/perf-config.txt | 12 +
 tools/perf/Documentation/perf-diff.txt   | 15 +--
 tools/perf/builtin-diff.c| 76 ++--
 3 files changed, 97 insertions(+), 6 deletions(-)

-- 
2.11.0

Re: [PATCH 6/9] ARM: sun5i: a13: Merge common controllers into the common DTSI

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Some controllers found in the A13 DTSI actually apply to all of the sun5i
> family. Move those into the common DTSI so that all SoCs can benefit from
> it.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 6/9] ARM: sun5i: a13: Merge common controllers into the common DTSI

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Some controllers found in the A13 DTSI actually apply to all of the sun5i
> family. Move those into the common DTSI so that all SoCs can benefit from
> it.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 5/9] ARM: sun5i: Rename UART3 flow control pins

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> The UART3 pin group for the CTS and RTS signals doesn't follow our usual
> pattern. Rename it so that it matches.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 4/9] ARM: sun5i: Add UART2 pin group

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> There's one UART2 pin group that can be used across all sun5i SoCs.
> However, the A10s already has one pin group for that controller.
>
> Change the index of the one in the A10s DTSI, and add the common one to
> sun5i.dtsi

Kind of goes against the tradition of not adding stuff no one uses?
Perhaps add a comment instead? I'm OK either way though.

>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 5/9] ARM: sun5i: Rename UART3 flow control pins

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> The UART3 pin group for the CTS and RTS signals doesn't follow our usual
> pattern. Rename it so that it matches.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 4/9] ARM: sun5i: Add UART2 pin group

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> There's one UART2 pin group that can be used across all sun5i SoCs.
> However, the A10s already has one pin group for that controller.
>
> Change the index of the one in the A10s DTSI, and add the common one to
> sun5i.dtsi

Kind of goes against the tradition of not adding stuff no one uses?
Perhaps add a comment instead? I'm OK either way though.

>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 3/9] ARM: sunxi: Rename pwm0_pins to match our usual pattern

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> The pwm0_pins group name is suggesting that this is the only option usable
> for the PWM0 on the SoCs it's declared on. However, this is not the case
> and defining a second pwm0 group would be quite weird given the name of the
> first group.

Can you elaborate on the second pwm0 option? I'm not seeing it in my datasheets.

ChenYu

>
> Rename it so that it matches our usual pattern.
>
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts |  2 +-
>  arch/arm/boot/dts/sun5i.dtsi   | 10 +-
>  arch/arm/boot/dts/sun8i-a23-a33.dtsi   |  2 +-
>  arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi   |  2 +-
>  4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts 
> b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
> index 42435454acef..1bc87523b37c 100644
> --- a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
> @@ -157,7 +157,7 @@
>
>   {
> pinctrl-names = "default";
> -   pinctrl-0 = <_pins>;
> +   pinctrl-0 = <_pins_a>;
> status = "okay";
>  };
>
> diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
> index a9574a6cd95c..fce3ec693531 100644
> --- a/arch/arm/boot/dts/sun5i.dtsi
> +++ b/arch/arm/boot/dts/sun5i.dtsi
> @@ -321,6 +321,11 @@
> bias-pull-up;
> };
>
> +   pwm0_pins_a: pwm0@0 {
> +   pins = "PB2";
> +   function = "pwm0";
> +   };
> +
> spi2_pins_a: spi2@0 {
> pins = "PE1", "PE2", "PE3";
> function = "spi2";
> @@ -340,11 +345,6 @@
> pins = "PG11", "PG12";
> function = "uart3";
> };
> -
> -   pwm0_pins: pwm0 {
> -   pins = "PB2";
> -   function = "pwm";
> -   };
> };
>
> timer@01c20c00 {
> diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
> b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> index 35008b78d899..b558d318a72e 100644
> --- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> @@ -316,7 +316,7 @@
> bias-pull-up;
> };
>
> -   pwm0_pins: pwm0 {
> +   pwm0_pins_a: pwm0 {
> pins = "PH0";
> function = "pwm0";
> };
> diff --git a/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi 
> b/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
> index b8241462fcea..5cd891942fe3 100644
> --- a/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
> @@ -78,6 +78,6 @@
>
>   {
> pinctrl-names = "default";
> -   pinctrl-0 = <_pins>;
> +   pinctrl-0 = <_pins_a>;
> status = "okay";
>  };
> --
> git-series 0.8.11

Re: [PATCH 3/9] ARM: sunxi: Rename pwm0_pins to match our usual pattern

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> The pwm0_pins group name is suggesting that this is the only option usable
> for the PWM0 on the SoCs it's declared on. However, this is not the case
> and defining a second pwm0 group would be quite weird given the name of the
> first group.

Can you elaborate on the second pwm0 option? I'm not seeing it in my datasheets.

ChenYu

>
> Rename it so that it matches our usual pattern.
>
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts |  2 +-
>  arch/arm/boot/dts/sun5i.dtsi   | 10 +-
>  arch/arm/boot/dts/sun8i-a23-a33.dtsi   |  2 +-
>  arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi   |  2 +-
>  4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts 
> b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
> index 42435454acef..1bc87523b37c 100644
> --- a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
> @@ -157,7 +157,7 @@
>
>   {
> pinctrl-names = "default";
> -   pinctrl-0 = <_pins>;
> +   pinctrl-0 = <_pins_a>;
> status = "okay";
>  };
>
> diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
> index a9574a6cd95c..fce3ec693531 100644
> --- a/arch/arm/boot/dts/sun5i.dtsi
> +++ b/arch/arm/boot/dts/sun5i.dtsi
> @@ -321,6 +321,11 @@
> bias-pull-up;
> };
>
> +   pwm0_pins_a: pwm0@0 {
> +   pins = "PB2";
> +   function = "pwm0";
> +   };
> +
> spi2_pins_a: spi2@0 {
> pins = "PE1", "PE2", "PE3";
> function = "spi2";
> @@ -340,11 +345,6 @@
> pins = "PG11", "PG12";
> function = "uart3";
> };
> -
> -   pwm0_pins: pwm0 {
> -   pins = "PB2";
> -   function = "pwm";
> -   };
> };
>
> timer@01c20c00 {
> diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
> b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> index 35008b78d899..b558d318a72e 100644
> --- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> @@ -316,7 +316,7 @@
> bias-pull-up;
> };
>
> -   pwm0_pins: pwm0 {
> +   pwm0_pins_a: pwm0 {
> pins = "PH0";
> function = "pwm0";
> };
> diff --git a/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi 
> b/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
> index b8241462fcea..5cd891942fe3 100644
> --- a/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
> @@ -78,6 +78,6 @@
>
>   {
> pinctrl-names = "default";
> -   pinctrl-0 = <_pins>;
> +   pinctrl-0 = <_pins_a>;
> status = "okay";
>  };
> --
> git-series 0.8.11

Re: [PATCH v4 net-next] net: mvneta: implement .set_wol and .get_wol

[Jisheng Zhang]

On Mon, 6 Feb 2017 15:08:48 +0800 Jisheng Zhang wrote:

> Hi Andrew,
> 
> On Mon, 23 Jan 2017 19:10:34 +0100 Andrew Lunn wrote:
> 
> > 
> > On Mon, Jan 23, 2017 at 02:55:07PM +0800, Jisheng Zhang wrote:  
> > > From: Jingju Hou 
> > > 
> > > From: Jingju Hou 
> > > 
> > > The mvneta itself does not support WOL, but the PHY might.
> > > So pass the calls to the PHY
> > > 
> > > Signed-off-by: Jingju Hou 
> > > Signed-off-by: Jisheng Zhang 
> > > ---
> > > since v3:
> > >  - really fix the build error
> > 
> > Keep trying
> > 
> > But maybe tomorrow, after you have taken the pause Dave said you
> > should take, and maybe ask Jingju to really review it, in detail.  
> 
> Jingju is a newbie in the Linux kernel community. She made a mistake
> when trying to send the old patch. I picked up her patch when she went
> on vacation, fixed the error and send it out on behalf of her.
> 
> >   
> > > 
> > > since v2,v1:
> > >  - using phy_dev member in struct net_device
> > >  - add commit msg
> > > 
> > >  drivers/net/ethernet/marvell/mvneta.c | 21 +
> > >  1 file changed, 21 insertions(+)
> > > 
> > > diff --git a/drivers/net/ethernet/marvell/mvneta.c 
> > > b/drivers/net/ethernet/marvell/mvneta.c
> > > index 6dcc951af0ff..02611fa1c3b8 100644
> > > --- a/drivers/net/ethernet/marvell/mvneta.c
> > > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > > @@ -3929,6 +3929,25 @@ static int mvneta_ethtool_get_rxfh(struct 
> > > net_device *dev, u32 *indir, u8 *key,
> > >   return 0;
> > >  }
> > >  
> > > +static void mvneta_ethtool_get_wol(struct net_device *dev,
> > > +struct ethtool_wolinfo *wol)
> > > +{
> > > + wol->supported = 0;
> > > + wol->wolopts = 0;
> > > +
> > > + if (dev->phydev)
> > > + return phy_ethtool_get_wol(dev->phydev, wol);
> > 
> > This is a void function.  And you are returning a value.  And
> > phy_ethtool_get_wol() is also a void function, so does not actually
> > return anything.  
> 
> Thanks for catching it, fixed in v4, can you please review?

typo, fixed in v5. 

Re: [PATCH v4 net-next] net: mvneta: implement .set_wol and .get_wol

[Jisheng Zhang]

On Mon, 6 Feb 2017 15:08:48 +0800 Jisheng Zhang wrote:

> Hi Andrew,
> 
> On Mon, 23 Jan 2017 19:10:34 +0100 Andrew Lunn wrote:
> 
> > 
> > On Mon, Jan 23, 2017 at 02:55:07PM +0800, Jisheng Zhang wrote:  
> > > From: Jingju Hou 
> > > 
> > > From: Jingju Hou 
> > > 
> > > The mvneta itself does not support WOL, but the PHY might.
> > > So pass the calls to the PHY
> > > 
> > > Signed-off-by: Jingju Hou 
> > > Signed-off-by: Jisheng Zhang 
> > > ---
> > > since v3:
> > >  - really fix the build error
> > 
> > Keep trying
> > 
> > But maybe tomorrow, after you have taken the pause Dave said you
> > should take, and maybe ask Jingju to really review it, in detail.  
> 
> Jingju is a newbie in the Linux kernel community. She made a mistake
> when trying to send the old patch. I picked up her patch when she went
> on vacation, fixed the error and send it out on behalf of her.
> 
> >   
> > > 
> > > since v2,v1:
> > >  - using phy_dev member in struct net_device
> > >  - add commit msg
> > > 
> > >  drivers/net/ethernet/marvell/mvneta.c | 21 +
> > >  1 file changed, 21 insertions(+)
> > > 
> > > diff --git a/drivers/net/ethernet/marvell/mvneta.c 
> > > b/drivers/net/ethernet/marvell/mvneta.c
> > > index 6dcc951af0ff..02611fa1c3b8 100644
> > > --- a/drivers/net/ethernet/marvell/mvneta.c
> > > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > > @@ -3929,6 +3929,25 @@ static int mvneta_ethtool_get_rxfh(struct 
> > > net_device *dev, u32 *indir, u8 *key,
> > >   return 0;
> > >  }
> > >  
> > > +static void mvneta_ethtool_get_wol(struct net_device *dev,
> > > +struct ethtool_wolinfo *wol)
> > > +{
> > > + wol->supported = 0;
> > > + wol->wolopts = 0;
> > > +
> > > + if (dev->phydev)
> > > + return phy_ethtool_get_wol(dev->phydev, wol);
> > 
> > This is a void function.  And you are returning a value.  And
> > phy_ethtool_get_wol() is also a void function, so does not actually
> > return anything.  
> 
> Thanks for catching it, fixed in v4, can you please review?

typo, fixed in v5. 

Re: [PATCH v4 net-next] net: mvneta: implement .set_wol and .get_wol

[Jisheng Zhang]

Hi Andrew,

On Mon, 23 Jan 2017 19:10:34 +0100 Andrew Lunn wrote:

> 
> On Mon, Jan 23, 2017 at 02:55:07PM +0800, Jisheng Zhang wrote:
> > From: Jingju Hou 
> > 
> > From: Jingju Hou 
> > 
> > The mvneta itself does not support WOL, but the PHY might.
> > So pass the calls to the PHY
> > 
> > Signed-off-by: Jingju Hou 
> > Signed-off-by: Jisheng Zhang 
> > ---
> > since v3:
> >  - really fix the build error  
> 
> Keep trying
> 
> But maybe tomorrow, after you have taken the pause Dave said you
> should take, and maybe ask Jingju to really review it, in detail.

Jingju is a newbie in the Linux kernel community. She made a mistake
when trying to send the old patch. I picked up her patch when she went
on vacation, fixed the error and send it out on behalf of her.

> 
> > 
> > since v2,v1:
> >  - using phy_dev member in struct net_device
> >  - add commit msg
> > 
> >  drivers/net/ethernet/marvell/mvneta.c | 21 +
> >  1 file changed, 21 insertions(+)
> > 
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c 
> > b/drivers/net/ethernet/marvell/mvneta.c
> > index 6dcc951af0ff..02611fa1c3b8 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -3929,6 +3929,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device 
> > *dev, u32 *indir, u8 *key,
> > return 0;
> >  }
> >  
> > +static void mvneta_ethtool_get_wol(struct net_device *dev,
> > +  struct ethtool_wolinfo *wol)
> > +{
> > +   wol->supported = 0;
> > +   wol->wolopts = 0;
> > +
> > +   if (dev->phydev)
> > +   return phy_ethtool_get_wol(dev->phydev, wol);  
> 
> This is a void function.  And you are returning a value.  And
> phy_ethtool_get_wol() is also a void function, so does not actually
> return anything.

Thanks for catching it, fixed in v4, can you please review?

Re: [PATCH v4 net-next] net: mvneta: implement .set_wol and .get_wol

[Jisheng Zhang]

Hi Andrew,

On Mon, 23 Jan 2017 19:10:34 +0100 Andrew Lunn wrote:

> 
> On Mon, Jan 23, 2017 at 02:55:07PM +0800, Jisheng Zhang wrote:
> > From: Jingju Hou 
> > 
> > From: Jingju Hou 
> > 
> > The mvneta itself does not support WOL, but the PHY might.
> > So pass the calls to the PHY
> > 
> > Signed-off-by: Jingju Hou 
> > Signed-off-by: Jisheng Zhang 
> > ---
> > since v3:
> >  - really fix the build error  
> 
> Keep trying
> 
> But maybe tomorrow, after you have taken the pause Dave said you
> should take, and maybe ask Jingju to really review it, in detail.

Jingju is a newbie in the Linux kernel community. She made a mistake
when trying to send the old patch. I picked up her patch when she went
on vacation, fixed the error and send it out on behalf of her.

> 
> > 
> > since v2,v1:
> >  - using phy_dev member in struct net_device
> >  - add commit msg
> > 
> >  drivers/net/ethernet/marvell/mvneta.c | 21 +
> >  1 file changed, 21 insertions(+)
> > 
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c 
> > b/drivers/net/ethernet/marvell/mvneta.c
> > index 6dcc951af0ff..02611fa1c3b8 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -3929,6 +3929,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device 
> > *dev, u32 *indir, u8 *key,
> > return 0;
> >  }
> >  
> > +static void mvneta_ethtool_get_wol(struct net_device *dev,
> > +  struct ethtool_wolinfo *wol)
> > +{
> > +   wol->supported = 0;
> > +   wol->wolopts = 0;
> > +
> > +   if (dev->phydev)
> > +   return phy_ethtool_get_wol(dev->phydev, wol);  
> 
> This is a void function.  And you are returning a value.  And
> phy_ethtool_get_wol() is also a void function, so does not actually
> return anything.

Thanks for catching it, fixed in v4, can you please review?

Re: [PATCH 2/9] ARM: sun5i: a10s: switch simple framebuffer indices

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Of the three simple framebuffer setups we have in the A10s, two of them can
> be shared with the other SoCs from the sun5i family (LCD panel and
> composite output).
>
> However, the only one we cannot share is the HDMI, which is the first
> listed in the A10s DTSI. In order to make it more logical and so that we
> can share the framebuffer nodes in the common DTSI, reorder those nodes.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 2/9] ARM: sun5i: a10s: switch simple framebuffer indices

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> Of the three simple framebuffer setups we have in the A10s, two of them can
> be shared with the other SoCs from the sun5i family (LCD panel and
> composite output).
>
> However, the only one we cannot share is the HDMI, which is the first
> listed in the A10s DTSI. In order to make it more logical and so that we
> can share the framebuffer nodes in the common DTSI, reorder those nodes.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 1/9] ARM: sun5i: A10s: Switch the EMAC pins indices

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> One of the pins group for the EMAC can be used by all the SoCs of the sun5i
> family, and as such can be moved to the common DTSI.
>
> Unfortunately, this group is the second one we declare in our DT for now.
> Make it the first one so that it's more logical and consistent with the
> rest of our DTs before moving it.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 1/9] ARM: sun5i: A10s: Switch the EMAC pins indices

[Chen-Yu Tsai]

On Mon, Feb 6, 2017 at 2:49 AM, Maxime Ripard
 wrote:
> One of the pins group for the EMAC can be used by all the SoCs of the sun5i
> family, and as such can be moved to the common DTSI.
>
> Unfortunately, this group is the second one we declare in our DT for now.
> Make it the first one so that it's more logical and consistent with the
> rest of our DTs before moving it.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH v3 5/7] dt-bindings: display: Add common rotation property

[Thierry Reding]

On Fri, Feb 03, 2017 at 01:16:45PM +0100, Noralf Trønnes wrote:
> Thierry, please have a look at this.
> In which direction should we rotate to match how drm rotation works?
> 
> 
> Den 01.02.2017 18.41, skrev Rob Herring:
> > On Tue, Jan 31, 2017 at 05:03:17PM +0100, Noralf Trønnes wrote:
> > > Display panels can be oriented many ways, especially in the embedded
> > > world. The rotation property is a way to describe this orientation.
> > > The counter clockwise direction is chosen because that's what fbdev
> > > and drm use.
> > The h/w mounting is rotated counter clockwise, so the framebuffers'
> > contents are rotated clockwise, right?

Given that this describes the rotation of the panel, I think it should
be described in terms of how the panel is rotated, not how the
framebuffer needs to be rotated. Using counter-clockwise, as described
in this binding seems fine to me.

It would have to be up to fbdev and DRM/KMS to transform that into a
clockwise rotation for the framebuffer, CRTC, plane, ...

Ideally with some sort of helper.

Thierry

> > 
> > > Signed-off-by: Noralf Trønnes 
> > > ---
> > >   Documentation/devicetree/bindings/display/display.txt | 4 
> > This is panel property, so bindings/display/panel/panel.txt.
> > 
> > >   1 file changed, 4 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/display/display.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/display.txt 
> > > b/Documentation/devicetree/bindings/display/display.txt
> > > new file mode 100644
> > > index 000..e2e6867
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/display.txt
> > > @@ -0,0 +1,4 @@
> > > +Common display properties
> > > +-
> > > +
> > > +- rotation:  Display rotation in degrees counter clockwise 
> > > (0,90,180,270)
> > > -- 
> > > 2.10.2
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


signature.asc
Description: PGP signature

Re: [PATCH v3 5/7] dt-bindings: display: Add common rotation property

[Thierry Reding]

On Fri, Feb 03, 2017 at 01:16:45PM +0100, Noralf Trønnes wrote:
> Thierry, please have a look at this.
> In which direction should we rotate to match how drm rotation works?
> 
> 
> Den 01.02.2017 18.41, skrev Rob Herring:
> > On Tue, Jan 31, 2017 at 05:03:17PM +0100, Noralf Trønnes wrote:
> > > Display panels can be oriented many ways, especially in the embedded
> > > world. The rotation property is a way to describe this orientation.
> > > The counter clockwise direction is chosen because that's what fbdev
> > > and drm use.
> > The h/w mounting is rotated counter clockwise, so the framebuffers'
> > contents are rotated clockwise, right?

Given that this describes the rotation of the panel, I think it should
be described in terms of how the panel is rotated, not how the
framebuffer needs to be rotated. Using counter-clockwise, as described
in this binding seems fine to me.

It would have to be up to fbdev and DRM/KMS to transform that into a
clockwise rotation for the framebuffer, CRTC, plane, ...

Ideally with some sort of helper.

Thierry

> > 
> > > Signed-off-by: Noralf Trønnes 
> > > ---
> > >   Documentation/devicetree/bindings/display/display.txt | 4 
> > This is panel property, so bindings/display/panel/panel.txt.
> > 
> > >   1 file changed, 4 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/display/display.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/display.txt 
> > > b/Documentation/devicetree/bindings/display/display.txt
> > > new file mode 100644
> > > index 000..e2e6867
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/display.txt
> > > @@ -0,0 +1,4 @@
> > > +Common display properties
> > > +-
> > > +
> > > +- rotation:  Display rotation in degrees counter clockwise 
> > > (0,90,180,270)
> > > -- 
> > > 2.10.2
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


signature.asc
Description: PGP signature

Re: [PATCH 2/6] usb: mtu3: add reference clock

[Chunfeng Yun]

On Wed, 2017-01-25 at 00:23 +0100, Matthias Brugger wrote:
> 
> On 01/20/2017 03:20 AM, Chunfeng Yun wrote:
> > On Thu, 2017-01-19 at 13:22 +0100, Matthias Brugger wrote:
> >>
> >> On 18/01/17 07:08, Chunfeng Yun wrote:
> >>> usually, the reference clock comes from 26M oscillator directly,
> >>> but some SoCs are not, add it for compatibility.
> >>>
> >>> Signed-off-by: Chunfeng Yun 
> >>> ---
> >>>  drivers/usb/mtu3/mtu3.h  |1 +
> >>>  drivers/usb/mtu3/mtu3_plat.c |   21 +++--
> >>>  2 files changed, 20 insertions(+), 2 deletions(-)
> > [...]
> >>> @@ -154,6 +162,7 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> >>>  static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
> >>>  {
> >>>   clk_disable_unprepare(ssusb->sys_clk);
> >>> + clk_disable_unprepare(ssusb->ref_clk);
> >>>   regulator_disable(ssusb->vusb33);
> >>>   ssusb_phy_power_off(ssusb);
> >>>   ssusb_phy_exit(ssusb);
> >>> @@ -216,6 +225,12 @@ static int get_ssusb_rscs(struct platform_device 
> >>> *pdev, struct ssusb_mtk *ssusb)
> >>>   return PTR_ERR(ssusb->sys_clk);
> >>>   }
> >>>
> >>> + ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
> >>> + if (IS_ERR(ssusb->ref_clk)) {
> >>> + dev_err(dev, "failed to get ref clock\n");
> >>> + return PTR_ERR(ssusb->ref_clk);
> >>> + }
> >>> +
> >>
> >> That would break older dts bindings, right?
> > Yes, So I send a new patch for the related dts. Maybe it's not a
> > problem, only one dts file need be updated currently.
> >
> >> ref_ck must be optional for the code.
> > I tend to make it be optional for the dts, but not for the code.
> > There are some "fixed-clock" which can be treated as dummy ones, and if
> > a clock is really optional, we can use one fixed-clock in dts, and keep
> > the code simple.
> > In fact, the reference clock is essential for usb controller.
> 
> Well the thing is that there are devices in the field with an older dtb 
> which would break on a newer kernel. That's why we need to make it work 
> with the old dtb in the code as well.
> 
Happy Chinese New Year!

Ok, I will make it optional.

Thanks and sorry for later reply.

> Regards,
> Matthias
> 
> >>
> >> Regards,
> >> Matthias
> >
> >

Re: [PATCH 2/6] usb: mtu3: add reference clock

[Chunfeng Yun]

On Wed, 2017-01-25 at 00:23 +0100, Matthias Brugger wrote:
> 
> On 01/20/2017 03:20 AM, Chunfeng Yun wrote:
> > On Thu, 2017-01-19 at 13:22 +0100, Matthias Brugger wrote:
> >>
> >> On 18/01/17 07:08, Chunfeng Yun wrote:
> >>> usually, the reference clock comes from 26M oscillator directly,
> >>> but some SoCs are not, add it for compatibility.
> >>>
> >>> Signed-off-by: Chunfeng Yun 
> >>> ---
> >>>  drivers/usb/mtu3/mtu3.h  |1 +
> >>>  drivers/usb/mtu3/mtu3_plat.c |   21 +++--
> >>>  2 files changed, 20 insertions(+), 2 deletions(-)
> > [...]
> >>> @@ -154,6 +162,7 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> >>>  static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
> >>>  {
> >>>   clk_disable_unprepare(ssusb->sys_clk);
> >>> + clk_disable_unprepare(ssusb->ref_clk);
> >>>   regulator_disable(ssusb->vusb33);
> >>>   ssusb_phy_power_off(ssusb);
> >>>   ssusb_phy_exit(ssusb);
> >>> @@ -216,6 +225,12 @@ static int get_ssusb_rscs(struct platform_device 
> >>> *pdev, struct ssusb_mtk *ssusb)
> >>>   return PTR_ERR(ssusb->sys_clk);
> >>>   }
> >>>
> >>> + ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
> >>> + if (IS_ERR(ssusb->ref_clk)) {
> >>> + dev_err(dev, "failed to get ref clock\n");
> >>> + return PTR_ERR(ssusb->ref_clk);
> >>> + }
> >>> +
> >>
> >> That would break older dts bindings, right?
> > Yes, So I send a new patch for the related dts. Maybe it's not a
> > problem, only one dts file need be updated currently.
> >
> >> ref_ck must be optional for the code.
> > I tend to make it be optional for the dts, but not for the code.
> > There are some "fixed-clock" which can be treated as dummy ones, and if
> > a clock is really optional, we can use one fixed-clock in dts, and keep
> > the code simple.
> > In fact, the reference clock is essential for usb controller.
> 
> Well the thing is that there are devices in the field with an older dtb 
> which would break on a newer kernel. That's why we need to make it work 
> with the old dtb in the code as well.
> 
Happy Chinese New Year!

Ok, I will make it optional.

Thanks and sorry for later reply.

> Regards,
> Matthias
> 
> >>
> >> Regards,
> >> Matthias
> >
> >

Re: [PATCH 6/6] dt-bindings: mt8173-mtu3: add reference clock

[Chunfeng Yun]

On Mon, 2017-01-23 at 08:02 -0600, Rob Herring wrote:
> On Sat, Jan 21, 2017 at 7:49 PM, Chunfeng Yun  
> wrote:
> > Hi,
> >
> > On Sat, 2017-01-21 at 14:11 -0600, Rob Herring wrote:
> >> On Wed, Jan 18, 2017 at 02:08:27PM +0800, Chunfeng Yun wrote:
> >> > add a reference clock for compatibility
> >>
> >> Why? This block suddenly has 2 clocks instead of 1?
> > In fact, there is a reference clock which comes from 26M oscillator
> > directly. I ignore it because it is a fixed-clock in DTS, and always
> > turned on for mt8173. But later, I find that I made a mistake before
> > when I bring up it on a new platform whose reference clock comes from
> > PLL, and need control it. So here add it, no matter it is a fixed-clock
> > or not.
> 
> Add this explanation to the changelog.
> 
Happy Chinese New Year!

Ok, I'll add it.

Thanks and sorry for later reply.

> Rob

Re: [PATCH 6/6] dt-bindings: mt8173-mtu3: add reference clock

[Chunfeng Yun]

On Mon, 2017-01-23 at 08:02 -0600, Rob Herring wrote:
> On Sat, Jan 21, 2017 at 7:49 PM, Chunfeng Yun  
> wrote:
> > Hi,
> >
> > On Sat, 2017-01-21 at 14:11 -0600, Rob Herring wrote:
> >> On Wed, Jan 18, 2017 at 02:08:27PM +0800, Chunfeng Yun wrote:
> >> > add a reference clock for compatibility
> >>
> >> Why? This block suddenly has 2 clocks instead of 1?
> > In fact, there is a reference clock which comes from 26M oscillator
> > directly. I ignore it because it is a fixed-clock in DTS, and always
> > turned on for mt8173. But later, I find that I made a mistake before
> > when I bring up it on a new platform whose reference clock comes from
> > PLL, and need control it. So here add it, no matter it is a fixed-clock
> > or not.
> 
> Add this explanation to the changelog.
> 
Happy Chinese New Year!

Ok, I'll add it.

Thanks and sorry for later reply.

> Rob

[PATCH] vfio: fix a typo in comment of function vfio_pin_pages

[changbin . du]

From: Changbin Du 

Correct the description that 'unpinned' -> 'pinned'.

Signed-off-by: Changbin Du 
---
 drivers/vfio/vfio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 9901c46..c162a7e 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1917,7 +1917,7 @@ EXPORT_SYMBOL(vfio_set_irqs_validate_and_prepare);
  * Pin a set of guest PFNs and return their associated host PFNs for local
  * domain only.
  * @dev [in] : device
- * @user_pfn [in]: array of user/guest PFNs to be unpinned.
+ * @user_pfn [in]: array of user/guest PFNs to be pinned.
  * @npage [in]   : count of elements in user_pfn array.  This count should not
  *be greater VFIO_PIN_PAGES_MAX_ENTRIES.
  * @prot [in]: protection flags
-- 
2.7.4

[PATCH] vfio: fix a typo in comment of function vfio_pin_pages

[changbin . du]

From: Changbin Du 

Correct the description that 'unpinned' -> 'pinned'.

Signed-off-by: Changbin Du 
---
 drivers/vfio/vfio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 9901c46..c162a7e 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1917,7 +1917,7 @@ EXPORT_SYMBOL(vfio_set_irqs_validate_and_prepare);
  * Pin a set of guest PFNs and return their associated host PFNs for local
  * domain only.
  * @dev [in] : device
- * @user_pfn [in]: array of user/guest PFNs to be unpinned.
+ * @user_pfn [in]: array of user/guest PFNs to be pinned.
  * @npage [in]   : count of elements in user_pfn array.  This count should not
  *be greater VFIO_PIN_PAGES_MAX_ENTRIES.
  * @prot [in]: protection flags
-- 
2.7.4

[PATCH v5] PCI: Xilinx NWL: Modifying irq chip for legacy interrupts

[Bharat Kumar Gogada]

- Adding spinlock for protecting legacy mask register
- Few wifi end points which only support legacy interrupts,
performs hardware reset functionalities after disabling interrupts
by invoking disable_irq and then re-enable using enable_irq, they
enable hardware interrupts first and then virtual irq line later.
- The legacy irq line goes low only after DEASSERT_INTx is
received.As the legacy irq line is high immediately after hardware
interrupts are enabled but virq of EP is still in disabled state
and EP handler is never executed resulting no DEASSERT_INTx.If dummy
irq chip is used, interrutps are not masked and system is
hanging with CPU stall.
- Adding irq chip functions instead of dummy irq chip for legacy
interrupts.
- Legacy interrupts are level sensitive, so using handle_level_irq
is more appropriate as it is masks interrupts until End point handles
interrupts and unmasks interrutps after End point handler is executed.
- Legacy interrupts are level triggered, virtual irq line of End
Point shows as edge in /proc/interrupts.
- Setting irq flags of virtual irq line of EP to level triggered
at the time of mapping.

Signed-off-by: Bharat Kumar Gogada 
---
 drivers/pci/host/pcie-xilinx-nwl.c | 45 +-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-xilinx-nwl.c 
b/drivers/pci/host/pcie-xilinx-nwl.c
index 43eaa4a..36f4fb4 100644
--- a/drivers/pci/host/pcie-xilinx-nwl.c
+++ b/drivers/pci/host/pcie-xilinx-nwl.c
@@ -184,6 +184,7 @@ struct nwl_pcie {
u8 root_busno;
struct nwl_msi msi;
struct irq_domain *legacy_irq_domain;
+   raw_spinlock_t leg_mask_lock;
 };
 
 static inline u32 nwl_bridge_readl(struct nwl_pcie *pcie, u32 off)
@@ -395,11 +396,52 @@ static void nwl_pcie_msi_handler_low(struct irq_desc 
*desc)
chained_irq_exit(chip, desc);
 }
 
+static void nwl_mask_leg_irq(struct irq_data *data)
+{
+   struct irq_desc *desc = irq_to_desc(data->irq);
+   struct nwl_pcie *pcie;
+   unsigned long flags;
+   u32 mask;
+   u32 val;
+
+   pcie = irq_desc_get_chip_data(desc);
+   mask = 1 << (data->hwirq - 1);
+   raw_spin_lock_irqsave(>leg_mask_lock, flags);
+   val = nwl_bridge_readl(pcie, MSGF_LEG_MASK);
+   nwl_bridge_writel(pcie, (val & (~mask)), MSGF_LEG_MASK);
+   raw_spin_unlock_irqrestore(>leg_mask_lock, flags);
+}
+
+static void nwl_unmask_leg_irq(struct irq_data *data)
+{
+   struct irq_desc *desc = irq_to_desc(data->irq);
+   struct nwl_pcie *pcie;
+   unsigned long flags;
+   u32 mask;
+   u32 val;
+
+   pcie = irq_desc_get_chip_data(desc);
+   mask = 1 << (data->hwirq - 1);
+   raw_spin_lock_irqsave(>leg_mask_lock, flags);
+   val = nwl_bridge_readl(pcie, MSGF_LEG_MASK);
+   nwl_bridge_writel(pcie, (val | mask), MSGF_LEG_MASK);
+   raw_spin_unlock_irqrestore(>leg_mask_lock, flags);
+}
+
+static struct irq_chip nwl_leg_irq_chip = {
+   .name = "nwl_pcie:legacy",
+   .irq_enable = nwl_unmask_leg_irq,
+   .irq_disable = nwl_mask_leg_irq,
+   .irq_mask = nwl_mask_leg_irq,
+   .irq_unmask = nwl_unmask_leg_irq,
+};
+
 static int nwl_legacy_map(struct irq_domain *domain, unsigned int irq,
  irq_hw_number_t hwirq)
 {
-   irq_set_chip_and_handler(irq, _irq_chip, handle_simple_irq);
+   irq_set_chip_and_handler(irq, _leg_irq_chip, handle_level_irq);
irq_set_chip_data(irq, domain->host_data);
+   irq_set_status_flags(irq, IRQ_LEVEL);
 
return 0;
 }
@@ -538,6 +580,7 @@ static int nwl_pcie_init_irq_domain(struct nwl_pcie *pcie)
return -ENOMEM;
}
 
+   raw_spin_lock_init(>leg_mask_lock);
nwl_pcie_init_msi_irq_domain(pcie);
return 0;
 }
-- 
2.1.1

[PATCH v5] PCI: Xilinx NWL: Modifying irq chip for legacy interrupts

[Bharat Kumar Gogada]

- Adding spinlock for protecting legacy mask register
- Few wifi end points which only support legacy interrupts,
performs hardware reset functionalities after disabling interrupts
by invoking disable_irq and then re-enable using enable_irq, they
enable hardware interrupts first and then virtual irq line later.
- The legacy irq line goes low only after DEASSERT_INTx is
received.As the legacy irq line is high immediately after hardware
interrupts are enabled but virq of EP is still in disabled state
and EP handler is never executed resulting no DEASSERT_INTx.If dummy
irq chip is used, interrutps are not masked and system is
hanging with CPU stall.
- Adding irq chip functions instead of dummy irq chip for legacy
interrupts.
- Legacy interrupts are level sensitive, so using handle_level_irq
is more appropriate as it is masks interrupts until End point handles
interrupts and unmasks interrutps after End point handler is executed.
- Legacy interrupts are level triggered, virtual irq line of End
Point shows as edge in /proc/interrupts.
- Setting irq flags of virtual irq line of EP to level triggered
at the time of mapping.

Signed-off-by: Bharat Kumar Gogada 
---
 drivers/pci/host/pcie-xilinx-nwl.c | 45 +-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-xilinx-nwl.c 
b/drivers/pci/host/pcie-xilinx-nwl.c
index 43eaa4a..36f4fb4 100644
--- a/drivers/pci/host/pcie-xilinx-nwl.c
+++ b/drivers/pci/host/pcie-xilinx-nwl.c
@@ -184,6 +184,7 @@ struct nwl_pcie {
u8 root_busno;
struct nwl_msi msi;
struct irq_domain *legacy_irq_domain;
+   raw_spinlock_t leg_mask_lock;
 };
 
 static inline u32 nwl_bridge_readl(struct nwl_pcie *pcie, u32 off)
@@ -395,11 +396,52 @@ static void nwl_pcie_msi_handler_low(struct irq_desc 
*desc)
chained_irq_exit(chip, desc);
 }
 
+static void nwl_mask_leg_irq(struct irq_data *data)
+{
+   struct irq_desc *desc = irq_to_desc(data->irq);
+   struct nwl_pcie *pcie;
+   unsigned long flags;
+   u32 mask;
+   u32 val;
+
+   pcie = irq_desc_get_chip_data(desc);
+   mask = 1 << (data->hwirq - 1);
+   raw_spin_lock_irqsave(>leg_mask_lock, flags);
+   val = nwl_bridge_readl(pcie, MSGF_LEG_MASK);
+   nwl_bridge_writel(pcie, (val & (~mask)), MSGF_LEG_MASK);
+   raw_spin_unlock_irqrestore(>leg_mask_lock, flags);
+}
+
+static void nwl_unmask_leg_irq(struct irq_data *data)
+{
+   struct irq_desc *desc = irq_to_desc(data->irq);
+   struct nwl_pcie *pcie;
+   unsigned long flags;
+   u32 mask;
+   u32 val;
+
+   pcie = irq_desc_get_chip_data(desc);
+   mask = 1 << (data->hwirq - 1);
+   raw_spin_lock_irqsave(>leg_mask_lock, flags);
+   val = nwl_bridge_readl(pcie, MSGF_LEG_MASK);
+   nwl_bridge_writel(pcie, (val | mask), MSGF_LEG_MASK);
+   raw_spin_unlock_irqrestore(>leg_mask_lock, flags);
+}
+
+static struct irq_chip nwl_leg_irq_chip = {
+   .name = "nwl_pcie:legacy",
+   .irq_enable = nwl_unmask_leg_irq,
+   .irq_disable = nwl_mask_leg_irq,
+   .irq_mask = nwl_mask_leg_irq,
+   .irq_unmask = nwl_unmask_leg_irq,
+};
+
 static int nwl_legacy_map(struct irq_domain *domain, unsigned int irq,
  irq_hw_number_t hwirq)
 {
-   irq_set_chip_and_handler(irq, _irq_chip, handle_simple_irq);
+   irq_set_chip_and_handler(irq, _leg_irq_chip, handle_level_irq);
irq_set_chip_data(irq, domain->host_data);
+   irq_set_status_flags(irq, IRQ_LEVEL);
 
return 0;
 }
@@ -538,6 +580,7 @@ static int nwl_pcie_init_irq_domain(struct nwl_pcie *pcie)
return -ENOMEM;
}
 
+   raw_spin_lock_init(>leg_mask_lock);
nwl_pcie_init_msi_irq_domain(pcie);
return 0;
 }
-- 
2.1.1

[PATCH v5 net-next] net: mvneta: implement .set_wol and .get_wol

[Jisheng Zhang]

From: Jingju Hou 

The mvneta itself does not support WOL, but the PHY might.
So pass the calls to the PHY

Signed-off-by: Jingju Hou 
Signed-off-by: Jisheng Zhang 
---
since v4:
 - address Andrew Lunn's comment

since v3:
 - really fix the build error

since v2,v1:
 - using phy_dev member in struct net_device
 - add commit msg

 drivers/net/ethernet/marvell/mvneta.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index de6c47744b8e..0f4d1697be46 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3927,6 +3927,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device 
*dev, u32 *indir, u8 *key,
return 0;
 }
 
+static void mvneta_ethtool_get_wol(struct net_device *dev,
+  struct ethtool_wolinfo *wol)
+{
+   wol->supported = 0;
+   wol->wolopts = 0;
+
+   if (dev->phydev)
+   phy_ethtool_get_wol(dev->phydev, wol);
+}
+
+static int mvneta_ethtool_set_wol(struct net_device *dev,
+ struct ethtool_wolinfo *wol)
+{
+   if (!dev->phydev)
+   return -EOPNOTSUPP;
+
+   return phy_ethtool_set_wol(dev->phydev, wol);
+}
+
 static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open= mvneta_open,
.ndo_stop= mvneta_stop,
@@ -3956,6 +3975,8 @@ const struct ethtool_ops mvneta_eth_tool_ops = {
.set_rxfh   = mvneta_ethtool_set_rxfh,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = mvneta_ethtool_set_link_ksettings,
+   .get_wol= mvneta_ethtool_get_wol,
+   .set_wol= mvneta_ethtool_set_wol,
 };
 
 /* Initialize hw */
-- 
2.11.0

[PATCH v5 net-next] net: mvneta: implement .set_wol and .get_wol

[Jisheng Zhang]

From: Jingju Hou 

The mvneta itself does not support WOL, but the PHY might.
So pass the calls to the PHY

Signed-off-by: Jingju Hou 
Signed-off-by: Jisheng Zhang 
---
since v4:
 - address Andrew Lunn's comment

since v3:
 - really fix the build error

since v2,v1:
 - using phy_dev member in struct net_device
 - add commit msg

 drivers/net/ethernet/marvell/mvneta.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index de6c47744b8e..0f4d1697be46 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3927,6 +3927,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device 
*dev, u32 *indir, u8 *key,
return 0;
 }
 
+static void mvneta_ethtool_get_wol(struct net_device *dev,
+  struct ethtool_wolinfo *wol)
+{
+   wol->supported = 0;
+   wol->wolopts = 0;
+
+   if (dev->phydev)
+   phy_ethtool_get_wol(dev->phydev, wol);
+}
+
+static int mvneta_ethtool_set_wol(struct net_device *dev,
+ struct ethtool_wolinfo *wol)
+{
+   if (!dev->phydev)
+   return -EOPNOTSUPP;
+
+   return phy_ethtool_set_wol(dev->phydev, wol);
+}
+
 static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open= mvneta_open,
.ndo_stop= mvneta_stop,
@@ -3956,6 +3975,8 @@ const struct ethtool_ops mvneta_eth_tool_ops = {
.set_rxfh   = mvneta_ethtool_set_rxfh,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = mvneta_ethtool_set_link_ksettings,
+   .get_wol= mvneta_ethtool_get_wol,
+   .set_wol= mvneta_ethtool_set_wol,
 };
 
 /* Initialize hw */
-- 
2.11.0

[PATCH 9/9] ARM: sun5i: gr8: Use common sun5i DTSI

[Maxime Ripard]

Most of the GR8 DTSI is duplicated with the common sun5i DTSI, and some of
the extra nodes defined there actually apply to all of the sun5i family.

Move those into the common DTSI so that all SoCs can benefit from it, and
include the sun5i DTSI.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-gr8-chip-pro.dts |   2 +-
 arch/arm/boot/dts/sun5i-gr8-evb.dts  |   2 +-
 arch/arm/boot/dts/sun5i-gr8.dtsi | 617 +---
 arch/arm/boot/dts/sun5i.dtsi |  45 ++-
 4 files changed, 76 insertions(+), 590 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts 
b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
index 0cf0813d363a..e5eb46b500ae 100644
--- a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
+++ b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
@@ -220,7 +220,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>, <_cts_rts_pins_a>;
+   pinctrl-0 = <_pins_b>, <_cts_rts_pins_a>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-gr8-evb.dts 
b/arch/arm/boot/dts/sun5i-gr8-evb.dts
index 1a845af4d4db..ebd8388e2ba1 100644
--- a/arch/arm/boot/dts/sun5i-gr8-evb.dts
+++ b/arch/arm/boot/dts/sun5i-gr8-evb.dts
@@ -332,7 +332,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>, <_cts_rts_pins_a>;
+   pinctrl-0 = <_pins_b>, <_cts_rts_pins_a>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-gr8.dtsi b/arch/arm/boot/dts/sun5i-gr8.dtsi
index cb9b2aaf7297..8921af3bf1ef 100644
--- a/arch/arm/boot/dts/sun5i-gr8.dtsi
+++ b/arch/arm/boot/dts/sun5i-gr8.dtsi
@@ -42,429 +42,20 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include "sun5i.dtsi"
+
 #include 
 #include 
 #include 
 #include 
 
 / {
-   interrupt-parent = <>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu0: cpu@0 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a8";
-   reg = <0x0>;
-   clocks = < CLK_CPU>;
-   };
-   };
-
-   clocks {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   osc24M: clk@01c20050 {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <2400>;
-   clock-output-names = "osc24M";
-   };
-
-   osc32k: clk@0 {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <32768>;
-   clock-output-names = "osc32k";
-   };
-   };
-
display-engine {
compatible = "allwinner,sun5i-a13-display-engine";
allwinner,pipelines = <>;
};
 
soc@01c0 {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   sram-controller@01c0 {
-   compatible = "allwinner,sun4i-a10-sram-controller";
-   reg = <0x01c0 0x30>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   sram_a: sram@ {
-   compatible = "mmio-sram";
-   reg = <0x 0xc000>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0 0x 0xc000>;
-   };
-
-   sram_d: sram@0001 {
-   compatible = "mmio-sram";
-   reg = <0x0001 0x1000>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0 0x0001 0x1000>;
-
-   otg_sram: sram-section@ {
-   compatible = 
"allwinner,sun4i-a10-sram-d";
-   reg = <0x 0x1000>;
-   status = "disabled";
-   };
-   };
-   };
-
-   dma: dma-controller@01c02000 {
-   compatible = "allwinner,sun4i-a10-dma";
-   reg = <0x01c02000 0x1000>;
-   interrupts = <27>;
-   clocks = < CLK_AHB_DMA>;
-   #dma-cells = <2>;
-   };
-
-   nfc: nand@01c03000 {
-   compatible = "allwinner,sun4i-a10-nand";
-   reg = <0x01c03000 0x1000>;
-   interrupts 

[PATCH 9/9] ARM: sun5i: gr8: Use common sun5i DTSI

[Maxime Ripard]

Most of the GR8 DTSI is duplicated with the common sun5i DTSI, and some of
the extra nodes defined there actually apply to all of the sun5i family.

Move those into the common DTSI so that all SoCs can benefit from it, and
include the sun5i DTSI.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-gr8-chip-pro.dts |   2 +-
 arch/arm/boot/dts/sun5i-gr8-evb.dts  |   2 +-
 arch/arm/boot/dts/sun5i-gr8.dtsi | 617 +---
 arch/arm/boot/dts/sun5i.dtsi |  45 ++-
 4 files changed, 76 insertions(+), 590 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts 
b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
index 0cf0813d363a..e5eb46b500ae 100644
--- a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
+++ b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
@@ -220,7 +220,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>, <_cts_rts_pins_a>;
+   pinctrl-0 = <_pins_b>, <_cts_rts_pins_a>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-gr8-evb.dts 
b/arch/arm/boot/dts/sun5i-gr8-evb.dts
index 1a845af4d4db..ebd8388e2ba1 100644
--- a/arch/arm/boot/dts/sun5i-gr8-evb.dts
+++ b/arch/arm/boot/dts/sun5i-gr8-evb.dts
@@ -332,7 +332,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>, <_cts_rts_pins_a>;
+   pinctrl-0 = <_pins_b>, <_cts_rts_pins_a>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-gr8.dtsi b/arch/arm/boot/dts/sun5i-gr8.dtsi
index cb9b2aaf7297..8921af3bf1ef 100644
--- a/arch/arm/boot/dts/sun5i-gr8.dtsi
+++ b/arch/arm/boot/dts/sun5i-gr8.dtsi
@@ -42,429 +42,20 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include "sun5i.dtsi"
+
 #include 
 #include 
 #include 
 #include 
 
 / {
-   interrupt-parent = <>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu0: cpu@0 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a8";
-   reg = <0x0>;
-   clocks = < CLK_CPU>;
-   };
-   };
-
-   clocks {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   osc24M: clk@01c20050 {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <2400>;
-   clock-output-names = "osc24M";
-   };
-
-   osc32k: clk@0 {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <32768>;
-   clock-output-names = "osc32k";
-   };
-   };
-
display-engine {
compatible = "allwinner,sun5i-a13-display-engine";
allwinner,pipelines = <>;
};
 
soc@01c0 {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   sram-controller@01c0 {
-   compatible = "allwinner,sun4i-a10-sram-controller";
-   reg = <0x01c0 0x30>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   sram_a: sram@ {
-   compatible = "mmio-sram";
-   reg = <0x 0xc000>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0 0x 0xc000>;
-   };
-
-   sram_d: sram@0001 {
-   compatible = "mmio-sram";
-   reg = <0x0001 0x1000>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0 0x0001 0x1000>;
-
-   otg_sram: sram-section@ {
-   compatible = 
"allwinner,sun4i-a10-sram-d";
-   reg = <0x 0x1000>;
-   status = "disabled";
-   };
-   };
-   };
-
-   dma: dma-controller@01c02000 {
-   compatible = "allwinner,sun4i-a10-dma";
-   reg = <0x01c02000 0x1000>;
-   interrupts = <27>;
-   clocks = < CLK_AHB_DMA>;
-   #dma-cells = <2>;
-   };
-
-   nfc: nand@01c03000 {
-   compatible = "allwinner,sun4i-a10-nand";
-   reg = <0x01c03000 0x1000>;
-   interrupts = <37>;
-   

[PATCH 6/9] ARM: sun5i: a13: Merge common controllers into the common DTSI

[Maxime Ripard]

Some controllers found in the A13 DTSI actually apply to all of the sun5i
family. Move those into the common DTSI so that all SoCs can benefit from
it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a13.dtsi | 139 +
 arch/arm/boot/dts/sun5i.dtsi | 140 -
 2 files changed, 140 insertions(+), 139 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index fb2ddb9a04c9..6f8c508e8e70 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -52,21 +52,6 @@
 / {
interrupt-parent = <>;
 
-   chosen {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   framebuffer@0 {
-   compatible = "allwinner,simple-framebuffer",
-"simple-framebuffer";
-   allwinner,pipeline = "de_be0-lcd0";
-   clocks = < CLK_AHB_LCD>, < CLK_AHB_DE_BE>, 
< CLK_DE_BE>,
-< CLK_TCON_CH0>, < CLK_DRAM_DE_BE>;
-   status = "disabled";
-   };
-   };
-
thermal-zones {
cpu_thermal {
/* milliseconds */
@@ -105,44 +90,6 @@
};
 
soc@01c0 {
-   tcon0: lcd-controller@01c0c000 {
-   compatible = "allwinner,sun5i-a13-tcon";
-   reg = <0x01c0c000 0x1000>;
-   interrupts = <44>;
-   resets = < RST_LCD>;
-   reset-names = "lcd";
-   clocks = < CLK_AHB_LCD>,
-< CLK_TCON_CH0>,
-< CLK_TCON_CH1>;
-   clock-names = "ahb",
- "tcon-ch0",
- "tcon-ch1";
-   clock-output-names = "tcon-pixel-clock";
-   status = "disabled";
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   tcon0_in: port@0 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0>;
-
-   tcon0_in_be0: endpoint@0 {
-   reg = <0>;
-   remote-endpoint = 
<_out_tcon0>;
-   };
-   };
-
-   tcon0_out: port@1 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <1>;
-   };
-   };
-   };
-
pwm: pwm@01c20e00 {
compatible = "allwinner,sun5i-a13-pwm";
reg = <0x01c20e00 0xc>;
@@ -151,74 +98,6 @@
status = "disabled";
};
 
-   fe0: display-frontend@01e0 {
-   compatible = "allwinner,sun5i-a13-display-frontend";
-   reg = <0x01e0 0x2>;
-   interrupts = <47>;
-   clocks = < CLK_DE_FE>, < CLK_DE_FE>,
-< CLK_DRAM_DE_FE>;
-   clock-names = "ahb", "mod",
- "ram";
-   resets = < RST_DE_FE>;
-   status = "disabled";
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   fe0_out: port@1 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <1>;
-
-   fe0_out_be0: endpoint@0 {
-   reg = <0>;
-   remote-endpoint = <_in_fe0>;
-   };
-   };
-   };
-   };
-
-   be0: display-backend@01e6 {
-   compatible = "allwinner,sun5i-a13-display-backend";
-   reg = <0x01e6 0x1>;
-   clocks = < CLK_AHB_DE_BE>, < CLK_DE_BE>,
-< CLK_DRAM_DE_BE>;
-   clock-names = "ahb", "mod",
- "ram";
-   resets = < RST_DE_BE>;
-   status = "disabled";
-
- 

[PATCH 4/9] ARM: sun5i: Add UART2 pin group

[Maxime Ripard]

There's one UART2 pin group that can be used across all sun5i SoCs.
However, the A10s already has one pin group for that controller.

Change the index of the one in the A10s DTSI, and add the common one to
sun5i.dtsi

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts |  2 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi|  2 +-
 arch/arm/boot/dts/sun5i.dtsi | 10 ++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index 9fbeb584abf5..baee64d61f6d 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -257,7 +257,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
+   pinctrl-0 = <_pins_b>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 0c08b6173d9c..5122d1179e59 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -151,7 +151,7 @@
function = "uart0";
};
 
-   uart2_pins_a: uart2@0 {
+   uart2_pins_b: uart2@1 {
pins = "PC18", "PC19";
function = "uart2";
};
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index fce3ec693531..cd951e2cdbe7 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -336,6 +336,16 @@
function = "spi2";
};
 
+   uart2_pins_a: uart2@0 {
+   pins = "PD2", "PD3";
+   function = "uart2";
+   };
+
+   uart2_cts_rts_pins_a: uart2-cts-rts@0 {
+   pins = "PD4", "PD5";
+   function = "uart2";
+   };
+
uart3_pins_a: uart3@0 {
pins = "PG9", "PG10";
function = "uart3";
-- 
git-series 0.8.11

[PATCH 4/9] ARM: sun5i: Add UART2 pin group

[Maxime Ripard]

There's one UART2 pin group that can be used across all sun5i SoCs.
However, the A10s already has one pin group for that controller.

Change the index of the one in the A10s DTSI, and add the common one to
sun5i.dtsi

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts |  2 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi|  2 +-
 arch/arm/boot/dts/sun5i.dtsi | 10 ++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index 9fbeb584abf5..baee64d61f6d 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -257,7 +257,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
+   pinctrl-0 = <_pins_b>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 0c08b6173d9c..5122d1179e59 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -151,7 +151,7 @@
function = "uart0";
};
 
-   uart2_pins_a: uart2@0 {
+   uart2_pins_b: uart2@1 {
pins = "PC18", "PC19";
function = "uart2";
};
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index fce3ec693531..cd951e2cdbe7 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -336,6 +336,16 @@
function = "spi2";
};
 
+   uart2_pins_a: uart2@0 {
+   pins = "PD2", "PD3";
+   function = "uart2";
+   };
+
+   uart2_cts_rts_pins_a: uart2-cts-rts@0 {
+   pins = "PD4", "PD5";
+   function = "uart2";
+   };
+
uart3_pins_a: uart3@0 {
pins = "PG9", "PG10";
function = "uart3";
-- 
git-series 0.8.11

[PATCH 6/9] ARM: sun5i: a13: Merge common controllers into the common DTSI

[Maxime Ripard]

Some controllers found in the A13 DTSI actually apply to all of the sun5i
family. Move those into the common DTSI so that all SoCs can benefit from
it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a13.dtsi | 139 +
 arch/arm/boot/dts/sun5i.dtsi | 140 -
 2 files changed, 140 insertions(+), 139 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index fb2ddb9a04c9..6f8c508e8e70 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -52,21 +52,6 @@
 / {
interrupt-parent = <>;
 
-   chosen {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   framebuffer@0 {
-   compatible = "allwinner,simple-framebuffer",
-"simple-framebuffer";
-   allwinner,pipeline = "de_be0-lcd0";
-   clocks = < CLK_AHB_LCD>, < CLK_AHB_DE_BE>, 
< CLK_DE_BE>,
-< CLK_TCON_CH0>, < CLK_DRAM_DE_BE>;
-   status = "disabled";
-   };
-   };
-
thermal-zones {
cpu_thermal {
/* milliseconds */
@@ -105,44 +90,6 @@
};
 
soc@01c0 {
-   tcon0: lcd-controller@01c0c000 {
-   compatible = "allwinner,sun5i-a13-tcon";
-   reg = <0x01c0c000 0x1000>;
-   interrupts = <44>;
-   resets = < RST_LCD>;
-   reset-names = "lcd";
-   clocks = < CLK_AHB_LCD>,
-< CLK_TCON_CH0>,
-< CLK_TCON_CH1>;
-   clock-names = "ahb",
- "tcon-ch0",
- "tcon-ch1";
-   clock-output-names = "tcon-pixel-clock";
-   status = "disabled";
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   tcon0_in: port@0 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0>;
-
-   tcon0_in_be0: endpoint@0 {
-   reg = <0>;
-   remote-endpoint = 
<_out_tcon0>;
-   };
-   };
-
-   tcon0_out: port@1 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <1>;
-   };
-   };
-   };
-
pwm: pwm@01c20e00 {
compatible = "allwinner,sun5i-a13-pwm";
reg = <0x01c20e00 0xc>;
@@ -151,74 +98,6 @@
status = "disabled";
};
 
-   fe0: display-frontend@01e0 {
-   compatible = "allwinner,sun5i-a13-display-frontend";
-   reg = <0x01e0 0x2>;
-   interrupts = <47>;
-   clocks = < CLK_DE_FE>, < CLK_DE_FE>,
-< CLK_DRAM_DE_FE>;
-   clock-names = "ahb", "mod",
- "ram";
-   resets = < RST_DE_FE>;
-   status = "disabled";
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   fe0_out: port@1 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <1>;
-
-   fe0_out_be0: endpoint@0 {
-   reg = <0>;
-   remote-endpoint = <_in_fe0>;
-   };
-   };
-   };
-   };
-
-   be0: display-backend@01e6 {
-   compatible = "allwinner,sun5i-a13-display-backend";
-   reg = <0x01e6 0x1>;
-   clocks = < CLK_AHB_DE_BE>, < CLK_DE_BE>,
-< CLK_DRAM_DE_BE>;
-   clock-names = "ahb", "mod",
- "ram";
-   resets = < RST_DE_BE>;
-   status = "disabled";
-
-   assigned-clocks 

[PATCH 7/9] ARM: sun5i: a10s: Merge common controllers into the common DTSI

[Maxime Ripard]

Some controllers found in the A10s DTSI actually apply to all of the sun5i
family. Move those into the common DTSI so that all SoCs can benefit from
it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 70 +
 arch/arm/boot/dts/sun5i.dtsi  | 62 -
 2 files changed, 62 insertions(+), 70 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 5122d1179e59..074485782a4a 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -70,45 +70,9 @@
 < CLK_DE_BE>, < CLK_HDMI>;
status = "disabled";
};
-
-   framebuffer@0 {
-   compatible = "allwinner,simple-framebuffer",
-"simple-framebuffer";
-   allwinner,pipeline = "de_be0-lcd0";
-   clocks = < CLK_AHB_LCD>, < CLK_AHB_DE_BE>, 
< CLK_DE_BE>,
-< CLK_TCON_CH0>, < CLK_DRAM_DE_BE>;
-   status = "disabled";
-   };
-
-   framebuffer@1 {
-   compatible = "allwinner,simple-framebuffer",
-"simple-framebuffer";
-   allwinner,pipeline = "de_be0-lcd0-tve0";
-   clocks = < CLK_AHB_TVE>, < CLK_AHB_LCD>,
-< CLK_AHB_DE_BE>, < CLK_DE_BE>,
-< CLK_TCON_CH1>, < CLK_DRAM_DE_BE>;
-   status = "disabled";
-   };
};
 
soc@01c0 {
-   emac: ethernet@01c0b000 {
-   compatible = "allwinner,sun4i-a10-emac";
-   reg = <0x01c0b000 0x1000>;
-   interrupts = <55>;
-   clocks = < CLK_AHB_EMAC>;
-   allwinner,sram = <_sram 1>;
-   status = "disabled";
-   };
-
-   mdio: mdio@01c0b080 {
-   compatible = "allwinner,sun4i-a10-mdio";
-   reg = <0x01c0b080 0x14>;
-   status = "disabled";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   };
-
pwm: pwm@01c20e00 {
compatible = "allwinner,sun5i-a10s-pwm";
reg = <0x01c20e00 0xc>;
@@ -116,26 +80,6 @@
#pwm-cells = <3>;
status = "disabled";
};
-
-   uart0: serial@01c28000 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x01c28000 0x400>;
-   interrupts = <1>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clocks = < CLK_APB1_UART0>;
-   status = "disabled";
-   };
-
-   uart2: serial@01c28800 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x01c28800 0x400>;
-   interrupts = <3>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clocks = < CLK_APB1_UART2>;
-   status = "disabled";
-   };
};
 };
 
@@ -165,15 +109,6 @@
function = "emac";
};
 
-   emac_pins_a: emac0@0 {
-   pins = "PD6", "PD7", "PD10",
-   "PD11", "PD12", "PD13", "PD14",
-   "PD15", "PD18", "PD19", "PD20",
-   "PD21", "PD22", "PD23", "PD24",
-   "PD25", "PD26", "PD27";
-   function = "emac";
-   };
-
mmc1_pins_a: mmc1@0 {
pins = "PG3", "PG4", "PG5",
 "PG6", "PG7", "PG8";
@@ -193,9 +128,4 @@
 };
 
 _a {
-   emac_sram: sram-section@8000 {
-   compatible = "allwinner,sun4i-a10-sram-a3-a4";
-   reg = <0x8000 0x4000>;
-   status = "disabled";
-   };
 };
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index f27ca0be5835..9ba0c0302183 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -77,6 +77,16 @@
 < CLK_TCON_CH0>, < CLK_DRAM_DE_BE>;
status = "disabled";
};
+
+   framebuffer@1 {
+   compatible = "allwinner,simple-framebuffer",
+"simple-framebuffer";
+   allwinner,pipeline = "de_be0-lcd0-tve0";
+   clocks = < CLK_AHB_TVE>, < CLK_AHB_LCD>,
+< CLK_AHB_DE_BE>, < CLK_DE_BE>,
+ 

[PATCH 5/9] ARM: sun5i: Rename UART3 flow control pins

[Maxime Ripard]

The UART3 pin group for the CTS and RTS signals doesn't follow our usual
pattern. Rename it so that it matches.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 2 +-
 arch/arm/boot/dts/sun5i.dtsi| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts 
b/arch/arm/boot/dts/sun5i-r8-chip.dts
index e86fa46fdd45..c9a18216674a 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -281,7 +281,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>,
-   <_pins_cts_rts_a>;
+   <_cts_rts_pins_a>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index cd951e2cdbe7..d4888e0a0a13 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -351,7 +351,7 @@
function = "uart3";
};
 
-   uart3_pins_cts_rts_a: uart3-cts-rts@0 {
+   uart3_cts_rts_pins_a: uart3-cts-rts@0 {
pins = "PG11", "PG12";
function = "uart3";
};
-- 
git-series 0.8.11

[PATCH 7/9] ARM: sun5i: a10s: Merge common controllers into the common DTSI

[Maxime Ripard]

Some controllers found in the A10s DTSI actually apply to all of the sun5i
family. Move those into the common DTSI so that all SoCs can benefit from
it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 70 +
 arch/arm/boot/dts/sun5i.dtsi  | 62 -
 2 files changed, 62 insertions(+), 70 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 5122d1179e59..074485782a4a 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -70,45 +70,9 @@
 < CLK_DE_BE>, < CLK_HDMI>;
status = "disabled";
};
-
-   framebuffer@0 {
-   compatible = "allwinner,simple-framebuffer",
-"simple-framebuffer";
-   allwinner,pipeline = "de_be0-lcd0";
-   clocks = < CLK_AHB_LCD>, < CLK_AHB_DE_BE>, 
< CLK_DE_BE>,
-< CLK_TCON_CH0>, < CLK_DRAM_DE_BE>;
-   status = "disabled";
-   };
-
-   framebuffer@1 {
-   compatible = "allwinner,simple-framebuffer",
-"simple-framebuffer";
-   allwinner,pipeline = "de_be0-lcd0-tve0";
-   clocks = < CLK_AHB_TVE>, < CLK_AHB_LCD>,
-< CLK_AHB_DE_BE>, < CLK_DE_BE>,
-< CLK_TCON_CH1>, < CLK_DRAM_DE_BE>;
-   status = "disabled";
-   };
};
 
soc@01c0 {
-   emac: ethernet@01c0b000 {
-   compatible = "allwinner,sun4i-a10-emac";
-   reg = <0x01c0b000 0x1000>;
-   interrupts = <55>;
-   clocks = < CLK_AHB_EMAC>;
-   allwinner,sram = <_sram 1>;
-   status = "disabled";
-   };
-
-   mdio: mdio@01c0b080 {
-   compatible = "allwinner,sun4i-a10-mdio";
-   reg = <0x01c0b080 0x14>;
-   status = "disabled";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   };
-
pwm: pwm@01c20e00 {
compatible = "allwinner,sun5i-a10s-pwm";
reg = <0x01c20e00 0xc>;
@@ -116,26 +80,6 @@
#pwm-cells = <3>;
status = "disabled";
};
-
-   uart0: serial@01c28000 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x01c28000 0x400>;
-   interrupts = <1>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clocks = < CLK_APB1_UART0>;
-   status = "disabled";
-   };
-
-   uart2: serial@01c28800 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x01c28800 0x400>;
-   interrupts = <3>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clocks = < CLK_APB1_UART2>;
-   status = "disabled";
-   };
};
 };
 
@@ -165,15 +109,6 @@
function = "emac";
};
 
-   emac_pins_a: emac0@0 {
-   pins = "PD6", "PD7", "PD10",
-   "PD11", "PD12", "PD13", "PD14",
-   "PD15", "PD18", "PD19", "PD20",
-   "PD21", "PD22", "PD23", "PD24",
-   "PD25", "PD26", "PD27";
-   function = "emac";
-   };
-
mmc1_pins_a: mmc1@0 {
pins = "PG3", "PG4", "PG5",
 "PG6", "PG7", "PG8";
@@ -193,9 +128,4 @@
 };
 
 _a {
-   emac_sram: sram-section@8000 {
-   compatible = "allwinner,sun4i-a10-sram-a3-a4";
-   reg = <0x8000 0x4000>;
-   status = "disabled";
-   };
 };
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index f27ca0be5835..9ba0c0302183 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -77,6 +77,16 @@
 < CLK_TCON_CH0>, < CLK_DRAM_DE_BE>;
status = "disabled";
};
+
+   framebuffer@1 {
+   compatible = "allwinner,simple-framebuffer",
+"simple-framebuffer";
+   allwinner,pipeline = "de_be0-lcd0-tve0";
+   clocks = < CLK_AHB_TVE>, < CLK_AHB_LCD>,
+< CLK_AHB_DE_BE>, < CLK_DE_BE>,
+< CLK_TCON_CH1>, < 

[PATCH 5/9] ARM: sun5i: Rename UART3 flow control pins

[Maxime Ripard]

The UART3 pin group for the CTS and RTS signals doesn't follow our usual
pattern. Rename it so that it matches.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 2 +-
 arch/arm/boot/dts/sun5i.dtsi| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts 
b/arch/arm/boot/dts/sun5i-r8-chip.dts
index e86fa46fdd45..c9a18216674a 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -281,7 +281,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>,
-   <_pins_cts_rts_a>;
+   <_cts_rts_pins_a>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index cd951e2cdbe7..d4888e0a0a13 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -351,7 +351,7 @@
function = "uart3";
};
 
-   uart3_pins_cts_rts_a: uart3-cts-rts@0 {
+   uart3_cts_rts_pins_a: uart3-cts-rts@0 {
pins = "PG11", "PG12";
function = "uart3";
};
-- 
git-series 0.8.11

[PATCH 2/9] ARM: sun5i: a10s: switch simple framebuffer indices

[Maxime Ripard]

Of the three simple framebuffer setups we have in the A10s, two of them can
be shared with the other SoCs from the sun5i family (LCD panel and
composite output).

However, the only one we cannot share is the HDMI, which is the first
listed in the A10s DTSI. In order to make it more logical and so that we
can share the framebuffer nodes in the common DTSI, reorder those nodes.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index df2ba63d4ff9..0c08b6173d9c 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -61,7 +61,7 @@
#size-cells = <1>;
ranges;
 
-   framebuffer@0 {
+   framebuffer@2 {
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-hdmi";
@@ -71,7 +71,7 @@
status = "disabled";
};
 
-   framebuffer@1 {
+   framebuffer@0 {
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
@@ -80,7 +80,7 @@
status = "disabled";
};
 
-   framebuffer@2 {
+   framebuffer@1 {
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-tve0";
-- 
git-series 0.8.11

[PATCH 0/9] ARM: sun5i: Cleanup and reorganisation of the DTSI

[Maxime Ripard]

Hi,

Most of the sun5i DTSI have grown organically, some nodes being added to
SoC DTSI because they were not properly tested, some because old datasheet
were wrong, and some times because we were not even sure whether it could
be shared at all, or how to share it.

Now that we have much more details, we can use that opportunity to
refactor all our DTSI so that we reduce greatly the duplication, especially
with the GR8 DTSI.

Let me know what you think,
Maxime

Maxime Ripard (9):
  ARM: sun5i: A10s: Switch the EMAC pins indices
  ARM: sun5i: a10s: switch simple framebuffer indices
  ARM: sunxi: Rename pwm0_pins to match our usual pattern
  ARM: sun5i: Add UART2 pin group
  ARM: sun5i: Rename UART3 flow control pins
  ARM: sun5i: a13: Merge common controllers into the common DTSI
  ARM: sun5i: a10s: Merge common controllers into the common DTSI
  ARM: sun5i: r8: Merge common controllers into the common DTSI
  ARM: sun5i: gr8: Use common sun5i DTSI

 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts   |   4 +-
 arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts   |   2 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi  |  76 +-
 arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts |   2 +-
 arch/arm/boot/dts/sun5i-a13.dtsi   | 139 +--
 arch/arm/boot/dts/sun5i-gr8-chip-pro.dts   |   2 +-
 arch/arm/boot/dts/sun5i-gr8-evb.dts|   2 +-
 arch/arm/boot/dts/sun5i-gr8.dtsi   | 617 +--
 arch/arm/boot/dts/sun5i-r8-chip.dts|   2 +-
 arch/arm/boot/dts/sun5i-r8.dtsi|  40 +-
 arch/arm/boot/dts/sun5i.dtsi   | 292 -
 arch/arm/boot/dts/sun8i-a23-a33.dtsi   |   2 +-
 arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi   |   2 +-
 13 files changed, 327 insertions(+), 855 deletions(-)

base-commit: 2a6e628efb37432a83bb42b00e3c403b1d8873dd
-- 
git-series 0.8.11

[PATCH 2/9] ARM: sun5i: a10s: switch simple framebuffer indices

[Maxime Ripard]

Of the three simple framebuffer setups we have in the A10s, two of them can
be shared with the other SoCs from the sun5i family (LCD panel and
composite output).

However, the only one we cannot share is the HDMI, which is the first
listed in the A10s DTSI. In order to make it more logical and so that we
can share the framebuffer nodes in the common DTSI, reorder those nodes.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index df2ba63d4ff9..0c08b6173d9c 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -61,7 +61,7 @@
#size-cells = <1>;
ranges;
 
-   framebuffer@0 {
+   framebuffer@2 {
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-hdmi";
@@ -71,7 +71,7 @@
status = "disabled";
};
 
-   framebuffer@1 {
+   framebuffer@0 {
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
@@ -80,7 +80,7 @@
status = "disabled";
};
 
-   framebuffer@2 {
+   framebuffer@1 {
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-tve0";
-- 
git-series 0.8.11

[PATCH 0/9] ARM: sun5i: Cleanup and reorganisation of the DTSI

[Maxime Ripard]

Hi,

Most of the sun5i DTSI have grown organically, some nodes being added to
SoC DTSI because they were not properly tested, some because old datasheet
were wrong, and some times because we were not even sure whether it could
be shared at all, or how to share it.

Now that we have much more details, we can use that opportunity to
refactor all our DTSI so that we reduce greatly the duplication, especially
with the GR8 DTSI.

Let me know what you think,
Maxime

Maxime Ripard (9):
  ARM: sun5i: A10s: Switch the EMAC pins indices
  ARM: sun5i: a10s: switch simple framebuffer indices
  ARM: sunxi: Rename pwm0_pins to match our usual pattern
  ARM: sun5i: Add UART2 pin group
  ARM: sun5i: Rename UART3 flow control pins
  ARM: sun5i: a13: Merge common controllers into the common DTSI
  ARM: sun5i: a10s: Merge common controllers into the common DTSI
  ARM: sun5i: r8: Merge common controllers into the common DTSI
  ARM: sun5i: gr8: Use common sun5i DTSI

 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts   |   4 +-
 arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts   |   2 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi  |  76 +-
 arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts |   2 +-
 arch/arm/boot/dts/sun5i-a13.dtsi   | 139 +--
 arch/arm/boot/dts/sun5i-gr8-chip-pro.dts   |   2 +-
 arch/arm/boot/dts/sun5i-gr8-evb.dts|   2 +-
 arch/arm/boot/dts/sun5i-gr8.dtsi   | 617 +--
 arch/arm/boot/dts/sun5i-r8-chip.dts|   2 +-
 arch/arm/boot/dts/sun5i-r8.dtsi|  40 +-
 arch/arm/boot/dts/sun5i.dtsi   | 292 -
 arch/arm/boot/dts/sun8i-a23-a33.dtsi   |   2 +-
 arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi   |   2 +-
 13 files changed, 327 insertions(+), 855 deletions(-)

base-commit: 2a6e628efb37432a83bb42b00e3c403b1d8873dd
-- 
git-series 0.8.11

[PATCH 3/9] ARM: sunxi: Rename pwm0_pins to match our usual pattern

[Maxime Ripard]

The pwm0_pins group name is suggesting that this is the only option usable
for the PWM0 on the SoCs it's declared on. However, this is not the case
and defining a second pwm0 group would be quite weird given the name of the
first group.

Rename it so that it matches our usual pattern.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts |  2 +-
 arch/arm/boot/dts/sun5i.dtsi   | 10 +-
 arch/arm/boot/dts/sun8i-a23-a33.dtsi   |  2 +-
 arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi   |  2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts 
b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
index 42435454acef..1bc87523b37c 100644
--- a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
+++ b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
@@ -157,7 +157,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
+   pinctrl-0 = <_pins_a>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index a9574a6cd95c..fce3ec693531 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -321,6 +321,11 @@
bias-pull-up;
};
 
+   pwm0_pins_a: pwm0@0 {
+   pins = "PB2";
+   function = "pwm0";
+   };
+
spi2_pins_a: spi2@0 {
pins = "PE1", "PE2", "PE3";
function = "spi2";
@@ -340,11 +345,6 @@
pins = "PG11", "PG12";
function = "uart3";
};
-
-   pwm0_pins: pwm0 {
-   pins = "PB2";
-   function = "pwm";
-   };
};
 
timer@01c20c00 {
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 35008b78d899..b558d318a72e 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -316,7 +316,7 @@
bias-pull-up;
};
 
-   pwm0_pins: pwm0 {
+   pwm0_pins_a: pwm0 {
pins = "PH0";
function = "pwm0";
};
diff --git a/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi 
b/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
index b8241462fcea..5cd891942fe3 100644
--- a/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
@@ -78,6 +78,6 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
+   pinctrl-0 = <_pins_a>;
status = "okay";
 };
-- 
git-series 0.8.11

[PATCH 1/9] ARM: sun5i: A10s: Switch the EMAC pins indices

[Maxime Ripard]

One of the pins group for the EMAC can be used by all the SoCs of the sun5i
family, and as such can be moved to the common DTSI.

Unfortunately, this group is the second one we declare in our DT for now.
Make it the first one so that it's more logical and consistent with the
rest of our DTs before moving it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 2 +-
 arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts | 2 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index d8245c6314a7..9fbeb584abf5 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -83,7 +83,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
+   pinctrl-0 = <_pins_b>;
phy = <>;
status = "okay";
 };
diff --git a/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts 
b/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
index 2b8adda0deda..99c84e870d91 100644
--- a/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
@@ -95,7 +95,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_b>;
+   pinctrl-0 = <_pins_a>;
phy = <>;
status = "okay";
 };
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 24b0f5f556f8..df2ba63d4ff9 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -156,7 +156,7 @@
function = "uart2";
};
 
-   emac_pins_a: emac0@0 {
+   emac_pins_b: emac0@1 {
pins = "PA0", "PA1", "PA2",
"PA3", "PA4", "PA5", "PA6",
"PA7", "PA8", "PA9", "PA10",
@@ -165,7 +165,7 @@
function = "emac";
};
 
-   emac_pins_b: emac0@1 {
+   emac_pins_a: emac0@0 {
pins = "PD6", "PD7", "PD10",
"PD11", "PD12", "PD13", "PD14",
"PD15", "PD18", "PD19", "PD20",
-- 
git-series 0.8.11

[PATCH 3/9] ARM: sunxi: Rename pwm0_pins to match our usual pattern

[Maxime Ripard]

The pwm0_pins group name is suggesting that this is the only option usable
for the PWM0 on the SoCs it's declared on. However, this is not the case
and defining a second pwm0 group would be quite weird given the name of the
first group.

Rename it so that it matches our usual pattern.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts |  2 +-
 arch/arm/boot/dts/sun5i.dtsi   | 10 +-
 arch/arm/boot/dts/sun8i-a23-a33.dtsi   |  2 +-
 arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi   |  2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts 
b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
index 42435454acef..1bc87523b37c 100644
--- a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
+++ b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
@@ -157,7 +157,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
+   pinctrl-0 = <_pins_a>;
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index a9574a6cd95c..fce3ec693531 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -321,6 +321,11 @@
bias-pull-up;
};
 
+   pwm0_pins_a: pwm0@0 {
+   pins = "PB2";
+   function = "pwm0";
+   };
+
spi2_pins_a: spi2@0 {
pins = "PE1", "PE2", "PE3";
function = "spi2";
@@ -340,11 +345,6 @@
pins = "PG11", "PG12";
function = "uart3";
};
-
-   pwm0_pins: pwm0 {
-   pins = "PB2";
-   function = "pwm";
-   };
};
 
timer@01c20c00 {
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 35008b78d899..b558d318a72e 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -316,7 +316,7 @@
bias-pull-up;
};
 
-   pwm0_pins: pwm0 {
+   pwm0_pins_a: pwm0 {
pins = "PH0";
function = "pwm0";
};
diff --git a/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi 
b/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
index b8241462fcea..5cd891942fe3 100644
--- a/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
@@ -78,6 +78,6 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
+   pinctrl-0 = <_pins_a>;
status = "okay";
 };
-- 
git-series 0.8.11

[PATCH 1/9] ARM: sun5i: A10s: Switch the EMAC pins indices

[Maxime Ripard]

One of the pins group for the EMAC can be used by all the SoCs of the sun5i
family, and as such can be moved to the common DTSI.

Unfortunately, this group is the second one we declare in our DT for now.
Make it the first one so that it's more logical and consistent with the
rest of our DTs before moving it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 2 +-
 arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts | 2 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index d8245c6314a7..9fbeb584abf5 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -83,7 +83,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
+   pinctrl-0 = <_pins_b>;
phy = <>;
status = "okay";
 };
diff --git a/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts 
b/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
index 2b8adda0deda..99c84e870d91 100644
--- a/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
@@ -95,7 +95,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins_b>;
+   pinctrl-0 = <_pins_a>;
phy = <>;
status = "okay";
 };
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 24b0f5f556f8..df2ba63d4ff9 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -156,7 +156,7 @@
function = "uart2";
};
 
-   emac_pins_a: emac0@0 {
+   emac_pins_b: emac0@1 {
pins = "PA0", "PA1", "PA2",
"PA3", "PA4", "PA5", "PA6",
"PA7", "PA8", "PA9", "PA10",
@@ -165,7 +165,7 @@
function = "emac";
};
 
-   emac_pins_b: emac0@1 {
+   emac_pins_a: emac0@0 {
pins = "PD6", "PD7", "PD10",
"PD11", "PD12", "PD13", "PD14",
"PD15", "PD18", "PD19", "PD20",
-- 
git-series 0.8.11

[PATCH 8/9] ARM: sun5i: r8: Merge common controllers into the common DTSI

[Maxime Ripard]

Some controllers found in the R8 DTSI actually apply to all of the sun5i
family. Move those into the common DTSI so that all SoCs can benefit from
it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-r8.dtsi | 40 +--
 arch/arm/boot/dts/sun5i.dtsi| 23 -
 2 files changed, 23 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/sun5i-r8.dtsi
index 4c1141396c99..de35dbcd1191 100644
--- a/arch/arm/boot/dts/sun5i-r8.dtsi
+++ b/arch/arm/boot/dts/sun5i-r8.dtsi
@@ -45,43 +45,3 @@
 
 #include "sun5i-a13.dtsi"
 
-/ {
-   chosen {
-   framebuffer@1 {
-   compatible = "allwinner,simple-framebuffer",
-"simple-framebuffer";
-   allwinner,pipeline = "de_be0-lcd0-tve0";
-   clocks = < CLK_AHB_TVE>, < CLK_AHB_LCD>,
-< CLK_AHB_DE_BE>, < CLK_DE_BE>,
-< CLK_TCON_CH1>, < CLK_DRAM_DE_BE>;
-   status = "disabled";
-   };
-   };
-
-   soc@01c0 {
-   tve0: tv-encoder@01c0a000 {
-   compatible = "allwinner,sun4i-a10-tv-encoder";
-   reg = <0x01c0a000 0x1000>;
-   clocks = < CLK_AHB_TVE>;
-   resets = < RST_TVE>;
-   status = "disabled";
-
-   port {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   tve0_in_tcon0: endpoint@0 {
-   reg = <0>;
-   remote-endpoint = <_out_tve0>;
-   };
-   };
-   };
-   };
-};
-
-_out {
-   tcon0_out_tve0: endpoint@1 {
-   reg = <1>;
-   remote-endpoint = <_in_tcon0>;
-   };
-};
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 9ba0c0302183..c8e2253cac1d 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -187,6 +187,24 @@
#size-cells = <0>;
};
 
+   tve0: tv-encoder@01c0a000 {
+   compatible = "allwinner,sun4i-a10-tv-encoder";
+   reg = <0x01c0a000 0x1000>;
+   clocks = < CLK_AHB_TVE>;
+   resets = < RST_TVE>;
+   status = "disabled";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tve0_in_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_tve0>;
+   };
+   };
+   };
+
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
@@ -238,6 +256,11 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+   tcon0_out_tve0: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = 
<_in_tcon0>;
+   };
};
};
};
-- 
git-series 0.8.11

[PATCH 8/9] ARM: sun5i: r8: Merge common controllers into the common DTSI

[Maxime Ripard]

Some controllers found in the R8 DTSI actually apply to all of the sun5i
family. Move those into the common DTSI so that all SoCs can benefit from
it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-r8.dtsi | 40 +--
 arch/arm/boot/dts/sun5i.dtsi| 23 -
 2 files changed, 23 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/sun5i-r8.dtsi
index 4c1141396c99..de35dbcd1191 100644
--- a/arch/arm/boot/dts/sun5i-r8.dtsi
+++ b/arch/arm/boot/dts/sun5i-r8.dtsi
@@ -45,43 +45,3 @@
 
 #include "sun5i-a13.dtsi"
 
-/ {
-   chosen {
-   framebuffer@1 {
-   compatible = "allwinner,simple-framebuffer",
-"simple-framebuffer";
-   allwinner,pipeline = "de_be0-lcd0-tve0";
-   clocks = < CLK_AHB_TVE>, < CLK_AHB_LCD>,
-< CLK_AHB_DE_BE>, < CLK_DE_BE>,
-< CLK_TCON_CH1>, < CLK_DRAM_DE_BE>;
-   status = "disabled";
-   };
-   };
-
-   soc@01c0 {
-   tve0: tv-encoder@01c0a000 {
-   compatible = "allwinner,sun4i-a10-tv-encoder";
-   reg = <0x01c0a000 0x1000>;
-   clocks = < CLK_AHB_TVE>;
-   resets = < RST_TVE>;
-   status = "disabled";
-
-   port {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   tve0_in_tcon0: endpoint@0 {
-   reg = <0>;
-   remote-endpoint = <_out_tve0>;
-   };
-   };
-   };
-   };
-};
-
-_out {
-   tcon0_out_tve0: endpoint@1 {
-   reg = <1>;
-   remote-endpoint = <_in_tcon0>;
-   };
-};
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 9ba0c0302183..c8e2253cac1d 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -187,6 +187,24 @@
#size-cells = <0>;
};
 
+   tve0: tv-encoder@01c0a000 {
+   compatible = "allwinner,sun4i-a10-tv-encoder";
+   reg = <0x01c0a000 0x1000>;
+   clocks = < CLK_AHB_TVE>;
+   resets = < RST_TVE>;
+   status = "disabled";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tve0_in_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_tve0>;
+   };
+   };
+   };
+
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
@@ -238,6 +256,11 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+   tcon0_out_tve0: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = 
<_in_tcon0>;
+   };
};
};
};
-- 
git-series 0.8.11

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

[Amir Goldstein]

On Mon, Feb 6, 2017 at 3:18 AM, James Bottomley
 wrote:
> On Sun, 2017-02-05 at 09:51 +0200, Amir Goldstein wrote:
>> On Sat, Feb 4, 2017 at 9:19 PM, James Bottomley
>>  wrote:
>> > This allows any subtree to be uid/gid shifted and bound elsewhere.
>> >  It does this by operating simlarly to overlayfs.  Its primary use
>> > is for shifting the underlying uids of filesystems used to support
>> > unpriviliged (uid shifted) containers.  The usual use case here is
>> > that the container is operating with an uid shifted unprivileged
>> > root but sometimes needs to make use of or work with a filesystem
>> > image that has root at real uid 0.
>> >
>> > The mechanism is to allow any subordinate mount namespace to mount
>> > a shiftfs filesystem (by marking it FS_USERNS_MOUNT) but only
>> > allowing it to mount marked subtrees (using the -o mark option as
>> > root).   Once mounted, the subtree is mapped via the super block
>> > user namespace so that the interior ids of the mounting user
>> > namespace are the ids written to the filesystem.
>> >
>> > Signed-off-by: James Bottomley <
>> > james.bottom...@hansenpartnership.com>
>> >
>>
>> James,
>>
>> Allow me to point out some problems in this patch and offer a
>> slightly different approach.
>>
>> First of all, the subject says "uid/gid shifting bind mount", but
>> it's not really a bind mount. What it is is a stackable mount and 2
>> levels of stack no less.
>
> The reason for the description is to have it behave exactly like a bind
> mount.  You can assert that a bind mount is, in fact, a stacked mount,
> but we don't currently.  I'm also not sure where you get your 2 levels
> from?
>

A bind mount does not incur recursion into VFS code, a stacked fs does.
And there is a programmable limit of stack depth of 2, which stacked
fs need to comply with.
Your proposed setup has 2 stacked fs, the mark shitfs by admin
and the uid shitfs by container user. Or maybe I misunderstood.


>>  So one thing that is missing is increasing of sb->s_stack_depth and
>> that also means that shiftfs cannot be used to recursively shift uids
>> in child userns if that was ever the intention.
>
> I can't think of a use case that would ever need that, but perhaps
> other container people can.
>
>> The other problem is that by forking overlayfs functionality,
>
> So this wouldn't really be the right way to look at it: shiftfs shares
> no code with overlayfs at all, so is definitely not a fork.  The only
> piece of functionality it has which is similar to overlayfs is the way
> it does lookups via a new dentry cache.  However, that functionality is
> not unique to overlayfs and if you look, you'll see that
> shiftfs_lookup() actually has far more in common with
> ecryptfs_lookup().

That's a good point. All stackable file systems may share similar problems
and solutions (e.g. consistent st_ino/st_dev). Perhaps it calls for shared
library code or more generic VFS code.
At the moment ecryptfs is not seeing much development, so everything
happens in overlayfs. If there is going to be more than 1 actively developed
stackable fs, we need to see about that.

>
>>  shiftfs is going to miss out on overlayfs bug fixes related to user
>> credentials differ from mounter credentials, like fd3220d ("ovl:
>> update S_ISGID when setting posix ACLs"). I am not sure that this
>> specific case is relevant to shiftfs, but there could be other.
>
> OK, so shiftfs doesn't have this bug and the reason why is
> illustrative: basically shiftfs does three things
>
>1. lookups via a uid/gid shifted dentry cache
>2. shifted credential inode operations permission checks on the
>   underlying filesystem
>3. location marking for unprivileged mount
>
> I think we've already seen that 1. isn't from overlayfs but the
> functionality could be added to overlayfs, I suppose.  The big problem
> is 2.  The overlayfs code emulates the permission checks, which makes
> it rather complex (this is where you get your bugs like the above
> from).  I did actually look at adding 2. to overlayfs on the theory
> that a single layer overlay might be closest to what this is, but
> eventually concluded I'd have to take the special cases and add a whole
> lot more to them ... it really would increase the maintenance burden
> substantially and make the code an unreadable rats nest.
>

The use cases for uid shifting are still overwelming for me.
I take your word for it that its going to be a maintanace burdon
to add this functionality to overlayfs.

> When you think about it this way, it becomes obvious that the clean
> separation is if shiftfs functionality is layered on top of overlayfs
> and when you do that, doing it as its own filesystem is more logical.
>

Yes, I agree with that statement. This is inline with the solution I outlined
at the end of my previous email, where single layer overlayfs is used
for the host "mark" mount, although I 

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

[Amir Goldstein]

On Mon, Feb 6, 2017 at 3:18 AM, James Bottomley
 wrote:
> On Sun, 2017-02-05 at 09:51 +0200, Amir Goldstein wrote:
>> On Sat, Feb 4, 2017 at 9:19 PM, James Bottomley
>>  wrote:
>> > This allows any subtree to be uid/gid shifted and bound elsewhere.
>> >  It does this by operating simlarly to overlayfs.  Its primary use
>> > is for shifting the underlying uids of filesystems used to support
>> > unpriviliged (uid shifted) containers.  The usual use case here is
>> > that the container is operating with an uid shifted unprivileged
>> > root but sometimes needs to make use of or work with a filesystem
>> > image that has root at real uid 0.
>> >
>> > The mechanism is to allow any subordinate mount namespace to mount
>> > a shiftfs filesystem (by marking it FS_USERNS_MOUNT) but only
>> > allowing it to mount marked subtrees (using the -o mark option as
>> > root).   Once mounted, the subtree is mapped via the super block
>> > user namespace so that the interior ids of the mounting user
>> > namespace are the ids written to the filesystem.
>> >
>> > Signed-off-by: James Bottomley <
>> > james.bottom...@hansenpartnership.com>
>> >
>>
>> James,
>>
>> Allow me to point out some problems in this patch and offer a
>> slightly different approach.
>>
>> First of all, the subject says "uid/gid shifting bind mount", but
>> it's not really a bind mount. What it is is a stackable mount and 2
>> levels of stack no less.
>
> The reason for the description is to have it behave exactly like a bind
> mount.  You can assert that a bind mount is, in fact, a stacked mount,
> but we don't currently.  I'm also not sure where you get your 2 levels
> from?
>

A bind mount does not incur recursion into VFS code, a stacked fs does.
And there is a programmable limit of stack depth of 2, which stacked
fs need to comply with.
Your proposed setup has 2 stacked fs, the mark shitfs by admin
and the uid shitfs by container user. Or maybe I misunderstood.


>>  So one thing that is missing is increasing of sb->s_stack_depth and
>> that also means that shiftfs cannot be used to recursively shift uids
>> in child userns if that was ever the intention.
>
> I can't think of a use case that would ever need that, but perhaps
> other container people can.
>
>> The other problem is that by forking overlayfs functionality,
>
> So this wouldn't really be the right way to look at it: shiftfs shares
> no code with overlayfs at all, so is definitely not a fork.  The only
> piece of functionality it has which is similar to overlayfs is the way
> it does lookups via a new dentry cache.  However, that functionality is
> not unique to overlayfs and if you look, you'll see that
> shiftfs_lookup() actually has far more in common with
> ecryptfs_lookup().

That's a good point. All stackable file systems may share similar problems
and solutions (e.g. consistent st_ino/st_dev). Perhaps it calls for shared
library code or more generic VFS code.
At the moment ecryptfs is not seeing much development, so everything
happens in overlayfs. If there is going to be more than 1 actively developed
stackable fs, we need to see about that.

>
>>  shiftfs is going to miss out on overlayfs bug fixes related to user
>> credentials differ from mounter credentials, like fd3220d ("ovl:
>> update S_ISGID when setting posix ACLs"). I am not sure that this
>> specific case is relevant to shiftfs, but there could be other.
>
> OK, so shiftfs doesn't have this bug and the reason why is
> illustrative: basically shiftfs does three things
>
>1. lookups via a uid/gid shifted dentry cache
>2. shifted credential inode operations permission checks on the
>   underlying filesystem
>3. location marking for unprivileged mount
>
> I think we've already seen that 1. isn't from overlayfs but the
> functionality could be added to overlayfs, I suppose.  The big problem
> is 2.  The overlayfs code emulates the permission checks, which makes
> it rather complex (this is where you get your bugs like the above
> from).  I did actually look at adding 2. to overlayfs on the theory
> that a single layer overlay might be closest to what this is, but
> eventually concluded I'd have to take the special cases and add a whole
> lot more to them ... it really would increase the maintenance burden
> substantially and make the code an unreadable rats nest.
>

The use cases for uid shifting are still overwelming for me.
I take your word for it that its going to be a maintanace burdon
to add this functionality to overlayfs.

> When you think about it this way, it becomes obvious that the clean
> separation is if shiftfs functionality is layered on top of overlayfs
> and when you do that, doing it as its own filesystem is more logical.
>

Yes, I agree with that statement. This is inline with the solution I outlined
at the end of my previous email, where single layer overlayfs is used
for the host "mark" mount, although I wonder if the same cannot be
achieved with a bind mount?

in host:
mount -t overlay 

[PATCH] [media] usbtv: add sharpness control

[Lubomir Rintel]

Signed-off-by: Lubomir Rintel 
---
 drivers/media/usb/usbtv/usbtv-video.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/usb/usbtv/usbtv-video.c 
b/drivers/media/usb/usbtv/usbtv-video.c
index d3b6d3d..8135614 100644
--- a/drivers/media/usb/usbtv/usbtv-video.c
+++ b/drivers/media/usb/usbtv/usbtv-video.c
@@ -757,6 +757,12 @@ static int usbtv_s_ctrl(struct v4l2_ctrl *ctrl)
data[1] = -ctrl->val & 0xff;
}
break;
+   case V4L2_CID_SHARPNESS:
+   index = USBTV_BASE + 0x0239;
+   data[0] = 0;
+   data[1] = ctrl->val;
+   size = 2;
+   break;
default:
kfree(data);
return -EINVAL;
@@ -825,6 +831,8 @@ int usbtv_video_init(struct usbtv *usbtv)
V4L2_CID_SATURATION, 0, 0x3ff, 1, 0x200);
v4l2_ctrl_new_std(>ctrl, _ctrl_ops,
V4L2_CID_HUE, -0xdff, 0xdff, 1, 0x000);
+   v4l2_ctrl_new_std(>ctrl, _ctrl_ops,
+   V4L2_CID_SHARPNESS, 0x0, 0xff, 1, 0x60);
ret = usbtv->ctrl.error;
if (ret < 0) {
dev_warn(usbtv->dev, "Could not initialize controls\n");
-- 
2.9.3

[PATCH] [media] usbtv: add sharpness control

[Lubomir Rintel]

Signed-off-by: Lubomir Rintel 
---
 drivers/media/usb/usbtv/usbtv-video.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/usb/usbtv/usbtv-video.c 
b/drivers/media/usb/usbtv/usbtv-video.c
index d3b6d3d..8135614 100644
--- a/drivers/media/usb/usbtv/usbtv-video.c
+++ b/drivers/media/usb/usbtv/usbtv-video.c
@@ -757,6 +757,12 @@ static int usbtv_s_ctrl(struct v4l2_ctrl *ctrl)
data[1] = -ctrl->val & 0xff;
}
break;
+   case V4L2_CID_SHARPNESS:
+   index = USBTV_BASE + 0x0239;
+   data[0] = 0;
+   data[1] = ctrl->val;
+   size = 2;
+   break;
default:
kfree(data);
return -EINVAL;
@@ -825,6 +831,8 @@ int usbtv_video_init(struct usbtv *usbtv)
V4L2_CID_SATURATION, 0, 0x3ff, 1, 0x200);
v4l2_ctrl_new_std(>ctrl, _ctrl_ops,
V4L2_CID_HUE, -0xdff, 0xdff, 1, 0x000);
+   v4l2_ctrl_new_std(>ctrl, _ctrl_ops,
+   V4L2_CID_SHARPNESS, 0x0, 0xff, 1, 0x60);
ret = usbtv->ctrl.error;
if (ret < 0) {
dev_warn(usbtv->dev, "Could not initialize controls\n");
-- 
2.9.3

Re: [PATCH 2/4] iio: chemical: add driver for dsm501/ppd42ns particle sensors

[Matt Ranostay]

> On Feb 5, 2017, at 08:24, Tomasz Duszynski  wrote:
> 
> Thanks for review!
> 
>> On Sun, Feb 05, 2017 at 04:19:47PM +0100, Peter Meerwald-Stadler wrote:
>> 
>>> This patch adds support for dsm501 and ppd42ns particle sensors.
>> 
>> quick comments below
>> G
>>> Both sensors work on the same principle. Heater (resistor) heats up air
>>> in sensor chamber which induces upward flow. Particles convect up through
>>> a light beam provided by internal infra-red LED. Light scattered by
>>> particles is picked by photodiode and internal electronics outputs PWM
>>> signal.
>>> 
>>> Measuring low time occupancy of the signal during 30s measurement period
>>> particles number in cubic meter can be computed.
>>> 

This a SI unit?

Also this maybe could be better off in drivers/iio/light... as much I like to 
have other people in drivers/iio/chemical 
>>> Signed-off-by: Tomasz Duszynski 
>>> ---
>>> drivers/iio/chemical/Kconfig  |  10 ++
>>> drivers/iio/chemical/Makefile |   1 +
>>> drivers/iio/chemical/dsm501.c | 231 
>>> ++
>>> 3 files changed, 242 insertions(+)
>>> create mode 100644 drivers/iio/chemical/dsm501.c
>>> 
>>> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
>>> index cea7f9857a1f..986d612aa77f 100644
>>> --- a/drivers/iio/chemical/Kconfig
>>> +++ b/drivers/iio/chemical/Kconfig
>>> @@ -21,6 +21,16 @@ config ATLAS_PH_SENSOR
>>> To compile this driver as module, choose M here: the
>>> module will be called atlas-ph-sensor.
>>> 
>>> +config DSM501
>>> +tristate "Samyoung DSM501 particle sensor"
>>> +depends on GPIOLIB
>>> +help
>>> + Say yes here to build support for the Samyoung DSM501
>>> + particle sensor.
>>> +
>>> + To compile this driver as a module, choose M here: the module
>>> + will be called dsm501.
>>> +
>>> config IAQCORE
>>>tristate "AMS iAQ-Core VOC sensors"
>>>depends on I2C
>>> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
>>> index b02202b41289..76f50ff8ba7d 100644
>>> --- a/drivers/iio/chemical/Makefile
>>> +++ b/drivers/iio/chemical/Makefile
>>> @@ -4,5 +4,6 @@
>>> 
>>> # When adding new entries keep the list in alphabetical order
>>> obj-$(CONFIG_ATLAS_PH_SENSOR)+= atlas-ph-sensor.o
>>> +obj-$(CONFIG_DSM501)+= dsm501.o
>>> obj-$(CONFIG_IAQCORE)+= ams-iaq-core.o
>>> obj-$(CONFIG_VZ89X)+= vz89x.o
>>> diff --git a/drivers/iio/chemical/dsm501.c b/drivers/iio/chemical/dsm501.c
>>> new file mode 100644
>>> index ..013f6b3bfd48
>>> --- /dev/null
>>> +++ b/drivers/iio/chemical/dsm501.c
>>> @@ -0,0 +1,231 @@
>>> +/*
>>> + * Samyoung DSM501 particle sensor driver
>>> + *
>>> + * Copyright (C) 2017 Tomasz Duszynski 
>>> + *
>>> + * Datasheets:
>>> + *  http://www.samyoungsnc.com/products/3-1%20Specification%20DSM501.pdf
>>> + *  http://wiki.timelab.org/images/f/f9/PPD42NS.pdf
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define DSM501_DRV_NAME "dsm501"
>>> +#defineDSM501_IRQ_NAME "dsm501_irq"
>> 
>> replace tab by space
> Ack.
>> 
>>> +
>>> +#define DSM501_DEFAULT_MEASUREMENT_TIME 30 /* seconds */
>>> +
>>> +struct dsm501_data {
>>> +ktime_t ts;
>>> +ktime_t low_time;
>>> +ktime_t meas_time;
>>> +
>>> +int irq;
>>> +struct gpio_desc *gpio;
>>> +
>>> +struct mutex lock;
>>> +
>>> +int (*number_concentration)(struct dsm501_data *data);
>>> +};
>>> +
>>> +/*
>>> + * Series of data points in Fig. 8-3 (Low Ratio vs Particle)
>>> + * can be approximated by following polynomials:
>>> + *
>>> + * p(r) = 0 (undefined) for r < 4
>>> + * p(r) = 2353564.2r - 4373814.7 for 4 <= r < 20
>>> + * p(r) = 4788112.4r - 53581390 for r >= 20
>>> + *
>>> + * Note: Result is in pcs/m3. To convert to pcs/0.01cf multiply
>>> + * by 0.0002831685.
>> 
>> is cf needed?
> No. I've put that sidenote so that others looking at figures in
> datahseets won't scratch their heads why units here are pcs/m3 and
> pcs/0.01cf there. Anyway I am happy to drop that part.
>> 
>>> + */
>>> +static int dsm501_number_concentartion(struct dsm501_data *data)
>>> +{
>>> +s64 retval = 0, r = div64_s64(ktime_to_ns(data->low_time) * 100,
>>> +  

Re: [PATCH 2/4] iio: chemical: add driver for dsm501/ppd42ns particle sensors

[Matt Ranostay]

> On Feb 5, 2017, at 08:24, Tomasz Duszynski  wrote:
> 
> Thanks for review!
> 
>> On Sun, Feb 05, 2017 at 04:19:47PM +0100, Peter Meerwald-Stadler wrote:
>> 
>>> This patch adds support for dsm501 and ppd42ns particle sensors.
>> 
>> quick comments below
>> G
>>> Both sensors work on the same principle. Heater (resistor) heats up air
>>> in sensor chamber which induces upward flow. Particles convect up through
>>> a light beam provided by internal infra-red LED. Light scattered by
>>> particles is picked by photodiode and internal electronics outputs PWM
>>> signal.
>>> 
>>> Measuring low time occupancy of the signal during 30s measurement period
>>> particles number in cubic meter can be computed.
>>> 

This a SI unit?

Also this maybe could be better off in drivers/iio/light... as much I like to 
have other people in drivers/iio/chemical 
>>> Signed-off-by: Tomasz Duszynski 
>>> ---
>>> drivers/iio/chemical/Kconfig  |  10 ++
>>> drivers/iio/chemical/Makefile |   1 +
>>> drivers/iio/chemical/dsm501.c | 231 
>>> ++
>>> 3 files changed, 242 insertions(+)
>>> create mode 100644 drivers/iio/chemical/dsm501.c
>>> 
>>> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
>>> index cea7f9857a1f..986d612aa77f 100644
>>> --- a/drivers/iio/chemical/Kconfig
>>> +++ b/drivers/iio/chemical/Kconfig
>>> @@ -21,6 +21,16 @@ config ATLAS_PH_SENSOR
>>> To compile this driver as module, choose M here: the
>>> module will be called atlas-ph-sensor.
>>> 
>>> +config DSM501
>>> +tristate "Samyoung DSM501 particle sensor"
>>> +depends on GPIOLIB
>>> +help
>>> + Say yes here to build support for the Samyoung DSM501
>>> + particle sensor.
>>> +
>>> + To compile this driver as a module, choose M here: the module
>>> + will be called dsm501.
>>> +
>>> config IAQCORE
>>>tristate "AMS iAQ-Core VOC sensors"
>>>depends on I2C
>>> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
>>> index b02202b41289..76f50ff8ba7d 100644
>>> --- a/drivers/iio/chemical/Makefile
>>> +++ b/drivers/iio/chemical/Makefile
>>> @@ -4,5 +4,6 @@
>>> 
>>> # When adding new entries keep the list in alphabetical order
>>> obj-$(CONFIG_ATLAS_PH_SENSOR)+= atlas-ph-sensor.o
>>> +obj-$(CONFIG_DSM501)+= dsm501.o
>>> obj-$(CONFIG_IAQCORE)+= ams-iaq-core.o
>>> obj-$(CONFIG_VZ89X)+= vz89x.o
>>> diff --git a/drivers/iio/chemical/dsm501.c b/drivers/iio/chemical/dsm501.c
>>> new file mode 100644
>>> index ..013f6b3bfd48
>>> --- /dev/null
>>> +++ b/drivers/iio/chemical/dsm501.c
>>> @@ -0,0 +1,231 @@
>>> +/*
>>> + * Samyoung DSM501 particle sensor driver
>>> + *
>>> + * Copyright (C) 2017 Tomasz Duszynski 
>>> + *
>>> + * Datasheets:
>>> + *  http://www.samyoungsnc.com/products/3-1%20Specification%20DSM501.pdf
>>> + *  http://wiki.timelab.org/images/f/f9/PPD42NS.pdf
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define DSM501_DRV_NAME "dsm501"
>>> +#defineDSM501_IRQ_NAME "dsm501_irq"
>> 
>> replace tab by space
> Ack.
>> 
>>> +
>>> +#define DSM501_DEFAULT_MEASUREMENT_TIME 30 /* seconds */
>>> +
>>> +struct dsm501_data {
>>> +ktime_t ts;
>>> +ktime_t low_time;
>>> +ktime_t meas_time;
>>> +
>>> +int irq;
>>> +struct gpio_desc *gpio;
>>> +
>>> +struct mutex lock;
>>> +
>>> +int (*number_concentration)(struct dsm501_data *data);
>>> +};
>>> +
>>> +/*
>>> + * Series of data points in Fig. 8-3 (Low Ratio vs Particle)
>>> + * can be approximated by following polynomials:
>>> + *
>>> + * p(r) = 0 (undefined) for r < 4
>>> + * p(r) = 2353564.2r - 4373814.7 for 4 <= r < 20
>>> + * p(r) = 4788112.4r - 53581390 for r >= 20
>>> + *
>>> + * Note: Result is in pcs/m3. To convert to pcs/0.01cf multiply
>>> + * by 0.0002831685.
>> 
>> is cf needed?
> No. I've put that sidenote so that others looking at figures in
> datahseets won't scratch their heads why units here are pcs/m3 and
> pcs/0.01cf there. Anyway I am happy to drop that part.
>> 
>>> + */
>>> +static int dsm501_number_concentartion(struct dsm501_data *data)
>>> +{
>>> +s64 retval = 0, r = div64_s64(ktime_to_ns(data->low_time) * 100,
>>> +  ktime_to_ns(data->meas_time));
>>> +
>>> +if (r >= 4 && r < 20)
>>> +retval = 

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

[James Bottomley]

On Mon, 2017-02-06 at 12:25 +0900, J. R. Okajima wrote:
> James Bottomley:
> > This allows any subtree to be uid/gid shifted and bound elsewhere. 
> >  It
>   :::
> 
> Interesting.
> But I am afraid that the inconsistency problem of the inode numbers 
> will happen.
> 
> shiftfs_new_inode() uses get_next_ino() which means
> - 1st time: inodeA is created and cached, inumA is assigned
> - after using inodeA, it will be discarded from the cache
> - 2nd time: inodeA is looked-up again, and another inode number 
> (inumB)   is assgined.

Yes, I know the problem.  However, I believe most current linux
filesystems no longer guarantee stable, for the lifetime of the file,
inode numbers.  The usual docker container root is overlayfs, which,
similarly doesn't support stable inode numbers.  I see the odd
complaint about docker with overlayfs having unstable inode numbers,
but none seems to have any serious repercussions.

[...]
> If shiftfs will supports exporting via NFS in the future, the
> consistency of inum will be important too.

If it's a problem, then it's fixable with s_export_op, but I was mostly
thinking that because it's not a problem for overlayfs based
containers, it wouldn't be one for shiftfs based ones, which is why I
didn't implement it.

James

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

[James Bottomley]

On Mon, 2017-02-06 at 12:25 +0900, J. R. Okajima wrote:
> James Bottomley:
> > This allows any subtree to be uid/gid shifted and bound elsewhere. 
> >  It
>   :::
> 
> Interesting.
> But I am afraid that the inconsistency problem of the inode numbers 
> will happen.
> 
> shiftfs_new_inode() uses get_next_ino() which means
> - 1st time: inodeA is created and cached, inumA is assigned
> - after using inodeA, it will be discarded from the cache
> - 2nd time: inodeA is looked-up again, and another inode number 
> (inumB)   is assgined.

Yes, I know the problem.  However, I believe most current linux
filesystems no longer guarantee stable, for the lifetime of the file,
inode numbers.  The usual docker container root is overlayfs, which,
similarly doesn't support stable inode numbers.  I see the odd
complaint about docker with overlayfs having unstable inode numbers,
but none seems to have any serious repercussions.

[...]
> If shiftfs will supports exporting via NFS in the future, the
> consistency of inum will be important too.

If it's a problem, then it's fixable with s_export_op, but I was mostly
thinking that because it's not a problem for overlayfs based
containers, it wouldn't be one for shiftfs based ones, which is why I
didn't implement it.

James

Re: [PATCH 3/3] MIPS: BMIPS: enable CPUfreq

[Markus Mayer]

On 5 February 2017 at 19:35, Viresh Kumar  wrote:
>
> On 03-02-17, 17:00, Markus Mayer wrote:
> > On 2 February 2017 at 20:29, Viresh Kumar  wrote:
> > > On 01-02-17, 17:06, Markus Mayer wrote:
> > >> From: Markus Mayer 
> > >>
> > >> Enable all applicable CPUfreq options.
> > >>
> > >> Signed-off-by: Markus Mayer 
> > >> ---
> > >>  arch/mips/configs/bmips_stb_defconfig | 10 ++
> > >>  1 file changed, 10 insertions(+)
> > >>
> > >> diff --git a/arch/mips/configs/bmips_stb_defconfig 
> > >> b/arch/mips/configs/bmips_stb_defconfig
> > >> index 4eb5d6e..6fda604 100644
> > >> --- a/arch/mips/configs/bmips_stb_defconfig
> > >> +++ b/arch/mips/configs/bmips_stb_defconfig
> > >> @@ -26,6 +26,16 @@ CONFIG_INET=y
> > >>  # CONFIG_INET_XFRM_MODE_BEET is not set
> > >>  # CONFIG_INET_LRO is not set
> > >>  # CONFIG_INET_DIAG is not set
> > >> +CONFIG_CPU_FREQ=y
> > >> +CONFIG_CPU_FREQ_STAT=y
> > >> +CONFIG_CPU_FREQ_STAT_DETAILS=y
> > >> +CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> > >> +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> > >> +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> > >> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> > >> +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> > >> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> > >> +CONFIG_BMIPS_CPUFREQ=y
> > >>  CONFIG_CFG80211=y
> > >>  CONFIG_NL80211_TESTMODE=y
> > >>  CONFIG_MAC80211=y
> > >
> > > Rebase your stuff over pm/linux-next and you will see some changes here. 
> > > Also
> > > schedutil is the new governor in town, you must give it a try.
> >
> > I'll definitely turn on SCHEDUTIL. As for the changes in next, I don't
> > see any conflicts. My series applied fine on top of linux-next from
> > https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/. Did
> > I use the wrong tree?
>
> No, but you didn't follow the right process. You should use 'make
> savedefconfig' to update the defconfig.
>
> The symbol CONFIG_CPU_FREQ_STAT_DETAILS is removed from the kernel
> now.

Okay. Got it. Will do.

-Markus

Re: [PATCH 3/3] MIPS: BMIPS: enable CPUfreq

[Markus Mayer]

On 5 February 2017 at 19:35, Viresh Kumar  wrote:
>
> On 03-02-17, 17:00, Markus Mayer wrote:
> > On 2 February 2017 at 20:29, Viresh Kumar  wrote:
> > > On 01-02-17, 17:06, Markus Mayer wrote:
> > >> From: Markus Mayer 
> > >>
> > >> Enable all applicable CPUfreq options.
> > >>
> > >> Signed-off-by: Markus Mayer 
> > >> ---
> > >>  arch/mips/configs/bmips_stb_defconfig | 10 ++
> > >>  1 file changed, 10 insertions(+)
> > >>
> > >> diff --git a/arch/mips/configs/bmips_stb_defconfig 
> > >> b/arch/mips/configs/bmips_stb_defconfig
> > >> index 4eb5d6e..6fda604 100644
> > >> --- a/arch/mips/configs/bmips_stb_defconfig
> > >> +++ b/arch/mips/configs/bmips_stb_defconfig
> > >> @@ -26,6 +26,16 @@ CONFIG_INET=y
> > >>  # CONFIG_INET_XFRM_MODE_BEET is not set
> > >>  # CONFIG_INET_LRO is not set
> > >>  # CONFIG_INET_DIAG is not set
> > >> +CONFIG_CPU_FREQ=y
> > >> +CONFIG_CPU_FREQ_STAT=y
> > >> +CONFIG_CPU_FREQ_STAT_DETAILS=y
> > >> +CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> > >> +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> > >> +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> > >> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> > >> +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> > >> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> > >> +CONFIG_BMIPS_CPUFREQ=y
> > >>  CONFIG_CFG80211=y
> > >>  CONFIG_NL80211_TESTMODE=y
> > >>  CONFIG_MAC80211=y
> > >
> > > Rebase your stuff over pm/linux-next and you will see some changes here. 
> > > Also
> > > schedutil is the new governor in town, you must give it a try.
> >
> > I'll definitely turn on SCHEDUTIL. As for the changes in next, I don't
> > see any conflicts. My series applied fine on top of linux-next from
> > https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/. Did
> > I use the wrong tree?
>
> No, but you didn't follow the right process. You should use 'make
> savedefconfig' to update the defconfig.
>
> The symbol CONFIG_CPU_FREQ_STAT_DETAILS is removed from the kernel
> now.

Okay. Got it. Will do.

-Markus

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

[Amir Goldstein]

On Mon, Feb 6, 2017 at 5:25 AM, J. R. Okajima  wrote:
> James Bottomley:
>> This allows any subtree to be uid/gid shifted and bound elsewhere.  It
> :::
>
> Interesting.
> But I am afraid that the inconsistency problem of the inode numbers will
> happen.
>

Yet another example that overlayfs already is in the process of solving
(it is fixed for stat of merged directory inode).
In fact, fir the case of single layer overlay (as well as shiftfs) the
solution is trivial -
preserve underlying inode st_ino/d_ino and use the overlayed fs st_dev.

> shiftfs_new_inode() uses get_next_ino() which means
> - 1st time: inodeA is created and cached, inumA is assigned
> - after using inodeA, it will be discarded from the cache
> - 2nd time: inodeA is looked-up again, and another inode number (inumB)
>   is assgined.
>
> This inconsistency will not be a problem for the "pure virtual" fs such
> as procfs and sysfs. But your shiftfs is not pure as them. Shiftfs will
> be used as a wrapper (or "binder" which means bind-mount) of an orginary
> filesystem.
> The symptom of this problem from users perspective will be
> - find -inum doesn't work
> - git-status doesn't work, which keeps st_dev and st_ino and compares
>   the current files.
> Of course they will be limited to when the target dir is huge and/or
> system memory is low. As long as the inode cache is large enough to hold
> all necessary inodes, the problem won't happen.
>
> If shiftfs will supports exporting via NFS in the future, the
> consistency of inum will be important too.
>
>
> J. R. Okajima

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

[Amir Goldstein]

On Mon, Feb 6, 2017 at 5:25 AM, J. R. Okajima  wrote:
> James Bottomley:
>> This allows any subtree to be uid/gid shifted and bound elsewhere.  It
> :::
>
> Interesting.
> But I am afraid that the inconsistency problem of the inode numbers will
> happen.
>

Yet another example that overlayfs already is in the process of solving
(it is fixed for stat of merged directory inode).
In fact, fir the case of single layer overlay (as well as shiftfs) the
solution is trivial -
preserve underlying inode st_ino/d_ino and use the overlayed fs st_dev.

> shiftfs_new_inode() uses get_next_ino() which means
> - 1st time: inodeA is created and cached, inumA is assigned
> - after using inodeA, it will be discarded from the cache
> - 2nd time: inodeA is looked-up again, and another inode number (inumB)
>   is assgined.
>
> This inconsistency will not be a problem for the "pure virtual" fs such
> as procfs and sysfs. But your shiftfs is not pure as them. Shiftfs will
> be used as a wrapper (or "binder" which means bind-mount) of an orginary
> filesystem.
> The symptom of this problem from users perspective will be
> - find -inum doesn't work
> - git-status doesn't work, which keeps st_dev and st_ino and compares
>   the current files.
> Of course they will be limited to when the target dir is huge and/or
> system memory is low. As long as the inode cache is large enough to hold
> all necessary inodes, the problem won't happen.
>
> If shiftfs will supports exporting via NFS in the future, the
> consistency of inum will be important too.
>
>
> J. R. Okajima