[PATCH 02/13] sh: drivers: convert to SPDX identifiers

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch updates license to use SPDX-License-Identifier
instead of verbose license text.

As original license mentioned, it is GPL-2.0 in SPDX.
Then, MODULE_LICENSE() should be "GPL v2" instead of "GPL".
See ${LINUX}/include/linux/module.h

"GPL"   [GNU Public License v2 or later]
"GPL v2"[GNU Public License v2]

Signed-off-by: Kuninori Morimoto 
Reviewed-by: Simon Horman 
---
 arch/sh/drivers/dma/Makefile | 1 +
 arch/sh/drivers/dma/dma-api.c| 7 ++-
 arch/sh/drivers/dma/dma-g2.c | 7 ++-
 arch/sh/drivers/dma/dma-pvr2.c   | 7 ++-
 arch/sh/drivers/dma/dma-sh.c | 7 ++-
 arch/sh/drivers/dma/dma-sysfs.c  | 5 +
 arch/sh/drivers/dma/dmabrg.c | 3 +--
 arch/sh/drivers/heartbeat.c  | 5 +
 arch/sh/drivers/pci/fixups-dreamcast.c   | 5 +
 arch/sh/drivers/pci/fixups-landisk.c | 4 +---
 arch/sh/drivers/pci/fixups-r7780rp.c | 5 +
 arch/sh/drivers/pci/fixups-rts7751r2d.c  | 5 +
 arch/sh/drivers/pci/fixups-sdk7780.c | 5 +
 arch/sh/drivers/pci/fixups-sdk7786.c | 5 +
 arch/sh/drivers/pci/fixups-snapgear.c| 4 +---
 arch/sh/drivers/pci/fixups-titan.c   | 4 +---
 arch/sh/drivers/pci/ops-dreamcast.c  | 5 +
 arch/sh/drivers/pci/ops-sh4.c| 5 +
 arch/sh/drivers/pci/ops-sh5.c| 4 +---
 arch/sh/drivers/pci/ops-sh7786.c | 5 +
 arch/sh/drivers/pci/pci-dreamcast.c  | 5 +
 arch/sh/drivers/pci/pci-sh5.c| 4 +---
 arch/sh/drivers/pci/pci-sh5.h| 6 ++
 arch/sh/drivers/pci/pci-sh7751.c | 5 +
 arch/sh/drivers/pci/pci-sh7751.h | 7 ++-
 arch/sh/drivers/pci/pci-sh7780.c | 5 +
 arch/sh/drivers/pci/pci-sh7780.h | 7 ++-
 arch/sh/drivers/pci/pci.c| 5 +
 arch/sh/drivers/pci/pcie-sh7786.c| 5 +
 arch/sh/drivers/pci/pcie-sh7786.h| 7 ++-
 arch/sh/drivers/push-switch.c| 5 +
 arch/sh/drivers/superhyway/Makefile  | 1 +
 arch/sh/drivers/superhyway/ops-sh4-202.c | 5 +
 33 files changed, 41 insertions(+), 124 deletions(-)

diff --git a/arch/sh/drivers/dma/Makefile b/arch/sh/drivers/dma/Makefile
index d88c948..d2fdd56 100644
--- a/arch/sh/drivers/dma/Makefile
+++ b/arch/sh/drivers/dma/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
 #
 # Makefile for the SuperH DMA specific kernel interface routines under Linux.
 #
diff --git a/arch/sh/drivers/dma/dma-api.c b/arch/sh/drivers/dma/dma-api.c
index b05be59..ab91704 100644
--- a/arch/sh/drivers/dma/dma-api.c
+++ b/arch/sh/drivers/dma/dma-api.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * arch/sh/drivers/dma/dma-api.c
  *
  * SuperH-specific DMA management API
  *
  * Copyright (C) 2003, 2004, 2005  Paul Mundt
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
 #include 
 #include 
@@ -417,4 +414,4 @@ subsys_initcall(dma_api_init);
 
 MODULE_AUTHOR("Paul Mundt ");
 MODULE_DESCRIPTION("DMA API for SuperH");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/arch/sh/drivers/dma/dma-g2.c b/arch/sh/drivers/dma/dma-g2.c
index e1ab6eb..52a8ae5 100644
--- a/arch/sh/drivers/dma/dma-g2.c
+++ b/arch/sh/drivers/dma/dma-g2.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * arch/sh/drivers/dma/dma-g2.c
  *
  * G2 bus DMA support
  *
  * Copyright (C) 2003 - 2006  Paul Mundt
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
 #include 
 #include 
@@ -197,4 +194,4 @@ module_exit(g2_dma_exit);
 
 MODULE_AUTHOR("Paul Mundt ");
 MODULE_DESCRIPTION("G2 bus DMA driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/arch/sh/drivers/dma/dma-pvr2.c b/arch/sh/drivers/dma/dma-pvr2.c
index 706a343..b5dbd1f 100644
--- a/arch/sh/drivers/dma/dma-pvr2.c
+++ b/arch/sh/drivers/dma/dma-pvr2.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * arch/sh/drivers/dma/dma-pvr2.c
  *
  * NEC PowerVR 2 (Dreamcast) DMA support
  *
  * Copyright (C) 2003, 2004  Paul Mundt
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
 #include 
 #include 
@@ -105,4 +102,4 @@ module_exit(pvr2_dma_exit);
 
 MODULE_AUTHOR("Paul Mundt ");
 MODULE_DESCRIPTION("NEC PowerVR 2 DMA driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/arch/sh/drivers/dma/dma-sh.c b/arch/sh/drivers/dma/dma-sh.c
index afde2a7..96c626c 100644
--- a/arch/sh/drivers/dma/dma-sh.c
+++ b/arch/sh/drivers/dma/dma-sh.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * 

[PATCH 02/13] sh: drivers: convert to SPDX identifiers

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch updates license to use SPDX-License-Identifier
instead of verbose license text.

As original license mentioned, it is GPL-2.0 in SPDX.
Then, MODULE_LICENSE() should be "GPL v2" instead of "GPL".
See ${LINUX}/include/linux/module.h

"GPL"   [GNU Public License v2 or later]
"GPL v2"[GNU Public License v2]

Signed-off-by: Kuninori Morimoto 
Reviewed-by: Simon Horman 
---
 arch/sh/drivers/dma/Makefile | 1 +
 arch/sh/drivers/dma/dma-api.c| 7 ++-
 arch/sh/drivers/dma/dma-g2.c | 7 ++-
 arch/sh/drivers/dma/dma-pvr2.c   | 7 ++-
 arch/sh/drivers/dma/dma-sh.c | 7 ++-
 arch/sh/drivers/dma/dma-sysfs.c  | 5 +
 arch/sh/drivers/dma/dmabrg.c | 3 +--
 arch/sh/drivers/heartbeat.c  | 5 +
 arch/sh/drivers/pci/fixups-dreamcast.c   | 5 +
 arch/sh/drivers/pci/fixups-landisk.c | 4 +---
 arch/sh/drivers/pci/fixups-r7780rp.c | 5 +
 arch/sh/drivers/pci/fixups-rts7751r2d.c  | 5 +
 arch/sh/drivers/pci/fixups-sdk7780.c | 5 +
 arch/sh/drivers/pci/fixups-sdk7786.c | 5 +
 arch/sh/drivers/pci/fixups-snapgear.c| 4 +---
 arch/sh/drivers/pci/fixups-titan.c   | 4 +---
 arch/sh/drivers/pci/ops-dreamcast.c  | 5 +
 arch/sh/drivers/pci/ops-sh4.c| 5 +
 arch/sh/drivers/pci/ops-sh5.c| 4 +---
 arch/sh/drivers/pci/ops-sh7786.c | 5 +
 arch/sh/drivers/pci/pci-dreamcast.c  | 5 +
 arch/sh/drivers/pci/pci-sh5.c| 4 +---
 arch/sh/drivers/pci/pci-sh5.h| 6 ++
 arch/sh/drivers/pci/pci-sh7751.c | 5 +
 arch/sh/drivers/pci/pci-sh7751.h | 7 ++-
 arch/sh/drivers/pci/pci-sh7780.c | 5 +
 arch/sh/drivers/pci/pci-sh7780.h | 7 ++-
 arch/sh/drivers/pci/pci.c| 5 +
 arch/sh/drivers/pci/pcie-sh7786.c| 5 +
 arch/sh/drivers/pci/pcie-sh7786.h| 7 ++-
 arch/sh/drivers/push-switch.c| 5 +
 arch/sh/drivers/superhyway/Makefile  | 1 +
 arch/sh/drivers/superhyway/ops-sh4-202.c | 5 +
 33 files changed, 41 insertions(+), 124 deletions(-)

diff --git a/arch/sh/drivers/dma/Makefile b/arch/sh/drivers/dma/Makefile
index d88c948..d2fdd56 100644
--- a/arch/sh/drivers/dma/Makefile
+++ b/arch/sh/drivers/dma/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
 #
 # Makefile for the SuperH DMA specific kernel interface routines under Linux.
 #
diff --git a/arch/sh/drivers/dma/dma-api.c b/arch/sh/drivers/dma/dma-api.c
index b05be59..ab91704 100644
--- a/arch/sh/drivers/dma/dma-api.c
+++ b/arch/sh/drivers/dma/dma-api.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * arch/sh/drivers/dma/dma-api.c
  *
  * SuperH-specific DMA management API
  *
  * Copyright (C) 2003, 2004, 2005  Paul Mundt
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
 #include 
 #include 
@@ -417,4 +414,4 @@ subsys_initcall(dma_api_init);
 
 MODULE_AUTHOR("Paul Mundt ");
 MODULE_DESCRIPTION("DMA API for SuperH");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/arch/sh/drivers/dma/dma-g2.c b/arch/sh/drivers/dma/dma-g2.c
index e1ab6eb..52a8ae5 100644
--- a/arch/sh/drivers/dma/dma-g2.c
+++ b/arch/sh/drivers/dma/dma-g2.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * arch/sh/drivers/dma/dma-g2.c
  *
  * G2 bus DMA support
  *
  * Copyright (C) 2003 - 2006  Paul Mundt
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
 #include 
 #include 
@@ -197,4 +194,4 @@ module_exit(g2_dma_exit);
 
 MODULE_AUTHOR("Paul Mundt ");
 MODULE_DESCRIPTION("G2 bus DMA driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/arch/sh/drivers/dma/dma-pvr2.c b/arch/sh/drivers/dma/dma-pvr2.c
index 706a343..b5dbd1f 100644
--- a/arch/sh/drivers/dma/dma-pvr2.c
+++ b/arch/sh/drivers/dma/dma-pvr2.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * arch/sh/drivers/dma/dma-pvr2.c
  *
  * NEC PowerVR 2 (Dreamcast) DMA support
  *
  * Copyright (C) 2003, 2004  Paul Mundt
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
 #include 
 #include 
@@ -105,4 +102,4 @@ module_exit(pvr2_dma_exit);
 
 MODULE_AUTHOR("Paul Mundt ");
 MODULE_DESCRIPTION("NEC PowerVR 2 DMA driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/arch/sh/drivers/dma/dma-sh.c b/arch/sh/drivers/dma/dma-sh.c
index afde2a7..96c626c 100644
--- a/arch/sh/drivers/dma/dma-sh.c
+++ b/arch/sh/drivers/dma/dma-sh.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * 

[PATCH resend 00/13] sh: convert to SPDX identifiers

[Kuninori Morimoto]

Hi Andrew Morton.
Cc SH ML

I'm posting these patches to SH ML from few month ago,
but, nothing happen.
SH Maintainer seems not working anymore ?
I'm not sure...

So now, I added Andrew in To: field.
I'm happy if some maintainer can handle these

Kuninori Morimoto (13):
  sh: boards: convert to SPDX identifiers
  sh: drivers: convert to SPDX identifiers
  sh: include: convert to SPDX identifiers
  sh: sh2: convert to SPDX identifiers
  sh: sh2a: convert to SPDX identifiers
  sh: sh3: convert to SPDX identifiers
  sh: sh4: convert to SPDX identifiers
  sh: sh4a: convert to SPDX identifiers
  sh: sh5: convert to SPDX identifiers
  sh: shmobile: convert to SPDX identifiers
  sh: cpu: convert to SPDX identifiers
  sh: kernel: convert to SPDX identifiers
  sh: lib: convert to SPDX identifiers

 arch/sh/boards/board-apsh4a3a.c|  5 +---
 arch/sh/boards/board-apsh4ad0a.c   |  5 +---
 arch/sh/boards/board-edosk7760.c   | 15 +--
 arch/sh/boards/board-espt.c|  5 +---
 arch/sh/boards/board-magicpanelr2.c|  5 +---
 arch/sh/boards/board-sh7757lcr.c   |  5 +---
 arch/sh/boards/board-sh7785lcr.c   |  5 +---
 arch/sh/boards/board-titan.c   |  5 +---
 arch/sh/boards/board-urquell.c |  5 +---
 arch/sh/boards/mach-ap325rxa/Makefile  |  1 +
 arch/sh/boards/mach-ap325rxa/sdram.S   |  7 ++
 arch/sh/boards/mach-cayman/Makefile|  1 +
 arch/sh/boards/mach-cayman/irq.c   |  5 +---
 arch/sh/boards/mach-cayman/panic.c |  5 +---
 arch/sh/boards/mach-cayman/setup.c |  5 +---
 arch/sh/boards/mach-dreamcast/Makefile |  1 +
 arch/sh/boards/mach-dreamcast/irq.c|  2 +-
 arch/sh/boards/mach-dreamcast/rtc.c|  4 +--
 arch/sh/boards/mach-dreamcast/setup.c  |  3 +--
 arch/sh/boards/mach-ecovec24/Makefile  |  3 ++-
 arch/sh/boards/mach-ecovec24/sdram.S   |  7 ++
 arch/sh/boards/mach-ecovec24/setup.c   |  5 +---
 arch/sh/boards/mach-highlander/irq-r7780mp.c   |  5 +---
 arch/sh/boards/mach-highlander/irq-r7780rp.c   |  5 +---
 arch/sh/boards/mach-highlander/irq-r7785rp.c   |  5 +---
 arch/sh/boards/mach-highlander/pinmux-r7785rp.c|  5 +---
 arch/sh/boards/mach-highlander/psw.c   |  5 +---
 arch/sh/boards/mach-highlander/setup.c |  5 +---
 arch/sh/boards/mach-hp6xx/Makefile |  1 +
 arch/sh/boards/mach-hp6xx/hp6xx_apm.c  |  4 +--
 arch/sh/boards/mach-hp6xx/pm.c |  4 +--
 arch/sh/boards/mach-hp6xx/pm_wakeup.S  |  8 ++
 arch/sh/boards/mach-hp6xx/setup.c  |  4 +--
 arch/sh/boards/mach-kfr2r09/Makefile   |  1 +
 arch/sh/boards/mach-kfr2r09/lcd_wqvga.c|  5 +---
 arch/sh/boards/mach-kfr2r09/sdram.S|  7 ++
 arch/sh/boards/mach-landisk/Makefile   |  1 +
 arch/sh/boards/mach-landisk/gio.c  |  6 +
 arch/sh/boards/mach-landisk/irq.c  |  5 +---
 arch/sh/boards/mach-landisk/psw.c  |  5 +---
 arch/sh/boards/mach-landisk/setup.c|  5 +---
 arch/sh/boards/mach-lboxre2/Makefile   |  1 +
 arch/sh/boards/mach-lboxre2/irq.c  |  6 +
 arch/sh/boards/mach-lboxre2/setup.c|  6 +
 arch/sh/boards/mach-microdev/Makefile  |  1 +
 arch/sh/boards/mach-microdev/fdc37c93xapm.c|  5 +---
 arch/sh/boards/mach-microdev/io.c  |  4 +--
 arch/sh/boards/mach-microdev/irq.c |  4 +--
 arch/sh/boards/mach-microdev/setup.c   |  4 +--
 arch/sh/boards/mach-migor/Makefile |  1 +
 arch/sh/boards/mach-migor/lcd_qvga.c   |  5 +---
 arch/sh/boards/mach-migor/sdram.S  |  7 ++
 arch/sh/boards/mach-r2d/Makefile   |  1 +
 arch/sh/boards/mach-r2d/setup.c|  5 +---
 arch/sh/boards/mach-rsk/Makefile   |  1 +
 arch/sh/boards/mach-rsk/devices-rsk7203.c  |  5 +---
 arch/sh/boards/mach-rsk/devices-rsk7264.c  |  5 +---
 arch/sh/boards/mach-rsk/devices-rsk7269.c  |  5 +---
 arch/sh/boards/mach-rsk/setup.c|  5 +---
 arch/sh/boards/mach-sdk7780/Makefile   |  1 +
 arch/sh/boards/mach-sdk7780/irq.c  |  5 +---
 arch/sh/boards/mach-sdk7780/setup.c|  5 +---
 arch/sh/boards/mach-sdk7786/Makefile   |  1 +
 arch/sh/boards/mach-sdk7786/fpga.c |  5 +---
 arch/sh/boards/mach-sdk7786/gpio.c |  5 +---
 arch/sh/boards/mach-sdk7786/irq.c  |  5 +---
 arch/sh/boards/mach-sdk7786/nmi.c  |  5 +---
 arch/sh/boards/mach-sdk7786/setup.c|  5 +---
 

[PATCH resend 00/13] sh: convert to SPDX identifiers

[Kuninori Morimoto]

Hi Andrew Morton.
Cc SH ML

I'm posting these patches to SH ML from few month ago,
but, nothing happen.
SH Maintainer seems not working anymore ?
I'm not sure...

So now, I added Andrew in To: field.
I'm happy if some maintainer can handle these

Kuninori Morimoto (13):
  sh: boards: convert to SPDX identifiers
  sh: drivers: convert to SPDX identifiers
  sh: include: convert to SPDX identifiers
  sh: sh2: convert to SPDX identifiers
  sh: sh2a: convert to SPDX identifiers
  sh: sh3: convert to SPDX identifiers
  sh: sh4: convert to SPDX identifiers
  sh: sh4a: convert to SPDX identifiers
  sh: sh5: convert to SPDX identifiers
  sh: shmobile: convert to SPDX identifiers
  sh: cpu: convert to SPDX identifiers
  sh: kernel: convert to SPDX identifiers
  sh: lib: convert to SPDX identifiers

 arch/sh/boards/board-apsh4a3a.c|  5 +---
 arch/sh/boards/board-apsh4ad0a.c   |  5 +---
 arch/sh/boards/board-edosk7760.c   | 15 +--
 arch/sh/boards/board-espt.c|  5 +---
 arch/sh/boards/board-magicpanelr2.c|  5 +---
 arch/sh/boards/board-sh7757lcr.c   |  5 +---
 arch/sh/boards/board-sh7785lcr.c   |  5 +---
 arch/sh/boards/board-titan.c   |  5 +---
 arch/sh/boards/board-urquell.c |  5 +---
 arch/sh/boards/mach-ap325rxa/Makefile  |  1 +
 arch/sh/boards/mach-ap325rxa/sdram.S   |  7 ++
 arch/sh/boards/mach-cayman/Makefile|  1 +
 arch/sh/boards/mach-cayman/irq.c   |  5 +---
 arch/sh/boards/mach-cayman/panic.c |  5 +---
 arch/sh/boards/mach-cayman/setup.c |  5 +---
 arch/sh/boards/mach-dreamcast/Makefile |  1 +
 arch/sh/boards/mach-dreamcast/irq.c|  2 +-
 arch/sh/boards/mach-dreamcast/rtc.c|  4 +--
 arch/sh/boards/mach-dreamcast/setup.c  |  3 +--
 arch/sh/boards/mach-ecovec24/Makefile  |  3 ++-
 arch/sh/boards/mach-ecovec24/sdram.S   |  7 ++
 arch/sh/boards/mach-ecovec24/setup.c   |  5 +---
 arch/sh/boards/mach-highlander/irq-r7780mp.c   |  5 +---
 arch/sh/boards/mach-highlander/irq-r7780rp.c   |  5 +---
 arch/sh/boards/mach-highlander/irq-r7785rp.c   |  5 +---
 arch/sh/boards/mach-highlander/pinmux-r7785rp.c|  5 +---
 arch/sh/boards/mach-highlander/psw.c   |  5 +---
 arch/sh/boards/mach-highlander/setup.c |  5 +---
 arch/sh/boards/mach-hp6xx/Makefile |  1 +
 arch/sh/boards/mach-hp6xx/hp6xx_apm.c  |  4 +--
 arch/sh/boards/mach-hp6xx/pm.c |  4 +--
 arch/sh/boards/mach-hp6xx/pm_wakeup.S  |  8 ++
 arch/sh/boards/mach-hp6xx/setup.c  |  4 +--
 arch/sh/boards/mach-kfr2r09/Makefile   |  1 +
 arch/sh/boards/mach-kfr2r09/lcd_wqvga.c|  5 +---
 arch/sh/boards/mach-kfr2r09/sdram.S|  7 ++
 arch/sh/boards/mach-landisk/Makefile   |  1 +
 arch/sh/boards/mach-landisk/gio.c  |  6 +
 arch/sh/boards/mach-landisk/irq.c  |  5 +---
 arch/sh/boards/mach-landisk/psw.c  |  5 +---
 arch/sh/boards/mach-landisk/setup.c|  5 +---
 arch/sh/boards/mach-lboxre2/Makefile   |  1 +
 arch/sh/boards/mach-lboxre2/irq.c  |  6 +
 arch/sh/boards/mach-lboxre2/setup.c|  6 +
 arch/sh/boards/mach-microdev/Makefile  |  1 +
 arch/sh/boards/mach-microdev/fdc37c93xapm.c|  5 +---
 arch/sh/boards/mach-microdev/io.c  |  4 +--
 arch/sh/boards/mach-microdev/irq.c |  4 +--
 arch/sh/boards/mach-microdev/setup.c   |  4 +--
 arch/sh/boards/mach-migor/Makefile |  1 +
 arch/sh/boards/mach-migor/lcd_qvga.c   |  5 +---
 arch/sh/boards/mach-migor/sdram.S  |  7 ++
 arch/sh/boards/mach-r2d/Makefile   |  1 +
 arch/sh/boards/mach-r2d/setup.c|  5 +---
 arch/sh/boards/mach-rsk/Makefile   |  1 +
 arch/sh/boards/mach-rsk/devices-rsk7203.c  |  5 +---
 arch/sh/boards/mach-rsk/devices-rsk7264.c  |  5 +---
 arch/sh/boards/mach-rsk/devices-rsk7269.c  |  5 +---
 arch/sh/boards/mach-rsk/setup.c|  5 +---
 arch/sh/boards/mach-sdk7780/Makefile   |  1 +
 arch/sh/boards/mach-sdk7780/irq.c  |  5 +---
 arch/sh/boards/mach-sdk7780/setup.c|  5 +---
 arch/sh/boards/mach-sdk7786/Makefile   |  1 +
 arch/sh/boards/mach-sdk7786/fpga.c |  5 +---
 arch/sh/boards/mach-sdk7786/gpio.c |  5 +---
 arch/sh/boards/mach-sdk7786/irq.c  |  5 +---
 arch/sh/boards/mach-sdk7786/nmi.c  |  5 +---
 arch/sh/boards/mach-sdk7786/setup.c|  5 +---
 

Re: [PATCH] Revert "clk: fix __clk_init_parent() for single parent clocks"

[Stephen Boyd]

Quoting Jerome Brunet (2018-12-04 11:51:17)
> On Tue, 2018-12-04 at 10:05 -0800, Stephen Boyd wrote:
> > Quoting Jerome Brunet (2018-12-04 08:32:57)
> > > This reverts commit 2430a94d1e719b7b4af2a65b781a4c036eb22e64.
> > > 
> > > From the original commit message:
> > >   It turned out a problem because there are some single-parent clocks
> > >   that implement .get_parent() callback and return non-zero index.
> > >   The SOCFPGA clock is the case; the commit broke the SOCFPGA boards.
> > > 
> > > It is wrong for a clock to return an index >= num_parents. CCF checks
> > > for this condition in clk_core_get_parent_by_index(). This function sets
> > > the parent to NULL if index is incoherent, which seems like the only
> > > sane choice.
> > > 
> > > commit 2430a94d1e71 ("clk: fix __clk_init_parent() for single parent
> > > clocks")
> > > appears to be a work around installed in the core framework for a problem
> > > that is platform specific, and should probably be fixed in the platform
> > > code.
> > 
> > Ouch. I see that I even pointed that out in 2016 but never got a reply
> > or a fix patch[1].
> > 
> > > Further more, it introduces a problem in a corner case of the mux clock.
> > > Take mux with multiple parents, but only one is known, the rest being
> > > undocumented. The register reset has one of unknown parent set.
> > > 
> > > Before commit 2430a94d1e71 ("clk: fix __clk_init_parent() for single
> > > parent clocks"):
> > >  * get_parent() is called, register is read and give an unknown index.
> > >-> the mux is orphaned.
> > >  * a call to set_rate() will reparent the mux to the only known parent.
> > > 
> > > With commit 2430a94d1e71 ("clk: fix __clk_init_parent() for single parent
> > > clocks"):
> > >  * the register is never read.
> > >  * parent is wrongly assumed to be the only known one.
> > >As a consequence, all the calculation deriving from the mux will be
> > >wrong
> > >  * Since we believe the only know parent to be set, set_parent() won't
> > >ever be called and the register won't be set with the correct value.
> > 
> > Isn't this the broken bad case all over again? Why register a clk as a
> > mux and then only say it has one parent?
> 
> I understand it is a bit odd but as I explained it is a corner case.
> 
> We are really trying to drive a mux here, applying a values will change the
> clock signal we get. Documentation being what it is, we only know one the
> parent. The other parent could anything or maybe not connected at all, who
> know. That is not the important part actually
> 
> If such mux was already set to the known entry by default, it would be OK to
> ignore it. But if it is not, then we CCF to realise that and change the
> setting accordingly.
> 
> This the case of the 'ao_cts_cec' clock in the following patch:
> https://lore.kernel.org/patchwork/patch/1021028/
> 
> by default the value in the register is 0, but the only one that makes sense
> for us is 1.

Ok. Thanks for the explanation. What do you do to fix this problem in
the 'ao_cts_cec' clk implementation? Sounds like you just rely on
clk_set_rate() to fix this all up for you when the consumer changes the
rate?

If we have something that is default parented to something we're not
telling the framework about for some reason then one solution would be
to have some init code reparent the clk in hardware before registering
it with the framework. Basically "fix up" the clk tree in hardware to be
consistent with what software can reason about. 

This also reminds me of some audio clks I've seen before where the
default parent is some external pin and it can be reparented to an
internal clk with clk_set_rate/parent. In that case, I think we forced
the parent over to the internal clk before registering so that it would
always get parented properly in the framework. Right now, this is going
to cause problems for plans to probe defer clk_get() on orphan clks.

Maybe this could work better if we allowed
'assigned-clock-parents/rates' to reparent clks regardless of orphan
status and/or had some flag that could be set on clks to indicate that
we're OK if clk_get() is called on it when it's an orphan because this
isn't a problem?

Or we can make the defer on orphan code only defer if the clk has a
single parent and it's an orphan and return the clk if there is at least
one parent of the clk that has been registered and isn't marked as an
orphan. That would need to be recursively applied, so I guess we would
update our orphan marking code to indicate that clk_get() on the clk
should probe defer or not instead of indicating the clk's orphan status.
Doing this would also side-step the problem Rockchip was having where
certain parents never appeared but the clk was parented to it in
hardware, essentially blocking the clk from ever being touched by
consumers.

On the other hand, not having the clk there causes us to do a global
search of the clk name space each time we look for parents by the
"unknown" index, which 

Re: [PATCH] Revert "clk: fix __clk_init_parent() for single parent clocks"

[Stephen Boyd]

Quoting Jerome Brunet (2018-12-04 11:51:17)
> On Tue, 2018-12-04 at 10:05 -0800, Stephen Boyd wrote:
> > Quoting Jerome Brunet (2018-12-04 08:32:57)
> > > This reverts commit 2430a94d1e719b7b4af2a65b781a4c036eb22e64.
> > > 
> > > From the original commit message:
> > >   It turned out a problem because there are some single-parent clocks
> > >   that implement .get_parent() callback and return non-zero index.
> > >   The SOCFPGA clock is the case; the commit broke the SOCFPGA boards.
> > > 
> > > It is wrong for a clock to return an index >= num_parents. CCF checks
> > > for this condition in clk_core_get_parent_by_index(). This function sets
> > > the parent to NULL if index is incoherent, which seems like the only
> > > sane choice.
> > > 
> > > commit 2430a94d1e71 ("clk: fix __clk_init_parent() for single parent
> > > clocks")
> > > appears to be a work around installed in the core framework for a problem
> > > that is platform specific, and should probably be fixed in the platform
> > > code.
> > 
> > Ouch. I see that I even pointed that out in 2016 but never got a reply
> > or a fix patch[1].
> > 
> > > Further more, it introduces a problem in a corner case of the mux clock.
> > > Take mux with multiple parents, but only one is known, the rest being
> > > undocumented. The register reset has one of unknown parent set.
> > > 
> > > Before commit 2430a94d1e71 ("clk: fix __clk_init_parent() for single
> > > parent clocks"):
> > >  * get_parent() is called, register is read and give an unknown index.
> > >-> the mux is orphaned.
> > >  * a call to set_rate() will reparent the mux to the only known parent.
> > > 
> > > With commit 2430a94d1e71 ("clk: fix __clk_init_parent() for single parent
> > > clocks"):
> > >  * the register is never read.
> > >  * parent is wrongly assumed to be the only known one.
> > >As a consequence, all the calculation deriving from the mux will be
> > >wrong
> > >  * Since we believe the only know parent to be set, set_parent() won't
> > >ever be called and the register won't be set with the correct value.
> > 
> > Isn't this the broken bad case all over again? Why register a clk as a
> > mux and then only say it has one parent?
> 
> I understand it is a bit odd but as I explained it is a corner case.
> 
> We are really trying to drive a mux here, applying a values will change the
> clock signal we get. Documentation being what it is, we only know one the
> parent. The other parent could anything or maybe not connected at all, who
> know. That is not the important part actually
> 
> If such mux was already set to the known entry by default, it would be OK to
> ignore it. But if it is not, then we CCF to realise that and change the
> setting accordingly.
> 
> This the case of the 'ao_cts_cec' clock in the following patch:
> https://lore.kernel.org/patchwork/patch/1021028/
> 
> by default the value in the register is 0, but the only one that makes sense
> for us is 1.

Ok. Thanks for the explanation. What do you do to fix this problem in
the 'ao_cts_cec' clk implementation? Sounds like you just rely on
clk_set_rate() to fix this all up for you when the consumer changes the
rate?

If we have something that is default parented to something we're not
telling the framework about for some reason then one solution would be
to have some init code reparent the clk in hardware before registering
it with the framework. Basically "fix up" the clk tree in hardware to be
consistent with what software can reason about. 

This also reminds me of some audio clks I've seen before where the
default parent is some external pin and it can be reparented to an
internal clk with clk_set_rate/parent. In that case, I think we forced
the parent over to the internal clk before registering so that it would
always get parented properly in the framework. Right now, this is going
to cause problems for plans to probe defer clk_get() on orphan clks.

Maybe this could work better if we allowed
'assigned-clock-parents/rates' to reparent clks regardless of orphan
status and/or had some flag that could be set on clks to indicate that
we're OK if clk_get() is called on it when it's an orphan because this
isn't a problem?

Or we can make the defer on orphan code only defer if the clk has a
single parent and it's an orphan and return the clk if there is at least
one parent of the clk that has been registered and isn't marked as an
orphan. That would need to be recursively applied, so I guess we would
update our orphan marking code to indicate that clk_get() on the clk
should probe defer or not instead of indicating the clk's orphan status.
Doing this would also side-step the problem Rockchip was having where
certain parents never appeared but the clk was parented to it in
hardware, essentially blocking the clk from ever being touched by
consumers.

On the other hand, not having the clk there causes us to do a global
search of the clk name space each time we look for parents by the
"unknown" index, which 

Quick Loans

[Loans Service]

Apply for a loan at 2% reply to this Email for more Info

Quick Loans

[Loans Service]

Apply for a loan at 2% reply to this Email for more Info

Re: [PATCH v2 1/2] bus: imx-weim: support multiple address ranges per child node

[Shawn Guo]

On Fri, Nov 30, 2018 at 03:56:23PM -0500, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck 
> 
> Ensure that timing values for the child node are applied to
> all chip selects in the child's address ranges.
> 
> Note that this does not support multiple timing settings per
> child; this can be added in the future if required.
> 
> Example:
>  {
>   acme@0,0 {
>   compatible = "acme,whatever";
>   reg = <0 0 0x100>, <0 0x40 0x800>,
>   <1 0x40 0x800>;
>   fsl,weim-cs-timing = <0x024400b1 0x1010 0x20081100
>   0x 0xa240 0x>;
>   };
> };

I'm not sure about that.  Shouldn't we have another child node for
different chip select, something like below?

 {
acme@0,0 {
compatible = "acme,whatever";
reg = <0 0 0x100>, <0 0x40 0x800>;
fsl,weim-cs-timing = <0x024400b1 0x1010 0x20081100
  0x 0xa240 0x>;
};

acme@1,40 {
compatible = "acme,whatever";
reg = <1 0x40 0x800>;
fsl,weim-cs-timing = <0x024400b1 0x1010 0x20081100
  0x 0xa240 0x>;
};

Shawn

> 
> Signed-off-by: Sven Van Asbroeck 
> ---
>  drivers/bus/imx-weim.c | 36 +---
>  1 file changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index f01308172de9..24f22285395d 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -46,6 +46,7 @@ static const struct imx_weim_devtype imx51_weim_devtype = {
>  };
>  
>  #define MAX_CS_REGS_COUNT6
> +#define OF_REG_SIZE  3
>  
>  static const struct of_device_id weim_id_table[] = {
>   /* i.MX1/21 */
> @@ -115,27 +116,40 @@ static int __init weim_timing_setup(struct device_node 
> *np, void __iomem *base,
>   const struct imx_weim_devtype *devtype)
>  {
>   u32 cs_idx, value[MAX_CS_REGS_COUNT];
> - int i, ret;
> + int i, ret, reg_idx, num_regs;
>  
>   if (WARN_ON(devtype->cs_regs_count > MAX_CS_REGS_COUNT))
>   return -EINVAL;
>  
> - /* get the CS index from this child node's "reg" property. */
> - ret = of_property_read_u32(np, "reg", _idx);
> + ret = of_property_read_u32_array(np, "fsl,weim-cs-timing",
> +  value, devtype->cs_regs_count);
>   if (ret)
>   return ret;
>  
> - if (cs_idx >= devtype->cs_count)
> + /*
> +  * the child node's "reg" property may contain multiple address ranges,
> +  * extract the chip select for each.
> +  */
> + num_regs = of_property_count_elems_of_size(np, "reg", OF_REG_SIZE);
> + if (num_regs < 0)
> + return num_regs;
> + if (!num_regs)
>   return -EINVAL;
> + for (reg_idx = 0; reg_idx < num_regs; reg_idx++) {
> + /* get the CS index from this child node's "reg" property. */
> + ret = of_property_read_u32_index(np, "reg",
> + reg_idx*OF_REG_SIZE, _idx);
> + if (ret)
> + break;
>  
> - ret = of_property_read_u32_array(np, "fsl,weim-cs-timing",
> -  value, devtype->cs_regs_count);
> - if (ret)
> - return ret;
> + if (cs_idx >= devtype->cs_count)
> + return -EINVAL;
>  
> - /* set the timing for WEIM */
> - for (i = 0; i < devtype->cs_regs_count; i++)
> - writel(value[i], base + cs_idx * devtype->cs_stride + i * 4);
> + /* set the timing for WEIM */
> + for (i = 0; i < devtype->cs_regs_count; i++)
> + writel(value[i],
> + base + cs_idx * devtype->cs_stride + i * 4);
> + }
>  
>   return 0;
>  }
> -- 
> 2.17.1
> 

Re: [PATCH v2 1/2] bus: imx-weim: support multiple address ranges per child node

[Shawn Guo]

On Fri, Nov 30, 2018 at 03:56:23PM -0500, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck 
> 
> Ensure that timing values for the child node are applied to
> all chip selects in the child's address ranges.
> 
> Note that this does not support multiple timing settings per
> child; this can be added in the future if required.
> 
> Example:
>  {
>   acme@0,0 {
>   compatible = "acme,whatever";
>   reg = <0 0 0x100>, <0 0x40 0x800>,
>   <1 0x40 0x800>;
>   fsl,weim-cs-timing = <0x024400b1 0x1010 0x20081100
>   0x 0xa240 0x>;
>   };
> };

I'm not sure about that.  Shouldn't we have another child node for
different chip select, something like below?

 {
acme@0,0 {
compatible = "acme,whatever";
reg = <0 0 0x100>, <0 0x40 0x800>;
fsl,weim-cs-timing = <0x024400b1 0x1010 0x20081100
  0x 0xa240 0x>;
};

acme@1,40 {
compatible = "acme,whatever";
reg = <1 0x40 0x800>;
fsl,weim-cs-timing = <0x024400b1 0x1010 0x20081100
  0x 0xa240 0x>;
};

Shawn

> 
> Signed-off-by: Sven Van Asbroeck 
> ---
>  drivers/bus/imx-weim.c | 36 +---
>  1 file changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index f01308172de9..24f22285395d 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -46,6 +46,7 @@ static const struct imx_weim_devtype imx51_weim_devtype = {
>  };
>  
>  #define MAX_CS_REGS_COUNT6
> +#define OF_REG_SIZE  3
>  
>  static const struct of_device_id weim_id_table[] = {
>   /* i.MX1/21 */
> @@ -115,27 +116,40 @@ static int __init weim_timing_setup(struct device_node 
> *np, void __iomem *base,
>   const struct imx_weim_devtype *devtype)
>  {
>   u32 cs_idx, value[MAX_CS_REGS_COUNT];
> - int i, ret;
> + int i, ret, reg_idx, num_regs;
>  
>   if (WARN_ON(devtype->cs_regs_count > MAX_CS_REGS_COUNT))
>   return -EINVAL;
>  
> - /* get the CS index from this child node's "reg" property. */
> - ret = of_property_read_u32(np, "reg", _idx);
> + ret = of_property_read_u32_array(np, "fsl,weim-cs-timing",
> +  value, devtype->cs_regs_count);
>   if (ret)
>   return ret;
>  
> - if (cs_idx >= devtype->cs_count)
> + /*
> +  * the child node's "reg" property may contain multiple address ranges,
> +  * extract the chip select for each.
> +  */
> + num_regs = of_property_count_elems_of_size(np, "reg", OF_REG_SIZE);
> + if (num_regs < 0)
> + return num_regs;
> + if (!num_regs)
>   return -EINVAL;
> + for (reg_idx = 0; reg_idx < num_regs; reg_idx++) {
> + /* get the CS index from this child node's "reg" property. */
> + ret = of_property_read_u32_index(np, "reg",
> + reg_idx*OF_REG_SIZE, _idx);
> + if (ret)
> + break;
>  
> - ret = of_property_read_u32_array(np, "fsl,weim-cs-timing",
> -  value, devtype->cs_regs_count);
> - if (ret)
> - return ret;
> + if (cs_idx >= devtype->cs_count)
> + return -EINVAL;
>  
> - /* set the timing for WEIM */
> - for (i = 0; i < devtype->cs_regs_count; i++)
> - writel(value[i], base + cs_idx * devtype->cs_stride + i * 4);
> + /* set the timing for WEIM */
> + for (i = 0; i < devtype->cs_regs_count; i++)
> + writel(value[i],
> + base + cs_idx * devtype->cs_stride + i * 4);
> + }
>  
>   return 0;
>  }
> -- 
> 2.17.1
> 

[PATCH linux-next v3 6/7] ASoC: rsnd: add avb clocks

[Jiada Wang]

There are AVB Counter Clocks in ADG, each clock has 12bits integral
and 8 bits fractional dividers which operates with S0D1ϕ clock.

This patch registers 8 AVB Counter Clocks when clock-cells of
rcar_sound node is 2,

Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/adg.c  | 316 +--
 sound/soc/sh/rcar/gen.c  |   9 ++
 sound/soc/sh/rcar/rsnd.h |   9 ++
 3 files changed, 325 insertions(+), 9 deletions(-)

diff --git a/sound/soc/sh/rcar/adg.c b/sound/soc/sh/rcar/adg.c
index 6768a66588eb..0708be1f38d9 100644
--- a/sound/soc/sh/rcar/adg.c
+++ b/sound/soc/sh/rcar/adg.c
@@ -5,6 +5,7 @@
 //  Copyright (C) 2013  Kuninori Morimoto 
 
 #include 
+#include 
 #include "rsnd.h"
 
 #define CLKA   0
@@ -21,13 +22,30 @@
 
 #define BRRx_MASK(x) (0x3FF & x)
 
+#define AVB_CLK_NUM8
+#define AVB_MAX_RATE   2500
+#define AVB_DIV_EN_COM BIT(31)
+#define AVB_MAX_DIV0x3ffc0
+
 static struct rsnd_mod_ops adg_ops = {
.name = "adg",
 };
 
+struct clk_avb {
+   struct clk_hw hw;
+   unsigned int idx;
+   struct rsnd_adg *adg;
+   /* lock reg access */
+   spinlock_t *lock;
+};
+
+#define hw_to_avb(_hw) container_of(_hw, struct clk_avb, hw)
+
 struct rsnd_adg {
struct clk *clk[CLKMAX];
struct clk *clkout[CLKOUTMAX];
+   struct clk *clkavb[AVB_CLK_NUM];
+   struct clk *clkadg;
struct clk_onecell_data onecell;
struct rsnd_mod mod;
u32 flags;
@@ -37,6 +55,7 @@ struct rsnd_adg {
 
int rbga_rate_for_441khz; /* RBGA */
int rbgb_rate_for_48khz;  /* RBGB */
+   spinlock_t avb_lock;
 };
 
 #define LRCLK_ASYNC(1 << 0)
@@ -408,6 +427,248 @@ void rsnd_adg_clk_control(struct rsnd_priv *priv, int 
enable)
}
 }
 
+static struct clk *rsnd_adg_clk_src_twocell_get(struct of_phandle_args 
*clkspec,
+   void *data)
+{
+   unsigned int clktype = clkspec->args[0];
+   unsigned int clkidx = clkspec->args[1];
+   struct rsnd_adg *adg = data;
+   struct rsnd_mod *adg_mod = rsnd_mod_get(adg);
+   struct rsnd_priv *priv = rsnd_mod_to_priv(adg_mod);
+   struct device *dev = rsnd_priv_to_dev(priv);
+   struct clk *clk;
+
+   switch (clktype) {
+   case 0:
+   if (clkidx >= CLKOUTMAX) {
+   dev_err(dev, "Invalid fixed clock index %u\n", clkidx);
+   return ERR_PTR(-EINVAL);
+   }
+   clk = adg->clkout[clkidx];
+   break;
+   case 1:
+   if (clkidx >= AVB_CLK_NUM) {
+   dev_err(dev, "Invalid avb clock index %u\n", clkidx);
+   return ERR_PTR(-EINVAL);
+   }
+   clk = adg->clkavb[clkidx];
+   break;
+   default:
+   dev_err(dev, "Invalid ADG clock type %u\n", clktype);
+   return ERR_PTR(-EINVAL);
+   }
+
+   return clk;
+}
+
+static void clk_avb_div_write(struct rsnd_adg *adg, u32 data, unsigned int idx)
+{
+   struct rsnd_mod *mod = rsnd_mod_get(adg);
+
+   switch (idx) {
+   case 0:
+   rsnd_mod_write(mod, AVB_CLK_DIV0, data);
+   break;
+   case 1:
+   rsnd_mod_write(mod, AVB_CLK_DIV1, data);
+   break;
+   case 2:
+   rsnd_mod_write(mod, AVB_CLK_DIV2, data);
+   break;
+   case 3:
+   rsnd_mod_write(mod, AVB_CLK_DIV3, data);
+   break;
+   case 4:
+   rsnd_mod_write(mod, AVB_CLK_DIV4, data);
+   break;
+   case 5:
+   rsnd_mod_write(mod, AVB_CLK_DIV5, data);
+   break;
+   case 6:
+   rsnd_mod_write(mod, AVB_CLK_DIV6, data);
+   break;
+   case 7:
+   rsnd_mod_write(mod, AVB_CLK_DIV7, data);
+   break;
+   }
+}
+
+static u32 clk_avb_div_read(struct rsnd_adg *adg, unsigned int idx)
+{
+   struct rsnd_mod *mod = rsnd_mod_get(adg);
+   u32 val = 0;
+
+   switch (idx) {
+   case 0:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV0);
+   break;
+   case 1:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV1);
+   break;
+   case 2:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV2);
+   break;
+   case 3:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV3);
+   break;
+   case 4:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV4);
+   break;
+   case 5:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV5);
+   break;
+   case 6:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV6);
+   break;
+   case 7:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV7);
+   break;
+   }
+
+   return val;
+}
+
+static int clk_avb_is_enabled(struct clk_hw *hw)
+{
+   struct clk_avb *avb = 

[PATCH linux-next v3 6/7] ASoC: rsnd: add avb clocks

[Jiada Wang]

There are AVB Counter Clocks in ADG, each clock has 12bits integral
and 8 bits fractional dividers which operates with S0D1ϕ clock.

This patch registers 8 AVB Counter Clocks when clock-cells of
rcar_sound node is 2,

Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/adg.c  | 316 +--
 sound/soc/sh/rcar/gen.c  |   9 ++
 sound/soc/sh/rcar/rsnd.h |   9 ++
 3 files changed, 325 insertions(+), 9 deletions(-)

diff --git a/sound/soc/sh/rcar/adg.c b/sound/soc/sh/rcar/adg.c
index 6768a66588eb..0708be1f38d9 100644
--- a/sound/soc/sh/rcar/adg.c
+++ b/sound/soc/sh/rcar/adg.c
@@ -5,6 +5,7 @@
 //  Copyright (C) 2013  Kuninori Morimoto 
 
 #include 
+#include 
 #include "rsnd.h"
 
 #define CLKA   0
@@ -21,13 +22,30 @@
 
 #define BRRx_MASK(x) (0x3FF & x)
 
+#define AVB_CLK_NUM8
+#define AVB_MAX_RATE   2500
+#define AVB_DIV_EN_COM BIT(31)
+#define AVB_MAX_DIV0x3ffc0
+
 static struct rsnd_mod_ops adg_ops = {
.name = "adg",
 };
 
+struct clk_avb {
+   struct clk_hw hw;
+   unsigned int idx;
+   struct rsnd_adg *adg;
+   /* lock reg access */
+   spinlock_t *lock;
+};
+
+#define hw_to_avb(_hw) container_of(_hw, struct clk_avb, hw)
+
 struct rsnd_adg {
struct clk *clk[CLKMAX];
struct clk *clkout[CLKOUTMAX];
+   struct clk *clkavb[AVB_CLK_NUM];
+   struct clk *clkadg;
struct clk_onecell_data onecell;
struct rsnd_mod mod;
u32 flags;
@@ -37,6 +55,7 @@ struct rsnd_adg {
 
int rbga_rate_for_441khz; /* RBGA */
int rbgb_rate_for_48khz;  /* RBGB */
+   spinlock_t avb_lock;
 };
 
 #define LRCLK_ASYNC(1 << 0)
@@ -408,6 +427,248 @@ void rsnd_adg_clk_control(struct rsnd_priv *priv, int 
enable)
}
 }
 
+static struct clk *rsnd_adg_clk_src_twocell_get(struct of_phandle_args 
*clkspec,
+   void *data)
+{
+   unsigned int clktype = clkspec->args[0];
+   unsigned int clkidx = clkspec->args[1];
+   struct rsnd_adg *adg = data;
+   struct rsnd_mod *adg_mod = rsnd_mod_get(adg);
+   struct rsnd_priv *priv = rsnd_mod_to_priv(adg_mod);
+   struct device *dev = rsnd_priv_to_dev(priv);
+   struct clk *clk;
+
+   switch (clktype) {
+   case 0:
+   if (clkidx >= CLKOUTMAX) {
+   dev_err(dev, "Invalid fixed clock index %u\n", clkidx);
+   return ERR_PTR(-EINVAL);
+   }
+   clk = adg->clkout[clkidx];
+   break;
+   case 1:
+   if (clkidx >= AVB_CLK_NUM) {
+   dev_err(dev, "Invalid avb clock index %u\n", clkidx);
+   return ERR_PTR(-EINVAL);
+   }
+   clk = adg->clkavb[clkidx];
+   break;
+   default:
+   dev_err(dev, "Invalid ADG clock type %u\n", clktype);
+   return ERR_PTR(-EINVAL);
+   }
+
+   return clk;
+}
+
+static void clk_avb_div_write(struct rsnd_adg *adg, u32 data, unsigned int idx)
+{
+   struct rsnd_mod *mod = rsnd_mod_get(adg);
+
+   switch (idx) {
+   case 0:
+   rsnd_mod_write(mod, AVB_CLK_DIV0, data);
+   break;
+   case 1:
+   rsnd_mod_write(mod, AVB_CLK_DIV1, data);
+   break;
+   case 2:
+   rsnd_mod_write(mod, AVB_CLK_DIV2, data);
+   break;
+   case 3:
+   rsnd_mod_write(mod, AVB_CLK_DIV3, data);
+   break;
+   case 4:
+   rsnd_mod_write(mod, AVB_CLK_DIV4, data);
+   break;
+   case 5:
+   rsnd_mod_write(mod, AVB_CLK_DIV5, data);
+   break;
+   case 6:
+   rsnd_mod_write(mod, AVB_CLK_DIV6, data);
+   break;
+   case 7:
+   rsnd_mod_write(mod, AVB_CLK_DIV7, data);
+   break;
+   }
+}
+
+static u32 clk_avb_div_read(struct rsnd_adg *adg, unsigned int idx)
+{
+   struct rsnd_mod *mod = rsnd_mod_get(adg);
+   u32 val = 0;
+
+   switch (idx) {
+   case 0:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV0);
+   break;
+   case 1:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV1);
+   break;
+   case 2:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV2);
+   break;
+   case 3:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV3);
+   break;
+   case 4:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV4);
+   break;
+   case 5:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV5);
+   break;
+   case 6:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV6);
+   break;
+   case 7:
+   val = rsnd_mod_read(mod, AVB_CLK_DIV7);
+   break;
+   }
+
+   return val;
+}
+
+static int clk_avb_is_enabled(struct clk_hw *hw)
+{
+   struct clk_avb *avb = 

[PATCH linux-next v3 7/7] clk: renesas: Add binding document for ADG

[Jiada Wang]

Add device tree bindings for Audio Clock Generator (ADG)
of R-Car Socs.

Signed-off-by: Jiada Wang 
---
 .../clock/renesas,rcar-adg-clocks.txt | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt

diff --git 
a/Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt 
b/Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt
new file mode 100644
index ..76fc4f8964e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt
@@ -0,0 +1,24 @@
+* Renesas R-Car Audio Clock Generator (ADG)
+
+The Audio Clock Generator (ADG) is part of R-Car Audio module, it
+selects and supplies the necessary clock for the SSIU, EAVB-IF, SCU,
+ADSP or DTCP module. It also divides the frequency of the selected
+clock and sends it outside the chip.
+
+Required Properties:
+
+  - compatible: Must be one of
+- "renesas,rcar_sound-gen1" for the R-Car GEN1 SoCs
+- "renesas,rcar_sound-gen2" for the R-Car GEN2 SoCs
+- "renesas,rcar_sound-gen3" for the R-Car GEN3 SoCs
+
+  - reg: Base address and length of the memory resource used by the ADG
+
+  - clocks: References to the parent clock S0D1.
+  - clock-names: ADG refer to its parent clock by name "adg".
+  - #clock-cells: Can be 0, 1 or 2
+- When clock-cells = 0, ADG registers one fixed clock out
+- When clock-cells = 1, ADG registers 3 fixed clock out
+- When clock-cells = 2, ADG registers 3 fixed clock out and 8 AVB clocks
+  second clock specifier need to be 0 to refer to fixed clock out, need
+  to be 1 to refer to AVB clocks
-- 
2.19.2

[PATCH linux-next v3 7/7] clk: renesas: Add binding document for ADG

[Jiada Wang]

Add device tree bindings for Audio Clock Generator (ADG)
of R-Car Socs.

Signed-off-by: Jiada Wang 
---
 .../clock/renesas,rcar-adg-clocks.txt | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt

diff --git 
a/Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt 
b/Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt
new file mode 100644
index ..76fc4f8964e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt
@@ -0,0 +1,24 @@
+* Renesas R-Car Audio Clock Generator (ADG)
+
+The Audio Clock Generator (ADG) is part of R-Car Audio module, it
+selects and supplies the necessary clock for the SSIU, EAVB-IF, SCU,
+ADSP or DTCP module. It also divides the frequency of the selected
+clock and sends it outside the chip.
+
+Required Properties:
+
+  - compatible: Must be one of
+- "renesas,rcar_sound-gen1" for the R-Car GEN1 SoCs
+- "renesas,rcar_sound-gen2" for the R-Car GEN2 SoCs
+- "renesas,rcar_sound-gen3" for the R-Car GEN3 SoCs
+
+  - reg: Base address and length of the memory resource used by the ADG
+
+  - clocks: References to the parent clock S0D1.
+  - clock-names: ADG refer to its parent clock by name "adg".
+  - #clock-cells: Can be 0, 1 or 2
+- When clock-cells = 0, ADG registers one fixed clock out
+- When clock-cells = 1, ADG registers 3 fixed clock out
+- When clock-cells = 2, ADG registers 3 fixed clock out and 8 AVB clocks
+  second clock specifier need to be 0 to refer to fixed clock out, need
+  to be 1 to refer to AVB clocks
-- 
2.19.2

[tip:x86/urgent] x86/build: Fix compiler support check for CONFIG_RETPOLINE

[tip-bot for Masahiro Yamada]

Commit-ID:  25896d073d8a0403b07e6dec56f58e6c33678207
Gitweb: https://git.kernel.org/tip/25896d073d8a0403b07e6dec56f58e6c33678207
Author: Masahiro Yamada 
AuthorDate: Wed, 5 Dec 2018 15:27:19 +0900
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Dec 2018 08:44:02 +0100

x86/build: Fix compiler support check for CONFIG_RETPOLINE

It is troublesome to add a diagnostic like this to the Makefile
parse stage because the top-level Makefile could be parsed with
a stale include/config/auto.conf.

Once you are hit by the error about non-retpoline compiler, the
compilation still breaks even after disabling CONFIG_RETPOLINE.

The easiest fix is to move this check to the "archprepare" like
this commit did:

  829fe4aa9ac1 ("x86: Allow generating user-space headers without a compiler")

Reported-by: Meelis Roos 
Tested-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
Acked-by: Zhenzhong Duan 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Zhenzhong Duan 
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler 
support")
Link: 
http://lkml.kernel.org/r/1543991239-18476-1-git-send-email-yamada.masah...@socionext.com
Link: https://lkml.org/lkml/2018/12/4/206
Signed-off-by: Ingo Molnar 
---
 arch/x86/Makefile | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f5d7f4134524..75ef499a66e2 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,9 +220,6 @@ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
 
 # Avoid indirect branches in kernel to deal with Spectre
 ifdef CONFIG_RETPOLINE
-ifeq ($(RETPOLINE_CFLAGS),)
-  $(error You are building kernel with non-retpoline compiler, please update 
your compiler.)
-endif
   KBUILD_CFLAGS += $(RETPOLINE_CFLAGS)
 endif
 
@@ -307,6 +304,13 @@ ifndef CC_HAVE_ASM_GOTO
@echo Compiler lacks asm-goto support.
@exit 1
 endif
+ifdef CONFIG_RETPOLINE
+ifeq ($(RETPOLINE_CFLAGS),)
+   @echo "You are building kernel with non-retpoline compiler." >&2
+   @echo "Please update your compiler." >&2
+   @false
+endif
+endif
 
 archclean:
$(Q)rm -rf $(objtree)/arch/i386

[tip:x86/urgent] x86/build: Fix compiler support check for CONFIG_RETPOLINE

[tip-bot for Masahiro Yamada]

Commit-ID:  25896d073d8a0403b07e6dec56f58e6c33678207
Gitweb: https://git.kernel.org/tip/25896d073d8a0403b07e6dec56f58e6c33678207
Author: Masahiro Yamada 
AuthorDate: Wed, 5 Dec 2018 15:27:19 +0900
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Dec 2018 08:44:02 +0100

x86/build: Fix compiler support check for CONFIG_RETPOLINE

It is troublesome to add a diagnostic like this to the Makefile
parse stage because the top-level Makefile could be parsed with
a stale include/config/auto.conf.

Once you are hit by the error about non-retpoline compiler, the
compilation still breaks even after disabling CONFIG_RETPOLINE.

The easiest fix is to move this check to the "archprepare" like
this commit did:

  829fe4aa9ac1 ("x86: Allow generating user-space headers without a compiler")

Reported-by: Meelis Roos 
Tested-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
Acked-by: Zhenzhong Duan 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Zhenzhong Duan 
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler 
support")
Link: 
http://lkml.kernel.org/r/1543991239-18476-1-git-send-email-yamada.masah...@socionext.com
Link: https://lkml.org/lkml/2018/12/4/206
Signed-off-by: Ingo Molnar 
---
 arch/x86/Makefile | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f5d7f4134524..75ef499a66e2 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,9 +220,6 @@ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
 
 # Avoid indirect branches in kernel to deal with Spectre
 ifdef CONFIG_RETPOLINE
-ifeq ($(RETPOLINE_CFLAGS),)
-  $(error You are building kernel with non-retpoline compiler, please update 
your compiler.)
-endif
   KBUILD_CFLAGS += $(RETPOLINE_CFLAGS)
 endif
 
@@ -307,6 +304,13 @@ ifndef CC_HAVE_ASM_GOTO
@echo Compiler lacks asm-goto support.
@exit 1
 endif
+ifdef CONFIG_RETPOLINE
+ifeq ($(RETPOLINE_CFLAGS),)
+   @echo "You are building kernel with non-retpoline compiler." >&2
+   @echo "Please update your compiler." >&2
+   @false
+endif
+endif
 
 archclean:
$(Q)rm -rf $(objtree)/arch/i386

[PATCH linux-next v3 5/7] clk: renesas: r8a77965: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A77965 SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Jiada Wang 
---
 drivers/clk/renesas/r8a77965-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a77965-cpg-mssr.c 
b/drivers/clk/renesas/r8a77965-cpg-mssr.c
index 1fcc411502da..3ce8b0b31647 100644
--- a/drivers/clk/renesas/r8a77965-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77965-cpg-mssr.c
@@ -211,6 +211,7 @@ static const struct mssr_mod_clk r8a77965_mod_clks[] 
__initconst = {
DEF_MOD("can-if0",  916,R8A77965_CLK_S3D4),
DEF_MOD("i2c6", 918,R8A77965_CLK_S0D6),
DEF_MOD("i2c5", 919,R8A77965_CLK_S0D6),
+   DEF_MOD("adg",  922,R8A77965_CLK_S0D1),
DEF_MOD("i2c-dvfs", 926,R8A77965_CLK_CP),
DEF_MOD("i2c4", 927,R8A77965_CLK_S0D6),
DEF_MOD("i2c3", 928,R8A77965_CLK_S0D6),
-- 
2.19.2

[PATCH linux-next v3 5/7] clk: renesas: r8a77965: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A77965 SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Jiada Wang 
---
 drivers/clk/renesas/r8a77965-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a77965-cpg-mssr.c 
b/drivers/clk/renesas/r8a77965-cpg-mssr.c
index 1fcc411502da..3ce8b0b31647 100644
--- a/drivers/clk/renesas/r8a77965-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77965-cpg-mssr.c
@@ -211,6 +211,7 @@ static const struct mssr_mod_clk r8a77965_mod_clks[] 
__initconst = {
DEF_MOD("can-if0",  916,R8A77965_CLK_S3D4),
DEF_MOD("i2c6", 918,R8A77965_CLK_S0D6),
DEF_MOD("i2c5", 919,R8A77965_CLK_S0D6),
+   DEF_MOD("adg",  922,R8A77965_CLK_S0D1),
DEF_MOD("i2c-dvfs", 926,R8A77965_CLK_CP),
DEF_MOD("i2c4", 927,R8A77965_CLK_S0D6),
DEF_MOD("i2c3", 928,R8A77965_CLK_S0D6),
-- 
2.19.2

[PATCH linux-next v3 1/7] clk: renesas: r8a7795: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A7795 SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Jiada Wang 
---
 drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c 
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 119c02440726..813288099c84 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -237,6 +237,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
DEF_MOD("can-if0",   916,   R8A7795_CLK_S3D4),
DEF_MOD("i2c6",  918,   R8A7795_CLK_S0D6),
DEF_MOD("i2c5",  919,   R8A7795_CLK_S0D6),
+   DEF_MOD("adg",   922,   R8A7795_CLK_S0D1),
DEF_MOD("i2c-dvfs",  926,   R8A7795_CLK_CP),
DEF_MOD("i2c4",  927,   R8A7795_CLK_S0D6),
DEF_MOD("i2c3",  928,   R8A7795_CLK_S0D6),
-- 
2.19.2

[PATCH linux-next v3 1/7] clk: renesas: r8a7795: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A7795 SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Jiada Wang 
---
 drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c 
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 119c02440726..813288099c84 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -237,6 +237,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
DEF_MOD("can-if0",   916,   R8A7795_CLK_S3D4),
DEF_MOD("i2c6",  918,   R8A7795_CLK_S0D6),
DEF_MOD("i2c5",  919,   R8A7795_CLK_S0D6),
+   DEF_MOD("adg",   922,   R8A7795_CLK_S0D1),
DEF_MOD("i2c-dvfs",  926,   R8A7795_CLK_CP),
DEF_MOD("i2c4",  927,   R8A7795_CLK_S0D6),
DEF_MOD("i2c3",  928,   R8A7795_CLK_S0D6),
-- 
2.19.2

[PATCH linux-next v3 3/7] clk: renesas: r8a77990: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A77990 SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Jiada Wang 
---
 drivers/clk/renesas/r8a77990-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a77990-cpg-mssr.c 
b/drivers/clk/renesas/r8a77990-cpg-mssr.c
index 9eb80180eea0..3bb55037a9e3 100644
--- a/drivers/clk/renesas/r8a77990-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77990-cpg-mssr.c
@@ -203,6 +203,7 @@ static const struct mssr_mod_clk r8a77990_mod_clks[] 
__initconst = {
DEF_MOD("can-if0",   916,   R8A77990_CLK_S3D4),
DEF_MOD("i2c6",  918,   R8A77990_CLK_S3D2),
DEF_MOD("i2c5",  919,   R8A77990_CLK_S3D2),
+   DEF_MOD("adg",   922,   R8A77990_CLK_ZA8),
DEF_MOD("i2c-dvfs",  926,   R8A77990_CLK_CP),
DEF_MOD("i2c4",  927,   R8A77990_CLK_S3D2),
DEF_MOD("i2c3",  928,   R8A77990_CLK_S3D2),
-- 
2.19.2

[PATCH linux-next v3 4/7] clk: renesas: r8a77995: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A77995 SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Jiada Wang 
---
 drivers/clk/renesas/r8a77995-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a77995-cpg-mssr.c 
b/drivers/clk/renesas/r8a77995-cpg-mssr.c
index 47e60e3dbe05..933084d896e3 100644
--- a/drivers/clk/renesas/r8a77995-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77995-cpg-mssr.c
@@ -165,6 +165,7 @@ static const struct mssr_mod_clk r8a77995_mod_clks[] 
__initconst = {
DEF_MOD("can-fd",914,   R8A77995_CLK_S3D2),
DEF_MOD("can-if1",   915,   R8A77995_CLK_S3D4),
DEF_MOD("can-if0",   916,   R8A77995_CLK_S3D4),
+   DEF_MOD("adg",   922,   R8A77995_CLK_ZA8),
DEF_MOD("i2c3",  928,   R8A77995_CLK_S3D2),
DEF_MOD("i2c2",  929,   R8A77995_CLK_S3D2),
DEF_MOD("i2c1",  930,   R8A77995_CLK_S3D2),
-- 
2.19.2

[PATCH linux-next v3 3/7] clk: renesas: r8a77990: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A77990 SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Jiada Wang 
---
 drivers/clk/renesas/r8a77990-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a77990-cpg-mssr.c 
b/drivers/clk/renesas/r8a77990-cpg-mssr.c
index 9eb80180eea0..3bb55037a9e3 100644
--- a/drivers/clk/renesas/r8a77990-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77990-cpg-mssr.c
@@ -203,6 +203,7 @@ static const struct mssr_mod_clk r8a77990_mod_clks[] 
__initconst = {
DEF_MOD("can-if0",   916,   R8A77990_CLK_S3D4),
DEF_MOD("i2c6",  918,   R8A77990_CLK_S3D2),
DEF_MOD("i2c5",  919,   R8A77990_CLK_S3D2),
+   DEF_MOD("adg",   922,   R8A77990_CLK_ZA8),
DEF_MOD("i2c-dvfs",  926,   R8A77990_CLK_CP),
DEF_MOD("i2c4",  927,   R8A77990_CLK_S3D2),
DEF_MOD("i2c3",  928,   R8A77990_CLK_S3D2),
-- 
2.19.2

[PATCH linux-next v3 4/7] clk: renesas: r8a77995: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A77995 SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Jiada Wang 
---
 drivers/clk/renesas/r8a77995-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a77995-cpg-mssr.c 
b/drivers/clk/renesas/r8a77995-cpg-mssr.c
index 47e60e3dbe05..933084d896e3 100644
--- a/drivers/clk/renesas/r8a77995-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77995-cpg-mssr.c
@@ -165,6 +165,7 @@ static const struct mssr_mod_clk r8a77995_mod_clks[] 
__initconst = {
DEF_MOD("can-fd",914,   R8A77995_CLK_S3D2),
DEF_MOD("can-if1",   915,   R8A77995_CLK_S3D4),
DEF_MOD("can-if0",   916,   R8A77995_CLK_S3D4),
+   DEF_MOD("adg",   922,   R8A77995_CLK_ZA8),
DEF_MOD("i2c3",  928,   R8A77995_CLK_S3D2),
DEF_MOD("i2c2",  929,   R8A77995_CLK_S3D2),
DEF_MOD("i2c1",  930,   R8A77995_CLK_S3D2),
-- 
2.19.2

[PATCH linux-next v3 2/7] clk: renesas: r8a7796: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A7796 SoC.

Signed-off-by: Takeshi Kihara 
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c 
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index 10567386e6dd..7568204e9ed6 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -209,6 +209,7 @@ static const struct mssr_mod_clk r8a7796_mod_clks[] 
__initconst = {
DEF_MOD("can-if0",   916,   R8A7796_CLK_S3D4),
DEF_MOD("i2c6",  918,   R8A7796_CLK_S0D6),
DEF_MOD("i2c5",  919,   R8A7796_CLK_S0D6),
+   DEF_MOD("adg",   922,   R8A7796_CLK_S0D1),
DEF_MOD("i2c-dvfs",  926,   R8A7796_CLK_CP),
DEF_MOD("i2c4",  927,   R8A7796_CLK_S0D6),
DEF_MOD("i2c3",  928,   R8A7796_CLK_S0D6),
-- 
2.19.2

[PATCH linux-next v3 0/7] clk: renesas: adg: add AVB Clock

[Jiada Wang]

on R-Car SoCs there are AVB Counter Clocks, each clock has 12bits integral
and 8 bits fractional dividers which operates with S0D1ϕ clock.

This patch-set adds 'adg' clock to R-Car Soc, and changes adg driver to
register avb clocks when clock-cells of rcar_sound node is 2.

---
v3:
- Removed clock id header file, added device tree bindings documentation
  instead to describe clock id
- Instead of hardcode parent clock name in adg driver,
  refer to parent clock via clock specifier in device tree with 'adg' name
- Added patch to add ADG in r8a77965
- Some other fixes

v2:
- expends adg register size and register avb clocks instead of
  add new clk-avb driver
- Add adg clock 

v1: initial version

Jiada Wang (2):
  ASoC: rsnd: add avb clocks
  clk: renesas: Add binding document for ADG

Takeshi Kihara (5):
  clk: renesas: r8a7795: Add ADG clock
  clk: renesas: r8a7796: Add ADG clock
  clk: renesas: r8a77990: Add ADG clock
  clk: renesas: r8a77995: Add ADG clock
  clk: renesas: r8a77965: Add ADG clock

 .../clock/renesas,rcar-adg-clocks.txt |  24 ++
 drivers/clk/renesas/r8a7795-cpg-mssr.c|   1 +
 drivers/clk/renesas/r8a7796-cpg-mssr.c|   1 +
 drivers/clk/renesas/r8a77965-cpg-mssr.c   |   1 +
 drivers/clk/renesas/r8a77990-cpg-mssr.c   |   1 +
 drivers/clk/renesas/r8a77995-cpg-mssr.c   |   1 +
 sound/soc/sh/rcar/adg.c   | 316 +-
 sound/soc/sh/rcar/gen.c   |   9 +
 sound/soc/sh/rcar/rsnd.h  |   9 +
 9 files changed, 354 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt

-- 
2.19.2

[PATCH linux-next v3 2/7] clk: renesas: r8a7796: Add ADG clock

[Jiada Wang]

From: Takeshi Kihara 

This patch adds ADG clock to the R8A7796 SoC.

Signed-off-by: Takeshi Kihara 
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c 
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index 10567386e6dd..7568204e9ed6 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -209,6 +209,7 @@ static const struct mssr_mod_clk r8a7796_mod_clks[] 
__initconst = {
DEF_MOD("can-if0",   916,   R8A7796_CLK_S3D4),
DEF_MOD("i2c6",  918,   R8A7796_CLK_S0D6),
DEF_MOD("i2c5",  919,   R8A7796_CLK_S0D6),
+   DEF_MOD("adg",   922,   R8A7796_CLK_S0D1),
DEF_MOD("i2c-dvfs",  926,   R8A7796_CLK_CP),
DEF_MOD("i2c4",  927,   R8A7796_CLK_S0D6),
DEF_MOD("i2c3",  928,   R8A7796_CLK_S0D6),
-- 
2.19.2

[PATCH linux-next v3 0/7] clk: renesas: adg: add AVB Clock

[Jiada Wang]

on R-Car SoCs there are AVB Counter Clocks, each clock has 12bits integral
and 8 bits fractional dividers which operates with S0D1ϕ clock.

This patch-set adds 'adg' clock to R-Car Soc, and changes adg driver to
register avb clocks when clock-cells of rcar_sound node is 2.

---
v3:
- Removed clock id header file, added device tree bindings documentation
  instead to describe clock id
- Instead of hardcode parent clock name in adg driver,
  refer to parent clock via clock specifier in device tree with 'adg' name
- Added patch to add ADG in r8a77965
- Some other fixes

v2:
- expends adg register size and register avb clocks instead of
  add new clk-avb driver
- Add adg clock 

v1: initial version

Jiada Wang (2):
  ASoC: rsnd: add avb clocks
  clk: renesas: Add binding document for ADG

Takeshi Kihara (5):
  clk: renesas: r8a7795: Add ADG clock
  clk: renesas: r8a7796: Add ADG clock
  clk: renesas: r8a77990: Add ADG clock
  clk: renesas: r8a77995: Add ADG clock
  clk: renesas: r8a77965: Add ADG clock

 .../clock/renesas,rcar-adg-clocks.txt |  24 ++
 drivers/clk/renesas/r8a7795-cpg-mssr.c|   1 +
 drivers/clk/renesas/r8a7796-cpg-mssr.c|   1 +
 drivers/clk/renesas/r8a77965-cpg-mssr.c   |   1 +
 drivers/clk/renesas/r8a77990-cpg-mssr.c   |   1 +
 drivers/clk/renesas/r8a77995-cpg-mssr.c   |   1 +
 sound/soc/sh/rcar/adg.c   | 316 +-
 sound/soc/sh/rcar/gen.c   |   9 +
 sound/soc/sh/rcar/rsnd.h  |   9 +
 9 files changed, 354 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,rcar-adg-clocks.txt

-- 
2.19.2

Re: [PATCH] x86/umip: Make the UMIP activated message generic

[Ingo Molnar]

* Lendacky, Thomas  wrote:

> The User Mode Instruction Prevention (UMIP) feature is part of the x86_64
> instruction set architecture and not specific to Intel.  Make the message
> generic.
> 
> Signed-off-by: Tom Lendacky 
> ---
> 
> This patch is against the x86/cpu branch of the tip tree:
>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cpu
> 
>  arch/x86/kernel/cpu/common.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 2c56b80..cb28e98 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -353,7 +353,7 @@ static __always_inline void setup_umip(struct cpuinfo_x86 
> *c)
>  
>   cr4_set_bits(X86_CR4_UMIP);
>  
> - pr_info_once("x86/cpu: Intel User Mode Instruction Prevention (UMIP) 
> activated\n");
> + pr_info_once("x86/cpu: User Mode Instruction Prevention (UMIP) 
> activated\n");

Is there any public information about which AMD CPUs are going to support 
it?

The latest AMD CPU I can test on is a Ryzen Threadripper 1950X, and that 
doesn't have UMIP.

Thanks,

Ingo

Re: [PATCH] x86/umip: Make the UMIP activated message generic

[Ingo Molnar]

* Lendacky, Thomas  wrote:

> The User Mode Instruction Prevention (UMIP) feature is part of the x86_64
> instruction set architecture and not specific to Intel.  Make the message
> generic.
> 
> Signed-off-by: Tom Lendacky 
> ---
> 
> This patch is against the x86/cpu branch of the tip tree:
>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cpu
> 
>  arch/x86/kernel/cpu/common.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 2c56b80..cb28e98 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -353,7 +353,7 @@ static __always_inline void setup_umip(struct cpuinfo_x86 
> *c)
>  
>   cr4_set_bits(X86_CR4_UMIP);
>  
> - pr_info_once("x86/cpu: Intel User Mode Instruction Prevention (UMIP) 
> activated\n");
> + pr_info_once("x86/cpu: User Mode Instruction Prevention (UMIP) 
> activated\n");

Is there any public information about which AMD CPUs are going to support 
it?

The latest AMD CPU I can test on is a Ryzen Threadripper 1950X, and that 
doesn't have UMIP.

Thanks,

Ingo

[tip:x86/urgent] x86/build: Fix compiler support check for CONFIG_RETPOLINE

[tip-bot for Masahiro Yamada]

Commit-ID:  10b87bc9f630a38a7f0c1e7cf13ff23fea1692ec
Gitweb: https://git.kernel.org/tip/10b87bc9f630a38a7f0c1e7cf13ff23fea1692ec
Author: Masahiro Yamada 
AuthorDate: Wed, 5 Dec 2018 15:27:19 +0900
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Dec 2018 08:42:09 +0100

x86/build: Fix compiler support check for CONFIG_RETPOLINE

It is troublesome to add a diagnostic like this to the Makefile
parse stage because the top-level Makefile could be parsed with
a stale include/config/auto.conf.

Once you are hit by the error about non-retpoline compiler, the
compilation still breaks even after disabling CONFIG_RETPOLINE.

The easiest fix is to move this check to the "archprepare" like
this commit did:

  829fe4aa9ac1 ("x86: Allow generating user-space headers without a compiler")

Reported-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
Acked-by: Zhenzhong Duan 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Zhenzhong Duan 
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler 
support")
Link: 
http://lkml.kernel.org/r/1543991239-18476-1-git-send-email-yamada.masah...@socionext.com
Link: https://lkml.org/lkml/2018/12/4/206
Signed-off-by: Ingo Molnar 
---
 arch/x86/Makefile | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f5d7f4134524..75ef499a66e2 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,9 +220,6 @@ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
 
 # Avoid indirect branches in kernel to deal with Spectre
 ifdef CONFIG_RETPOLINE
-ifeq ($(RETPOLINE_CFLAGS),)
-  $(error You are building kernel with non-retpoline compiler, please update 
your compiler.)
-endif
   KBUILD_CFLAGS += $(RETPOLINE_CFLAGS)
 endif
 
@@ -307,6 +304,13 @@ ifndef CC_HAVE_ASM_GOTO
@echo Compiler lacks asm-goto support.
@exit 1
 endif
+ifdef CONFIG_RETPOLINE
+ifeq ($(RETPOLINE_CFLAGS),)
+   @echo "You are building kernel with non-retpoline compiler." >&2
+   @echo "Please update your compiler." >&2
+   @false
+endif
+endif
 
 archclean:
$(Q)rm -rf $(objtree)/arch/i386

[tip:x86/urgent] x86/build: Fix compiler support check for CONFIG_RETPOLINE

[tip-bot for Masahiro Yamada]

Commit-ID:  10b87bc9f630a38a7f0c1e7cf13ff23fea1692ec
Gitweb: https://git.kernel.org/tip/10b87bc9f630a38a7f0c1e7cf13ff23fea1692ec
Author: Masahiro Yamada 
AuthorDate: Wed, 5 Dec 2018 15:27:19 +0900
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Dec 2018 08:42:09 +0100

x86/build: Fix compiler support check for CONFIG_RETPOLINE

It is troublesome to add a diagnostic like this to the Makefile
parse stage because the top-level Makefile could be parsed with
a stale include/config/auto.conf.

Once you are hit by the error about non-retpoline compiler, the
compilation still breaks even after disabling CONFIG_RETPOLINE.

The easiest fix is to move this check to the "archprepare" like
this commit did:

  829fe4aa9ac1 ("x86: Allow generating user-space headers without a compiler")

Reported-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
Acked-by: Zhenzhong Duan 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Zhenzhong Duan 
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler 
support")
Link: 
http://lkml.kernel.org/r/1543991239-18476-1-git-send-email-yamada.masah...@socionext.com
Link: https://lkml.org/lkml/2018/12/4/206
Signed-off-by: Ingo Molnar 
---
 arch/x86/Makefile | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f5d7f4134524..75ef499a66e2 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,9 +220,6 @@ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
 
 # Avoid indirect branches in kernel to deal with Spectre
 ifdef CONFIG_RETPOLINE
-ifeq ($(RETPOLINE_CFLAGS),)
-  $(error You are building kernel with non-retpoline compiler, please update 
your compiler.)
-endif
   KBUILD_CFLAGS += $(RETPOLINE_CFLAGS)
 endif
 
@@ -307,6 +304,13 @@ ifndef CC_HAVE_ASM_GOTO
@echo Compiler lacks asm-goto support.
@exit 1
 endif
+ifdef CONFIG_RETPOLINE
+ifeq ($(RETPOLINE_CFLAGS),)
+   @echo "You are building kernel with non-retpoline compiler." >&2
+   @echo "Please update your compiler." >&2
+   @false
+endif
+endif
 
 archclean:
$(Q)rm -rf $(objtree)/arch/i386

[PATCH 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294

[Jian-Hong Pan]

The ASUS UX533FD with ALC294 cannot detect the headset MIC and output
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.

Signed-off-by: Daniel Drake 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bbae06267054..5c25c8c3f703 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5518,6 +5518,7 @@ enum {
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
ALC294_FIXUP_ASUS_MIC,
+   ALC294_FIXUP_ASUS_SPK_NOISE,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -6414,6 +6415,17 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
},
+   [ALC294_FIXUP_ASUS_SPK_NOISE] = {
+   .type = HDA_FIXUP_VERBS,
+   .v.verbs = (const struct hda_verb[]) {
+   /* Set EAPD high */
+   {0x20, AC_VERB_SET_COEF_INDEX, 0x10},
+   {0x20, AC_VERB_SET_PROC_COEF, 0x14},
+   {}
+   },
+   .chained = true,
+   .chain_id = ALC255_FIXUP_ASUS_MIC_NO_PRESENCE
+   },
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6556,6 +6568,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", 
ALC269VB_FIXUP_ASUS_ZENBOOK),
+   SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD", 
ALC294_FIXUP_ASUS_SPK_NOISE),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", 
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
-- 
2.11.0

[PATCH 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294

[Jian-Hong Pan]

The ASUS UX533FD with ALC294 cannot detect the headset MIC and output
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.

Signed-off-by: Daniel Drake 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bbae06267054..5c25c8c3f703 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5518,6 +5518,7 @@ enum {
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
ALC294_FIXUP_ASUS_MIC,
+   ALC294_FIXUP_ASUS_SPK_NOISE,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -6414,6 +6415,17 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
},
+   [ALC294_FIXUP_ASUS_SPK_NOISE] = {
+   .type = HDA_FIXUP_VERBS,
+   .v.verbs = (const struct hda_verb[]) {
+   /* Set EAPD high */
+   {0x20, AC_VERB_SET_COEF_INDEX, 0x10},
+   {0x20, AC_VERB_SET_PROC_COEF, 0x14},
+   {}
+   },
+   .chained = true,
+   .chain_id = ALC255_FIXUP_ASUS_MIC_NO_PRESENCE
+   },
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6556,6 +6568,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", 
ALC269VB_FIXUP_ASUS_ZENBOOK),
+   SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD", 
ALC294_FIXUP_ASUS_SPK_NOISE),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", 
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
-- 
2.11.0

[PATCH 3/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN with ALC294

[Jian-Hong Pan]

The ASUS UX433FN with ALC294 cannot detect the headset MIC and output
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.

Signed-off-by: Daniel Drake 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 5c25c8c3f703..56925140bfe6 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7180,6 +7180,10 @@ static const struct snd_hda_pin_quirk 
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x04211020}),
+   SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", 
ALC294_FIXUP_ASUS_SPK_NOISE,
+   {0x12, 0x90a60130},
+   {0x17, 0x90170110},
+   {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", 
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
-- 
2.11.0

Re: [PATCH] perf/core: declare the percpu variable properly

[Mukesh Ojha]

Hi All,

Can you please review the change ?

Thanks,
Mukesh


On 11/27/2018 2:43 PM, Mukesh Ojha wrote:

Sparse reports the current declaration of percpu variable with
below warning

warning: incorrect type in initializer (different address spaces)
  expected void const [noderef] *__vpp_verify
  got struct perf_cpu_context *

Fix it by declaring it properly.

Signed-off-by: Mukesh Ojha 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Namhyung Kim 

---
  include/linux/perf_event.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 53c500f..1d5c551 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -262,8 +262,8 @@ struct pmu {
 */
int capabilities;
  
-	int * __percpu			pmu_disable_count;

-   struct perf_cpu_context * __percpu pmu_cpu_context;
+   int __percpu*pmu_disable_count;
+   struct perf_cpu_context __percpu *pmu_cpu_context;
atomic_texclusive_cnt; /* < 0: cpu; > 0: tsk */
int task_ctx_nr;
int hrtimer_interval_ms;

[PATCH 3/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN with ALC294

[Jian-Hong Pan]

The ASUS UX433FN with ALC294 cannot detect the headset MIC and output
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.

Signed-off-by: Daniel Drake 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 5c25c8c3f703..56925140bfe6 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7180,6 +7180,10 @@ static const struct snd_hda_pin_quirk 
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x04211020}),
+   SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", 
ALC294_FIXUP_ASUS_SPK_NOISE,
+   {0x12, 0x90a60130},
+   {0x17, 0x90170110},
+   {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", 
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
-- 
2.11.0

Re: [PATCH] perf/core: declare the percpu variable properly

[Mukesh Ojha]

Hi All,

Can you please review the change ?

Thanks,
Mukesh


On 11/27/2018 2:43 PM, Mukesh Ojha wrote:

Sparse reports the current declaration of percpu variable with
below warning

warning: incorrect type in initializer (different address spaces)
  expected void const [noderef] *__vpp_verify
  got struct perf_cpu_context *

Fix it by declaring it properly.

Signed-off-by: Mukesh Ojha 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Namhyung Kim 

---
  include/linux/perf_event.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 53c500f..1d5c551 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -262,8 +262,8 @@ struct pmu {
 */
int capabilities;
  
-	int * __percpu			pmu_disable_count;

-   struct perf_cpu_context * __percpu pmu_cpu_context;
+   int __percpu*pmu_disable_count;
+   struct perf_cpu_context __percpu *pmu_cpu_context;
atomic_texclusive_cnt; /* < 0: cpu; > 0: tsk */
int task_ctx_nr;
int hrtimer_interval_ms;

[PATCH 1/3] ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN

[Jian-Hong Pan]

From: Chris Chiu 

The known ALC256_FIXUP_ASUS_MIC fixup can fix the headphone jack
sensing and enable use of the internal microphone on this laptop
X542UN. However, it's ALC294 so create a new fixup named
ALC294_FIXUP_ASUS_MIC to avoid confusion.

Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bb40624fb6d5..bbae06267054 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5517,6 +5517,7 @@ enum {
ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
+   ALC294_FIXUP_ASUS_MIC,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -6403,6 +6404,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+   [ALC294_FIXUP_ASUS_MIC] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   { 0x13, 0x90a60160 }, /* use as internal mic */
+   { 0x19, 0x04a11120 }, /* use as headset mic, without 
its own jack detect */
+   { }
+   },
+   .chained = true,
+   .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
+   },
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7152,6 +7163,10 @@ static const struct snd_hda_pin_quirk 
alc269_pin_fixup_tbl[] = {
SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell", 
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC292_STANDARD_PINS,
{0x13, 0x90a60140}),
+   SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_MIC,
+   {0x14, 0x90170110},
+   {0x1b, 0x90a70130},
+   {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", 
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
-- 
2.11.0

[PATCH 0/3] Add ALC294 quirks for ASUS laptops

[Jian-Hong Pan]

Add Realtek ALC294 quirks for ASUS X542UN, UX533FD and UX433FN laptops.

Chris Chiu (1):
  ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN

Jian-Hong Pan (2):
  ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294
  ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN with ALC294

 sound/pci/hda/patch_realtek.c | 32 
 1 file changed, 32 insertions(+)

-- 
2.11.0

[PATCH 1/3] ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN

[Jian-Hong Pan]

From: Chris Chiu 

The known ALC256_FIXUP_ASUS_MIC fixup can fix the headphone jack
sensing and enable use of the internal microphone on this laptop
X542UN. However, it's ALC294 so create a new fixup named
ALC294_FIXUP_ASUS_MIC to avoid confusion.

Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bb40624fb6d5..bbae06267054 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5517,6 +5517,7 @@ enum {
ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
+   ALC294_FIXUP_ASUS_MIC,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -6403,6 +6404,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+   [ALC294_FIXUP_ASUS_MIC] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   { 0x13, 0x90a60160 }, /* use as internal mic */
+   { 0x19, 0x04a11120 }, /* use as headset mic, without 
its own jack detect */
+   { }
+   },
+   .chained = true,
+   .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
+   },
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7152,6 +7163,10 @@ static const struct snd_hda_pin_quirk 
alc269_pin_fixup_tbl[] = {
SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell", 
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC292_STANDARD_PINS,
{0x13, 0x90a60140}),
+   SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_MIC,
+   {0x14, 0x90170110},
+   {0x1b, 0x90a70130},
+   {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", 
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
-- 
2.11.0

[PATCH 0/3] Add ALC294 quirks for ASUS laptops

[Jian-Hong Pan]

Add Realtek ALC294 quirks for ASUS X542UN, UX533FD and UX433FN laptops.

Chris Chiu (1):
  ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN

Jian-Hong Pan (2):
  ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294
  ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN with ALC294

 sound/pci/hda/patch_realtek.c | 32 
 1 file changed, 32 insertions(+)

-- 
2.11.0

Re: [PATCH 4.14 000/146] 4.14.86-stable review

[Greg Kroah-Hartman]

On Wed, Dec 05, 2018 at 10:48:59AM +0530, Naresh Kamboju wrote:
> On Tue, 4 Dec 2018 at 16:34, Greg Kroah-Hartman
>  wrote:
> >
> > This is the start of the stable review cycle for the 4.14.86 release.
> > There are 146 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Dec  6 10:36:52 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.86-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Thanks for testing two of these and letting me know.

greg k-h

Re: [patch 0/2 for-4.20] mm, thp: fix remote access and allocation regressions

[Michal Hocko]

On Tue 04-12-18 14:25:54, David Rientjes wrote:
> On Tue, 4 Dec 2018, Michal Hocko wrote:
> 
> > > This fixes a 13.9% of remote memory access regression and 40% remote
> > > memory allocation regression on Haswell when the local node is fragmented
> > > for hugepage sized pages and memory is being faulted with either the thp
> > > defrag setting of "always" or has been madvised with MADV_HUGEPAGE.
> > > 
> > > The usecase that initially identified this issue were binaries that mremap
> > > their .text segment to be backed by transparent hugepages on startup.
> > > They do mmap(), madvise(MADV_HUGEPAGE), memcpy(), and mremap().
> > 
> > Do you have something you can share with so that other people can play
> > and try to reproduce?
> > 
> 
> This is a single MADV_HUGEPAGE usecase, there is nothing special about it.  
> It would be the same as if you did mmap(), madvise(MADV_HUGEPAGE), and 
> faulted the memory with a fragmented local node and then measured the 
> remote access latency to the remote hugepage that occurs without setting 
> __GFP_THISNODE.  You can also measure the remote allocation latency by 
> fragmenting the entire system and then faulting.
> 
> (Remapping the text segment only involves parsing /proc/self/exe, mmap, 
> madvise, memcpy, and mremap.)

How does this reflect your real workload and regressions in it. It
certainly shows the worst case behavior where the access penalty is
prevalent while there are no other metrics which might be interesting or
even important. E.g. page table savings or the TLB pressure in general
when THP fail too eagerly.
As Anrea mentioned there are really valid cases where the remote latency
pays off.

Have you actually seen the advertised regression in the real workload
and do you have any means to simulate that workload.

> > > This requires a full revert and partial revert of commits merged during
> > > the 4.20 rc cycle.  The full revert, of ac5b2c18911f ("mm: thp: relax
> > > __GFP_THISNODE for MADV_HUGEPAGE mappings"), was anticipated to fix large
> > > amounts of swap activity on the local zone when faulting hugepages by
> > > falling back to remote memory.  This remote allocation causes the access
> > > regression and, if fragmented, the allocation regression.
> > 
> > Have you tried to measure any of the workloads Mel and Andrea have
> > pointed out during the previous review discussion? In other words what
> > is the impact on the THP success rate and allocation latencies for other
> > usecases?
> 
> It isn't a property of the workload, it's a property of the how fragmented 
> both local and remote memory is.  In Andrea's case, I believe he has 
> stated that memory compaction has failed locally and the resulting reclaim 
> activity ends up looping and causing it the thrash the local node whereas 
> 75% of remote memory is free and not fragmented.  So we have local 
> fragmentation and reclaim is very expensive to enable compaction to 
> succeed, if it ever does succeed[*], and mostly free remote memory.
> 
> If remote memory is also fragmented, Andrea's case will run into a much 
> more severe swap storm as a result of not setting __GFP_THISNODE.  The 
> premise of the entire change is that his remote memory is mostly free so 
> fallback results in a quick allocation.  For balanced nodes, that's not 
> going to be the case.  The fix to prevent the heavy reclaim activity is to 
> set __GFP_NORETRY as the page allocator suspects, which patch 2 here does.

You are not answering my question and I take it as you haven't actually
tested this in a variety of workload and base your assumptions on an
artificial worst case scenario. Please correct me if I am wrong.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 4.14 000/146] 4.14.86-stable review

[Greg Kroah-Hartman]

On Wed, Dec 05, 2018 at 10:48:59AM +0530, Naresh Kamboju wrote:
> On Tue, 4 Dec 2018 at 16:34, Greg Kroah-Hartman
>  wrote:
> >
> > This is the start of the stable review cycle for the 4.14.86 release.
> > There are 146 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Dec  6 10:36:52 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.86-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Thanks for testing two of these and letting me know.

greg k-h

Re: [patch 0/2 for-4.20] mm, thp: fix remote access and allocation regressions

[Michal Hocko]

On Tue 04-12-18 14:25:54, David Rientjes wrote:
> On Tue, 4 Dec 2018, Michal Hocko wrote:
> 
> > > This fixes a 13.9% of remote memory access regression and 40% remote
> > > memory allocation regression on Haswell when the local node is fragmented
> > > for hugepage sized pages and memory is being faulted with either the thp
> > > defrag setting of "always" or has been madvised with MADV_HUGEPAGE.
> > > 
> > > The usecase that initially identified this issue were binaries that mremap
> > > their .text segment to be backed by transparent hugepages on startup.
> > > They do mmap(), madvise(MADV_HUGEPAGE), memcpy(), and mremap().
> > 
> > Do you have something you can share with so that other people can play
> > and try to reproduce?
> > 
> 
> This is a single MADV_HUGEPAGE usecase, there is nothing special about it.  
> It would be the same as if you did mmap(), madvise(MADV_HUGEPAGE), and 
> faulted the memory with a fragmented local node and then measured the 
> remote access latency to the remote hugepage that occurs without setting 
> __GFP_THISNODE.  You can also measure the remote allocation latency by 
> fragmenting the entire system and then faulting.
> 
> (Remapping the text segment only involves parsing /proc/self/exe, mmap, 
> madvise, memcpy, and mremap.)

How does this reflect your real workload and regressions in it. It
certainly shows the worst case behavior where the access penalty is
prevalent while there are no other metrics which might be interesting or
even important. E.g. page table savings or the TLB pressure in general
when THP fail too eagerly.
As Anrea mentioned there are really valid cases where the remote latency
pays off.

Have you actually seen the advertised regression in the real workload
and do you have any means to simulate that workload.

> > > This requires a full revert and partial revert of commits merged during
> > > the 4.20 rc cycle.  The full revert, of ac5b2c18911f ("mm: thp: relax
> > > __GFP_THISNODE for MADV_HUGEPAGE mappings"), was anticipated to fix large
> > > amounts of swap activity on the local zone when faulting hugepages by
> > > falling back to remote memory.  This remote allocation causes the access
> > > regression and, if fragmented, the allocation regression.
> > 
> > Have you tried to measure any of the workloads Mel and Andrea have
> > pointed out during the previous review discussion? In other words what
> > is the impact on the THP success rate and allocation latencies for other
> > usecases?
> 
> It isn't a property of the workload, it's a property of the how fragmented 
> both local and remote memory is.  In Andrea's case, I believe he has 
> stated that memory compaction has failed locally and the resulting reclaim 
> activity ends up looping and causing it the thrash the local node whereas 
> 75% of remote memory is free and not fragmented.  So we have local 
> fragmentation and reclaim is very expensive to enable compaction to 
> succeed, if it ever does succeed[*], and mostly free remote memory.
> 
> If remote memory is also fragmented, Andrea's case will run into a much 
> more severe swap storm as a result of not setting __GFP_THISNODE.  The 
> premise of the entire change is that his remote memory is mostly free so 
> fallback results in a quick allocation.  For balanced nodes, that's not 
> going to be the case.  The fix to prevent the heavy reclaim activity is to 
> set __GFP_NORETRY as the page allocator suspects, which patch 2 here does.

You are not answering my question and I take it as you haven't actually
tested this in a variety of workload and base your assumptions on an
artificial worst case scenario. Please correct me if I am wrong.

-- 
Michal Hocko
SUSE Labs

[PATCH] kbuild: exploit parallel building for CONFIG_HEADERS_CHECK

[Masahiro Yamada]

When CONFIG_HEADERS_CHECK is enabled, the headers_check is executed
as a serialized task in the vmlinux recipe.

Make it independent of vmlinux so that parallel building can process
the headers_check and other build targets simultaneously.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 3af0379..2808a7d 100644
--- a/Makefile
+++ b/Makefile
@@ -1035,9 +1035,6 @@ cmd_link-vmlinux =
 \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
 
 vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE
-ifdef CONFIG_HEADERS_CHECK
-   $(Q)$(MAKE) -f $(srctree)/Makefile headers_check
-endif
 ifdef CONFIG_GDB_SCRIPTS
$(Q)ln -fsn $(abspath $(srctree)/scripts/gdb/vmlinux-gdb.py)
 endif
@@ -1208,6 +1205,10 @@ headers_check: headers_install
$(Q)$(MAKE) $(hdr-inst)=include/uapi dst=include HDRCHECK=1
$(Q)$(MAKE) $(hdr-inst)=arch/$(SRCARCH)/include/uapi $(hdr-dst) 
HDRCHECK=1
 
+ifdef CONFIG_HEADERS_CHECK
+all: headers_check
+endif
+
 # ---
 # Kernel selftest
 
-- 
2.7.4

[PATCH] kbuild: exploit parallel building for CONFIG_HEADERS_CHECK

[Masahiro Yamada]

When CONFIG_HEADERS_CHECK is enabled, the headers_check is executed
as a serialized task in the vmlinux recipe.

Make it independent of vmlinux so that parallel building can process
the headers_check and other build targets simultaneously.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 3af0379..2808a7d 100644
--- a/Makefile
+++ b/Makefile
@@ -1035,9 +1035,6 @@ cmd_link-vmlinux =
 \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
 
 vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE
-ifdef CONFIG_HEADERS_CHECK
-   $(Q)$(MAKE) -f $(srctree)/Makefile headers_check
-endif
 ifdef CONFIG_GDB_SCRIPTS
$(Q)ln -fsn $(abspath $(srctree)/scripts/gdb/vmlinux-gdb.py)
 endif
@@ -1208,6 +1205,10 @@ headers_check: headers_install
$(Q)$(MAKE) $(hdr-inst)=include/uapi dst=include HDRCHECK=1
$(Q)$(MAKE) $(hdr-inst)=arch/$(SRCARCH)/include/uapi $(hdr-dst) 
HDRCHECK=1
 
+ifdef CONFIG_HEADERS_CHECK
+all: headers_check
+endif
+
 # ---
 # Kernel selftest
 
-- 
2.7.4

[PATCH] kbuild: remove a special handling for *.agh in Makefile.headersinst

[Masahiro Yamada]

scripts/Makefile.headersinst takes care of *.agh just for

  arch/cris/include/uapi/arch-v10/arch/sv_addr.agh

because renaming exported headers is difficult (or impossible).

This code is no longer necessary thanks to commit c690eddc2f3b ("CRIS:
Drop support for the CRIS port").

Signed-off-by: Masahiro Yamada 
---

 scripts/Makefile.headersinst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 0d4a96d..3d1ebaa 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -44,7 +44,6 @@ kbuild-file := $(srctree)/$(obj)/Kbuild
 installdir:= $(INSTALL_HDR_PATH)/$(dst)
 gendir:= $(objtree)/$(subst include/,include/generated/,$(obj))
 header-files  := $(notdir $(wildcard $(srcdir)/*.h))
-header-files  += $(notdir $(wildcard $(srcdir)/*.agh))
 header-files  := $(filter-out $(no-export-headers), $(header-files))
 genhdr-files  := $(notdir $(wildcard $(gendir)/*.h))
 genhdr-files  := $(filter-out $(header-files), $(genhdr-files))
-- 
2.7.4

Re: [PATCH 1/2] ARM: Remove '-p' from LDFLAGS

[Ard Biesheuvel]

On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor  wrote:
>
> This option is not supported by lld:
>
> ld.lld: error: unknown argument: -p
>
> This has been a no-op in binutils since 2004 (see commit dea514f51da1 in
> that tree). Given that the lowest officially supported of binutils for
> the kernel is 2.20, which was released in 2009, nobody needs this flag
> around so just remove it. Commit 1a381d4a0a9a ("arm64: remove no-op -p
> linker flag") did the same for arm64.
>
> Signed-off-by: Nathan Chancellor 

Acked-by: Ard Biesheuvel 

> ---
>  arch/arm/Makefile | 2 +-
>  arch/arm/boot/compressed/Makefile | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 05a91d8b89f3..e2a0baf36766 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -10,7 +10,7 @@
>  #
>  # Copyright (C) 1995-2001 by Russell King
>
> -LDFLAGS_vmlinux:=-p --no-undefined -X --pic-veneer
> +LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux+= --be8
>  KBUILD_LDFLAGS_MODULE  += --be8
> diff --git a/arch/arm/boot/compressed/Makefile 
> b/arch/arm/boot/compressed/Makefile
> index 1f5a5ffe7fcf..dcd07bd24b85 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -131,8 +131,6 @@ endif
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux += --be8
>  endif
> -# ?
> -LDFLAGS_vmlinux += -p
>  # Report unresolved symbol references
>  LDFLAGS_vmlinux += --no-undefined
>  # Delete all temporary local symbols
> --
> 2.20.0.rc1
>

[PATCH] kbuild: remove a special handling for *.agh in Makefile.headersinst

[Masahiro Yamada]

scripts/Makefile.headersinst takes care of *.agh just for

  arch/cris/include/uapi/arch-v10/arch/sv_addr.agh

because renaming exported headers is difficult (or impossible).

This code is no longer necessary thanks to commit c690eddc2f3b ("CRIS:
Drop support for the CRIS port").

Signed-off-by: Masahiro Yamada 
---

 scripts/Makefile.headersinst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 0d4a96d..3d1ebaa 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -44,7 +44,6 @@ kbuild-file := $(srctree)/$(obj)/Kbuild
 installdir:= $(INSTALL_HDR_PATH)/$(dst)
 gendir:= $(objtree)/$(subst include/,include/generated/,$(obj))
 header-files  := $(notdir $(wildcard $(srcdir)/*.h))
-header-files  += $(notdir $(wildcard $(srcdir)/*.agh))
 header-files  := $(filter-out $(no-export-headers), $(header-files))
 genhdr-files  := $(notdir $(wildcard $(gendir)/*.h))
 genhdr-files  := $(filter-out $(header-files), $(genhdr-files))
-- 
2.7.4

Re: [PATCH 1/2] ARM: Remove '-p' from LDFLAGS

[Ard Biesheuvel]

On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor  wrote:
>
> This option is not supported by lld:
>
> ld.lld: error: unknown argument: -p
>
> This has been a no-op in binutils since 2004 (see commit dea514f51da1 in
> that tree). Given that the lowest officially supported of binutils for
> the kernel is 2.20, which was released in 2009, nobody needs this flag
> around so just remove it. Commit 1a381d4a0a9a ("arm64: remove no-op -p
> linker flag") did the same for arm64.
>
> Signed-off-by: Nathan Chancellor 

Acked-by: Ard Biesheuvel 

> ---
>  arch/arm/Makefile | 2 +-
>  arch/arm/boot/compressed/Makefile | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 05a91d8b89f3..e2a0baf36766 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -10,7 +10,7 @@
>  #
>  # Copyright (C) 1995-2001 by Russell King
>
> -LDFLAGS_vmlinux:=-p --no-undefined -X --pic-veneer
> +LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux+= --be8
>  KBUILD_LDFLAGS_MODULE  += --be8
> diff --git a/arch/arm/boot/compressed/Makefile 
> b/arch/arm/boot/compressed/Makefile
> index 1f5a5ffe7fcf..dcd07bd24b85 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -131,8 +131,6 @@ endif
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux += --be8
>  endif
> -# ?
> -LDFLAGS_vmlinux += -p
>  # Report unresolved symbol references
>  LDFLAGS_vmlinux += --no-undefined
>  # Delete all temporary local symbols
> --
> 2.20.0.rc1
>

Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option

[Ard Biesheuvel]

On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor  wrote:
>
> This flag is not supported by lld:
>
> ld.lld: error: unknown argument: --pic-veneer
>
> Signed-off-by: Nathan Chancellor 

Hi Nate,

Does this mean ld.lld is guaranteed to produce position independent
veneers if you build kernels that are bigger than the typical range of
a relative branch?

> ---
>  arch/arm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index e2a0baf36766..4fab2aa29570 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -10,7 +10,7 @@
>  #
>  # Copyright (C) 1995-2001 by Russell King
>
> -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
> +LDFLAGS_vmlinux:= --no-undefined -X $(call ld-option,--pic-veneer)
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux+= --be8
>  KBUILD_LDFLAGS_MODULE  += --be8
> --
> 2.20.0.rc1
>

Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option

[Ard Biesheuvel]

On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor  wrote:
>
> This flag is not supported by lld:
>
> ld.lld: error: unknown argument: --pic-veneer
>
> Signed-off-by: Nathan Chancellor 

Hi Nate,

Does this mean ld.lld is guaranteed to produce position independent
veneers if you build kernels that are bigger than the typical range of
a relative branch?

> ---
>  arch/arm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index e2a0baf36766..4fab2aa29570 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -10,7 +10,7 @@
>  #
>  # Copyright (C) 1995-2001 by Russell King
>
> -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
> +LDFLAGS_vmlinux:= --no-undefined -X $(call ld-option,--pic-veneer)
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux+= --be8
>  KBUILD_LDFLAGS_MODULE  += --be8
> --
> 2.20.0.rc1
>

Re: [patch 1/2 for-4.20] mm, thp: restore node-local hugepage allocations

[Michal Hocko]

On Tue 04-12-18 13:56:30, David Rientjes wrote:
> On Tue, 4 Dec 2018, Michal Hocko wrote:
> 
> > > This is a full revert of ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
> > > MADV_HUGEPAGE mappings") and a partial revert of 89c83fb539f9 ("mm, thp:
> > > consolidate THP gfp handling into alloc_hugepage_direct_gfpmask").
> > > 
> > > By not setting __GFP_THISNODE, applications can allocate remote hugepages
> > > when the local node is fragmented or low on memory when either the thp
> > > defrag setting is "always" or the vma has been madvised with
> > > MADV_HUGEPAGE.
> > > 
> > > Remote access to hugepages often has much higher latency than local pages
> > > of the native page size.  On Haswell, ac5b2c18911f was shown to have a
> > > 13.9% access regression after this commit for binaries that remap their
> > > text segment to be backed by transparent hugepages.
> > > 
> > > The intent of ac5b2c18911f is to address an issue where a local node is
> > > low on memory or fragmented such that a hugepage cannot be allocated.  In
> > > every scenario where this was described as a fix, there is abundant and
> > > unfragmented remote memory available to allocate from, even with a greater
> > > access latency.
> > > 
> > > If remote memory is also low or fragmented, not setting __GFP_THISNODE was
> > > also measured on Haswell to have a 40% regression in allocation latency.
> > > 
> > > Restore __GFP_THISNODE for thp allocations.
> > > 
> > > Fixes: ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE 
> > > mappings")
> > > Fixes: 89c83fb539f9 ("mm, thp: consolidate THP gfp handling into 
> > > alloc_hugepage_direct_gfpmask")
> > 
> > At minimum do not remove the cleanup part which consolidates the gfp
> > hadnling to a single place. There is no real reason to have the
> > __GFP_THISNODE ugliness outside of alloc_hugepage_direct_gfpmask.
> > 
> 
> The __GFP_THISNODE usage is still confined to 
> alloc_hugepage_direct_gfpmask() for the thp fault path, we no longer set 
> it in alloc_pages_vma() as done before the cleanup.

Why should be new_page any different?

-- 
Michal Hocko
SUSE Labs

Re: [patch 1/2 for-4.20] mm, thp: restore node-local hugepage allocations

[Michal Hocko]

On Tue 04-12-18 13:56:30, David Rientjes wrote:
> On Tue, 4 Dec 2018, Michal Hocko wrote:
> 
> > > This is a full revert of ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
> > > MADV_HUGEPAGE mappings") and a partial revert of 89c83fb539f9 ("mm, thp:
> > > consolidate THP gfp handling into alloc_hugepage_direct_gfpmask").
> > > 
> > > By not setting __GFP_THISNODE, applications can allocate remote hugepages
> > > when the local node is fragmented or low on memory when either the thp
> > > defrag setting is "always" or the vma has been madvised with
> > > MADV_HUGEPAGE.
> > > 
> > > Remote access to hugepages often has much higher latency than local pages
> > > of the native page size.  On Haswell, ac5b2c18911f was shown to have a
> > > 13.9% access regression after this commit for binaries that remap their
> > > text segment to be backed by transparent hugepages.
> > > 
> > > The intent of ac5b2c18911f is to address an issue where a local node is
> > > low on memory or fragmented such that a hugepage cannot be allocated.  In
> > > every scenario where this was described as a fix, there is abundant and
> > > unfragmented remote memory available to allocate from, even with a greater
> > > access latency.
> > > 
> > > If remote memory is also low or fragmented, not setting __GFP_THISNODE was
> > > also measured on Haswell to have a 40% regression in allocation latency.
> > > 
> > > Restore __GFP_THISNODE for thp allocations.
> > > 
> > > Fixes: ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE 
> > > mappings")
> > > Fixes: 89c83fb539f9 ("mm, thp: consolidate THP gfp handling into 
> > > alloc_hugepage_direct_gfpmask")
> > 
> > At minimum do not remove the cleanup part which consolidates the gfp
> > hadnling to a single place. There is no real reason to have the
> > __GFP_THISNODE ugliness outside of alloc_hugepage_direct_gfpmask.
> > 
> 
> The __GFP_THISNODE usage is still confined to 
> alloc_hugepage_direct_gfpmask() for the thp fault path, we no longer set 
> it in alloc_pages_vma() as done before the cleanup.

Why should be new_page any different?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v4 0/7] lib/lzo: performance improvements

[Sergey Senozhatsky]

On (11/30/18 14:26), Dave Rodgman wrote:
> 
> This patch series introduces performance improvements for lzo.
> 
> The previous version of this patchset is here:
> https://lkml.org/lkml/2018/11/30/807
> 
> This version of the patchset fixes a maybe-used-uninitialized warning
> (although the previous version was still safe).

Hi Dave,

Notices this warning today:

lib/lzo/lzo1x_compress.c: In function ‘lzo1x_1_do_compress’:
lib/lzo/lzo1x_compress.c:239:14: warning: ‘m_pos’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
239 |   m_off = ip - m_pos;

Care to take a look? (could be false positive)

-ss

Re: [PATCH v4 0/7] lib/lzo: performance improvements

[Sergey Senozhatsky]

On (11/30/18 14:26), Dave Rodgman wrote:
> 
> This patch series introduces performance improvements for lzo.
> 
> The previous version of this patchset is here:
> https://lkml.org/lkml/2018/11/30/807
> 
> This version of the patchset fixes a maybe-used-uninitialized warning
> (although the previous version was still safe).

Hi Dave,

Notices this warning today:

lib/lzo/lzo1x_compress.c: In function ‘lzo1x_1_do_compress’:
lib/lzo/lzo1x_compress.c:239:14: warning: ‘m_pos’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
239 |   m_off = ip - m_pos;

Care to take a look? (could be false positive)

-ss

Re: > [PATCH] Security: Handle hidepid option correctly

[程洋]

Anyone who can review my patch?

程洋  于2018年11月30日周五 上午10:34写道：
>
> Here is an article illustrates the details.
> https://medium.com/@topjohnwu/from-anime-game-to-android-system-security-vulnerability-9b955a182f20
>
> And There is a similar fix on kernel-4.4:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99663be772c827b8f5f594fe87eb4807be1994e5
>
> Q: Other filesystems parse the options from fill_super().  Is proc special in 
> some fashion?
> A: According to my research, start_kernel will call proc_mount first, and 
> initialize sb->s_root before any userspace process runs. If others want to 
> mount it, all options will be ignored.
>  AOSP change here: 
> https://android-review.googlesource.com/c/platform/system/core/+/181345/4/init/init.cpp
>  At first I though we should mount it with MS_REMOUNT flag. But kernel 
> will crash if we did this.
>
> Q:  Why is this considered to be security sensitive?  I can guess, but I'd 
> like to know your reasoning.
> A: See the article above. It's part of Android sanbox.
>
>
> > [PATCH] Security: Handle hidepid option correctly
>
> Why is this considered to be security sensitive?  I can guess, but I'd like 
> to know your reasoning.
>
> On Thu, 29 Nov 2018 19:08:21 +0800 mailto:d17103...@gmail.com wrote:
>
> > From: Cheng Yang 
> >
> > The proc_parse_options() call from proc_mount() runs only once at boot
> > time.  So on any later mount attempt, any mount options are ignored
> > because ->s_root is already initialized.
> > As a consequence, "mount -o " will ignore the options.  The
> > only way to change mount options is "mount -o remount,".
> > To fix this, parse the mount options unconditionally.
> >
> > --- a/fs/proc/inode.c
> > +++ b/fs/proc/inode.c
> > @@ -493,13 +493,9 @@ struct inode *proc_get_inode(struct super_block
> > *sb, struct proc_dir_entry *de)
> >
> >  int proc_fill_super(struct super_block *s, void *data, int silent)  {
> > -struct pid_namespace *ns = get_pid_ns(s->s_fs_info);
> >  struct inode *root_inode;
> >  int ret;
> >
> > -if (!proc_parse_options(data, ns))
> > -return -EINVAL;
> > -
> >  /* User space would break if executables or devices appear on proc */
> >  s->s_iflags |= SB_I_USERNS_VISIBLE | SB_I_NOEXEC | SB_I_NODEV;
> >  s->s_flags |= SB_NODIRATIME | SB_NOSUID | SB_NOEXEC; diff --git
> > a/fs/proc/root.c b/fs/proc/root.c index f4b1a9d..f5f3bf3 100644
> > --- a/fs/proc/root.c
> > +++ b/fs/proc/root.c
> > @@ -98,6 +98,9 @@ static struct dentry *proc_mount(struct file_system_type 
> > *fs_type,
> >  ns = task_active_pid_ns(current);
> >  }
> >
> > +if (!proc_parse_options(data, ns))
> > +return ERR_PTR(-EINVAL);
> > +
> >  return mount_ns(fs_type, flags, data, ns, ns->user_ns,
> > proc_fill_super);  }
>
> Other filesystems parse the options from fill_super().  Is proc special in 
> some fashion?
>
> #/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
>  This e-mail and its attachments contain confidential information from 
> XIAOMI, which is intended only for the person or entity whose address is 
> listed above. Any use of the information contained herein in any way 
> (including, but not limited to, total or partial disclosure, reproduction, or 
> dissemination) by persons other than the intended recipient(s) is prohibited. 
> If you receive this e-mail in error, please notify the sender by phone or 
> email immediately and delete it!**/#

Re: > [PATCH] Security: Handle hidepid option correctly

[程洋]

Anyone who can review my patch?

程洋  于2018年11月30日周五 上午10:34写道：
>
> Here is an article illustrates the details.
> https://medium.com/@topjohnwu/from-anime-game-to-android-system-security-vulnerability-9b955a182f20
>
> And There is a similar fix on kernel-4.4:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99663be772c827b8f5f594fe87eb4807be1994e5
>
> Q: Other filesystems parse the options from fill_super().  Is proc special in 
> some fashion?
> A: According to my research, start_kernel will call proc_mount first, and 
> initialize sb->s_root before any userspace process runs. If others want to 
> mount it, all options will be ignored.
>  AOSP change here: 
> https://android-review.googlesource.com/c/platform/system/core/+/181345/4/init/init.cpp
>  At first I though we should mount it with MS_REMOUNT flag. But kernel 
> will crash if we did this.
>
> Q:  Why is this considered to be security sensitive?  I can guess, but I'd 
> like to know your reasoning.
> A: See the article above. It's part of Android sanbox.
>
>
> > [PATCH] Security: Handle hidepid option correctly
>
> Why is this considered to be security sensitive?  I can guess, but I'd like 
> to know your reasoning.
>
> On Thu, 29 Nov 2018 19:08:21 +0800 mailto:d17103...@gmail.com wrote:
>
> > From: Cheng Yang 
> >
> > The proc_parse_options() call from proc_mount() runs only once at boot
> > time.  So on any later mount attempt, any mount options are ignored
> > because ->s_root is already initialized.
> > As a consequence, "mount -o " will ignore the options.  The
> > only way to change mount options is "mount -o remount,".
> > To fix this, parse the mount options unconditionally.
> >
> > --- a/fs/proc/inode.c
> > +++ b/fs/proc/inode.c
> > @@ -493,13 +493,9 @@ struct inode *proc_get_inode(struct super_block
> > *sb, struct proc_dir_entry *de)
> >
> >  int proc_fill_super(struct super_block *s, void *data, int silent)  {
> > -struct pid_namespace *ns = get_pid_ns(s->s_fs_info);
> >  struct inode *root_inode;
> >  int ret;
> >
> > -if (!proc_parse_options(data, ns))
> > -return -EINVAL;
> > -
> >  /* User space would break if executables or devices appear on proc */
> >  s->s_iflags |= SB_I_USERNS_VISIBLE | SB_I_NOEXEC | SB_I_NODEV;
> >  s->s_flags |= SB_NODIRATIME | SB_NOSUID | SB_NOEXEC; diff --git
> > a/fs/proc/root.c b/fs/proc/root.c index f4b1a9d..f5f3bf3 100644
> > --- a/fs/proc/root.c
> > +++ b/fs/proc/root.c
> > @@ -98,6 +98,9 @@ static struct dentry *proc_mount(struct file_system_type 
> > *fs_type,
> >  ns = task_active_pid_ns(current);
> >  }
> >
> > +if (!proc_parse_options(data, ns))
> > +return ERR_PTR(-EINVAL);
> > +
> >  return mount_ns(fs_type, flags, data, ns, ns->user_ns,
> > proc_fill_super);  }
>
> Other filesystems parse the options from fill_super().  Is proc special in 
> some fashion?
>
> #/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
>  This e-mail and its attachments contain confidential information from 
> XIAOMI, which is intended only for the person or entity whose address is 
> listed above. Any use of the information contained herein in any way 
> (including, but not limited to, total or partial disclosure, reproduction, or 
> dissemination) by persons other than the intended recipient(s) is prohibited. 
> If you receive this e-mail in error, please notify the sender by phone or 
> email immediately and delete it!**/#

Re: [PATCH v3 2/8] mfd / platform: cros_ec: move lightbar attributes to its own driver.

[Lee Jones]

On Tue, 04 Dec 2018, Enric Balletbo i Serra wrote:
> On 4/12/18 10:21, Lee Jones wrote:
> > On Mon, 03 Dec 2018, Enric Balletbo i Serra wrote:
> >> On 3/12/18 11:36, Lee Jones wrote:
> >>> On Tue, 27 Nov 2018, Enric Balletbo i Serra wrote:
> >>>
>  The entire way how cros sysfs attibutes are created is broken.
>  cros_ec_lightbar should be its own driver and its attributes should be
>  associated with a lightbar driver not the mfd driver. In order to retain
>  the path, the lightbar attributes are attached to the cros_class.
> >>>
> >>> I'm not exactly clear on what a lightbar is, but shouldn't it live in
> >>> the appropriate subsystem.  Like LED for example?
> >>>
> >>
> >> The lightbar is a four-color indicator available on some Chromebook, but 
> >> the
> >> fact that can you can program this lightbar with different sequences, 
> >> including
> >> user defined sequences makes the device a bit special and very chrome 
> >> platform
> >> specific. The same happens with the VBC driver.
> > 
> > Being Chrome specific doesn't necessarily mean that these drivers
> > shouldn't reside in a proper subsystem.  A lot of drivers in the
> > kernel are only relevant to very specific hardware/platforms.
> 
> Agree, and we try to put these drivers in their subsystem when we think it is
> appropriate (we have in rtc, power, iio, keyboard, etc.)

Right.  I can see that.  This is good.

> > IMHO code in drivers/platform should pertain only to the core platform
> > itself.  Any drivers for leaf hardware/functionality should be split
> > out into the subsystems, however niche you think they are.
> 
> To be honest, I don't have a hard opinion yet on if the drivers/platform 
> should
> pertain only to the core platform itself.
> 
> The cros_ec_lightbar.c file already exists in drivers/platform, the patch just
> converts it to a kernel module (only adds few lines). The main purpose of the 
> se
> patches was have cros-ec mfd code and their subdrivers separated instead of
> having crossed calls.

Right.  I have no intention of blocking *this* patch.  All we're doing
here is highlighting potential issues I see.

> I don't mind to move to another subsystem (I need to discuss with the chromium
> guys

Wonderful.  That's exactly what I wanted to hear.

> and I am still not sure if LED fits very well in this case, I can look in
> more detail)

Sure.

> but shouldn't be this a follow up patch?

Absolutely.

> I am also worried on how this could affect the current user interface. Well,
> something to look, right.

Right.

Thanks again for looking into this.  I will re-review your patch, this
time *not* taking the location of the driver into consideration.

> > I also understand the convenience factor of not having to go through
> > a !Google Maintainer, but this is not a loophole I'm prepared to
> > support. ;)
> > 
> >> Other subdevices like, rtc, keyboard, usbpd charger,etc. are already in 
> >> their
> >> subsystems.
> >>
>  The patch also adds the sysfs documentation.
> 
>  Signed-off-by: Enric Balletbo i Serra 
>  ---
> 
>  Changes in v3:
>  - Removed unneded check for ec_dev.
> 
>  Changes in v2:
>  - Removed the two exported functions to attach/detach to the cros_class.
>  - Use dev_warn instead of dev_err when adding the lightbar.
> 
>   ...sfs-class-chromeos-driver-cros-ec-lightbar | 74 +++
>   drivers/mfd/cros_ec_dev.c | 24 ++---
>   drivers/mfd/cros_ec_dev.h |  6 --
>   drivers/platform/chrome/Kconfig   | 10 ++
>   drivers/platform/chrome/Makefile  |  3 +-
>   drivers/platform/chrome/cros_ec_lightbar.c| 95 ++-
>   include/linux/mfd/cros_ec.h   |  1 -
>   7 files changed, 172 insertions(+), 41 deletions(-)
>   create mode 100644 
>  Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar
> >>>
> > 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v3 2/8] mfd / platform: cros_ec: move lightbar attributes to its own driver.

[Lee Jones]

On Tue, 04 Dec 2018, Enric Balletbo i Serra wrote:
> On 4/12/18 10:21, Lee Jones wrote:
> > On Mon, 03 Dec 2018, Enric Balletbo i Serra wrote:
> >> On 3/12/18 11:36, Lee Jones wrote:
> >>> On Tue, 27 Nov 2018, Enric Balletbo i Serra wrote:
> >>>
>  The entire way how cros sysfs attibutes are created is broken.
>  cros_ec_lightbar should be its own driver and its attributes should be
>  associated with a lightbar driver not the mfd driver. In order to retain
>  the path, the lightbar attributes are attached to the cros_class.
> >>>
> >>> I'm not exactly clear on what a lightbar is, but shouldn't it live in
> >>> the appropriate subsystem.  Like LED for example?
> >>>
> >>
> >> The lightbar is a four-color indicator available on some Chromebook, but 
> >> the
> >> fact that can you can program this lightbar with different sequences, 
> >> including
> >> user defined sequences makes the device a bit special and very chrome 
> >> platform
> >> specific. The same happens with the VBC driver.
> > 
> > Being Chrome specific doesn't necessarily mean that these drivers
> > shouldn't reside in a proper subsystem.  A lot of drivers in the
> > kernel are only relevant to very specific hardware/platforms.
> 
> Agree, and we try to put these drivers in their subsystem when we think it is
> appropriate (we have in rtc, power, iio, keyboard, etc.)

Right.  I can see that.  This is good.

> > IMHO code in drivers/platform should pertain only to the core platform
> > itself.  Any drivers for leaf hardware/functionality should be split
> > out into the subsystems, however niche you think they are.
> 
> To be honest, I don't have a hard opinion yet on if the drivers/platform 
> should
> pertain only to the core platform itself.
> 
> The cros_ec_lightbar.c file already exists in drivers/platform, the patch just
> converts it to a kernel module (only adds few lines). The main purpose of the 
> se
> patches was have cros-ec mfd code and their subdrivers separated instead of
> having crossed calls.

Right.  I have no intention of blocking *this* patch.  All we're doing
here is highlighting potential issues I see.

> I don't mind to move to another subsystem (I need to discuss with the chromium
> guys

Wonderful.  That's exactly what I wanted to hear.

> and I am still not sure if LED fits very well in this case, I can look in
> more detail)

Sure.

> but shouldn't be this a follow up patch?

Absolutely.

> I am also worried on how this could affect the current user interface. Well,
> something to look, right.

Right.

Thanks again for looking into this.  I will re-review your patch, this
time *not* taking the location of the driver into consideration.

> > I also understand the convenience factor of not having to go through
> > a !Google Maintainer, but this is not a loophole I'm prepared to
> > support. ;)
> > 
> >> Other subdevices like, rtc, keyboard, usbpd charger,etc. are already in 
> >> their
> >> subsystems.
> >>
>  The patch also adds the sysfs documentation.
> 
>  Signed-off-by: Enric Balletbo i Serra 
>  ---
> 
>  Changes in v3:
>  - Removed unneded check for ec_dev.
> 
>  Changes in v2:
>  - Removed the two exported functions to attach/detach to the cros_class.
>  - Use dev_warn instead of dev_err when adding the lightbar.
> 
>   ...sfs-class-chromeos-driver-cros-ec-lightbar | 74 +++
>   drivers/mfd/cros_ec_dev.c | 24 ++---
>   drivers/mfd/cros_ec_dev.h |  6 --
>   drivers/platform/chrome/Kconfig   | 10 ++
>   drivers/platform/chrome/Makefile  |  3 +-
>   drivers/platform/chrome/cros_ec_lightbar.c| 95 ++-
>   include/linux/mfd/cros_ec.h   |  1 -
>   7 files changed, 172 insertions(+), 41 deletions(-)
>   create mode 100644 
>  Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar
> >>>
> > 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] clk: socfpga: Don't have get_parent for single parent ops

[Stephen Boyd]

(Adding Dinh's korg email)

I also wonder if this driver is even used anymore or maybe we can delete
it?

Quoting Stephen Boyd (2018-12-04 11:34:16)
> This driver creates a gate clk with the possibility to have multiple
> parents. That can cause problems if the common clk framework tries to
> call the get_parent() op and gets back a number that's larger than the
> number of parents the clk says it supports in
> clk_init_data::num_parents. Let's duplicate the clk_ops structure each
> time this function is called and drop the get/set parent ops when there
> is only one parent. This allows the framework to consider a number
> larger than clk_init_data::num_parents as an error condition of the
> get_parent() clk op, clearing the way for proper code.
> 
> Cc: Jerome Brunet 
> Cc: Masahiro Yamada 
> Cc: Dinh Nguyen 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/clk/socfpga/clk-gate.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
> index aa7a6e6a15b6..73e03328d5c5 100644
> --- a/drivers/clk/socfpga/clk-gate.c
> +++ b/drivers/clk/socfpga/clk-gate.c
> @@ -176,8 +176,7 @@ static struct clk_ops gateclk_ops = {
> .set_parent = socfpga_clk_set_parent,
>  };
>  
> -static void __init __socfpga_gate_init(struct device_node *node,
> -   const struct clk_ops *ops)
> +void __init socfpga_gate_init(struct device_node *node)
>  {
> u32 clk_gate[2];
> u32 div_reg[3];
> @@ -188,12 +187,17 @@ static void __init __socfpga_gate_init(struct 
> device_node *node,
> const char *clk_name = node->name;
> const char *parent_name[SOCFPGA_MAX_PARENTS];
> struct clk_init_data init;
> +   struct clk_ops *ops;
> int rc;
>  
> socfpga_clk = kzalloc(sizeof(*socfpga_clk), GFP_KERNEL);
> if (WARN_ON(!socfpga_clk))
> return;
>  
> +   ops = kmemdup(_ops, sizeof(gateclk_ops), GFP_KERNEL);
> +   if (WARN_ON(!ops))
> +   return;
> +
> rc = of_property_read_u32_array(node, "clk-gate", clk_gate, 2);
> if (rc)
> clk_gate[0] = 0;
> @@ -202,8 +206,8 @@ static void __init __socfpga_gate_init(struct device_node 
> *node,
> socfpga_clk->hw.reg = clk_mgr_base_addr + clk_gate[0];
> socfpga_clk->hw.bit_idx = clk_gate[1];
>  
> -   gateclk_ops.enable = clk_gate_ops.enable;
> -   gateclk_ops.disable = clk_gate_ops.disable;
> +   ops->enable = clk_gate_ops.enable;
> +   ops->disable = clk_gate_ops.disable;
> }
>  
> rc = of_property_read_u32(node, "fixed-divider", _div);
> @@ -234,6 +238,11 @@ static void __init __socfpga_gate_init(struct 
> device_node *node,
> init.flags = 0;
>  
> init.num_parents = of_clk_parent_fill(node, parent_name, 
> SOCFPGA_MAX_PARENTS);
> +   if (init.num_parents < 2) {
> +   ops->get_parent = NULL;
> +   ops->set_parent = NULL;
> +   }
> +
> init.parent_names = parent_name;
> socfpga_clk->hw.hw.init = 
>  
> @@ -246,8 +255,3 @@ static void __init __socfpga_gate_init(struct device_node 
> *node,
> if (WARN_ON(rc))
> return;
>  }
> -
> -void __init socfpga_gate_init(struct device_node *node)
> -{
> -   __socfpga_gate_init(node, _ops);
> -}

Re: [PATCH] clk: socfpga: Don't have get_parent for single parent ops

[Stephen Boyd]

(Adding Dinh's korg email)

I also wonder if this driver is even used anymore or maybe we can delete
it?

Quoting Stephen Boyd (2018-12-04 11:34:16)
> This driver creates a gate clk with the possibility to have multiple
> parents. That can cause problems if the common clk framework tries to
> call the get_parent() op and gets back a number that's larger than the
> number of parents the clk says it supports in
> clk_init_data::num_parents. Let's duplicate the clk_ops structure each
> time this function is called and drop the get/set parent ops when there
> is only one parent. This allows the framework to consider a number
> larger than clk_init_data::num_parents as an error condition of the
> get_parent() clk op, clearing the way for proper code.
> 
> Cc: Jerome Brunet 
> Cc: Masahiro Yamada 
> Cc: Dinh Nguyen 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/clk/socfpga/clk-gate.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
> index aa7a6e6a15b6..73e03328d5c5 100644
> --- a/drivers/clk/socfpga/clk-gate.c
> +++ b/drivers/clk/socfpga/clk-gate.c
> @@ -176,8 +176,7 @@ static struct clk_ops gateclk_ops = {
> .set_parent = socfpga_clk_set_parent,
>  };
>  
> -static void __init __socfpga_gate_init(struct device_node *node,
> -   const struct clk_ops *ops)
> +void __init socfpga_gate_init(struct device_node *node)
>  {
> u32 clk_gate[2];
> u32 div_reg[3];
> @@ -188,12 +187,17 @@ static void __init __socfpga_gate_init(struct 
> device_node *node,
> const char *clk_name = node->name;
> const char *parent_name[SOCFPGA_MAX_PARENTS];
> struct clk_init_data init;
> +   struct clk_ops *ops;
> int rc;
>  
> socfpga_clk = kzalloc(sizeof(*socfpga_clk), GFP_KERNEL);
> if (WARN_ON(!socfpga_clk))
> return;
>  
> +   ops = kmemdup(_ops, sizeof(gateclk_ops), GFP_KERNEL);
> +   if (WARN_ON(!ops))
> +   return;
> +
> rc = of_property_read_u32_array(node, "clk-gate", clk_gate, 2);
> if (rc)
> clk_gate[0] = 0;
> @@ -202,8 +206,8 @@ static void __init __socfpga_gate_init(struct device_node 
> *node,
> socfpga_clk->hw.reg = clk_mgr_base_addr + clk_gate[0];
> socfpga_clk->hw.bit_idx = clk_gate[1];
>  
> -   gateclk_ops.enable = clk_gate_ops.enable;
> -   gateclk_ops.disable = clk_gate_ops.disable;
> +   ops->enable = clk_gate_ops.enable;
> +   ops->disable = clk_gate_ops.disable;
> }
>  
> rc = of_property_read_u32(node, "fixed-divider", _div);
> @@ -234,6 +238,11 @@ static void __init __socfpga_gate_init(struct 
> device_node *node,
> init.flags = 0;
>  
> init.num_parents = of_clk_parent_fill(node, parent_name, 
> SOCFPGA_MAX_PARENTS);
> +   if (init.num_parents < 2) {
> +   ops->get_parent = NULL;
> +   ops->set_parent = NULL;
> +   }
> +
> init.parent_names = parent_name;
> socfpga_clk->hw.hw.init = 
>  
> @@ -246,8 +255,3 @@ static void __init __socfpga_gate_init(struct device_node 
> *node,
> if (WARN_ON(rc))
> return;
>  }
> -
> -void __init socfpga_gate_init(struct device_node *node)
> -{
> -   __socfpga_gate_init(node, _ops);
> -}

Re: [PATCH] fanotify: Make sure to check event_len when copying

[Amir Goldstein]

On Wed, Dec 5, 2018 at 1:44 AM Kees Cook  wrote:
>
> As a precaution, make sure we check event_len when copying to userspace.
> Based on old feedback: https://lkml.kernel.org/r/542d9fe5.3010...@gmx.de
>

This precaution serves the new fanotify_event_info_fid format well:
https://marc.info/?l=linux-fsdevel=154375073318106=2
but also conflicts with my series.

I can weave your patch into my series and add a similar sanity check in
copy_fid_to_user() or if Jan applies your patch and has more comments
on my v4 series, I'll rebase on top of that.

Thanks,
Amir.

> Signed-off-by: Kees Cook 
> ---
>  fs/notify/fanotify/fanotify_user.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify_user.c 
> b/fs/notify/fanotify/fanotify_user.c
> index e03be5071362..d9484a0ac6b3 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -206,7 +206,7 @@ static int process_access_response(struct fsnotify_group 
> *group,
>
>  static ssize_t copy_event_to_user(struct fsnotify_group *group,
>   struct fsnotify_event *event,
> - char __user *buf)
> + char __user *buf, size_t count)
>  {
> struct fanotify_event_metadata fanotify_event_metadata;
> struct file *f;
> @@ -220,6 +220,12 @@ static ssize_t copy_event_to_user(struct fsnotify_group 
> *group,
>
> fd = fanotify_event_metadata.fd;
> ret = -EFAULT;
> +   /*
> +* Sanity check copy size in case get_one_event() and
> +* fill_event_metadata() event_len sizes ever get out of sync.
> +*/
> +   if (WARN_ON_ONCE(fanotify_event_metadata.event_len > count))
> +   goto out_close_fd;
> if (copy_to_user(buf, _event_metadata,
>  fanotify_event_metadata.event_len))
> goto out_close_fd;
> @@ -295,7 +301,7 @@ static ssize_t fanotify_read(struct file *file, char 
> __user *buf,
> continue;
> }
>
> -   ret = copy_event_to_user(group, kevent, buf);
> +   ret = copy_event_to_user(group, kevent, buf, count);
> if (unlikely(ret == -EOPENSTALE)) {
> /*
>  * We cannot report events with stale fd so drop it.
> --
> 2.17.1
>
>
> --
> Kees Cook

Re: [PATCH] fanotify: Make sure to check event_len when copying

[Amir Goldstein]

On Wed, Dec 5, 2018 at 1:44 AM Kees Cook  wrote:
>
> As a precaution, make sure we check event_len when copying to userspace.
> Based on old feedback: https://lkml.kernel.org/r/542d9fe5.3010...@gmx.de
>

This precaution serves the new fanotify_event_info_fid format well:
https://marc.info/?l=linux-fsdevel=154375073318106=2
but also conflicts with my series.

I can weave your patch into my series and add a similar sanity check in
copy_fid_to_user() or if Jan applies your patch and has more comments
on my v4 series, I'll rebase on top of that.

Thanks,
Amir.

> Signed-off-by: Kees Cook 
> ---
>  fs/notify/fanotify/fanotify_user.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify_user.c 
> b/fs/notify/fanotify/fanotify_user.c
> index e03be5071362..d9484a0ac6b3 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -206,7 +206,7 @@ static int process_access_response(struct fsnotify_group 
> *group,
>
>  static ssize_t copy_event_to_user(struct fsnotify_group *group,
>   struct fsnotify_event *event,
> - char __user *buf)
> + char __user *buf, size_t count)
>  {
> struct fanotify_event_metadata fanotify_event_metadata;
> struct file *f;
> @@ -220,6 +220,12 @@ static ssize_t copy_event_to_user(struct fsnotify_group 
> *group,
>
> fd = fanotify_event_metadata.fd;
> ret = -EFAULT;
> +   /*
> +* Sanity check copy size in case get_one_event() and
> +* fill_event_metadata() event_len sizes ever get out of sync.
> +*/
> +   if (WARN_ON_ONCE(fanotify_event_metadata.event_len > count))
> +   goto out_close_fd;
> if (copy_to_user(buf, _event_metadata,
>  fanotify_event_metadata.event_len))
> goto out_close_fd;
> @@ -295,7 +301,7 @@ static ssize_t fanotify_read(struct file *file, char 
> __user *buf,
> continue;
> }
>
> -   ret = copy_event_to_user(group, kevent, buf);
> +   ret = copy_event_to_user(group, kevent, buf, count);
> if (unlikely(ret == -EOPENSTALE)) {
> /*
>  * We cannot report events with stale fd so drop it.
> --
> 2.17.1
>
>
> --
> Kees Cook

Re: [RFC PATCH] clk: qcom: clk-rpmh: Add IPA clock support

[Stephen Boyd]

Quoting David Dai (2018-12-04 17:14:10)
> 
> On 12/4/2018 2:34 PM, Stephen Boyd wrote:
> > Quoting Alex Elder (2018-12-04 13:41:47)
> >> On 12/4/18 1:24 PM, Stephen Boyd wrote:
> >>> Quoting David Dai (2018-12-03 19:50:13)
>  Add IPA clock support by extending the current clk rpmh driver to support
>  clocks that are managed by a different type of RPMh resource known as
>  Bus Clock Manager(BCM).
> >>> Yes, but why? Does the IPA driver need to set clk rates and that somehow
> >>> doesn't work as a bandwidth request?
> >> The IPA core clock is a *clock*, not a bus.  Representing it as if
> >> it were a bus, abusing the interconnect interface--pretending a bandwidth
> >> request is really a clock rate request--is kind of kludgy.  I think Bjorn
> >> and David (and maybe Georgi? I don't know) decided a long time ago that
> >> exposing this as a clock is the right way to do it.  I agree with that.
> >>
> > But then we translate that clock rate into a bandwidth request to the
> > BCM hardware? Seems really weird because it's doing the opposite of what
> > you say is abusive. What does the IPA driver plan to do with this clk?
> > Calculate a frequency by knowing that it really boils down to some
> > bandwidth that then gets converted back into some clock frequency? Do we
> > have the user somewhere that can be pointed to?
> The clock rate is translated into a unitless threshold value sent as 
> part of the rpmh msg
> that BCM takes to select a performance. In this case, the unit 
> conversion is based on
> the unit value read from the aux data which is in Khz. I understand that 
> this wasn't
> explicitly mentioned anywhere and I'll improve on that next patch. 

How is this different from bus bandwidth requests? In those cases the
bandwidth is calculated in bits per second or something like that, and
written to the hardware so it can convert that bandwidth into kHz and
set a bus clk frequency in the clock controller? So in the IPA case
we've skipped the bps to kHz conversion step and gone straight to the
clk frequency setting part? Is a BCM able to aggregate units of
bandwidth or kHz depending on how it's configured and this BCM is
configured for kHz?

> Here's a link to
> the IPA driver implementation: https://lkml.org/lkml/2018/11/7/220

Thanks for the link. It looks like the IPA driver hard codes a rate of
75 MHz.

Re: [RFC PATCH] clk: qcom: clk-rpmh: Add IPA clock support

[Stephen Boyd]

Quoting David Dai (2018-12-04 17:14:10)
> 
> On 12/4/2018 2:34 PM, Stephen Boyd wrote:
> > Quoting Alex Elder (2018-12-04 13:41:47)
> >> On 12/4/18 1:24 PM, Stephen Boyd wrote:
> >>> Quoting David Dai (2018-12-03 19:50:13)
>  Add IPA clock support by extending the current clk rpmh driver to support
>  clocks that are managed by a different type of RPMh resource known as
>  Bus Clock Manager(BCM).
> >>> Yes, but why? Does the IPA driver need to set clk rates and that somehow
> >>> doesn't work as a bandwidth request?
> >> The IPA core clock is a *clock*, not a bus.  Representing it as if
> >> it were a bus, abusing the interconnect interface--pretending a bandwidth
> >> request is really a clock rate request--is kind of kludgy.  I think Bjorn
> >> and David (and maybe Georgi? I don't know) decided a long time ago that
> >> exposing this as a clock is the right way to do it.  I agree with that.
> >>
> > But then we translate that clock rate into a bandwidth request to the
> > BCM hardware? Seems really weird because it's doing the opposite of what
> > you say is abusive. What does the IPA driver plan to do with this clk?
> > Calculate a frequency by knowing that it really boils down to some
> > bandwidth that then gets converted back into some clock frequency? Do we
> > have the user somewhere that can be pointed to?
> The clock rate is translated into a unitless threshold value sent as 
> part of the rpmh msg
> that BCM takes to select a performance. In this case, the unit 
> conversion is based on
> the unit value read from the aux data which is in Khz. I understand that 
> this wasn't
> explicitly mentioned anywhere and I'll improve on that next patch. 

How is this different from bus bandwidth requests? In those cases the
bandwidth is calculated in bits per second or something like that, and
written to the hardware so it can convert that bandwidth into kHz and
set a bus clk frequency in the clock controller? So in the IPA case
we've skipped the bps to kHz conversion step and gone straight to the
clk frequency setting part? Is a BCM able to aggregate units of
bandwidth or kHz depending on how it's configured and this BCM is
configured for kHz?

> Here's a link to
> the IPA driver implementation: https://lkml.org/lkml/2018/11/7/220

Thanks for the link. It looks like the IPA driver hard codes a rate of
75 MHz.

Re: [PATCH v2] x86/build: fix compiler support check for CONFIG_RETPOLINE

[Zhenzhong Duan]

On 2018/12/5 14:27, Masahiro Yamada wrote:

It is troublesome to add a diagnostic like this to the Makefile
parse stage because the top-level Makefile could be parsed with
a stale include/config/auto.conf.

Once you are hit by the error about non-retpoline compiler, the
compilation still breaks even after disabling CONFIG_RETPOLINE.

The easiest fix is to move this check to the "archprepare" like commit
829fe4aa9ac1 ("x86: Allow generating user-space headers without a
compiler") did.

Link: https://lkml.org/lkml/2018/12/4/206
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler 
support")
Reported-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
   - Revive ifdef CONFIG_RETPOLINE surrounding the KBUILD_CFLAGS addition
   - Rephase the commit log a bit, hoping the cause of the issue will be clearer

  arch/x86/Makefile | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f5d7f41..75ef499 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,9 +220,6 @@ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
  
  # Avoid indirect branches in kernel to deal with Spectre

  ifdef CONFIG_RETPOLINE
-ifeq ($(RETPOLINE_CFLAGS),)
-  $(error You are building kernel with non-retpoline compiler, please update 
your compiler.)
-endif
KBUILD_CFLAGS += $(RETPOLINE_CFLAGS)
  endif
  
@@ -307,6 +304,13 @@ ifndef CC_HAVE_ASM_GOTO

@echo Compiler lacks asm-goto support.
@exit 1
  endif
+ifdef CONFIG_RETPOLINE
+ifeq ($(RETPOLINE_CFLAGS),)
+   @echo "You are building kernel with non-retpoline compiler." >&2
+   @echo "Please update your compiler." >&2
+   @false
+endif
+endif
  
  archclean:

$(Q)rm -rf $(objtree)/arch/i386

Acked-by: Zhenzhong Duan 

--
Regards
Zhenzhong

Re: [PATCH v2] x86/build: fix compiler support check for CONFIG_RETPOLINE

[Zhenzhong Duan]

On 2018/12/5 14:27, Masahiro Yamada wrote:

It is troublesome to add a diagnostic like this to the Makefile
parse stage because the top-level Makefile could be parsed with
a stale include/config/auto.conf.

Once you are hit by the error about non-retpoline compiler, the
compilation still breaks even after disabling CONFIG_RETPOLINE.

The easiest fix is to move this check to the "archprepare" like commit
829fe4aa9ac1 ("x86: Allow generating user-space headers without a
compiler") did.

Link: https://lkml.org/lkml/2018/12/4/206
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler 
support")
Reported-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
   - Revive ifdef CONFIG_RETPOLINE surrounding the KBUILD_CFLAGS addition
   - Rephase the commit log a bit, hoping the cause of the issue will be clearer

  arch/x86/Makefile | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f5d7f41..75ef499 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,9 +220,6 @@ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
  
  # Avoid indirect branches in kernel to deal with Spectre

  ifdef CONFIG_RETPOLINE
-ifeq ($(RETPOLINE_CFLAGS),)
-  $(error You are building kernel with non-retpoline compiler, please update 
your compiler.)
-endif
KBUILD_CFLAGS += $(RETPOLINE_CFLAGS)
  endif
  
@@ -307,6 +304,13 @@ ifndef CC_HAVE_ASM_GOTO

@echo Compiler lacks asm-goto support.
@exit 1
  endif
+ifdef CONFIG_RETPOLINE
+ifeq ($(RETPOLINE_CFLAGS),)
+   @echo "You are building kernel with non-retpoline compiler." >&2
+   @echo "Please update your compiler." >&2
+   @false
+endif
+endif
  
  archclean:

$(Q)rm -rf $(objtree)/arch/i386

Acked-by: Zhenzhong Duan 

--
Regards
Zhenzhong

Re: [PATCH v5 7/8] arm64: dts: sdm845: Add rpmh powercontroller node

[Rajendra Nayak]

On 12/5/2018 4:46 AM, Stephen Boyd wrote:

Quoting Rajendra Nayak (2018-12-03 21:21:18)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index b72bdb0a31a5..a6d0cd8d17b0 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1324,6 +1325,56 @@
 compatible = "qcom,sdm845-rpmh-clk";
 #clock-cells = <1>;
 };
+
+   rpmhpd: power-controller {
+   compatible = "qcom,sdm845-rpmhpd";
+   #power-domain-cells = <1>;
+   operating-points-v2 = <_opp_table>;
+   };
+
+   rpmhpd_opp_table: opp-table {


This table should go somewhere else? I don't understand why it's in the
rpmh node because it's not an rpmh device. Does it go to the root? Or
does it go under rpmhpd itself? I'm not sure.


I could move it to root perhaps, we seem to do that atleast in the case of
GPU. The power domain bindings 
(Documentation/devicetree/bindings/power/power_domain.txt)
seem to suggest it can't be under the power-controller node itself.

Re: [PATCH v5 7/8] arm64: dts: sdm845: Add rpmh powercontroller node

[Rajendra Nayak]

On 12/5/2018 4:46 AM, Stephen Boyd wrote:

Quoting Rajendra Nayak (2018-12-03 21:21:18)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index b72bdb0a31a5..a6d0cd8d17b0 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1324,6 +1325,56 @@
 compatible = "qcom,sdm845-rpmh-clk";
 #clock-cells = <1>;
 };
+
+   rpmhpd: power-controller {
+   compatible = "qcom,sdm845-rpmhpd";
+   #power-domain-cells = <1>;
+   operating-points-v2 = <_opp_table>;
+   };
+
+   rpmhpd_opp_table: opp-table {


This table should go somewhere else? I don't understand why it's in the
rpmh node because it's not an rpmh device. Does it go to the root? Or
does it go under rpmhpd itself? I'm not sure.


I could move it to root perhaps, we seem to do that atleast in the case of
GPU. The power domain bindings 
(Documentation/devicetree/bindings/power/power_domain.txt)
seem to suggest it can't be under the power-controller node itself.

Re: [PATCH v5 4/8] soc: qcom: rpmpd: Add support for get/set performance state

[Rajendra Nayak]

On 12/5/2018 4:44 AM, Stephen Boyd wrote:

Quoting Rajendra Nayak (2018-12-03 21:21:15)

@@ -221,6 +224,47 @@ static int rpmpd_power_off(struct generic_pm_domain 
*domain)
 return ret;
  }
  
+static int rpmpd_set_performance(struct generic_pm_domain *domain,

+unsigned int state)
+{
+   int ret = 0;
+   struct rpmpd *pd = domain_to_rpmpd(domain);
+
+   mutex_lock(_lock);
+
+   if (state > MAX_RPMPD_STATE)
+   goto out;


Does this need to be under the mutex lock? Doesn't look like it.


Nope, will move it out.




+
+   pd->corner = state;
+
+   if (!pd->enabled && (pd->key != KEY_FLOOR_CORNER))


Please drop useless parenthesis.


sure




+   goto out;
+
+   ret = rpmpd_aggregate_corner(pd);
+
+out:
+   mutex_unlock(_lock);
+
+   return ret;
+}
+
+static unsigned int rpmpd_get_performance(struct generic_pm_domain *genpd,
+ struct dev_pm_opp *opp)
+{
+   struct device_node *np;
+   unsigned int corner = 0;
+
+   np = dev_pm_opp_get_of_node(opp);
+   if (of_property_read_u32(np, "qcom,level", )) {
+   pr_err("%s: missing 'qcom,level' property\n", __func__);


We leak np reference here, assuming dev_pm_opp_get_of_node() returns an
of_node_get() pointer to the caller.


good catch, will fix.




+   return 0;
+   }
+
+   of_node_put(np);


This same code exists twice. Perhaps a helper needs to exist for
qcom_rpm_get_performance() to pull the number out of the DT.


Sure I can make both drivers use a common helper instead of duplicating it.




+
+   return corner;
+}

Re: [PATCH v5 4/8] soc: qcom: rpmpd: Add support for get/set performance state

[Rajendra Nayak]

On 12/5/2018 4:44 AM, Stephen Boyd wrote:

Quoting Rajendra Nayak (2018-12-03 21:21:15)

@@ -221,6 +224,47 @@ static int rpmpd_power_off(struct generic_pm_domain 
*domain)
 return ret;
  }
  
+static int rpmpd_set_performance(struct generic_pm_domain *domain,

+unsigned int state)
+{
+   int ret = 0;
+   struct rpmpd *pd = domain_to_rpmpd(domain);
+
+   mutex_lock(_lock);
+
+   if (state > MAX_RPMPD_STATE)
+   goto out;


Does this need to be under the mutex lock? Doesn't look like it.


Nope, will move it out.




+
+   pd->corner = state;
+
+   if (!pd->enabled && (pd->key != KEY_FLOOR_CORNER))


Please drop useless parenthesis.


sure




+   goto out;
+
+   ret = rpmpd_aggregate_corner(pd);
+
+out:
+   mutex_unlock(_lock);
+
+   return ret;
+}
+
+static unsigned int rpmpd_get_performance(struct generic_pm_domain *genpd,
+ struct dev_pm_opp *opp)
+{
+   struct device_node *np;
+   unsigned int corner = 0;
+
+   np = dev_pm_opp_get_of_node(opp);
+   if (of_property_read_u32(np, "qcom,level", )) {
+   pr_err("%s: missing 'qcom,level' property\n", __func__);


We leak np reference here, assuming dev_pm_opp_get_of_node() returns an
of_node_get() pointer to the caller.


good catch, will fix.




+   return 0;
+   }
+
+   of_node_put(np);


This same code exists twice. Perhaps a helper needs to exist for
qcom_rpm_get_performance() to pull the number out of the DT.


Sure I can make both drivers use a common helper instead of duplicating it.




+
+   return corner;
+}

Re: [resend PATCH] dt-bindings: sound: Add documentation for pcm3060 property out-single-ended

[Kirill Marinushkin]

Thank you Rob,

Mark already applied this patch, with a slightly modified subject:

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=for-next=fd7de6370cb62b147185834d60069568a21acacd

Best Regards,
Kirill

On 12/04/18 22:43, Rob Herring wrote:
> On Thu, 15 Nov 2018 08:12:53 +0100, Kirill Marinushkin wrote:
>> Output of pcm3060 codec may be configured as single-ended or differential
>>
>> Signed-off-by: Kirill Marinushkin 
>> Cc: devicet...@vger.kernel.org
>> ---
>> Hello Mark,
>>
>> yesterday there was a misunderstanding: when I wrote you
>>
>>> I think you forgot one patch in the series
>>
>> you accidently applied the already-applied patch instead of the forgotten
>> one. To avoid the confusion, in this e-mail I resend you the proper
>> forgotten patch in a separate mailing thread.
>>
>> Please apply this patch for-next.
>>
>> Best Regards,
>> Kirill
>> ---
>>  Documentation/devicetree/bindings/sound/pcm3060.txt | 6 ++
>>  1 file changed, 6 insertions(+)
>>
> 
> Reviewed-by: Rob Herring 
> 

Re: [resend PATCH] dt-bindings: sound: Add documentation for pcm3060 property out-single-ended

[Kirill Marinushkin]

Thank you Rob,

Mark already applied this patch, with a slightly modified subject:

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=for-next=fd7de6370cb62b147185834d60069568a21acacd

Best Regards,
Kirill

On 12/04/18 22:43, Rob Herring wrote:
> On Thu, 15 Nov 2018 08:12:53 +0100, Kirill Marinushkin wrote:
>> Output of pcm3060 codec may be configured as single-ended or differential
>>
>> Signed-off-by: Kirill Marinushkin 
>> Cc: devicet...@vger.kernel.org
>> ---
>> Hello Mark,
>>
>> yesterday there was a misunderstanding: when I wrote you
>>
>>> I think you forgot one patch in the series
>>
>> you accidently applied the already-applied patch instead of the forgotten
>> one. To avoid the confusion, in this e-mail I resend you the proper
>> forgotten patch in a separate mailing thread.
>>
>> Please apply this patch for-next.
>>
>> Best Regards,
>> Kirill
>> ---
>>  Documentation/devicetree/bindings/sound/pcm3060.txt | 6 ++
>>  1 file changed, 6 insertions(+)
>>
> 
> Reviewed-by: Rob Herring 
> 

Re: [PATCH v5 3/8] soc: qcom: rpmpd: Add a Power domain driver to model corners

[Rajendra Nayak]

On 12/5/2018 4:42 AM, Stephen Boyd wrote:

Overall looks good to me, just some nitpicks around modules and
includes.


Thanks for the review, I will fix up all your concerns below and respin soon.



Quoting Rajendra Nayak (2018-12-03 21:21:14)

The Power domains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.

We add all Power domain data needed on msm8996 here. This driver can easily
be extended by adding data for other qualcomm SoCs as well.



Why is "Power" capitalized in power domain?


diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index f25b54cd6cf8..f1b25fdcf2ad 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
  obj-$(CONFIG_QCOM_APR) += apr.o
  obj-$(CONFIG_QCOM_LLCC) += llcc-slice.o
  obj-$(CONFIG_QCOM_SDM845_LLCC) += llcc-sdm845.o
+obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
new file mode 100644
index ..a0b9f122d793
--- /dev/null
+++ b/drivers/soc/qcom/rpmpd.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. */
+
+#include 
+#include 


And what is exported?


+#include 
+#include 
+#include 


Is it a module? It's only bool so I don't think so.


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
+
+/* Resource types */
+#define RPMPD_SMPA 0x61706d73
+#define RPMPD_LDOA 0x616f646c
+
+/* Operation Keys */
+#define KEY_CORNER 0x6e726f63 /* corn */
+#define KEY_ENABLE 0x6e657773 /* swen */
+#define KEY_FLOOR_CORNER   0x636676   /* vfc */
+
+#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
+   static struct rpmpd _platform##_##_active;  \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .peer = &_platform##_##_active, \
+   .res_type = RPMPD_SMPA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   };  \
+   static struct rpmpd _platform##_##_active = {   \
+   .pd = { .name = #_active, },\
+   .peer = &_platform##_##_name,   \
+   .active_only = true,\
+   .res_type = RPMPD_SMPA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   }
+
+#define DEFINE_RPMPD_CORN_LDOA(_platform, _name, r_id) \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .res_type = RPMPD_LDOA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   }
+
+#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type)   \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .res_type = r_type, \
+   .res_id = r_id, \
+   .key = KEY_FLOOR_CORNER,\
+   }
+
+#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id)  \
+   DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
+
+#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id)  \
+   DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_LDOA)
+
+struct rpmpd_req {
+   __le32 key;
+   __le32 nbytes;
+   __le32 value;
+};
+
+struct rpmpd {
+   struct generic_pm_domain pd;
+   struct rpmpd *peer;
+   const bool active_only;
+   unsigned int corner;
+   bool enabled;
+   const char *res_name;
+   const int res_type;
+   const int res_id;
+   struct qcom_smd_rpm *rpm;
+   __le32 key;
+};
+
+struct rpmpd_desc {
+   struct rpmpd **rpmpds;
+   size_t num_pds;
+};
+
+static DEFINE_MUTEX(rpmpd_lock);
+
+/* msm8996 RPM Power domains */
+DEFINE_RPMPD_CORN_SMPA(msm8996, vddcx, vddcx_ao, 1);
+DEFINE_RPMPD_CORN_SMPA(msm8996, vddmx, vddmx_ao, 2);

Re: [PATCH v10 0/6] Support for Qualcomm UFS QMP PHY on SDM845

[Vivek Gautam]

On Tue, Oct 23, 2018 at 10:07 AM Can Guo  wrote:
>
> This patch series adds support for UFS QMP PHY on SDM845 and the
> compatible string for it. This patch series depends on the current
> proposed QMP V3 USB3 UNI PHY support for sdm845 driver [1], on
> the DT bindings for the QMP V3 USB3 PHYs based dirver [2], and also
> rebased on updated pipe_clk initialization sequence [3]. This series
> can only be merged once the dependent patches do.
> [1] 
> http://lists-archives.com/linux-kernel/29071659-dt-bindings-phy-qcom-qmp-update-bindings-for-sdm845.html
> [2] 
> http://lists-archives.com/linux-kernel/29071660-phy-qcom-qmp-add-qmp-v3-usb3-uni-phy-support-for-sdm845.html
> [3] https://patchwork.kernel.org/patch/10376551/

Besides my comment for PATCH 4/6, I have already reviewed the entire series,
and it looks good.
If adding new bindings for sdm845 needs a further review, can you separate out
just the phy patches from this series (patch 1, 2, 3 & 6), and re-send them.
We can ask Kishon if he can pull them in for this merge window.
Thanks.

best regards
Vivek

>
> Changes since v9:
> - Incorporated review comments from Rob.
>
> Changes since v8:
> - Add one new change to support ufs core reset.
> - Incorporated review comments from Evan, Vivek.
>
> Changes since v7:
> - Add one new change to update UFS PHY power on sequence
> - Incorporated review comments from Evan, Vivek and Manu.
>
> Changes since v6:
> - Add one new change to clean up some structs and field
> - Updates the PHY power control sequence.
> - Incorporated review comments from Vivek and Manu.
>
> Changes since v5:
> - Updates the PHY power control sequence.
> - Updates UFS PHY power on condition check.
>
> Changes since v4:
> - Adds 'ref_aux' clock back to SDM845 UFS PHY clock list.
> - Power on PHY before serdes configuration starts.
> - Updates the UFS PHY initialization sequence.
> - Updates a few UFS PHY registers.
> - Incorporated review comments from Vivek and Manu.
>
> Changes since v3:
> - Incorporated review comments from Vivek and Rob.
>
> Changes since v2:
> - Incorporated review comments from Vivek and Rob.
> - Remove "ref_aux" from sdm845 ufs phy clock list structure.
>
> Changes since v1:
> - Incorporated review comments from Vivek and Manu.
> - Update the commit title of patch 2.
>
> Can Guo (5):
>   phy: Update PHY power control sequence
>   phy: General struct and field cleanup
>   phy: Add QMP phy based UFS phy support for sdm845
>   scsi: ufs: Power on phy after it is initialized
>   dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845
>
> Dov Levenglick (1):
>   scsi: ufs: Add core reset support
>
>  .../devicetree/bindings/phy/qcom-qmp-phy.txt   |   4 +-
>  drivers/phy/qualcomm/phy-qcom-qmp.c| 216 
> +++--
>  drivers/phy/qualcomm/phy-qcom-qmp.h|  15 ++
>  drivers/scsi/ufs/ufs-qcom.c|  34 +++-
>  drivers/scsi/ufs/ufs-qcom.h|   1 +
>  drivers/scsi/ufs/ufshcd-pltfrm.c   |  22 +++
>  drivers/scsi/ufs/ufshcd.c  |  13 ++
>  drivers/scsi/ufs/ufshcd.h  |  12 ++
>  8 files changed, 296 insertions(+), 21 deletions(-)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v5 3/8] soc: qcom: rpmpd: Add a Power domain driver to model corners

[Rajendra Nayak]

On 12/5/2018 4:42 AM, Stephen Boyd wrote:

Overall looks good to me, just some nitpicks around modules and
includes.


Thanks for the review, I will fix up all your concerns below and respin soon.



Quoting Rajendra Nayak (2018-12-03 21:21:14)

The Power domains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.

We add all Power domain data needed on msm8996 here. This driver can easily
be extended by adding data for other qualcomm SoCs as well.



Why is "Power" capitalized in power domain?


diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index f25b54cd6cf8..f1b25fdcf2ad 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
  obj-$(CONFIG_QCOM_APR) += apr.o
  obj-$(CONFIG_QCOM_LLCC) += llcc-slice.o
  obj-$(CONFIG_QCOM_SDM845_LLCC) += llcc-sdm845.o
+obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
new file mode 100644
index ..a0b9f122d793
--- /dev/null
+++ b/drivers/soc/qcom/rpmpd.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. */
+
+#include 
+#include 


And what is exported?


+#include 
+#include 
+#include 


Is it a module? It's only bool so I don't think so.


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
+
+/* Resource types */
+#define RPMPD_SMPA 0x61706d73
+#define RPMPD_LDOA 0x616f646c
+
+/* Operation Keys */
+#define KEY_CORNER 0x6e726f63 /* corn */
+#define KEY_ENABLE 0x6e657773 /* swen */
+#define KEY_FLOOR_CORNER   0x636676   /* vfc */
+
+#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
+   static struct rpmpd _platform##_##_active;  \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .peer = &_platform##_##_active, \
+   .res_type = RPMPD_SMPA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   };  \
+   static struct rpmpd _platform##_##_active = {   \
+   .pd = { .name = #_active, },\
+   .peer = &_platform##_##_name,   \
+   .active_only = true,\
+   .res_type = RPMPD_SMPA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   }
+
+#define DEFINE_RPMPD_CORN_LDOA(_platform, _name, r_id) \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .res_type = RPMPD_LDOA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   }
+
+#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type)   \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .res_type = r_type, \
+   .res_id = r_id, \
+   .key = KEY_FLOOR_CORNER,\
+   }
+
+#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id)  \
+   DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
+
+#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id)  \
+   DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_LDOA)
+
+struct rpmpd_req {
+   __le32 key;
+   __le32 nbytes;
+   __le32 value;
+};
+
+struct rpmpd {
+   struct generic_pm_domain pd;
+   struct rpmpd *peer;
+   const bool active_only;
+   unsigned int corner;
+   bool enabled;
+   const char *res_name;
+   const int res_type;
+   const int res_id;
+   struct qcom_smd_rpm *rpm;
+   __le32 key;
+};
+
+struct rpmpd_desc {
+   struct rpmpd **rpmpds;
+   size_t num_pds;
+};
+
+static DEFINE_MUTEX(rpmpd_lock);
+
+/* msm8996 RPM Power domains */
+DEFINE_RPMPD_CORN_SMPA(msm8996, vddcx, vddcx_ao, 1);
+DEFINE_RPMPD_CORN_SMPA(msm8996, vddmx, vddmx_ao, 2);

Re: [PATCH v10 0/6] Support for Qualcomm UFS QMP PHY on SDM845

[Vivek Gautam]

On Tue, Oct 23, 2018 at 10:07 AM Can Guo  wrote:
>
> This patch series adds support for UFS QMP PHY on SDM845 and the
> compatible string for it. This patch series depends on the current
> proposed QMP V3 USB3 UNI PHY support for sdm845 driver [1], on
> the DT bindings for the QMP V3 USB3 PHYs based dirver [2], and also
> rebased on updated pipe_clk initialization sequence [3]. This series
> can only be merged once the dependent patches do.
> [1] 
> http://lists-archives.com/linux-kernel/29071659-dt-bindings-phy-qcom-qmp-update-bindings-for-sdm845.html
> [2] 
> http://lists-archives.com/linux-kernel/29071660-phy-qcom-qmp-add-qmp-v3-usb3-uni-phy-support-for-sdm845.html
> [3] https://patchwork.kernel.org/patch/10376551/

Besides my comment for PATCH 4/6, I have already reviewed the entire series,
and it looks good.
If adding new bindings for sdm845 needs a further review, can you separate out
just the phy patches from this series (patch 1, 2, 3 & 6), and re-send them.
We can ask Kishon if he can pull them in for this merge window.
Thanks.

best regards
Vivek

>
> Changes since v9:
> - Incorporated review comments from Rob.
>
> Changes since v8:
> - Add one new change to support ufs core reset.
> - Incorporated review comments from Evan, Vivek.
>
> Changes since v7:
> - Add one new change to update UFS PHY power on sequence
> - Incorporated review comments from Evan, Vivek and Manu.
>
> Changes since v6:
> - Add one new change to clean up some structs and field
> - Updates the PHY power control sequence.
> - Incorporated review comments from Vivek and Manu.
>
> Changes since v5:
> - Updates the PHY power control sequence.
> - Updates UFS PHY power on condition check.
>
> Changes since v4:
> - Adds 'ref_aux' clock back to SDM845 UFS PHY clock list.
> - Power on PHY before serdes configuration starts.
> - Updates the UFS PHY initialization sequence.
> - Updates a few UFS PHY registers.
> - Incorporated review comments from Vivek and Manu.
>
> Changes since v3:
> - Incorporated review comments from Vivek and Rob.
>
> Changes since v2:
> - Incorporated review comments from Vivek and Rob.
> - Remove "ref_aux" from sdm845 ufs phy clock list structure.
>
> Changes since v1:
> - Incorporated review comments from Vivek and Manu.
> - Update the commit title of patch 2.
>
> Can Guo (5):
>   phy: Update PHY power control sequence
>   phy: General struct and field cleanup
>   phy: Add QMP phy based UFS phy support for sdm845
>   scsi: ufs: Power on phy after it is initialized
>   dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845
>
> Dov Levenglick (1):
>   scsi: ufs: Add core reset support
>
>  .../devicetree/bindings/phy/qcom-qmp-phy.txt   |   4 +-
>  drivers/phy/qualcomm/phy-qcom-qmp.c| 216 
> +++--
>  drivers/phy/qualcomm/phy-qcom-qmp.h|  15 ++
>  drivers/scsi/ufs/ufs-qcom.c|  34 +++-
>  drivers/scsi/ufs/ufs-qcom.h|   1 +
>  drivers/scsi/ufs/ufshcd-pltfrm.c   |  22 +++
>  drivers/scsi/ufs/ufshcd.c  |  13 ++
>  drivers/scsi/ufs/ufshcd.h  |  12 ++
>  8 files changed, 296 insertions(+), 21 deletions(-)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

RE: [PATCH v7 3/9] spi: Add a driver for the Freescale/NXP QuadSPI controller

[Yogesh Narayan Gaur]

Hi,

Verified patch on LS1088ardb this board is having two connected flash slave 
devices on CS0 and CS1.

Verified with simple Read/Write/Erase operations along with JFFS2 mounting and 
booting from flash MTD partition for both slave devices.

> -Original Message-
> From: Schrempf Frieder [mailto:frieder.schre...@kontron.de]
> Sent: Tuesday, December 4, 2018 7:45 PM
> To: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; linux-
> s...@vger.kernel.org; Marek Vasut ; Mark Brown
> ; Han Xu 
> Cc: dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> miquel.ray...@bootlin.com; David Wolfe ; Fabio
> Estevam ; Prabhakar Kushwaha
> ; Yogesh Narayan Gaur
> ; shawn...@kernel.org; Schrempf Frieder
> ; linux-kernel@vger.kernel.org
> Subject: [PATCH v7 3/9] spi: Add a driver for the Freescale/NXP QuadSPI
> controller
> 
> From: Frieder Schrempf 
> 
> This driver is derived from the SPI NOR driver at mtd/spi-nor/fsl-quadspi.c. 
> It
> uses the new SPI memory interface of the SPI framework to issue flash memory
> operations to up to four connected flash chips (2 buses with 2 CS each).
> 
> The controller does not support generic SPI messages.
> 
> This patch also disables the build of the "old" driver and reuses its Kconfig 
> option
> CONFIG_SPI_FSL_QUADSPI to replace it.
> 
> Signed-off-by: Frieder Schrempf 
Reviewed-by: Yogesh Gaur 
Tested-by: Yogesh Gaur 

--
Thanks
Yogesh Gaur

> ---
>  drivers/mtd/spi-nor/Kconfig  |   9 -
>  drivers/mtd/spi-nor/Makefile |   1 -
>  drivers/spi/Kconfig  |  11 +
>  drivers/spi/Makefile |   1 +
>  drivers/spi/spi-fsl-qspi.c   | 966 ++
>  5 files changed, 978 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index
> 6cc9c92..d1ca307 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -59,15 +59,6 @@ config SPI_CADENCE_QUADSPI
> device with a Cadence QSPI controller and want to access the
> Flash as an MTD device.
> 
> -config SPI_FSL_QUADSPI
> - tristate "Freescale Quad SPI controller"
> - depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE ||
> COMPILE_TEST
> - depends on HAS_IOMEM
> - help
> -   This enables support for the Quad SPI controller in master mode.
> -   This controller does not support generic SPI. It only supports
> -   SPI NOR.
> -
>  config SPI_HISI_SFC
>   tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
>   depends on ARCH_HISI || COMPILE_TEST
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile index
> f4c61d2..3f160c2e3 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -3,7 +3,6 @@ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o
>  obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
>  obj-$(CONFIG_SPI_ATMEL_QUADSPI)  += atmel-quadspi.o
>  obj-$(CONFIG_SPI_CADENCE_QUADSPI)+= cadence-quadspi.o
> -obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o
>  obj-$(CONFIG_SPI_HISI_SFC)   += hisi-sfc.o
>  obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o
>  obj-$(CONFIG_SPI_NXP_SPIFI)  += nxp-spifi.o
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 7d3a5c9..8c84186
> 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -259,6 +259,17 @@ config SPI_FSL_LPSPI
>   help
> This enables Freescale i.MX LPSPI controllers in master mode.
> 
> +config SPI_FSL_QUADSPI
> + tristate "Freescale QSPI controller"
> + depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE ||
> COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> +   This enables support for the Quad SPI controller in master mode.
> +   Up to four flash chips can be connected on two buses with two
> +   chipselects each.
> +   This controller does not support generic SPI messages. It only
> +   supports the high-level SPI memory interface.
> +
>  config SPI_GPIO
>   tristate "GPIO-based bitbanging SPI Master"
>   depends on GPIOLIB || COMPILE_TEST
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 
> 3575205..5377e61
> 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -44,6 +44,7 @@ obj-$(CONFIG_SPI_FSL_DSPI)  += spi-fsl-
> dspi.o
>  obj-$(CONFIG_SPI_FSL_LIB)+= spi-fsl-lib.o
>  obj-$(CONFIG_SPI_FSL_ESPI)   += spi-fsl-espi.o
>  obj-$(CONFIG_SPI_FSL_LPSPI)  += spi-fsl-lpspi.o
> +obj-$(CONFIG_SPI_FSL_QUADSPI)+= spi-fsl-qspi.o
>  obj-$(CONFIG_SPI_FSL_SPI)+= spi-fsl-spi.o
>  obj-$(CONFIG_SPI_GPIO)   += spi-gpio.o
>  obj-$(CONFIG_SPI_IMG_SPFI)   += spi-img-spfi.o
> diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c new file 
> mode
> 100644 index 000..f0a3400
> --- /dev/null
> +++ b/drivers/spi/spi-fsl-qspi.c
> @@ -0,0 +1,966 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Freescale QuadSPI driver.
> + *
> + * 

Re: [PATCH v6 03/10] clk: of-provider: look at parent if registered device has no provider info

[Matti Vaittinen]

Hello Stephen,

I copied some parts of the v4 discussion here as well. Let's continue
them under this one email thread. (and yep, this is my bad we now have
multiple email threads - I did these new patches without waiting for
the final conclusion. I should try to be more patient in the future...)

> > > I think we should use parent device's node, not the paren node in DT, 
> > >
> > > right? But I agree, we should only look "one level up in the chain".  
> > >

 
> > Are these two things different? I'm suggesting looking at   
> >
> > device_node::parent and trying to find a #clock-cells property. 
> >

 
> I thought that MFD sub-devices may completely lack the DT node but I
> will verify this tomorrow.

So yep. It appears that the DT node for MFD sub-device is left NULL.
This is quite logical as there really is no clk sub-node in MFD (pmic)
node. The option to "hack around" this would be setting the of_node to
parent node in driver code. But this feels wrong. Drivers should not
mess with the "dt node ownership" - and it also feels a bit odd when
many devices use same DT node. I think we may hit in problems when
obtaining resources or doing reference counting. Hence I think we should
keep the of_node NULL for sub-device if the sub-device does not have own
node inside the main devie node. And I think Rob was not a fan of having
own nodes for sub-devices inside the MFD node (AFAIR my first driver
draft for this device had it but Rob and you thought that was not correct).

On Tue, Dec 04, 2018 at 11:38:17AM -0800, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2018-12-04 03:34:53)
> > It seems to be usual for MFD devices that the created 'clock sub-device'
> > do not have own DT node. The clock provider information is usually in the
> > main device node which is owned by the MFD device. Change the devm variant
> > of clk of-provider registration to check the parent device node if given
> > device has no own node or if the node does not contain the #clock-cells
> > property. In such case use the parent node if it contains the #clock-cells.
> > 
> > Signed-off-by: Matti Vaittinen 
> > ---
> >  drivers/clk/clk.c | 27 +++
> >  1 file changed, 23 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 78c90913f987..66dc7c1483d7 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -3893,6 +3893,11 @@ static void devm_of_clk_release_provider(struct 
> > device *dev, void *res)
> > of_clk_del_provider(*(struct device_node **)res);
> >  }
> >  
> > +static int of_is_clk_provider(struct device_node *np)
> > +{
> > +   return !!of_find_property(np, "#clock-cells", NULL);
> > +}
> > +
> >  /**
> >   * devm_of_clk_add_hw_provider() - Managed clk provider node registration
> >   * @dev: Device acting as the clock provider. Used for DT node and 
> > lifetime.
> > @@ -3901,8 +3906,11 @@ static void devm_of_clk_release_provider(struct 
> > device *dev, void *res)
> >   *
> >   * Returns 0 on success or an errno on failure.
> >   *
> > - * Registers clock provider for given device's node. Provider is 
> > automatically
> > - * released at device exit.
> > + * Registers clock provider for given device's node. If the device has no 
> > DT
> > + * node or if the device node lacks of clock provider information 
> > (#clock-cells)
> > + * then the parent device's node is scanned for this information. If 
> > parent node
> > + * has the #clock-cells then it is used in registration. Provider is
> > + * automatically released at device exit.
> >   */
> >  int devm_of_clk_add_hw_provider(struct device *dev,
> > struct clk_hw *(*get)(struct of_phandle_args 
> > *clkspec,
> > @@ -3912,12 +3920,17 @@ int devm_of_clk_add_hw_provider(struct device *dev,
> > struct device_node **ptr, *np;
> > int ret;
> >  
> > +   np = dev->of_node;
> > +
> > +   if (!of_is_clk_provider(dev->of_node))
> > +   if (of_is_clk_provider(dev->parent->of_node))
> > +   np = dev->parent->of_node;
> 
> As said on v5, let's just modify of_clk_add_provider() to do the parent
> search.

But that won't solve the issue if we don't do "dirty hacks" in driver.
The devm interface still only gets the device-pointer, not the DT node
as argument. And if DT node for device is NULL (like in MFD cases) -
then there is no parent node, only parent device with a node. For plain
of_clk_add_provider() the driver can just give the parent's node pointer
in cases where it knows it is the parent who has the provider data in
DT. But our original problem is in devm interfaces.

Br,
Matti Vaittinen

-- 
Matti Vaittinen
ROHM Semiconductors

~~~ "I don't think so," said Rene Descartes.  Just then, he 

RE: [PATCH v7 3/9] spi: Add a driver for the Freescale/NXP QuadSPI controller

[Yogesh Narayan Gaur]

Hi,

Verified patch on LS1088ardb this board is having two connected flash slave 
devices on CS0 and CS1.

Verified with simple Read/Write/Erase operations along with JFFS2 mounting and 
booting from flash MTD partition for both slave devices.

> -Original Message-
> From: Schrempf Frieder [mailto:frieder.schre...@kontron.de]
> Sent: Tuesday, December 4, 2018 7:45 PM
> To: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; linux-
> s...@vger.kernel.org; Marek Vasut ; Mark Brown
> ; Han Xu 
> Cc: dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> miquel.ray...@bootlin.com; David Wolfe ; Fabio
> Estevam ; Prabhakar Kushwaha
> ; Yogesh Narayan Gaur
> ; shawn...@kernel.org; Schrempf Frieder
> ; linux-kernel@vger.kernel.org
> Subject: [PATCH v7 3/9] spi: Add a driver for the Freescale/NXP QuadSPI
> controller
> 
> From: Frieder Schrempf 
> 
> This driver is derived from the SPI NOR driver at mtd/spi-nor/fsl-quadspi.c. 
> It
> uses the new SPI memory interface of the SPI framework to issue flash memory
> operations to up to four connected flash chips (2 buses with 2 CS each).
> 
> The controller does not support generic SPI messages.
> 
> This patch also disables the build of the "old" driver and reuses its Kconfig 
> option
> CONFIG_SPI_FSL_QUADSPI to replace it.
> 
> Signed-off-by: Frieder Schrempf 
Reviewed-by: Yogesh Gaur 
Tested-by: Yogesh Gaur 

--
Thanks
Yogesh Gaur

> ---
>  drivers/mtd/spi-nor/Kconfig  |   9 -
>  drivers/mtd/spi-nor/Makefile |   1 -
>  drivers/spi/Kconfig  |  11 +
>  drivers/spi/Makefile |   1 +
>  drivers/spi/spi-fsl-qspi.c   | 966 ++
>  5 files changed, 978 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index
> 6cc9c92..d1ca307 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -59,15 +59,6 @@ config SPI_CADENCE_QUADSPI
> device with a Cadence QSPI controller and want to access the
> Flash as an MTD device.
> 
> -config SPI_FSL_QUADSPI
> - tristate "Freescale Quad SPI controller"
> - depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE ||
> COMPILE_TEST
> - depends on HAS_IOMEM
> - help
> -   This enables support for the Quad SPI controller in master mode.
> -   This controller does not support generic SPI. It only supports
> -   SPI NOR.
> -
>  config SPI_HISI_SFC
>   tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
>   depends on ARCH_HISI || COMPILE_TEST
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile index
> f4c61d2..3f160c2e3 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -3,7 +3,6 @@ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o
>  obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
>  obj-$(CONFIG_SPI_ATMEL_QUADSPI)  += atmel-quadspi.o
>  obj-$(CONFIG_SPI_CADENCE_QUADSPI)+= cadence-quadspi.o
> -obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o
>  obj-$(CONFIG_SPI_HISI_SFC)   += hisi-sfc.o
>  obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o
>  obj-$(CONFIG_SPI_NXP_SPIFI)  += nxp-spifi.o
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 7d3a5c9..8c84186
> 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -259,6 +259,17 @@ config SPI_FSL_LPSPI
>   help
> This enables Freescale i.MX LPSPI controllers in master mode.
> 
> +config SPI_FSL_QUADSPI
> + tristate "Freescale QSPI controller"
> + depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE ||
> COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> +   This enables support for the Quad SPI controller in master mode.
> +   Up to four flash chips can be connected on two buses with two
> +   chipselects each.
> +   This controller does not support generic SPI messages. It only
> +   supports the high-level SPI memory interface.
> +
>  config SPI_GPIO
>   tristate "GPIO-based bitbanging SPI Master"
>   depends on GPIOLIB || COMPILE_TEST
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 
> 3575205..5377e61
> 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -44,6 +44,7 @@ obj-$(CONFIG_SPI_FSL_DSPI)  += spi-fsl-
> dspi.o
>  obj-$(CONFIG_SPI_FSL_LIB)+= spi-fsl-lib.o
>  obj-$(CONFIG_SPI_FSL_ESPI)   += spi-fsl-espi.o
>  obj-$(CONFIG_SPI_FSL_LPSPI)  += spi-fsl-lpspi.o
> +obj-$(CONFIG_SPI_FSL_QUADSPI)+= spi-fsl-qspi.o
>  obj-$(CONFIG_SPI_FSL_SPI)+= spi-fsl-spi.o
>  obj-$(CONFIG_SPI_GPIO)   += spi-gpio.o
>  obj-$(CONFIG_SPI_IMG_SPFI)   += spi-img-spfi.o
> diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c new file 
> mode
> 100644 index 000..f0a3400
> --- /dev/null
> +++ b/drivers/spi/spi-fsl-qspi.c
> @@ -0,0 +1,966 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Freescale QuadSPI driver.
> + *
> + * 

Re: [PATCH v6 03/10] clk: of-provider: look at parent if registered device has no provider info

[Matti Vaittinen]

Hello Stephen,

I copied some parts of the v4 discussion here as well. Let's continue
them under this one email thread. (and yep, this is my bad we now have
multiple email threads - I did these new patches without waiting for
the final conclusion. I should try to be more patient in the future...)

> > > I think we should use parent device's node, not the paren node in DT, 
> > >
> > > right? But I agree, we should only look "one level up in the chain".  
> > >

 
> > Are these two things different? I'm suggesting looking at   
> >
> > device_node::parent and trying to find a #clock-cells property. 
> >

 
> I thought that MFD sub-devices may completely lack the DT node but I
> will verify this tomorrow.

So yep. It appears that the DT node for MFD sub-device is left NULL.
This is quite logical as there really is no clk sub-node in MFD (pmic)
node. The option to "hack around" this would be setting the of_node to
parent node in driver code. But this feels wrong. Drivers should not
mess with the "dt node ownership" - and it also feels a bit odd when
many devices use same DT node. I think we may hit in problems when
obtaining resources or doing reference counting. Hence I think we should
keep the of_node NULL for sub-device if the sub-device does not have own
node inside the main devie node. And I think Rob was not a fan of having
own nodes for sub-devices inside the MFD node (AFAIR my first driver
draft for this device had it but Rob and you thought that was not correct).

On Tue, Dec 04, 2018 at 11:38:17AM -0800, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2018-12-04 03:34:53)
> > It seems to be usual for MFD devices that the created 'clock sub-device'
> > do not have own DT node. The clock provider information is usually in the
> > main device node which is owned by the MFD device. Change the devm variant
> > of clk of-provider registration to check the parent device node if given
> > device has no own node or if the node does not contain the #clock-cells
> > property. In such case use the parent node if it contains the #clock-cells.
> > 
> > Signed-off-by: Matti Vaittinen 
> > ---
> >  drivers/clk/clk.c | 27 +++
> >  1 file changed, 23 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 78c90913f987..66dc7c1483d7 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -3893,6 +3893,11 @@ static void devm_of_clk_release_provider(struct 
> > device *dev, void *res)
> > of_clk_del_provider(*(struct device_node **)res);
> >  }
> >  
> > +static int of_is_clk_provider(struct device_node *np)
> > +{
> > +   return !!of_find_property(np, "#clock-cells", NULL);
> > +}
> > +
> >  /**
> >   * devm_of_clk_add_hw_provider() - Managed clk provider node registration
> >   * @dev: Device acting as the clock provider. Used for DT node and 
> > lifetime.
> > @@ -3901,8 +3906,11 @@ static void devm_of_clk_release_provider(struct 
> > device *dev, void *res)
> >   *
> >   * Returns 0 on success or an errno on failure.
> >   *
> > - * Registers clock provider for given device's node. Provider is 
> > automatically
> > - * released at device exit.
> > + * Registers clock provider for given device's node. If the device has no 
> > DT
> > + * node or if the device node lacks of clock provider information 
> > (#clock-cells)
> > + * then the parent device's node is scanned for this information. If 
> > parent node
> > + * has the #clock-cells then it is used in registration. Provider is
> > + * automatically released at device exit.
> >   */
> >  int devm_of_clk_add_hw_provider(struct device *dev,
> > struct clk_hw *(*get)(struct of_phandle_args 
> > *clkspec,
> > @@ -3912,12 +3920,17 @@ int devm_of_clk_add_hw_provider(struct device *dev,
> > struct device_node **ptr, *np;
> > int ret;
> >  
> > +   np = dev->of_node;
> > +
> > +   if (!of_is_clk_provider(dev->of_node))
> > +   if (of_is_clk_provider(dev->parent->of_node))
> > +   np = dev->parent->of_node;
> 
> As said on v5, let's just modify of_clk_add_provider() to do the parent
> search.

But that won't solve the issue if we don't do "dirty hacks" in driver.
The devm interface still only gets the device-pointer, not the DT node
as argument. And if DT node for device is NULL (like in MFD cases) -
then there is no parent node, only parent device with a node. For plain
of_clk_add_provider() the driver can just give the parent's node pointer
in cases where it knows it is the parent who has the provider data in
DT. But our original problem is in devm interfaces.

Br,
Matti Vaittinen

-- 
Matti Vaittinen
ROHM Semiconductors

~~~ "I don't think so," said Rene Descartes.  Just then, he 

Re: [PATCH v2] x86/build: fix compiler support check for CONFIG_RETPOLINE

[Meelis Roos]

05.12.18 08:27 Masahiro Yamada kirjutas:

The easiest fix is to move this check to the "archprepare" like commit
829fe4aa9ac1 ("x86: Allow generating user-space headers without a
compiler") did.

Link: https://lkml.org/lkml/2018/12/4/206
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler 
support")
Reported-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
   - Revive ifdef CONFIG_RETPOLINE surrounding the KBUILD_CFLAGS addition
   - Rephase the commit log a bit, hoping the cause of the issue will be clearer


Works for me - first it did

scripts/kconfig/conf  --syncconfig Kconfig

and then started compiling. The #define is gone from include/linux.

Thank you!

--
Meelis Roos 

Re: [PATCH v2] x86/build: fix compiler support check for CONFIG_RETPOLINE

[Meelis Roos]

05.12.18 08:27 Masahiro Yamada kirjutas:

The easiest fix is to move this check to the "archprepare" like commit
829fe4aa9ac1 ("x86: Allow generating user-space headers without a
compiler") did.

Link: https://lkml.org/lkml/2018/12/4/206
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler 
support")
Reported-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
   - Revive ifdef CONFIG_RETPOLINE surrounding the KBUILD_CFLAGS addition
   - Rephase the commit log a bit, hoping the cause of the issue will be clearer


Works for me - first it did

scripts/kconfig/conf  --syncconfig Kconfig

and then started compiling. The #define is gone from include/linux.

Thank you!

--
Meelis Roos 

Re: [PATCH 4.14 054/146] f2fs: fix to do sanity check with block address in main area

[Greg Kroah-Hartman]

On Tue, Dec 04, 2018 at 08:27:32PM +, Sudip Mukherjee wrote:
> Hi Greg,
> 
> On Tue, Dec 4, 2018 at 11:05 AM Greg Kroah-Hartman
>  wrote:
> >
> > 4.14-stable review patch.  If anyone has any objections, please let me know.
> >
> > --
> >
> > commit c9b60788fc760d136211853f10ce73dc152d1f4a upstream.
> 
> There is another upstream commit which fixes this.
> 89d13c38501d ("f2fs: fix missing up_read")

Thanks for pointing this out, now queued up.

greg k-h

Re: [PATCH 4.14 054/146] f2fs: fix to do sanity check with block address in main area

[Greg Kroah-Hartman]

On Tue, Dec 04, 2018 at 08:27:32PM +, Sudip Mukherjee wrote:
> Hi Greg,
> 
> On Tue, Dec 4, 2018 at 11:05 AM Greg Kroah-Hartman
>  wrote:
> >
> > 4.14-stable review patch.  If anyone has any objections, please let me know.
> >
> > --
> >
> > commit c9b60788fc760d136211853f10ce73dc152d1f4a upstream.
> 
> There is another upstream commit which fixes this.
> 89d13c38501d ("f2fs: fix missing up_read")

Thanks for pointing this out, now queued up.

greg k-h

Re: [PATCH 4.19 000/139] 4.19.7-stable review

[Greg Kroah-Hartman]

On Tue, Dec 04, 2018 at 01:42:47PM -0800, Guenter Roeck wrote:
> On 12/4/18 2:48 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.7 release.
> > There are 139 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Dec  6 10:36:22 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 159 pass: 159 fail: 0
> Qemu test results:
>   total: 337 pass: 337 fail: 0
> 
> Details are available at https://kerneltests.org/builders/.

Thanks for testing all 3 of these and letting me know.

greg k-h

Re: [PATCH 4.19 000/139] 4.19.7-stable review

[Greg Kroah-Hartman]

On Tue, Dec 04, 2018 at 01:42:47PM -0800, Guenter Roeck wrote:
> On 12/4/18 2:48 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.7 release.
> > There are 139 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Dec  6 10:36:22 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 159 pass: 159 fail: 0
> Qemu test results:
>   total: 337 pass: 337 fail: 0
> 
> Details are available at https://kerneltests.org/builders/.

Thanks for testing all 3 of these and letting me know.

greg k-h

Re: [PATCH v2] memblock: Anonotate memblock_is_reserved() with __init_memblock.

[Wei Yang]

On Wed, Dec 05, 2018 at 05:37:37AM +, Yueyi Li wrote:
>
>On 2018/12/4 11:04, Wei Yang wrote:
>> On Mon, Dec 03, 2018 at 04:00:08AM +, Yueyi Li wrote:
>>> Found warning:
>>>
>>> WARNING: EXPORT symbol "gsi_write_channel_scratch" [vmlinux] version 
>>> generation failed, symbol will not be versioned.
>>> WARNING: vmlinux.o(.text+0x1e0a0): Section mismatch in reference from the 
>>> function valid_phys_addr_range() to the function 
>>> .init.text:memblock_is_reserved()
>>> The function valid_phys_addr_range() references
>>> the function __init memblock_is_reserved().
>>> This is often because valid_phys_addr_range lacks a __init
>>> annotation or the annotation of memblock_is_reserved is wrong.
>>>
>>> Use __init_memblock instead of __init.
>> Not familiar with this error, the change looks good to me while have
>> some questions.
>>
>> 1. I don't see valid_phys_addr_range() reference memblock_is_reserved().
>> This is in which file or arch?
>
>Yes,  I modified valid_phys_addr_range() for some other debugging.
>
>> 2. In case a function reference memblock_is_reserved(), should it has
>> the annotation of __init_memblock too? Or just __init is ok? If my
>> understanding is correct, annotation __init is ok. Well, I don't see
>> valid_phys_addr_range() has an annotation.
>> 3. The only valid_phys_addr_range() reference some memblock function is
>> the one in arch/arm64/mm/mmap.c. Do we suppose to add an annotation to
>> this?
>
>Actually, __init_memblock is null in arch arm64, this warning is due to
>CONFIG_DEBUG_SECTION_MISMATCH enabled,  the help text in lib/Kconfig.debug.
>

Ok, thanks.

>
>
>Thanks,
>Yueyi

-- 
Wei Yang
Help you, Help me

Re: [PATCH v2] memblock: Anonotate memblock_is_reserved() with __init_memblock.

[Wei Yang]

On Wed, Dec 05, 2018 at 05:37:37AM +, Yueyi Li wrote:
>
>On 2018/12/4 11:04, Wei Yang wrote:
>> On Mon, Dec 03, 2018 at 04:00:08AM +, Yueyi Li wrote:
>>> Found warning:
>>>
>>> WARNING: EXPORT symbol "gsi_write_channel_scratch" [vmlinux] version 
>>> generation failed, symbol will not be versioned.
>>> WARNING: vmlinux.o(.text+0x1e0a0): Section mismatch in reference from the 
>>> function valid_phys_addr_range() to the function 
>>> .init.text:memblock_is_reserved()
>>> The function valid_phys_addr_range() references
>>> the function __init memblock_is_reserved().
>>> This is often because valid_phys_addr_range lacks a __init
>>> annotation or the annotation of memblock_is_reserved is wrong.
>>>
>>> Use __init_memblock instead of __init.
>> Not familiar with this error, the change looks good to me while have
>> some questions.
>>
>> 1. I don't see valid_phys_addr_range() reference memblock_is_reserved().
>> This is in which file or arch?
>
>Yes,  I modified valid_phys_addr_range() for some other debugging.
>
>> 2. In case a function reference memblock_is_reserved(), should it has
>> the annotation of __init_memblock too? Or just __init is ok? If my
>> understanding is correct, annotation __init is ok. Well, I don't see
>> valid_phys_addr_range() has an annotation.
>> 3. The only valid_phys_addr_range() reference some memblock function is
>> the one in arch/arm64/mm/mmap.c. Do we suppose to add an annotation to
>> this?
>
>Actually, __init_memblock is null in arch arm64, this warning is due to
>CONFIG_DEBUG_SECTION_MISMATCH enabled,  the help text in lib/Kconfig.debug.
>

Ok, thanks.

>
>
>Thanks,
>Yueyi

-- 
Wei Yang
Help you, Help me

Re: [PATCH 4.19 000/139] 4.19.7-stable review

[Greg Kroah-Hartman]

On Tue, Dec 04, 2018 at 07:09:46PM -0200, Rafael David Tinoco wrote:
> On 12/4/18 8:48 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.7 release.
> > There are 139 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Dec  6 10:36:22 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.19.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> During functional tests for this v4.19 release, we faced a PANIC,
> described bellow, but unlikely related to this specific v4.19 version.
> 
> First a WARN() at tcp_output.c:
> 
> tcp_send_loss_probe():
> ...
>   /* Retransmit last segment. */
>   if (WARN_ON(!skb))
>   goto rearm_timer;
> ...
> 
> [  173.557528] WARNING: CPU: 1 PID: 0 at
> /srv/oe/build/tmp-rpb-glibc/work-shared/juno/kernel-source/net/ipv4/tcp_output.c:2485
> tcp_send_loss_probe+0x164/0x1e8
> [  173.571425] Modules linked in: crc32_ce crct10dif_ce fuse
> [  173.576804] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.7-rc1 #1
> [  173.583014] Hardware name: ARM Juno development board (r2) (DT)

So only this one machine saw this failure?

If you can reproduce it again, bisection would be great to do if
possible.

thanks,

greg k-h

Re: [PATCH 4.19 000/139] 4.19.7-stable review

[Greg Kroah-Hartman]

On Tue, Dec 04, 2018 at 07:09:46PM -0200, Rafael David Tinoco wrote:
> On 12/4/18 8:48 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.7 release.
> > There are 139 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Dec  6 10:36:22 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.19.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> During functional tests for this v4.19 release, we faced a PANIC,
> described bellow, but unlikely related to this specific v4.19 version.
> 
> First a WARN() at tcp_output.c:
> 
> tcp_send_loss_probe():
> ...
>   /* Retransmit last segment. */
>   if (WARN_ON(!skb))
>   goto rearm_timer;
> ...
> 
> [  173.557528] WARNING: CPU: 1 PID: 0 at
> /srv/oe/build/tmp-rpb-glibc/work-shared/juno/kernel-source/net/ipv4/tcp_output.c:2485
> tcp_send_loss_probe+0x164/0x1e8
> [  173.571425] Modules linked in: crc32_ce crct10dif_ce fuse
> [  173.576804] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.7-rc1 #1
> [  173.583014] Hardware name: ARM Juno development board (r2) (DT)

So only this one machine saw this failure?

If you can reproduce it again, bisection would be great to do if
possible.

thanks,

greg k-h

Re: [PATCH 07/14] clock: milbeaut: Add Milbeaut M10V clock control

[Stephen Boyd]

Quoting Masahiro Yamada (2018-12-04 20:26:06)
> On Wed, Dec 5, 2018 at 3:14 AM Stephen Boyd  wrote:
> >
> > Quoting Masahiro Yamada (2018-12-04 03:03:53)
> > > Hi Stephen,
> > >
> > >
> > > On Fri, Nov 30, 2018 at 5:31 PM Stephen Boyd  wrote:
> > > >
> > > > Quoting Sugaya Taichi (2018-11-18 17:01:12)
> > > > > Add Milbeaut M10V clock ( including PLL ) control.
> > > >
> > > > Please give some more details here.
> > > >
> > > > >
> > > > > Signed-off-by: Sugaya Taichi 
> > > > > ---
> > > > >  drivers/clk/Makefile   |   1 +
> > > > >  drivers/clk/clk-m10v.c | 671 
> > > > > +
> > > >
> > > > And this is different from Uniphier? Maybe we need a socionext
> > > > directory under drivers/clk/.
> > >
> > >
> > >
> > > This is always a difficult question,
> > > and I do not have a strong opinion.
> > >
> > >
> > > I am fine with moving the files to drivers/clk/socionext
> > > although no file would be shared.
> > >
> > >
> > > FYI
> > >
> > > UniPhier and Milbeaut are completely different platforms
> > > developed/maintained by different teams.
> > >
> > > They happen to live in the same company now
> > > just because Socionext merged the LSI business from Panasonic and Fujitsu.
> > >
> > > UniPhier originates in Panasonic, while Milbeaut in Fujitsu.
> > >
> >
> > Thanks for the background info. I'd prefer to defer to however the dts
> > files are getting split up into directories. If they're all put under
> > arch/arm64/boot/dts/socionext/ then I would say combine the two clk
> > drivers into a socionext directory. Otherwise, keep them split out.
> 
> 
> If you want to align with the DT directory structure,
> the answer is clear.
> 
> 
> Milbeaut DT files will be put together with UniPhier ones
> into socionext directory.
> 
> 
> For arm64, DT directories are already sorted out by vendors.
> 
> Even 32-bit ARM is going to that way.
> 
> Rob Herring just posted a python script
> to move all DT files in arch/arm/boot/dts/
> into vendor subdirectories.
> 
> 
> Please let me know if you want me to
> move drivers/clk/uniphier/* to drivers/clk/socionext/*.
> 

Maybe the dts needs to be split up instead? Looks like the gpio drivers
are in a uniphier directory and there is some precedence to keep the
"taken over" company name when vendors are merged into other vendors.
Maybe that's how things have happened here? It would be nice to be
consistent, but I leave the decision up to you to figure out if that
really matters to you. I'll be fine either way.

Re: [PATCH 07/14] clock: milbeaut: Add Milbeaut M10V clock control

[Stephen Boyd]

Quoting Masahiro Yamada (2018-12-04 20:26:06)
> On Wed, Dec 5, 2018 at 3:14 AM Stephen Boyd  wrote:
> >
> > Quoting Masahiro Yamada (2018-12-04 03:03:53)
> > > Hi Stephen,
> > >
> > >
> > > On Fri, Nov 30, 2018 at 5:31 PM Stephen Boyd  wrote:
> > > >
> > > > Quoting Sugaya Taichi (2018-11-18 17:01:12)
> > > > > Add Milbeaut M10V clock ( including PLL ) control.
> > > >
> > > > Please give some more details here.
> > > >
> > > > >
> > > > > Signed-off-by: Sugaya Taichi 
> > > > > ---
> > > > >  drivers/clk/Makefile   |   1 +
> > > > >  drivers/clk/clk-m10v.c | 671 
> > > > > +
> > > >
> > > > And this is different from Uniphier? Maybe we need a socionext
> > > > directory under drivers/clk/.
> > >
> > >
> > >
> > > This is always a difficult question,
> > > and I do not have a strong opinion.
> > >
> > >
> > > I am fine with moving the files to drivers/clk/socionext
> > > although no file would be shared.
> > >
> > >
> > > FYI
> > >
> > > UniPhier and Milbeaut are completely different platforms
> > > developed/maintained by different teams.
> > >
> > > They happen to live in the same company now
> > > just because Socionext merged the LSI business from Panasonic and Fujitsu.
> > >
> > > UniPhier originates in Panasonic, while Milbeaut in Fujitsu.
> > >
> >
> > Thanks for the background info. I'd prefer to defer to however the dts
> > files are getting split up into directories. If they're all put under
> > arch/arm64/boot/dts/socionext/ then I would say combine the two clk
> > drivers into a socionext directory. Otherwise, keep them split out.
> 
> 
> If you want to align with the DT directory structure,
> the answer is clear.
> 
> 
> Milbeaut DT files will be put together with UniPhier ones
> into socionext directory.
> 
> 
> For arm64, DT directories are already sorted out by vendors.
> 
> Even 32-bit ARM is going to that way.
> 
> Rob Herring just posted a python script
> to move all DT files in arch/arm/boot/dts/
> into vendor subdirectories.
> 
> 
> Please let me know if you want me to
> move drivers/clk/uniphier/* to drivers/clk/socionext/*.
> 

Maybe the dts needs to be split up instead? Looks like the gpio drivers
are in a uniphier directory and there is some precedence to keep the
"taken over" company name when vendors are merged into other vendors.
Maybe that's how things have happened here? It would be nice to be
consistent, but I leave the decision up to you to figure out if that
really matters to you. I'll be fine either way.

[PATCH 4/4] ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G

[Jian-Hong Pan]

From: Chris Chiu 

Acer AIO Veriton Z4860G/Z6860G with the same ALC286 codec has issues
with the input from external microphone. The issue can be fixed by
the fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE for Veriton Z4660G.

Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 98f0abaa3540..bb40624fb6d5 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6419,6 +6419,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", 
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14", 
ALC283_FIXUP_CHROME_BOOK),
+   SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+   SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710", 
ALC275_FIXUP_DELL_XPS),
-- 
2.11.0

[PATCH 4/4] ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G

[Jian-Hong Pan]

From: Chris Chiu 

Acer AIO Veriton Z4860G/Z6860G with the same ALC286 codec has issues
with the input from external microphone. The issue can be fixed by
the fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE for Veriton Z4660G.

Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 98f0abaa3540..bb40624fb6d5 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6419,6 +6419,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", 
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14", 
ALC283_FIXUP_CHROME_BOOK),
+   SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+   SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710", 
ALC275_FIXUP_DELL_XPS),
-- 
2.11.0

[PATCH 2/4] ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset mic

[Jian-Hong Pan]

From: Chris Chiu 

The Acer AIO Aspire C24-860 with ALC286 can't detect the headset
microphone. Just like another Acer AIO U27-880, it needs a different
pin value for 0x18 and the headset fixup to make headset mic work.

Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index f21d52eb2ed3..5a7a297546db 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6417,6 +6417,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x0762, "Acer Aspire E1-472", 
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", 
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", 
ALC282_FIXUP_ASPIRE_V5_PINS),
+   SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14", 
ALC283_FIXUP_CHROME_BOOK),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710", 
ALC275_FIXUP_DELL_XPS),
-- 
2.11.0

[PATCH 3/4] ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G

[Jian-Hong Pan]

From: Chris Chiu 

Acer AIO Veriton Z4660G with ALC286 codec has issue with the input
from external microphones connecting via 'Front Mic' jack. The fixup
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE enables the jack sensing of
the headset and fix the audio input issue of external microphone.

Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 5a7a297546db..98f0abaa3540 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6419,6 +6419,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", 
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14", 
ALC283_FIXUP_CHROME_BOOK),
+   SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710", 
ALC275_FIXUP_DELL_XPS),
SND_PCI_QUIRK(0x1028, 0x05bd, "Dell Latitude E6440", 
ALC292_FIXUP_DELL_E7X),
-- 
2.11.0