[PATCH 0/5] ARM: Socionext MB86S71 and Fujitsu F-Cue enablement

[PATCH 0/5] ARM: Socionext MB86S71 and Fujitsu F-Cue enablement

[Andreas Färber]

Hello,

This mini-series adds initial Device Trees for the Socionext MB86S71 SoC and
the Fujitsu F-Cue board. A clk driver and a gpio driver are already merged,
although the clk driver does not build for lack of an scb mailbox driver.
I am not familiar with the circumstances of those older efforts.

My proposal is to disable the build of the clk driver for now. This allows
to introduce the Kconfig symbol without breaking the build.

With the Device Tree added here it is possible to boot into an initrd,
with one CPU core up.

Cf. https://en.opensuse.org/HCL:F-Cue

More experimental patches at:
https://github.com/afaerber/linux/commits/f-cue-next

Have a lot of fun!

Cheers,
Andreas

Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Satoru OKAMOTO <okamoto.satoru@socionext.com>
Cc: devicetree@vger.kernel.org

Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Andy Green <andy.green@linaro.org>
Cc: Vincent Yang <vincent.yang@socionext.com>
Cc: Tetsuya Nuriya <nuriya.tetsuya@socionext.com>
Cc: Michael Turquette <mturquette@linaro.org>
Cc: Stephen Boyd <stephen.boyd@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>

Andreas Färber (5):
  clk: mb86s7x: Suppress build
  ARM: Prepare Socionext MB86S71
  dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: mb86s71-f-cue: Add fake UART0 clock

 .../devicetree/bindings/arm/socionext.txt          |  17 ++
 arch/arm/Kconfig                                   |   2 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/mb86s71-f-cue.dts                |  46 ++++++
 arch/arm/boot/dts/mb86s71.dtsi                     | 178 +++++++++++++++++++++
 arch/arm/mach-mb86s7x/Kconfig                      |  10 ++
 arch/arm/mach-mb86s7x/Makefile                     |   1 +
 drivers/clk/Makefile                               |   2 +-
 9 files changed, 258 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
 create mode 100644 arch/arm/boot/dts/mb86s71-f-cue.dts
 create mode 100644 arch/arm/boot/dts/mb86s71.dtsi
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile

-- 
2.12.3

[PATCH 0/5] ARM: Socionext MB86S71 and Fujitsu F-Cue enablement

[Andreas Färber]

Hello,

This mini-series adds initial Device Trees for the Socionext MB86S71 SoC and
the Fujitsu F-Cue board. A clk driver and a gpio driver are already merged,
although the clk driver does not build for lack of an scb mailbox driver.
I am not familiar with the circumstances of those older efforts.

My proposal is to disable the build of the clk driver for now. This allows
to introduce the Kconfig symbol without breaking the build.

With the Device Tree added here it is possible to boot into an initrd,
with one CPU core up.

Cf. https://en.opensuse.org/HCL:F-Cue

More experimental patches at:
https://github.com/afaerber/linux/commits/f-cue-next

Have a lot of fun!

Cheers,
Andreas

Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Satoru OKAMOTO <okamoto.satoru@socionext.com>
Cc: devicetree at vger.kernel.org

Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Andy Green <andy.green@linaro.org>
Cc: Vincent Yang <vincent.yang@socionext.com>
Cc: Tetsuya Nuriya <nuriya.tetsuya@socionext.com>
Cc: Michael Turquette <mturquette@linaro.org>
Cc: Stephen Boyd <stephen.boyd@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>

Andreas F?rber (5):
  clk: mb86s7x: Suppress build
  ARM: Prepare Socionext MB86S71
  dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: mb86s71-f-cue: Add fake UART0 clock

 .../devicetree/bindings/arm/socionext.txt          |  17 ++
 arch/arm/Kconfig                                   |   2 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/mb86s71-f-cue.dts                |  46 ++++++
 arch/arm/boot/dts/mb86s71.dtsi                     | 178 +++++++++++++++++++++
 arch/arm/mach-mb86s7x/Kconfig                      |  10 ++
 arch/arm/mach-mb86s7x/Makefile                     |   1 +
 drivers/clk/Makefile                               |   2 +-
 9 files changed, 258 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
 create mode 100644 arch/arm/boot/dts/mb86s71-f-cue.dts
 create mode 100644 arch/arm/boot/dts/mb86s71.dtsi
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile

-- 
2.12.3

[PATCH 0/5] ARM: Socionext MB86S71 and Fujitsu F-Cue enablement

[Andreas Färber]

Hello,

This mini-series adds initial Device Trees for the Socionext MB86S71 SoC and
the Fujitsu F-Cue board. A clk driver and a gpio driver are already merged,
although the clk driver does not build for lack of an scb mailbox driver.
I am not familiar with the circumstances of those older efforts.

My proposal is to disable the build of the clk driver for now. This allows
to introduce the Kconfig symbol without breaking the build.

With the Device Tree added here it is possible to boot into an initrd,
with one CPU core up.

Cf. https://en.opensuse.org/HCL:F-Cue

More experimental patches at:
https://github.com/afaerber/linux/commits/f-cue-next

Have a lot of fun!

Cheers,
Andreas

Cc: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Cc: Satoru OKAMOTO <okamoto.satoru-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org

Cc: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Vincent Yang <vincent.yang-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Cc: Tetsuya Nuriya <nuriya.tetsuya-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Cc: Michael Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Andreas Färber (5):
  clk: mb86s7x: Suppress build
  ARM: Prepare Socionext MB86S71
  dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: mb86s71-f-cue: Add fake UART0 clock

 .../devicetree/bindings/arm/socionext.txt          |  17 ++
 arch/arm/Kconfig                                   |   2 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/mb86s71-f-cue.dts                |  46 ++++++
 arch/arm/boot/dts/mb86s71.dtsi                     | 178 +++++++++++++++++++++
 arch/arm/mach-mb86s7x/Kconfig                      |  10 ++
 arch/arm/mach-mb86s7x/Makefile                     |   1 +
 drivers/clk/Makefile                               |   2 +-
 9 files changed, 258 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
 create mode 100644 arch/arm/boot/dts/mb86s71-f-cue.dts
 create mode 100644 arch/arm/boot/dts/mb86s71.dtsi
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile

-- 
2.12.3

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

[PATCH 1/5] clk: mb86s7x: Suppress build

[Andreas Färber]

It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:

  drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
   #include <soc/mb86s7x/scb_mhu.h>
            ^~~~~~~~~~~~~~~~~~~~~~~
  compilation terminated.

And when commenting out that line, we get:

  drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
  drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
    ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
          ^~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
    ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
  drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
  drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
     code = CMD_PERI_CLOCK_RATE_SET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
     code = CMD_PERI_CLOCK_RATE_GET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
            CMD_PERI_CLOCK_RATE_SET_REQ
  drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
  drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
     code = CMD_CPU_CLOCK_RATE_GET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
     code = CMD_CPU_CLOCK_RATE_SET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~
            CMD_CPU_CLOCK_RATE_GET_REQ
  cc1: some warnings being treated as errors
  scripts/Makefile.build:302: recipe for target
  'drivers/clk/clk-mb86s7x.o' failed
  make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1

Comment it out in the Makefile for now.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 drivers/clk/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4f6a812342ed..0f0ab6f03ccd 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_ARCH_EFM32)		+= clk-efm32gg.o
 obj-$(CONFIG_COMMON_CLK_GEMINI)		+= clk-gemini.o
 obj-$(CONFIG_ARCH_HIGHBANK)		+= clk-highbank.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)	+= clk-max77686.o
-obj-$(CONFIG_ARCH_MB86S7X)		+= clk-mb86s7x.o
+#obj-$(CONFIG_ARCH_MB86S7X)		+= clk-mb86s7x.o
 obj-$(CONFIG_ARCH_MOXART)		+= clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK)		+= clk-nomadik.o
 obj-$(CONFIG_ARCH_NSPIRE)		+= clk-nspire.o
-- 
2.12.3

[PATCH 1/5] clk: mb86s7x: Suppress build

[Andreas Färber]

It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:

  drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
   #include <soc/mb86s7x/scb_mhu.h>
            ^~~~~~~~~~~~~~~~~~~~~~~
  compilation terminated.

And when commenting out that line, we get:

  drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
  drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
    ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
          ^~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
    ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
  drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
  drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
     code = CMD_PERI_CLOCK_RATE_SET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
     code = CMD_PERI_CLOCK_RATE_GET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
            CMD_PERI_CLOCK_RATE_SET_REQ
  drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
  drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
     code = CMD_CPU_CLOCK_RATE_GET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
     code = CMD_CPU_CLOCK_RATE_SET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~
            CMD_CPU_CLOCK_RATE_GET_REQ
  cc1: some warnings being treated as errors
  scripts/Makefile.build:302: recipe for target
  'drivers/clk/clk-mb86s7x.o' failed
  make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1

Comment it out in the Makefile for now.

Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
 drivers/clk/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4f6a812342ed..0f0ab6f03ccd 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_ARCH_EFM32)		+= clk-efm32gg.o
 obj-$(CONFIG_COMMON_CLK_GEMINI)		+= clk-gemini.o
 obj-$(CONFIG_ARCH_HIGHBANK)		+= clk-highbank.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)	+= clk-max77686.o
-obj-$(CONFIG_ARCH_MB86S7X)		+= clk-mb86s7x.o
+#obj-$(CONFIG_ARCH_MB86S7X)		+= clk-mb86s7x.o
 obj-$(CONFIG_ARCH_MOXART)		+= clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK)		+= clk-nomadik.o
 obj-$(CONFIG_ARCH_NSPIRE)		+= clk-nspire.o
-- 
2.12.3

Re: [PATCH 1/5] clk: mb86s7x: Suppress build

[Stephen Boyd]

On 06/25, Andreas Färber wrote:
> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
> 
>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>    #include <soc/mb86s7x/scb_mhu.h>
>             ^~~~~~~~~~~~~~~~~~~~~~~
>   compilation terminated.
> 
> And when commenting out that line, we get:
> 
>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>           ^~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
>      code = CMD_PERI_CLOCK_RATE_SET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
>      code = CMD_PERI_CLOCK_RATE_GET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>             CMD_PERI_CLOCK_RATE_SET_REQ
>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
>      code = CMD_CPU_CLOCK_RATE_GET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
>      code = CMD_CPU_CLOCK_RATE_SET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>             CMD_CPU_CLOCK_RATE_GET_REQ
>   cc1: some warnings being treated as errors
>   scripts/Makefile.build:302: recipe for target
>   'drivers/clk/clk-mb86s7x.o' failed
>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
> 
> Comment it out in the Makefile for now.
> 

Why not delete the whole driver instead? It's been two years and
the driver has never compiled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/5] clk: mb86s7x: Suppress build

[Stephen Boyd]

On 06/25, Andreas F?rber wrote:
> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
> 
>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>    #include <soc/mb86s7x/scb_mhu.h>
>             ^~~~~~~~~~~~~~~~~~~~~~~
>   compilation terminated.
> 
> And when commenting out that line, we get:
> 
>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>           ^~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
>      code = CMD_PERI_CLOCK_RATE_SET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
>      code = CMD_PERI_CLOCK_RATE_GET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>             CMD_PERI_CLOCK_RATE_SET_REQ
>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
>      code = CMD_CPU_CLOCK_RATE_GET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
>      code = CMD_CPU_CLOCK_RATE_SET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>             CMD_CPU_CLOCK_RATE_GET_REQ
>   cc1: some warnings being treated as errors
>   scripts/Makefile.build:302: recipe for target
>   'drivers/clk/clk-mb86s7x.o' failed
>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
> 
> Comment it out in the Makefile for now.
> 

Why not delete the whole driver instead? It's been two years and
the driver has never compiled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/5] clk: mb86s7x: Suppress build

[Jassi Brar]

On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 06/25, Andreas Färber wrote:
>> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
>>
>>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>>    #include <soc/mb86s7x/scb_mhu.h>
>>             ^~~~~~~~~~~~~~~~~~~~~~~
>>   compilation terminated.
>>
>> And when commenting out that line, we get:
>>
>>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
>>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
>>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>>           ^~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
>>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
>>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
>>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
>>      code = CMD_PERI_CLOCK_RATE_SET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
>>      code = CMD_PERI_CLOCK_RATE_GET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>             CMD_PERI_CLOCK_RATE_SET_REQ
>>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
>>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
>>      code = CMD_CPU_CLOCK_RATE_GET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
>>      code = CMD_CPU_CLOCK_RATE_SET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>>             CMD_CPU_CLOCK_RATE_GET_REQ
>>   cc1: some warnings being treated as errors
>>   scripts/Makefile.build:302: recipe for target
>>   'drivers/clk/clk-mb86s7x.o' failed
>>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
>>
>> Comment it out in the Makefile for now.
>>
>
> Why not delete the whole driver instead? It's been two years and
> the driver has never compiled.
>
I won't complain. The interest of moving powers evaporated in the
midst of upstreaming. Though some next platform is supposed to reuse
the IPs, but I can't say when will that be upstreamed and by whom.

Regards.

[PATCH 1/5] clk: mb86s7x: Suppress build

[Jassi Brar]

On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 06/25, Andreas F?rber wrote:
>> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
>>
>>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>>    #include <soc/mb86s7x/scb_mhu.h>
>>             ^~~~~~~~~~~~~~~~~~~~~~~
>>   compilation terminated.
>>
>> And when commenting out that line, we get:
>>
>>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
>>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
>>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>>           ^~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
>>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
>>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
>>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
>>      code = CMD_PERI_CLOCK_RATE_SET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
>>      code = CMD_PERI_CLOCK_RATE_GET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>             CMD_PERI_CLOCK_RATE_SET_REQ
>>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
>>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
>>      code = CMD_CPU_CLOCK_RATE_GET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
>>      code = CMD_CPU_CLOCK_RATE_SET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>>             CMD_CPU_CLOCK_RATE_GET_REQ
>>   cc1: some warnings being treated as errors
>>   scripts/Makefile.build:302: recipe for target
>>   'drivers/clk/clk-mb86s7x.o' failed
>>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
>>
>> Comment it out in the Makefile for now.
>>
>
> Why not delete the whole driver instead? It's been two years and
> the driver has never compiled.
>
I won't complain. The interest of moving powers evaporated in the
midst of upstreaming. Though some next platform is supposed to reuse
the IPs, but I can't say when will that be upstreamed and by whom.

Regards.

Re: [PATCH 1/5] clk: mb86s7x: Suppress build

[Jassi Brar]

On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 06/25, Andreas F=C3=A4rber wrote:
>> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
>>
>>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: N=
o such file or directory
>>    #include <soc/mb86s7x/scb_mhu.h>
>>             ^~~~~~~~~~~~~~~~~~~~~~~
>>   compilation terminated.
>>
>> And when commenting out that line, we get:
>>
>>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
>>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of functio=
n 'mb86s7x_send_packet' [-Werror=3Dimplicit-function-declaration]
>>     ret =3D mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>>           ^~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' =
undeclared (first use in this function)
>>     ret =3D mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is r=
eported only once for each function it appears in
>>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
>>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ'=
 undeclared (first use in this function)
>>      code =3D CMD_PERI_CLOCK_RATE_SET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ'=
 undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE=
_SET_REQ'?
>>      code =3D CMD_PERI_CLOCK_RATE_GET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>             CMD_PERI_CLOCK_RATE_SET_REQ
>>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
>>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' =
undeclared (first use in this function)
>>      code =3D CMD_CPU_CLOCK_RATE_GET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' =
undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_G=
ET_REQ'?
>>      code =3D CMD_CPU_CLOCK_RATE_SET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>>             CMD_CPU_CLOCK_RATE_GET_REQ
>>   cc1: some warnings being treated as errors
>>   scripts/Makefile.build:302: recipe for target
>>   'drivers/clk/clk-mb86s7x.o' failed
>>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
>>
>> Comment it out in the Makefile for now.
>>
>
> Why not delete the whole driver instead? It's been two years and
> the driver has never compiled.
>
I won't complain. The interest of moving powers evaporated in the
midst of upstreaming. Though some next platform is supposed to reuse
the IPs, but I can't say when will that be upstreamed and by whom.

Regards.

Re: [PATCH 1/5] clk: mb86s7x: Suppress build

[Stephen Boyd]

On 06/28, Jassi Brar wrote:
> On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 06/25, Andreas Färber wrote:
> >> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
> >>
> >>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
> >>    #include <soc/mb86s7x/scb_mhu.h>
> >>             ^~~~~~~~~~~~~~~~~~~~~~~
> >>   compilation terminated.
> >>
> >> And when commenting out that line, we get:
> >>
> >>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
> >>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
> >>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
> >>           ^~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
> >>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
> >>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
> >>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
> >>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
> >>      code = CMD_PERI_CLOCK_RATE_SET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
> >>      code = CMD_PERI_CLOCK_RATE_GET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>             CMD_PERI_CLOCK_RATE_SET_REQ
> >>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
> >>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
> >>      code = CMD_CPU_CLOCK_RATE_GET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
> >>      code = CMD_CPU_CLOCK_RATE_SET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >>             CMD_CPU_CLOCK_RATE_GET_REQ
> >>   cc1: some warnings being treated as errors
> >>   scripts/Makefile.build:302: recipe for target
> >>   'drivers/clk/clk-mb86s7x.o' failed
> >>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
> >>
> >> Comment it out in the Makefile for now.
> >>
> >
> > Why not delete the whole driver instead? It's been two years and
> > the driver has never compiled.
> >
> I won't complain. The interest of moving powers evaporated in the
> midst of upstreaming. Though some next platform is supposed to reuse
> the IPs, but I can't say when will that be upstreamed and by whom.
> 

Thanks for the info.

Andreas, can you send a deletion patch instead?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/5] clk: mb86s7x: Suppress build

[Stephen Boyd]

On 06/28, Jassi Brar wrote:
> On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 06/25, Andreas F?rber wrote:
> >> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
> >>
> >>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
> >>    #include <soc/mb86s7x/scb_mhu.h>
> >>             ^~~~~~~~~~~~~~~~~~~~~~~
> >>   compilation terminated.
> >>
> >> And when commenting out that line, we get:
> >>
> >>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
> >>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
> >>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
> >>           ^~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
> >>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
> >>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
> >>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
> >>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
> >>      code = CMD_PERI_CLOCK_RATE_SET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
> >>      code = CMD_PERI_CLOCK_RATE_GET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>             CMD_PERI_CLOCK_RATE_SET_REQ
> >>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
> >>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
> >>      code = CMD_CPU_CLOCK_RATE_GET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
> >>      code = CMD_CPU_CLOCK_RATE_SET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >>             CMD_CPU_CLOCK_RATE_GET_REQ
> >>   cc1: some warnings being treated as errors
> >>   scripts/Makefile.build:302: recipe for target
> >>   'drivers/clk/clk-mb86s7x.o' failed
> >>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
> >>
> >> Comment it out in the Makefile for now.
> >>
> >
> > Why not delete the whole driver instead? It's been two years and
> > the driver has never compiled.
> >
> I won't complain. The interest of moving powers evaporated in the
> midst of upstreaming. Though some next platform is supposed to reuse
> the IPs, but I can't say when will that be upstreamed and by whom.
> 

Thanks for the info.

Andreas, can you send a deletion patch instead?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/5] clk: mb86s7x: Suppress build

[Andreas Färber]

Am 29.06.2017 um 00:29 schrieb Stephen Boyd:
> On 06/28, Jassi Brar wrote:
>> On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
>>> On 06/25, Andreas Färber wrote:
>>>> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
>>>>
>>>>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>>>>    #include <soc/mb86s7x/scb_mhu.h>
>>>>             ^~~~~~~~~~~~~~~~~~~~~~~
>>>>   compilation terminated.
[...]
>>>> Comment it out in the Makefile for now.
>>>>
>>>
>>> Why not delete the whole driver instead? It's been two years and
>>> the driver has never compiled.
>>>
>> I won't complain. The interest of moving powers evaporated in the
>> midst of upstreaming. Though some next platform is supposed to reuse
>> the IPs, but I can't say when will that be upstreamed and by whom.

Satoru-san is in CC to comment on that aspect. :)

> Thanks for the info.
> 
> Andreas, can you send a deletion patch instead?

I can.

But obviously the idea is to follow-up on this initial series with an
scb mailbox driver (which is blocking both clk and PM domains drivers)
and to either resolve the compilation failure by adding the expected
symbols or to update the clk driver to build against a new driver.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[PATCH 1/5] clk: mb86s7x: Suppress build

[Andreas Färber]

Am 29.06.2017 um 00:29 schrieb Stephen Boyd:
> On 06/28, Jassi Brar wrote:
>> On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
>>> On 06/25, Andreas F?rber wrote:
>>>> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
>>>>
>>>>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>>>>    #include <soc/mb86s7x/scb_mhu.h>
>>>>             ^~~~~~~~~~~~~~~~~~~~~~~
>>>>   compilation terminated.
[...]
>>>> Comment it out in the Makefile for now.
>>>>
>>>
>>> Why not delete the whole driver instead? It's been two years and
>>> the driver has never compiled.
>>>
>> I won't complain. The interest of moving powers evaporated in the
>> midst of upstreaming. Though some next platform is supposed to reuse
>> the IPs, but I can't say when will that be upstreamed and by whom.

Satoru-san is in CC to comment on that aspect. :)

> Thanks for the info.
> 
> Andreas, can you send a deletion patch instead?

I can.

But obviously the idea is to follow-up on this initial series with an
scb mailbox driver (which is blocking both clk and PM domains drivers)
and to either resolve the compilation failure by adding the expected
symbols or to update the clk driver to build against a new driver.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH 1/5] clk: mb86s7x: Suppress build

[Andreas Färber]

Am 29.06.2017 um 00:29 schrieb Stephen Boyd:
> On 06/28, Jassi Brar wrote:
>> On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
>>> On 06/25, Andreas Färber wrote:
>>>> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
>>>>
>>>>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>>>>    #include <soc/mb86s7x/scb_mhu.h>
>>>>             ^~~~~~~~~~~~~~~~~~~~~~~
>>>>   compilation terminated.
[...]
>>>> Comment it out in the Makefile for now.
>>>>
>>>
>>> Why not delete the whole driver instead? It's been two years and
>>> the driver has never compiled.
>>>
>> I won't complain. The interest of moving powers evaporated in the
>> midst of upstreaming. Though some next platform is supposed to reuse
>> the IPs, but I can't say when will that be upstreamed and by whom.

Satoru-san is in CC to comment on that aspect. :)

> Thanks for the info.
> 
> Andreas, can you send a deletion patch instead?

I can.

But obviously the idea is to follow-up on this initial series with an
scb mailbox driver (which is blocking both clk and PM domains drivers)
and to either resolve the compilation failure by adding the expected
symbols or to update the clk driver to build against a new driver.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[PATCH 2/5] ARM: Prepare Socionext MB86S71

[Andreas Färber]

Introduce CONFIG_ARCH_MB86S7X, which was already being used.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 arch/arm/Kconfig               |  2 ++
 arch/arm/Makefile              |  1 +
 arch/arm/mach-mb86s7x/Kconfig  | 10 ++++++++++
 arch/arm/mach-mb86s7x/Makefile |  1 +
 4 files changed, 14 insertions(+)
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f77c77556..cbf56aa0a9e5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -763,6 +763,8 @@ source "arch/arm/mach-keystone/Kconfig"
 
 source "arch/arm/mach-ks8695/Kconfig"
 
+source "arch/arm/mach-mb86s7x/Kconfig"
+
 source "arch/arm/mach-meson/Kconfig"
 
 source "arch/arm/mach-moxart/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..d728548e0e59 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -180,6 +180,7 @@ machine-$(CONFIG_ARCH_KEYSTONE)		+= keystone
 machine-$(CONFIG_ARCH_KS8695)		+= ks8695
 machine-$(CONFIG_ARCH_LPC18XX)		+= lpc18xx
 machine-$(CONFIG_ARCH_LPC32XX)		+= lpc32xx
+machine-$(CONFIG_ARCH_MB86S7X)		+= mb86s7x
 machine-$(CONFIG_ARCH_MESON)		+= meson
 machine-$(CONFIG_ARCH_MMP)		+= mmp
 machine-$(CONFIG_ARCH_MPS2)		+= vexpress
diff --git a/arch/arm/mach-mb86s7x/Kconfig b/arch/arm/mach-mb86s7x/Kconfig
new file mode 100644
index 000000000000..8fe81bb7da0d
--- /dev/null
+++ b/arch/arm/mach-mb86s7x/Kconfig
@@ -0,0 +1,10 @@
+config ARCH_MB86S7X
+	bool "Socionext MB86S7x SoCs"
+	depends on ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GLOBAL_TIMER
+	select ARM_GIC
+	select HAVE_ARM_SCU
+	select HAVE_ARM_TWD if SMP
+	help
+	  Support for MB86S71 SoC family developed by Socionext Inc.
diff --git a/arch/arm/mach-mb86s7x/Makefile b/arch/arm/mach-mb86s7x/Makefile
new file mode 100644
index 000000000000..6bea3d3a2dd7
--- /dev/null
+++ b/arch/arm/mach-mb86s7x/Makefile
@@ -0,0 +1 @@
+obj- += dummy.o
-- 
2.12.3

[PATCH 2/5] ARM: Prepare Socionext MB86S71

[Andreas Färber]

Introduce CONFIG_ARCH_MB86S7X, which was already being used.

Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
 arch/arm/Kconfig               |  2 ++
 arch/arm/Makefile              |  1 +
 arch/arm/mach-mb86s7x/Kconfig  | 10 ++++++++++
 arch/arm/mach-mb86s7x/Makefile |  1 +
 4 files changed, 14 insertions(+)
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f77c77556..cbf56aa0a9e5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -763,6 +763,8 @@ source "arch/arm/mach-keystone/Kconfig"
 
 source "arch/arm/mach-ks8695/Kconfig"
 
+source "arch/arm/mach-mb86s7x/Kconfig"
+
 source "arch/arm/mach-meson/Kconfig"
 
 source "arch/arm/mach-moxart/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..d728548e0e59 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -180,6 +180,7 @@ machine-$(CONFIG_ARCH_KEYSTONE)		+= keystone
 machine-$(CONFIG_ARCH_KS8695)		+= ks8695
 machine-$(CONFIG_ARCH_LPC18XX)		+= lpc18xx
 machine-$(CONFIG_ARCH_LPC32XX)		+= lpc32xx
+machine-$(CONFIG_ARCH_MB86S7X)		+= mb86s7x
 machine-$(CONFIG_ARCH_MESON)		+= meson
 machine-$(CONFIG_ARCH_MMP)		+= mmp
 machine-$(CONFIG_ARCH_MPS2)		+= vexpress
diff --git a/arch/arm/mach-mb86s7x/Kconfig b/arch/arm/mach-mb86s7x/Kconfig
new file mode 100644
index 000000000000..8fe81bb7da0d
--- /dev/null
+++ b/arch/arm/mach-mb86s7x/Kconfig
@@ -0,0 +1,10 @@
+config ARCH_MB86S7X
+	bool "Socionext MB86S7x SoCs"
+	depends on ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GLOBAL_TIMER
+	select ARM_GIC
+	select HAVE_ARM_SCU
+	select HAVE_ARM_TWD if SMP
+	help
+	  Support for MB86S71 SoC family developed by Socionext Inc.
diff --git a/arch/arm/mach-mb86s7x/Makefile b/arch/arm/mach-mb86s7x/Makefile
new file mode 100644
index 000000000000..6bea3d3a2dd7
--- /dev/null
+++ b/arch/arm/mach-mb86s7x/Makefile
@@ -0,0 +1 @@
+obj- += dummy.o
-- 
2.12.3

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
socionext.txt.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt

diff --git a/Documentation/devicetree/bindings/arm/socionext.txt b/Documentation/devicetree/bindings/arm/socionext.txt
new file mode 100644
index 000000000000..63227fe7b773
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/socionext.txt
@@ -0,0 +1,17 @@
+Socionext platforms device tree bindings
+----------------------------------------
+
+
+MB86S7x SoC
+===========
+
+Required root node properties:
+
+ - compatible :  must contain "fujitsu,mb86s71" for MB86S71
+
+
+Boards:
+
+Root node property compatible must contain, depending on board:
+
+ - Fujitsu F-Cue: "fujitsu,f-cue"
-- 
2.12.3

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
socionext.txt.

Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
 Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt

diff --git a/Documentation/devicetree/bindings/arm/socionext.txt b/Documentation/devicetree/bindings/arm/socionext.txt
new file mode 100644
index 000000000000..63227fe7b773
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/socionext.txt
@@ -0,0 +1,17 @@
+Socionext platforms device tree bindings
+----------------------------------------
+
+
+MB86S7x SoC
+===========
+
+Required root node properties:
+
+ - compatible :  must contain "fujitsu,mb86s71" for MB86S71
+
+
+Boards:
+
+Root node property compatible must contain, depending on board:
+
+ - Fujitsu F-Cue: "fujitsu,f-cue"
-- 
2.12.3

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
socionext.txt.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt

diff --git a/Documentation/devicetree/bindings/arm/socionext.txt b/Documentation/devicetree/bindings/arm/socionext.txt
new file mode 100644
index 000000000000..63227fe7b773
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/socionext.txt
@@ -0,0 +1,17 @@
+Socionext platforms device tree bindings
+----------------------------------------
+
+
+MB86S7x SoC
+===========
+
+Required root node properties:
+
+ - compatible :  must contain "fujitsu,mb86s71" for MB86S71
+
+
+Boards:
+
+Root node property compatible must contain, depending on board:
+
+ - Fujitsu F-Cue: "fujitsu,f-cue"
-- 
2.12.3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Rob Herring]

On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
> socionext.txt.
> 
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt

Acked-by: Rob Herring <robh@kernel.org>

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Rob Herring]

On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
> socionext.txt.
> 
> Signed-off-by: Andreas F?rber <afaerber@suse.de>
> ---
>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Rob Herring]

On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
> socionext.txt.
> 
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Masahiro Yamada]

2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>> socionext.txt.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>
> Acked-by: Rob Herring <robh@kernel.org>
> --

I do not mind this, but
please note there are multiple product lines in Socionext
because Socionext merged LSI divisions from Panasonic and Fujitsu.

I maintain documents for Socionext UniPhier SoC family
(which inherits SoC architecture of Panasonic)
in Documentation/devicetree/bindings/arm/uniphier/.





-- 
Best Regards
Masahiro Yamada

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Masahiro Yamada]

2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>> socionext.txt.
>>
>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>> ---
>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>
> Acked-by: Rob Herring <robh@kernel.org>
> --

I do not mind this, but
please note there are multiple product lines in Socionext
because Socionext merged LSI divisions from Panasonic and Fujitsu.

I maintain documents for Socionext UniPhier SoC family
(which inherits SoC architecture of Panasonic)
in Documentation/devicetree/bindings/arm/uniphier/.





-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Masahiro Yamada]

2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>> socionext.txt.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>
> Acked-by: Rob Herring <robh@kernel.org>
> --

I do not mind this, but
please note there are multiple product lines in Socionext
because Socionext merged LSI divisions from Panasonic and Fujitsu.

I maintain documents for Socionext UniPhier SoC family
(which inherits SoC architecture of Panasonic)
in Documentation/devicetree/bindings/arm/uniphier/.





-- 
Best Regards
Masahiro Yamada

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Hi Masahiro-san,

Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>> socionext.txt.
>>>
>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>> ---
>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>  1 file changed, 17 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>> --
> 
> I do not mind this, but
> please note there are multiple product lines in Socionext
> because Socionext merged LSI divisions from Panasonic and Fujitsu.
> 
> I maintain documents for Socionext UniPhier SoC family
> (which inherits SoC architecture of Panasonic)
> in Documentation/devicetree/bindings/arm/uniphier/.

Actually you seemed to be lacking bindings beyond the cache controller
for Uniphier:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier

The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
somewhere too, as done here. A git-grep for that particular compatible
only finds derived clk and reset bindings.

Using socionext.txt allows you to add those bindings to a shared file;
if you prefer to host them separately below uniphier/ or as uniphier.txt
do you have a better name suggestion for this one? I was trying to keep
our options open to later add SC2A11 in socionext.txt, and I also saw
some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
don't know a good common name for the non-Panasonic parts. And if we
take fujitsu.txt for MB86S7x to match the vendor prefix then we will
need a separate file for the new SC2A11 IIUC.

Also if you can tell us where the cut between Fujitsu and Socionext
should be done, we can certainly adapt. NXP is still adding all their
new SoCs in fsl.txt, it seems.
(A similar naming issue exists for my not-yet-submitted FM4 patches,
where it changed owners from Fujitsu to Spansion and then to Cypress.)

Best regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Hi Masahiro-san,

Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>> socionext.txt.
>>>
>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>> ---
>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>  1 file changed, 17 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>> --
> 
> I do not mind this, but
> please note there are multiple product lines in Socionext
> because Socionext merged LSI divisions from Panasonic and Fujitsu.
> 
> I maintain documents for Socionext UniPhier SoC family
> (which inherits SoC architecture of Panasonic)
> in Documentation/devicetree/bindings/arm/uniphier/.

Actually you seemed to be lacking bindings beyond the cache controller
for Uniphier:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier

The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
somewhere too, as done here. A git-grep for that particular compatible
only finds derived clk and reset bindings.

Using socionext.txt allows you to add those bindings to a shared file;
if you prefer to host them separately below uniphier/ or as uniphier.txt
do you have a better name suggestion for this one? I was trying to keep
our options open to later add SC2A11 in socionext.txt, and I also saw
some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
don't know a good common name for the non-Panasonic parts. And if we
take fujitsu.txt for MB86S7x to match the vendor prefix then we will
need a separate file for the new SC2A11 IIUC.

Also if you can tell us where the cut between Fujitsu and Socionext
should be done, we can certainly adapt. NXP is still adding all their
new SoCs in fsl.txt, it seems.
(A similar naming issue exists for my not-yet-submitted FM4 patches,
where it changed owners from Fujitsu to Spansion and then to Cypress.)

Best regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Hi Masahiro-san,

Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>> socionext.txt.
>>>
>>> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
>>> ---
>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>  1 file changed, 17 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> --
> 
> I do not mind this, but
> please note there are multiple product lines in Socionext
> because Socionext merged LSI divisions from Panasonic and Fujitsu.
> 
> I maintain documents for Socionext UniPhier SoC family
> (which inherits SoC architecture of Panasonic)
> in Documentation/devicetree/bindings/arm/uniphier/.

Actually you seemed to be lacking bindings beyond the cache controller
for Uniphier:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier

The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
somewhere too, as done here. A git-grep for that particular compatible
only finds derived clk and reset bindings.

Using socionext.txt allows you to add those bindings to a shared file;
if you prefer to host them separately below uniphier/ or as uniphier.txt
do you have a better name suggestion for this one? I was trying to keep
our options open to later add SC2A11 in socionext.txt, and I also saw
some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
don't know a good common name for the non-Panasonic parts. And if we
take fujitsu.txt for MB86S7x to match the vendor prefix then we will
need a separate file for the new SC2A11 IIUC.

Also if you can tell us where the cut between Fujitsu and Socionext
should be done, we can certainly adapt. NXP is still adding all their
new SoCs in fsl.txt, it seems.
(A similar naming issue exists for my not-yet-submitted FM4 patches,
where it changed owners from Fujitsu to Spansion and then to Cypress.)

Best regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Masahiro Yamada]

Hi Andreas,


2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
> Hi Masahiro-san,
>
> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>> socionext.txt.
>>>>
>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>  1 file changed, 17 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> --
>>
>> I do not mind this, but
>> please note there are multiple product lines in Socionext
>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>
>> I maintain documents for Socionext UniPhier SoC family
>> (which inherits SoC architecture of Panasonic)
>> in Documentation/devicetree/bindings/arm/uniphier/.
>
> Actually you seemed to be lacking bindings beyond the cache controller
> for Uniphier:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>
> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
> somewhere too, as done here. A git-grep for that particular compatible
> only finds derived clk and reset bindings.

I can care to send a patch later, but it is off-topic here.


> Using socionext.txt allows you to add those bindings to a shared file;
> if you prefer to host them separately below uniphier/ or as uniphier.txt

I was thinking of this way.

For example, TI has omap/, keystone/, davinci.txt, etc.
in this directory level.


> do you have a better name suggestion for this one? I was trying to keep
> our options open to later add SC2A11 in socionext.txt, and I also saw
> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
> don't know a good common name for the non-Panasonic parts. And if we
> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
> need a separate file for the new SC2A11 IIUC.

I have no idea.
Actually, I am not familiar with those SoCs.

I am not sure if there exists a common name for those Fujitsu-derived SoCs.
I think a SoC family name will be helpful to avoid proliferating
arch/arm/mach-{mb86s7x,mb8ac300, ...}.

I see some Socionext guys CC'ed in this mail,
somebody might have information about this.

As I said before, I do not mind adding socionext.txt
and it seems reasonable enough
if there is no common name for those SoCs.



> Also if you can tell us where the cut between Fujitsu and Socionext
> should be done, we can certainly adapt. NXP is still adding all their
> new SoCs in fsl.txt, it seems.
> (A similar naming issue exists for my not-yet-submitted FM4 patches,
> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>

Right, vendor names are not future-proof in some cases.

We use "uniphier" because it is convenient to
make a group of SoCs with similar architecture,
and it will work even if UniPhier product lines are sold again in the
future.  :-)



-- 
Best Regards
Masahiro Yamada

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Masahiro Yamada]

Hi Andreas,


2017-06-29 21:53 GMT+09:00 Andreas F?rber <afaerber@suse.de>:
> Hi Masahiro-san,
>
> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>> socionext.txt.
>>>>
>>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>  1 file changed, 17 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> --
>>
>> I do not mind this, but
>> please note there are multiple product lines in Socionext
>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>
>> I maintain documents for Socionext UniPhier SoC family
>> (which inherits SoC architecture of Panasonic)
>> in Documentation/devicetree/bindings/arm/uniphier/.
>
> Actually you seemed to be lacking bindings beyond the cache controller
> for Uniphier:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>
> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
> somewhere too, as done here. A git-grep for that particular compatible
> only finds derived clk and reset bindings.

I can care to send a patch later, but it is off-topic here.


> Using socionext.txt allows you to add those bindings to a shared file;
> if you prefer to host them separately below uniphier/ or as uniphier.txt

I was thinking of this way.

For example, TI has omap/, keystone/, davinci.txt, etc.
in this directory level.


> do you have a better name suggestion for this one? I was trying to keep
> our options open to later add SC2A11 in socionext.txt, and I also saw
> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
> don't know a good common name for the non-Panasonic parts. And if we
> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
> need a separate file for the new SC2A11 IIUC.

I have no idea.
Actually, I am not familiar with those SoCs.

I am not sure if there exists a common name for those Fujitsu-derived SoCs.
I think a SoC family name will be helpful to avoid proliferating
arch/arm/mach-{mb86s7x,mb8ac300, ...}.

I see some Socionext guys CC'ed in this mail,
somebody might have information about this.

As I said before, I do not mind adding socionext.txt
and it seems reasonable enough
if there is no common name for those SoCs.



> Also if you can tell us where the cut between Fujitsu and Socionext
> should be done, we can certainly adapt. NXP is still adding all their
> new SoCs in fsl.txt, it seems.
> (A similar naming issue exists for my not-yet-submitted FM4 patches,
> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>

Right, vendor names are not future-proof in some cases.

We use "uniphier" because it is convenient to
make a group of SoCs with similar architecture,
and it will work even if UniPhier product lines are sold again in the
future.  :-)



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Masahiro Yamada]

Hi Andreas,


2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>:
> Hi Masahiro-san,
>
> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>> socionext.txt.
>>>>
>>>> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>  1 file changed, 17 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>
>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> --
>>
>> I do not mind this, but
>> please note there are multiple product lines in Socionext
>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>
>> I maintain documents for Socionext UniPhier SoC family
>> (which inherits SoC architecture of Panasonic)
>> in Documentation/devicetree/bindings/arm/uniphier/.
>
> Actually you seemed to be lacking bindings beyond the cache controller
> for Uniphier:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>
> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
> somewhere too, as done here. A git-grep for that particular compatible
> only finds derived clk and reset bindings.

I can care to send a patch later, but it is off-topic here.


> Using socionext.txt allows you to add those bindings to a shared file;
> if you prefer to host them separately below uniphier/ or as uniphier.txt

I was thinking of this way.

For example, TI has omap/, keystone/, davinci.txt, etc.
in this directory level.


> do you have a better name suggestion for this one? I was trying to keep
> our options open to later add SC2A11 in socionext.txt, and I also saw
> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
> don't know a good common name for the non-Panasonic parts. And if we
> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
> need a separate file for the new SC2A11 IIUC.

I have no idea.
Actually, I am not familiar with those SoCs.

I am not sure if there exists a common name for those Fujitsu-derived SoCs.
I think a SoC family name will be helpful to avoid proliferating
arch/arm/mach-{mb86s7x,mb8ac300, ...}.

I see some Socionext guys CC'ed in this mail,
somebody might have information about this.

As I said before, I do not mind adding socionext.txt
and it seems reasonable enough
if there is no common name for those SoCs.



> Also if you can tell us where the cut between Fujitsu and Socionext
> should be done, we can certainly adapt. NXP is still adding all their
> new SoCs in fsl.txt, it seems.
> (A similar naming issue exists for my not-yet-submitted FM4 patches,
> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>

Right, vendor names are not future-proof in some cases.

We use "uniphier" because it is convenient to
make a group of SoCs with similar architecture,
and it will work even if UniPhier product lines are sold again in the
future.  :-)



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Hi everyone,

The non-building clk driver has been removed for 4.14, but this patchset
seems stuck on matters of naming and maintenance...

Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
> Hi Andreas,
> 
> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
>> Hi Masahiro-san,
>>
>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>> socionext.txt.
>>>>>
>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>  1 file changed, 17 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>
>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>> --
>>>
>>> I do not mind this, but
>>> please note there are multiple product lines in Socionext
>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>
>>> I maintain documents for Socionext UniPhier SoC family
>>> (which inherits SoC architecture of Panasonic)
>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>
>> Actually you seemed to be lacking bindings beyond the cache controller
>> for Uniphier:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>
>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>> somewhere too, as done here. A git-grep for that particular compatible
>> only finds derived clk and reset bindings.
> 
> I can care to send a patch later, but it is off-topic here.

[The relevance was that had there been any bindings precedence from
UniPhier, it would've influenced my naming choices.]

>> Using socionext.txt allows you to add those bindings to a shared file;
>> if you prefer to host them separately below uniphier/ or as uniphier.txt
> 
> I was thinking of this way.
> 
> For example, TI has omap/, keystone/, davinci.txt, etc.
> in this directory level.
> 
> 
>> do you have a better name suggestion for this one? I was trying to keep
>> our options open to later add SC2A11 in socionext.txt, and I also saw
>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>> don't know a good common name for the non-Panasonic parts. And if we
>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>> need a separate file for the new SC2A11 IIUC.
> 
> I have no idea.
> Actually, I am not familiar with those SoCs.
> 
> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
> I think a SoC family name will be helpful to avoid proliferating
> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
> 
> I see some Socionext guys CC'ed in this mail,
> somebody might have information about this.
> 
> As I said before, I do not mind adding socionext.txt
> and it seems reasonable enough
> if there is no common name for those SoCs.
> 
> 
> 
>> Also if you can tell us where the cut between Fujitsu and Socionext
>> should be done, we can certainly adapt. NXP is still adding all their
>> new SoCs in fsl.txt, it seems.
>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>
> 
> Right, vendor names are not future-proof in some cases.
> 
> We use "uniphier" because it is convenient to
> make a group of SoCs with similar architecture,
> and it will work even if UniPhier product lines are sold again in the
> future.  :-)

Summarizing: Masahiro-san only wants to maintain the UniPhier family of
Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
volunteered as maintainer for these F-Cue MB86S71 patches - that seems
to indicate I'll again have to set up a new repository and start
maintaining it myself.

Naming it linux-socionext.git wouldn't quite be right due to UniPhier
also being Socionext.

It's also unclear whether and by whom there may be SC2A11 patches - I
hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
against linux.git.

So... what about naming it linux-fujitsu.git? Then we could keep the
"fujitsu," vendor prefix and document compatibles in a fujitsu.txt for
consistency (instead of this v1's socionext.txt), and I could later add
non-Socionext FM4 (Spansion/Cypress) to the same tree and bindings file.

That still leaves conflict potential with the upcoming Fujitsu Post-K
chip, but we could still worry about that if it ever results in DT
bindings patches rather than just ACPI tables.

Objections, suggestions?

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Hi everyone,

The non-building clk driver has been removed for 4.14, but this patchset
seems stuck on matters of naming and maintenance...

Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
> Hi Andreas,
> 
> 2017-06-29 21:53 GMT+09:00 Andreas F?rber <afaerber@suse.de>:
>> Hi Masahiro-san,
>>
>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>> socionext.txt.
>>>>>
>>>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>  1 file changed, 17 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>
>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>> --
>>>
>>> I do not mind this, but
>>> please note there are multiple product lines in Socionext
>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>
>>> I maintain documents for Socionext UniPhier SoC family
>>> (which inherits SoC architecture of Panasonic)
>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>
>> Actually you seemed to be lacking bindings beyond the cache controller
>> for Uniphier:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>
>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>> somewhere too, as done here. A git-grep for that particular compatible
>> only finds derived clk and reset bindings.
> 
> I can care to send a patch later, but it is off-topic here.

[The relevance was that had there been any bindings precedence from
UniPhier, it would've influenced my naming choices.]

>> Using socionext.txt allows you to add those bindings to a shared file;
>> if you prefer to host them separately below uniphier/ or as uniphier.txt
> 
> I was thinking of this way.
> 
> For example, TI has omap/, keystone/, davinci.txt, etc.
> in this directory level.
> 
> 
>> do you have a better name suggestion for this one? I was trying to keep
>> our options open to later add SC2A11 in socionext.txt, and I also saw
>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>> don't know a good common name for the non-Panasonic parts. And if we
>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>> need a separate file for the new SC2A11 IIUC.
> 
> I have no idea.
> Actually, I am not familiar with those SoCs.
> 
> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
> I think a SoC family name will be helpful to avoid proliferating
> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
> 
> I see some Socionext guys CC'ed in this mail,
> somebody might have information about this.
> 
> As I said before, I do not mind adding socionext.txt
> and it seems reasonable enough
> if there is no common name for those SoCs.
> 
> 
> 
>> Also if you can tell us where the cut between Fujitsu and Socionext
>> should be done, we can certainly adapt. NXP is still adding all their
>> new SoCs in fsl.txt, it seems.
>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>
> 
> Right, vendor names are not future-proof in some cases.
> 
> We use "uniphier" because it is convenient to
> make a group of SoCs with similar architecture,
> and it will work even if UniPhier product lines are sold again in the
> future.  :-)

Summarizing: Masahiro-san only wants to maintain the UniPhier family of
Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
volunteered as maintainer for these F-Cue MB86S71 patches - that seems
to indicate I'll again have to set up a new repository and start
maintaining it myself.

Naming it linux-socionext.git wouldn't quite be right due to UniPhier
also being Socionext.

It's also unclear whether and by whom there may be SC2A11 patches - I
hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
against linux.git.

So... what about naming it linux-fujitsu.git? Then we could keep the
"fujitsu," vendor prefix and document compatibles in a fujitsu.txt for
consistency (instead of this v1's socionext.txt), and I could later add
non-Socionext FM4 (Spansion/Cypress) to the same tree and bindings file.

That still leaves conflict potential with the upcoming Fujitsu Post-K
chip, but we could still worry about that if it ever results in DT
bindings patches rather than just ACPI tables.

Objections, suggestions?

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Hi everyone,

The non-building clk driver has been removed for 4.14, but this patchset
seems stuck on matters of naming and maintenance...

Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
> Hi Andreas,
> 
> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>:
>> Hi Masahiro-san,
>>
>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>> socionext.txt.
>>>>>
>>>>> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>  1 file changed, 17 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>
>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>> --
>>>
>>> I do not mind this, but
>>> please note there are multiple product lines in Socionext
>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>
>>> I maintain documents for Socionext UniPhier SoC family
>>> (which inherits SoC architecture of Panasonic)
>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>
>> Actually you seemed to be lacking bindings beyond the cache controller
>> for Uniphier:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>
>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>> somewhere too, as done here. A git-grep for that particular compatible
>> only finds derived clk and reset bindings.
> 
> I can care to send a patch later, but it is off-topic here.

[The relevance was that had there been any bindings precedence from
UniPhier, it would've influenced my naming choices.]

>> Using socionext.txt allows you to add those bindings to a shared file;
>> if you prefer to host them separately below uniphier/ or as uniphier.txt
> 
> I was thinking of this way.
> 
> For example, TI has omap/, keystone/, davinci.txt, etc.
> in this directory level.
> 
> 
>> do you have a better name suggestion for this one? I was trying to keep
>> our options open to later add SC2A11 in socionext.txt, and I also saw
>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>> don't know a good common name for the non-Panasonic parts. And if we
>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>> need a separate file for the new SC2A11 IIUC.
> 
> I have no idea.
> Actually, I am not familiar with those SoCs.
> 
> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
> I think a SoC family name will be helpful to avoid proliferating
> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
> 
> I see some Socionext guys CC'ed in this mail,
> somebody might have information about this.
> 
> As I said before, I do not mind adding socionext.txt
> and it seems reasonable enough
> if there is no common name for those SoCs.
> 
> 
> 
>> Also if you can tell us where the cut between Fujitsu and Socionext
>> should be done, we can certainly adapt. NXP is still adding all their
>> new SoCs in fsl.txt, it seems.
>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>
> 
> Right, vendor names are not future-proof in some cases.
> 
> We use "uniphier" because it is convenient to
> make a group of SoCs with similar architecture,
> and it will work even if UniPhier product lines are sold again in the
> future.  :-)

Summarizing: Masahiro-san only wants to maintain the UniPhier family of
Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
volunteered as maintainer for these F-Cue MB86S71 patches - that seems
to indicate I'll again have to set up a new repository and start
maintaining it myself.

Naming it linux-socionext.git wouldn't quite be right due to UniPhier
also being Socionext.

It's also unclear whether and by whom there may be SC2A11 patches - I
hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
against linux.git.

So... what about naming it linux-fujitsu.git? Then we could keep the
"fujitsu," vendor prefix and document compatibles in a fujitsu.txt for
consistency (instead of this v1's socionext.txt), and I could later add
non-Socionext FM4 (Spansion/Cypress) to the same tree and bindings file.

That still leaves conflict potential with the upcoming Fujitsu Post-K
chip, but we could still worry about that if it ever results in DT
bindings patches rather than just ACPI tables.

Objections, suggestions?

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 4 November 2017 at 13:44, Andreas Färber <afaerber@suse.de> wrote:
> Hi everyone,
>
> The non-building clk driver has been removed for 4.14, but this patchset
> seems stuck on matters of naming and maintenance...
>
> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>> Hi Andreas,
>>
>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
>>> Hi Masahiro-san,
>>>
>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>> socionext.txt.
>>>>>>
>>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>  1 file changed, 17 insertions(+)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>
>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>> --
>>>>
>>>> I do not mind this, but
>>>> please note there are multiple product lines in Socionext
>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>
>>>> I maintain documents for Socionext UniPhier SoC family
>>>> (which inherits SoC architecture of Panasonic)
>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>
>>> Actually you seemed to be lacking bindings beyond the cache controller
>>> for Uniphier:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>
>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>> somewhere too, as done here. A git-grep for that particular compatible
>>> only finds derived clk and reset bindings.
>>
>> I can care to send a patch later, but it is off-topic here.
>
> [The relevance was that had there been any bindings precedence from
> UniPhier, it would've influenced my naming choices.]
>
>>> Using socionext.txt allows you to add those bindings to a shared file;
>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>
>> I was thinking of this way.
>>
>> For example, TI has omap/, keystone/, davinci.txt, etc.
>> in this directory level.
>>
>>
>>> do you have a better name suggestion for this one? I was trying to keep
>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>> don't know a good common name for the non-Panasonic parts. And if we
>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>> need a separate file for the new SC2A11 IIUC.
>>
>> I have no idea.
>> Actually, I am not familiar with those SoCs.
>>
>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>> I think a SoC family name will be helpful to avoid proliferating
>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>
>> I see some Socionext guys CC'ed in this mail,
>> somebody might have information about this.
>>
>> As I said before, I do not mind adding socionext.txt
>> and it seems reasonable enough
>> if there is no common name for those SoCs.
>>
>>
>>
>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>> should be done, we can certainly adapt. NXP is still adding all their
>>> new SoCs in fsl.txt, it seems.
>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>
>>
>> Right, vendor names are not future-proof in some cases.
>>
>> We use "uniphier" because it is convenient to
>> make a group of SoCs with similar architecture,
>> and it will work even if UniPhier product lines are sold again in the
>> future.  :-)
>
> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
> to indicate I'll again have to set up a new repository and start
> maintaining it myself.
>
> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
> also being Socionext.
>
> It's also unclear whether and by whom there may be SC2A11 patches - I
> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
> against linux.git.
>

Eh, wait, what? "Rebelling against linux.git"? What is that supposed
to mean exactly?


> So... what about naming it linux-fujitsu.git? Then we could keep the
> "fujitsu," vendor prefix and document compatibles in a fujitsu.txt for
> consistency (instead of this v1's socionext.txt), and I could later add
> non-Socionext FM4 (Spansion/Cypress) to the same tree and bindings file.
>
> That still leaves conflict potential with the upcoming Fujitsu Post-K
> chip, but we could still worry about that if it ever results in DT
> bindings patches rather than just ACPI tables.
>
> Objections, suggestions?
>
> Thanks,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 4 November 2017 at 13:44, Andreas F?rber <afaerber@suse.de> wrote:
> Hi everyone,
>
> The non-building clk driver has been removed for 4.14, but this patchset
> seems stuck on matters of naming and maintenance...
>
> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>> Hi Andreas,
>>
>> 2017-06-29 21:53 GMT+09:00 Andreas F?rber <afaerber@suse.de>:
>>> Hi Masahiro-san,
>>>
>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>> socionext.txt.
>>>>>>
>>>>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>  1 file changed, 17 insertions(+)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>
>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>> --
>>>>
>>>> I do not mind this, but
>>>> please note there are multiple product lines in Socionext
>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>
>>>> I maintain documents for Socionext UniPhier SoC family
>>>> (which inherits SoC architecture of Panasonic)
>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>
>>> Actually you seemed to be lacking bindings beyond the cache controller
>>> for Uniphier:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>
>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>> somewhere too, as done here. A git-grep for that particular compatible
>>> only finds derived clk and reset bindings.
>>
>> I can care to send a patch later, but it is off-topic here.
>
> [The relevance was that had there been any bindings precedence from
> UniPhier, it would've influenced my naming choices.]
>
>>> Using socionext.txt allows you to add those bindings to a shared file;
>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>
>> I was thinking of this way.
>>
>> For example, TI has omap/, keystone/, davinci.txt, etc.
>> in this directory level.
>>
>>
>>> do you have a better name suggestion for this one? I was trying to keep
>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>> don't know a good common name for the non-Panasonic parts. And if we
>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>> need a separate file for the new SC2A11 IIUC.
>>
>> I have no idea.
>> Actually, I am not familiar with those SoCs.
>>
>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>> I think a SoC family name will be helpful to avoid proliferating
>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>
>> I see some Socionext guys CC'ed in this mail,
>> somebody might have information about this.
>>
>> As I said before, I do not mind adding socionext.txt
>> and it seems reasonable enough
>> if there is no common name for those SoCs.
>>
>>
>>
>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>> should be done, we can certainly adapt. NXP is still adding all their
>>> new SoCs in fsl.txt, it seems.
>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>
>>
>> Right, vendor names are not future-proof in some cases.
>>
>> We use "uniphier" because it is convenient to
>> make a group of SoCs with similar architecture,
>> and it will work even if UniPhier product lines are sold again in the
>> future.  :-)
>
> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
> to indicate I'll again have to set up a new repository and start
> maintaining it myself.
>
> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
> also being Socionext.
>
> It's also unclear whether and by whom there may be SC2A11 patches - I
> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
> against linux.git.
>

Eh, wait, what? "Rebelling against linux.git"? What is that supposed
to mean exactly?


> So... what about naming it linux-fujitsu.git? Then we could keep the
> "fujitsu," vendor prefix and document compatibles in a fujitsu.txt for
> consistency (instead of this v1's socionext.txt), and I could later add
> non-Socionext FM4 (Spansion/Cypress) to the same tree and bindings file.
>
> That still leaves conflict potential with the upcoming Fujitsu Post-K
> chip, but we could still worry about that if it ever results in DT
> bindings patches rather than just ACPI tables.
>
> Objections, suggestions?
>
> Thanks,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Felix Imend?rffer, Jane Smithard, Graham Norton
> HRB 21284 (AG N?rnberg)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
> On 4 November 2017 at 13:44, Andreas Färber <afaerber@suse.de> wrote:
>> Hi everyone,
>>
>> The non-building clk driver has been removed for 4.14, but this patchset
>> seems stuck on matters of naming and maintenance...
>>
>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>> Hi Andreas,
>>>
>>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
>>>> Hi Masahiro-san,
>>>>
>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>> socionext.txt.
>>>>>>>
>>>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>>>> ---
>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>
>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>> --
>>>>>
>>>>> I do not mind this, but
>>>>> please note there are multiple product lines in Socionext
>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>
>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>> (which inherits SoC architecture of Panasonic)
>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>
>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>> for Uniphier:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>
>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>> only finds derived clk and reset bindings.
>>>
>>> I can care to send a patch later, but it is off-topic here.
>>
>> [The relevance was that had there been any bindings precedence from
>> UniPhier, it would've influenced my naming choices.]
>>
>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>
>>> I was thinking of this way.
>>>
>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>> in this directory level.
>>>
>>>
>>>> do you have a better name suggestion for this one? I was trying to keep
>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>> need a separate file for the new SC2A11 IIUC.
>>>
>>> I have no idea.
>>> Actually, I am not familiar with those SoCs.
>>>
>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>> I think a SoC family name will be helpful to avoid proliferating
>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>
>>> I see some Socionext guys CC'ed in this mail,
>>> somebody might have information about this.
>>>
>>> As I said before, I do not mind adding socionext.txt
>>> and it seems reasonable enough
>>> if there is no common name for those SoCs.
>>>
>>>
>>>
>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>> new SoCs in fsl.txt, it seems.
>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>
>>>
>>> Right, vendor names are not future-proof in some cases.
>>>
>>> We use "uniphier" because it is convenient to
>>> make a group of SoCs with similar architecture,
>>> and it will work even if UniPhier product lines are sold again in the
>>> future.  :-)
>>
>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>> to indicate I'll again have to set up a new repository and start
>> maintaining it myself.
>>
>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>> also being Socionext.
>>
>> It's also unclear whether and by whom there may be SC2A11 patches - I
>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>> against linux.git.
>>
> 
> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
> to mean exactly?

Bindings must be submitted to the devicetree mailing list, acked by Rob
and merged into the Linux tree before compatible strings may be used in
Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.

U-Boot only allows import of new .dts files from Linux, too.

So Linus' linux.git is the location to merge any vendor prefixes and
device tree bindings, as well as the central location for device trees.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts

If you're unfamiliar with that, talk to your Linaro colleagues please!

Regards,
Andreas

> 
> 
>> So... what about naming it linux-fujitsu.git? Then we could keep the
>> "fujitsu," vendor prefix and document compatibles in a fujitsu.txt for
>> consistency (instead of this v1's socionext.txt), and I could later add
>> non-Socionext FM4 (Spansion/Cypress) to the same tree and bindings file.
>>
>> That still leaves conflict potential with the upcoming Fujitsu Post-K
>> chip, but we could still worry about that if it ever results in DT
>> bindings patches rather than just ACPI tables.
>>
>> Objections, suggestions?
>>
>> Thanks,
>> Andreas
>>
>> --
>> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> GF: Felix Imendörffer, Jane Smithard, Graham Norton
>> HRB 21284 (AG Nürnberg)
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
> On 4 November 2017 at 13:44, Andreas F?rber <afaerber@suse.de> wrote:
>> Hi everyone,
>>
>> The non-building clk driver has been removed for 4.14, but this patchset
>> seems stuck on matters of naming and maintenance...
>>
>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>> Hi Andreas,
>>>
>>> 2017-06-29 21:53 GMT+09:00 Andreas F?rber <afaerber@suse.de>:
>>>> Hi Masahiro-san,
>>>>
>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>> socionext.txt.
>>>>>>>
>>>>>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>>>>>> ---
>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>
>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>> --
>>>>>
>>>>> I do not mind this, but
>>>>> please note there are multiple product lines in Socionext
>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>
>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>> (which inherits SoC architecture of Panasonic)
>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>
>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>> for Uniphier:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>
>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>> only finds derived clk and reset bindings.
>>>
>>> I can care to send a patch later, but it is off-topic here.
>>
>> [The relevance was that had there been any bindings precedence from
>> UniPhier, it would've influenced my naming choices.]
>>
>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>
>>> I was thinking of this way.
>>>
>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>> in this directory level.
>>>
>>>
>>>> do you have a better name suggestion for this one? I was trying to keep
>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>> need a separate file for the new SC2A11 IIUC.
>>>
>>> I have no idea.
>>> Actually, I am not familiar with those SoCs.
>>>
>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>> I think a SoC family name will be helpful to avoid proliferating
>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>
>>> I see some Socionext guys CC'ed in this mail,
>>> somebody might have information about this.
>>>
>>> As I said before, I do not mind adding socionext.txt
>>> and it seems reasonable enough
>>> if there is no common name for those SoCs.
>>>
>>>
>>>
>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>> new SoCs in fsl.txt, it seems.
>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>
>>>
>>> Right, vendor names are not future-proof in some cases.
>>>
>>> We use "uniphier" because it is convenient to
>>> make a group of SoCs with similar architecture,
>>> and it will work even if UniPhier product lines are sold again in the
>>> future.  :-)
>>
>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>> to indicate I'll again have to set up a new repository and start
>> maintaining it myself.
>>
>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>> also being Socionext.
>>
>> It's also unclear whether and by whom there may be SC2A11 patches - I
>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>> against linux.git.
>>
> 
> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
> to mean exactly?

Bindings must be submitted to the devicetree mailing list, acked by Rob
and merged into the Linux tree before compatible strings may be used in
Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.

U-Boot only allows import of new .dts files from Linux, too.

So Linus' linux.git is the location to merge any vendor prefixes and
device tree bindings, as well as the central location for device trees.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts

If you're unfamiliar with that, talk to your Linaro colleagues please!

Regards,
Andreas

> 
> 
>> So... what about naming it linux-fujitsu.git? Then we could keep the
>> "fujitsu," vendor prefix and document compatibles in a fujitsu.txt for
>> consistency (instead of this v1's socionext.txt), and I could later add
>> non-Socionext FM4 (Spansion/Cypress) to the same tree and bindings file.
>>
>> That still leaves conflict potential with the upcoming Fujitsu Post-K
>> chip, but we could still worry about that if it ever results in DT
>> bindings patches rather than just ACPI tables.
>>
>> Objections, suggestions?
>>
>> Thanks,
>> Andreas
>>
>> --
>> SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
>> GF: Felix Imend?rffer, Jane Smithard, Graham Norton
>> HRB 21284 (AG N?rnberg)
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
> On 4 November 2017 at 13:44, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote:
>> Hi everyone,
>>
>> The non-building clk driver has been removed for 4.14, but this patchset
>> seems stuck on matters of naming and maintenance...
>>
>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>> Hi Andreas,
>>>
>>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>:
>>>> Hi Masahiro-san,
>>>>
>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>> socionext.txt.
>>>>>>>
>>>>>>> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
>>>>>>> ---
>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>
>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>> --
>>>>>
>>>>> I do not mind this, but
>>>>> please note there are multiple product lines in Socionext
>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>
>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>> (which inherits SoC architecture of Panasonic)
>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>
>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>> for Uniphier:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>
>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>> only finds derived clk and reset bindings.
>>>
>>> I can care to send a patch later, but it is off-topic here.
>>
>> [The relevance was that had there been any bindings precedence from
>> UniPhier, it would've influenced my naming choices.]
>>
>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>
>>> I was thinking of this way.
>>>
>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>> in this directory level.
>>>
>>>
>>>> do you have a better name suggestion for this one? I was trying to keep
>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>> need a separate file for the new SC2A11 IIUC.
>>>
>>> I have no idea.
>>> Actually, I am not familiar with those SoCs.
>>>
>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>> I think a SoC family name will be helpful to avoid proliferating
>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>
>>> I see some Socionext guys CC'ed in this mail,
>>> somebody might have information about this.
>>>
>>> As I said before, I do not mind adding socionext.txt
>>> and it seems reasonable enough
>>> if there is no common name for those SoCs.
>>>
>>>
>>>
>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>> new SoCs in fsl.txt, it seems.
>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>
>>>
>>> Right, vendor names are not future-proof in some cases.
>>>
>>> We use "uniphier" because it is convenient to
>>> make a group of SoCs with similar architecture,
>>> and it will work even if UniPhier product lines are sold again in the
>>> future.  :-)
>>
>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>> to indicate I'll again have to set up a new repository and start
>> maintaining it myself.
>>
>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>> also being Socionext.
>>
>> It's also unclear whether and by whom there may be SC2A11 patches - I
>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>> against linux.git.
>>
> 
> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
> to mean exactly?

Bindings must be submitted to the devicetree mailing list, acked by Rob
and merged into the Linux tree before compatible strings may be used in
Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.

U-Boot only allows import of new .dts files from Linux, too.

So Linus' linux.git is the location to merge any vendor prefixes and
device tree bindings, as well as the central location for device trees.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts

If you're unfamiliar with that, talk to your Linaro colleagues please!

Regards,
Andreas

> 
> 
>> So... what about naming it linux-fujitsu.git? Then we could keep the
>> "fujitsu," vendor prefix and document compatibles in a fujitsu.txt for
>> consistency (instead of this v1's socionext.txt), and I could later add
>> non-Socionext FM4 (Spansion/Cypress) to the same tree and bindings file.
>>
>> That still leaves conflict potential with the upcoming Fujitsu Post-K
>> chip, but we could still worry about that if it ever results in DT
>> bindings patches rather than just ACPI tables.
>>
>> Objections, suggestions?
>>
>> Thanks,
>> Andreas
>>
>> --
>> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> GF: Felix Imendörffer, Jane Smithard, Graham Norton
>> HRB 21284 (AG Nürnberg)
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 4 November 2017 at 15:30, Andreas Färber <afaerber@suse.de> wrote:
> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>> On 4 November 2017 at 13:44, Andreas Färber <afaerber@suse.de> wrote:
>>> Hi everyone,
>>>
>>> The non-building clk driver has been removed for 4.14, but this patchset
>>> seems stuck on matters of naming and maintenance...
>>>
>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>> Hi Andreas,
>>>>
>>>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
>>>>> Hi Masahiro-san,
>>>>>
>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>> socionext.txt.
>>>>>>>>
>>>>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>>>>> ---
>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>
>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>> --
>>>>>>
>>>>>> I do not mind this, but
>>>>>> please note there are multiple product lines in Socionext
>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>
>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>
>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>> for Uniphier:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>
>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>> only finds derived clk and reset bindings.
>>>>
>>>> I can care to send a patch later, but it is off-topic here.
>>>
>>> [The relevance was that had there been any bindings precedence from
>>> UniPhier, it would've influenced my naming choices.]
>>>
>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>
>>>> I was thinking of this way.
>>>>
>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>> in this directory level.
>>>>
>>>>
>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>> need a separate file for the new SC2A11 IIUC.
>>>>
>>>> I have no idea.
>>>> Actually, I am not familiar with those SoCs.
>>>>
>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>> I think a SoC family name will be helpful to avoid proliferating
>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>
>>>> I see some Socionext guys CC'ed in this mail,
>>>> somebody might have information about this.
>>>>
>>>> As I said before, I do not mind adding socionext.txt
>>>> and it seems reasonable enough
>>>> if there is no common name for those SoCs.
>>>>
>>>>
>>>>
>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>> new SoCs in fsl.txt, it seems.
>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>
>>>>
>>>> Right, vendor names are not future-proof in some cases.
>>>>
>>>> We use "uniphier" because it is convenient to
>>>> make a group of SoCs with similar architecture,
>>>> and it will work even if UniPhier product lines are sold again in the
>>>> future.  :-)
>>>
>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>> to indicate I'll again have to set up a new repository and start
>>> maintaining it myself.
>>>
>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>> also being Socionext.
>>>
>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>> against linux.git.
>>>
>>
>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>> to mean exactly?
>
> Bindings must be submitted to the devicetree mailing list, acked by Rob
> and merged into the Linux tree before compatible strings may be used in
> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
>

OK, so where did we deviate from this in your opinion?

> U-Boot only allows import of new .dts files from Linux, too.
>
> So Linus' linux.git is the location to merge any vendor prefixes and
> device tree bindings,

Agreed.

> as well as the central location for device trees.
>

Why should there be a central location for device trees?

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>
> If you're unfamiliar with that, talk to your Linaro colleagues please!
>

Please don't lecture me on this.

The bindings are the contract between the OS and the platform, and I
agree that those need to be reviewed and maintained in a central
location, and the kernel tree, while not optimal, is a suitable place
for that.

However, the existence of such contracts means that there is no need
to have a central location for device trees, nor should there be a
need for distros to ever ship device trees with the kernel. That
practice defeats the entire purpose of having contracts in the first
place, especially with the pathetic churn we are seeing in device
trees that are kept in the kernel.

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 4 November 2017 at 15:30, Andreas F?rber <afaerber@suse.de> wrote:
> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>> On 4 November 2017 at 13:44, Andreas F?rber <afaerber@suse.de> wrote:
>>> Hi everyone,
>>>
>>> The non-building clk driver has been removed for 4.14, but this patchset
>>> seems stuck on matters of naming and maintenance...
>>>
>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>> Hi Andreas,
>>>>
>>>> 2017-06-29 21:53 GMT+09:00 Andreas F?rber <afaerber@suse.de>:
>>>>> Hi Masahiro-san,
>>>>>
>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>> socionext.txt.
>>>>>>>>
>>>>>>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>>>>>>> ---
>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>
>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>> --
>>>>>>
>>>>>> I do not mind this, but
>>>>>> please note there are multiple product lines in Socionext
>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>
>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>
>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>> for Uniphier:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>
>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>> only finds derived clk and reset bindings.
>>>>
>>>> I can care to send a patch later, but it is off-topic here.
>>>
>>> [The relevance was that had there been any bindings precedence from
>>> UniPhier, it would've influenced my naming choices.]
>>>
>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>
>>>> I was thinking of this way.
>>>>
>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>> in this directory level.
>>>>
>>>>
>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>> need a separate file for the new SC2A11 IIUC.
>>>>
>>>> I have no idea.
>>>> Actually, I am not familiar with those SoCs.
>>>>
>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>> I think a SoC family name will be helpful to avoid proliferating
>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>
>>>> I see some Socionext guys CC'ed in this mail,
>>>> somebody might have information about this.
>>>>
>>>> As I said before, I do not mind adding socionext.txt
>>>> and it seems reasonable enough
>>>> if there is no common name for those SoCs.
>>>>
>>>>
>>>>
>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>> new SoCs in fsl.txt, it seems.
>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>
>>>>
>>>> Right, vendor names are not future-proof in some cases.
>>>>
>>>> We use "uniphier" because it is convenient to
>>>> make a group of SoCs with similar architecture,
>>>> and it will work even if UniPhier product lines are sold again in the
>>>> future.  :-)
>>>
>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>> to indicate I'll again have to set up a new repository and start
>>> maintaining it myself.
>>>
>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>> also being Socionext.
>>>
>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>> against linux.git.
>>>
>>
>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>> to mean exactly?
>
> Bindings must be submitted to the devicetree mailing list, acked by Rob
> and merged into the Linux tree before compatible strings may be used in
> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
>

OK, so where did we deviate from this in your opinion?

> U-Boot only allows import of new .dts files from Linux, too.
>
> So Linus' linux.git is the location to merge any vendor prefixes and
> device tree bindings,

Agreed.

> as well as the central location for device trees.
>

Why should there be a central location for device trees?

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>
> If you're unfamiliar with that, talk to your Linaro colleagues please!
>

Please don't lecture me on this.

The bindings are the contract between the OS and the platform, and I
agree that those need to be reviewed and maintained in a central
location, and the kernel tree, while not optimal, is a suitable place
for that.

However, the existence of such contracts means that there is no need
to have a central location for device trees, nor should there be a
need for distros to ever ship device trees with the kernel. That
practice defeats the entire purpose of having contracts in the first
place, especially with the pathetic churn we are seeing in device
trees that are kept in the kernel.

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 15:30, Andreas Färber <afaerber@suse.de> wrote:
>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 13:44, Andreas Färber <afaerber@suse.de> wrote:
>>>> Hi everyone,
>>>>
>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>> seems stuck on matters of naming and maintenance...
>>>>
>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>> Hi Andreas,
>>>>>
>>>>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
>>>>>> Hi Masahiro-san,
>>>>>>
>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>> socionext.txt.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>>>>>> ---
>>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>
>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>> --
>>>>>>>
>>>>>>> I do not mind this, but
>>>>>>> please note there are multiple product lines in Socionext
>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>
>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>
>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>> for Uniphier:
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>
>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>> only finds derived clk and reset bindings.
>>>>>
>>>>> I can care to send a patch later, but it is off-topic here.
>>>>
>>>> [The relevance was that had there been any bindings precedence from
>>>> UniPhier, it would've influenced my naming choices.]
>>>>
>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>
>>>>> I was thinking of this way.
>>>>>
>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>> in this directory level.
>>>>>
>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>
>>>>> I have no idea.
>>>>> Actually, I am not familiar with those SoCs.
>>>>>
>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>
>>>>> I see some Socionext guys CC'ed in this mail,
>>>>> somebody might have information about this.
>>>>>
>>>>> As I said before, I do not mind adding socionext.txt
>>>>> and it seems reasonable enough
>>>>> if there is no common name for those SoCs.
>>>>>
>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>> new SoCs in fsl.txt, it seems.
>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>
>>>>> Right, vendor names are not future-proof in some cases.
>>>>>
>>>>> We use "uniphier" because it is convenient to
>>>>> make a group of SoCs with similar architecture,
>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>> future.  :-)
>>>>
>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>> to indicate I'll again have to set up a new repository and start
>>>> maintaining it myself.
>>>>
>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>> also being Socionext.
>>>>
>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>> against linux.git.
>>>
>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>> to mean exactly?
>>
>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>> and merged into the Linux tree before compatible strings may be used in
>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
> 
> OK, so where did we deviate from this in your opinion?

I was very clear which new Socionext 96board platform my remark was
about. There not being a socionext.txt file before this patch here hints
at there being no official SoC binding defined for any.

Adding one would require coordinating how to go about these platforms,
as unsuccessfully attempted here.

I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
could've well come from you, given your rant. Note that both the
bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
you're essentially fighting against your colleagues here...

Last but not least pretty much every shipping 96Board to date had a
pre-installed DT that did not have official bindings submitted (I don't
count the Cello as shipping) and thus later changed incompatibly.

>> U-Boot only allows import of new .dts files from Linux, too.
>>
>> So Linus' linux.git is the location to merge any vendor prefixes and
>> device tree bindings,
> 
> Agreed.
> 
>> as well as the central location for device trees.
> 
> Why should there be a central location for device trees?

Because with a .dtsi for SoC and SoM we can share DT code across boards
and bootloaders. And at least one .dts is needed for compile-testing it.
>From a central location files can be either individually copied or
potentially aggregated as submodules.

DT patch reviews have resulted in GIC nodes growing virtualization
support for instance, and there have been in-tree refactorings fixing
the arch timer's interrupt type iirc. Comparing modeling across vendors
is also useful to not live in silos.

Also considering that drivers are spread over subsystem rather than SoC
directories these days, the central location being Linux facilitates
checking which platforms have been enabled already and to which degree.

>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>
>> If you're unfamiliar with that, talk to your Linaro colleagues please!
> 
> Please don't lecture me on this.

If you ask questions, you may get answers. Blame yourself if you
intended them as rhetorical questions.

> The bindings are the contract between the OS and the platform, and I
> agree that those need to be reviewed and maintained in a central
> location, and the kernel tree, while not optimal, is a suitable place
> for that.
> 
> However, the existence of such contracts means that there is no need
> to have a central location for device trees, nor should there be a
> need for distros to ever ship device trees with the kernel. That
> practice defeats the entire purpose of having contracts in the first
> place, especially with the pathetic churn we are seeing in device
> trees that are kept in the kernel.

Please don't argue with me about these fundamentals. Not my decisions!

This is not about distros shipping things; there is no openSUSE on these
platforms precisely because code is not in central repositories.

It's rather about three platforms by one vendor all going into different
directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
vendor kernel / U-Boot tarballs (and my kernel patches here), and
UniPhier as only one in mainline kernel and mainline U-Boot.

Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
kernel you are trying to boot? Good luck... Even server vendors
occasionally change their device trees with firmware updates.

Fact is, as platforms get enabled, device trees grow additional nodes
and properties. DTs don't fall from skies in some final form for new SoCs.

Especially not if they keep getting written by volunteers like me - I'm
already enabling the fourth 96board because Linaro and its partners keep
throwing ~3.10 kernels at users again and again and again, which as I've
pointed out at BUD17 is highly annoying! Even more annoying every single
time Linaro marketing asks people to join as paying members because
Linaro supposedly does so awesome Open Source work and such great
96Boards. Just this Friday again.
Nobody needs Reference Platform kernels if everything just timely gets
merged into linux-next and mainline, where code belongs.
Same for device trees, until the powers that be decide on a different
location - which would not change the problem at all: Every review will
be regarded as churn by someone else, and some people will always be
lazy in submitting patches to whatever widely agreed-upon location, be
it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.

We wouldn't be having this argument if everything were great with the
various non-central 96boards trees and downstream DTs.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 15:30, Andreas F?rber <afaerber@suse.de> wrote:
>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 13:44, Andreas F?rber <afaerber@suse.de> wrote:
>>>> Hi everyone,
>>>>
>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>> seems stuck on matters of naming and maintenance...
>>>>
>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>> Hi Andreas,
>>>>>
>>>>> 2017-06-29 21:53 GMT+09:00 Andreas F?rber <afaerber@suse.de>:
>>>>>> Hi Masahiro-san,
>>>>>>
>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>> socionext.txt.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>>>>>>>> ---
>>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>
>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>> --
>>>>>>>
>>>>>>> I do not mind this, but
>>>>>>> please note there are multiple product lines in Socionext
>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>
>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>
>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>> for Uniphier:
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>
>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>> only finds derived clk and reset bindings.
>>>>>
>>>>> I can care to send a patch later, but it is off-topic here.
>>>>
>>>> [The relevance was that had there been any bindings precedence from
>>>> UniPhier, it would've influenced my naming choices.]
>>>>
>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>
>>>>> I was thinking of this way.
>>>>>
>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>> in this directory level.
>>>>>
>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>
>>>>> I have no idea.
>>>>> Actually, I am not familiar with those SoCs.
>>>>>
>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>
>>>>> I see some Socionext guys CC'ed in this mail,
>>>>> somebody might have information about this.
>>>>>
>>>>> As I said before, I do not mind adding socionext.txt
>>>>> and it seems reasonable enough
>>>>> if there is no common name for those SoCs.
>>>>>
>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>> new SoCs in fsl.txt, it seems.
>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>
>>>>> Right, vendor names are not future-proof in some cases.
>>>>>
>>>>> We use "uniphier" because it is convenient to
>>>>> make a group of SoCs with similar architecture,
>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>> future.  :-)
>>>>
>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>> to indicate I'll again have to set up a new repository and start
>>>> maintaining it myself.
>>>>
>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>> also being Socionext.
>>>>
>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>> against linux.git.
>>>
>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>> to mean exactly?
>>
>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>> and merged into the Linux tree before compatible strings may be used in
>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
> 
> OK, so where did we deviate from this in your opinion?

I was very clear which new Socionext 96board platform my remark was
about. There not being a socionext.txt file before this patch here hints
at there being no official SoC binding defined for any.

Adding one would require coordinating how to go about these platforms,
as unsuccessfully attempted here.

I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
could've well come from you, given your rant. Note that both the
bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
you're essentially fighting against your colleagues here...

Last but not least pretty much every shipping 96Board to date had a
pre-installed DT that did not have official bindings submitted (I don't
count the Cello as shipping) and thus later changed incompatibly.

>> U-Boot only allows import of new .dts files from Linux, too.
>>
>> So Linus' linux.git is the location to merge any vendor prefixes and
>> device tree bindings,
> 
> Agreed.
> 
>> as well as the central location for device trees.
> 
> Why should there be a central location for device trees?

Because with a .dtsi for SoC and SoM we can share DT code across boards
and bootloaders. And at least one .dts is needed for compile-testing it.
>From a central location files can be either individually copied or
potentially aggregated as submodules.

DT patch reviews have resulted in GIC nodes growing virtualization
support for instance, and there have been in-tree refactorings fixing
the arch timer's interrupt type iirc. Comparing modeling across vendors
is also useful to not live in silos.

Also considering that drivers are spread over subsystem rather than SoC
directories these days, the central location being Linux facilitates
checking which platforms have been enabled already and to which degree.

>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>
>> If you're unfamiliar with that, talk to your Linaro colleagues please!
> 
> Please don't lecture me on this.

If you ask questions, you may get answers. Blame yourself if you
intended them as rhetorical questions.

> The bindings are the contract between the OS and the platform, and I
> agree that those need to be reviewed and maintained in a central
> location, and the kernel tree, while not optimal, is a suitable place
> for that.
> 
> However, the existence of such contracts means that there is no need
> to have a central location for device trees, nor should there be a
> need for distros to ever ship device trees with the kernel. That
> practice defeats the entire purpose of having contracts in the first
> place, especially with the pathetic churn we are seeing in device
> trees that are kept in the kernel.

Please don't argue with me about these fundamentals. Not my decisions!

This is not about distros shipping things; there is no openSUSE on these
platforms precisely because code is not in central repositories.

It's rather about three platforms by one vendor all going into different
directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
vendor kernel / U-Boot tarballs (and my kernel patches here), and
UniPhier as only one in mainline kernel and mainline U-Boot.

Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
kernel you are trying to boot? Good luck... Even server vendors
occasionally change their device trees with firmware updates.

Fact is, as platforms get enabled, device trees grow additional nodes
and properties. DTs don't fall from skies in some final form for new SoCs.

Especially not if they keep getting written by volunteers like me - I'm
already enabling the fourth 96board because Linaro and its partners keep
throwing ~3.10 kernels at users again and again and again, which as I've
pointed out at BUD17 is highly annoying! Even more annoying every single
time Linaro marketing asks people to join as paying members because
Linaro supposedly does so awesome Open Source work and such great
96Boards. Just this Friday again.
Nobody needs Reference Platform kernels if everything just timely gets
merged into linux-next and mainline, where code belongs.
Same for device trees, until the powers that be decide on a different
location - which would not change the problem at all: Every review will
be regarded as churn by someone else, and some people will always be
lazy in submitting patches to whatever widely agreed-upon location, be
it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.

We wouldn't be having this argument if everything were great with the
various non-central 96boards trees and downstream DTs.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 15:30, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote:
>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 13:44, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote:
>>>> Hi everyone,
>>>>
>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>> seems stuck on matters of naming and maintenance...
>>>>
>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>> Hi Andreas,
>>>>>
>>>>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>:
>>>>>> Hi Masahiro-san,
>>>>>>
>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>> socionext.txt.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
>>>>>>>>> ---
>>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>
>>>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>>>> --
>>>>>>>
>>>>>>> I do not mind this, but
>>>>>>> please note there are multiple product lines in Socionext
>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>
>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>
>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>> for Uniphier:
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>
>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>> only finds derived clk and reset bindings.
>>>>>
>>>>> I can care to send a patch later, but it is off-topic here.
>>>>
>>>> [The relevance was that had there been any bindings precedence from
>>>> UniPhier, it would've influenced my naming choices.]
>>>>
>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>
>>>>> I was thinking of this way.
>>>>>
>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>> in this directory level.
>>>>>
>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>
>>>>> I have no idea.
>>>>> Actually, I am not familiar with those SoCs.
>>>>>
>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>
>>>>> I see some Socionext guys CC'ed in this mail,
>>>>> somebody might have information about this.
>>>>>
>>>>> As I said before, I do not mind adding socionext.txt
>>>>> and it seems reasonable enough
>>>>> if there is no common name for those SoCs.
>>>>>
>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>> new SoCs in fsl.txt, it seems.
>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>
>>>>> Right, vendor names are not future-proof in some cases.
>>>>>
>>>>> We use "uniphier" because it is convenient to
>>>>> make a group of SoCs with similar architecture,
>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>> future.  :-)
>>>>
>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>> to indicate I'll again have to set up a new repository and start
>>>> maintaining it myself.
>>>>
>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>> also being Socionext.
>>>>
>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>> against linux.git.
>>>
>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>> to mean exactly?
>>
>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>> and merged into the Linux tree before compatible strings may be used in
>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
> 
> OK, so where did we deviate from this in your opinion?

I was very clear which new Socionext 96board platform my remark was
about. There not being a socionext.txt file before this patch here hints
at there being no official SoC binding defined for any.

Adding one would require coordinating how to go about these platforms,
as unsuccessfully attempted here.

I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
could've well come from you, given your rant. Note that both the
bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
you're essentially fighting against your colleagues here...

Last but not least pretty much every shipping 96Board to date had a
pre-installed DT that did not have official bindings submitted (I don't
count the Cello as shipping) and thus later changed incompatibly.

>> U-Boot only allows import of new .dts files from Linux, too.
>>
>> So Linus' linux.git is the location to merge any vendor prefixes and
>> device tree bindings,
> 
> Agreed.
> 
>> as well as the central location for device trees.
> 
> Why should there be a central location for device trees?

Because with a .dtsi for SoC and SoM we can share DT code across boards
and bootloaders. And at least one .dts is needed for compile-testing it.
>From a central location files can be either individually copied or
potentially aggregated as submodules.

DT patch reviews have resulted in GIC nodes growing virtualization
support for instance, and there have been in-tree refactorings fixing
the arch timer's interrupt type iirc. Comparing modeling across vendors
is also useful to not live in silos.

Also considering that drivers are spread over subsystem rather than SoC
directories these days, the central location being Linux facilitates
checking which platforms have been enabled already and to which degree.

>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>
>> If you're unfamiliar with that, talk to your Linaro colleagues please!
> 
> Please don't lecture me on this.

If you ask questions, you may get answers. Blame yourself if you
intended them as rhetorical questions.

> The bindings are the contract between the OS and the platform, and I
> agree that those need to be reviewed and maintained in a central
> location, and the kernel tree, while not optimal, is a suitable place
> for that.
> 
> However, the existence of such contracts means that there is no need
> to have a central location for device trees, nor should there be a
> need for distros to ever ship device trees with the kernel. That
> practice defeats the entire purpose of having contracts in the first
> place, especially with the pathetic churn we are seeing in device
> trees that are kept in the kernel.

Please don't argue with me about these fundamentals. Not my decisions!

This is not about distros shipping things; there is no openSUSE on these
platforms precisely because code is not in central repositories.

It's rather about three platforms by one vendor all going into different
directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
vendor kernel / U-Boot tarballs (and my kernel patches here), and
UniPhier as only one in mainline kernel and mainline U-Boot.

Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
kernel you are trying to boot? Good luck... Even server vendors
occasionally change their device trees with firmware updates.

Fact is, as platforms get enabled, device trees grow additional nodes
and properties. DTs don't fall from skies in some final form for new SoCs.

Especially not if they keep getting written by volunteers like me - I'm
already enabling the fourth 96board because Linaro and its partners keep
throwing ~3.10 kernels at users again and again and again, which as I've
pointed out at BUD17 is highly annoying! Even more annoying every single
time Linaro marketing asks people to join as paying members because
Linaro supposedly does so awesome Open Source work and such great
96Boards. Just this Friday again.
Nobody needs Reference Platform kernels if everything just timely gets
merged into linux-next and mainline, where code belongs.
Same for device trees, until the powers that be decide on a different
location - which would not change the problem at all: Every review will
be regarded as churn by someone else, and some people will always be
lazy in submitting patches to whatever widely agreed-upon location, be
it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.

We wouldn't be having this argument if everything were great with the
various non-central 96boards trees and downstream DTs.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 4 November 2017 at 20:06, Andreas Färber <afaerber@suse.de> wrote:
> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>> On 4 November 2017 at 15:30, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>>> On 4 November 2017 at 13:44, Andreas Färber <afaerber@suse.de> wrote:
>>>>> Hi everyone,
>>>>>
>>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>>> seems stuck on matters of naming and maintenance...
>>>>>
>>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>>> Hi Andreas,
>>>>>>
>>>>>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
>>>>>>> Hi Masahiro-san,
>>>>>>>
>>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>>> socionext.txt.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>>>>>>> ---
>>>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>>
>>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>>> --
>>>>>>>>
>>>>>>>> I do not mind this, but
>>>>>>>> please note there are multiple product lines in Socionext
>>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>>
>>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>>
>>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>>> for Uniphier:
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>>
>>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>>> only finds derived clk and reset bindings.
>>>>>>
>>>>>> I can care to send a patch later, but it is off-topic here.
>>>>>
>>>>> [The relevance was that had there been any bindings precedence from
>>>>> UniPhier, it would've influenced my naming choices.]
>>>>>
>>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>>
>>>>>> I was thinking of this way.
>>>>>>
>>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>>> in this directory level.
>>>>>>
>>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>>
>>>>>> I have no idea.
>>>>>> Actually, I am not familiar with those SoCs.
>>>>>>
>>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>>
>>>>>> I see some Socionext guys CC'ed in this mail,
>>>>>> somebody might have information about this.
>>>>>>
>>>>>> As I said before, I do not mind adding socionext.txt
>>>>>> and it seems reasonable enough
>>>>>> if there is no common name for those SoCs.
>>>>>>
>>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>>> new SoCs in fsl.txt, it seems.
>>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>>
>>>>>> Right, vendor names are not future-proof in some cases.
>>>>>>
>>>>>> We use "uniphier" because it is convenient to
>>>>>> make a group of SoCs with similar architecture,
>>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>>> future.  :-)
>>>>>
>>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>>> to indicate I'll again have to set up a new repository and start
>>>>> maintaining it myself.
>>>>>
>>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>>> also being Socionext.
>>>>>
>>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>>> against linux.git.
>>>>
>>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>>> to mean exactly?
>>>
>>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>>> and merged into the Linux tree before compatible strings may be used in
>>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
>>
>> OK, so where did we deviate from this in your opinion?
>
> I was very clear which new Socionext 96board platform my remark was
> about. There not being a socionext.txt file before this patch here hints
> at there being no official SoC binding defined for any.
>
> Adding one would require coordinating how to go about these platforms,
> as unsuccessfully attempted here.
>
> I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
> could've well come from you, given your rant.

I honestly have no idea what you are talking about here. You see
rebellion and argument where there is none.

>  Note that both the
> bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
> you're essentially fighting against your colleagues here...
>

I am not fighting anyone, but you seem to think we are rebelling.

The reality is that the platform topology is not finalized yet, and
submitting and merging what are essentially draft version of DT
descriptions and then having to update them is something we are trying
very hard to avoid. There is enough churn in upstream DTs as it is.

> Last but not least pretty much every shipping 96Board to date had a
> pre-installed DT that did not have official bindings submitted (I don't
> count the Cello as shipping) and thus later changed incompatibly.
>

We are working very hard to make sure the upstream bindings and
drivers in the kernel are in shape to support the SoC we are
developing firmware support for. When the time comes, we may or may
not decide to propose the SoC DT for inclusion in the kernel. But
those are two different things.

This has nothing to do with 'rebelling against linux.git' (your words)

>>> U-Boot only allows import of new .dts files from Linux, too.
>>>
>>> So Linus' linux.git is the location to merge any vendor prefixes and
>>> device tree bindings,
>>
>> Agreed.
>>
>>> as well as the central location for device trees.
>>
>> Why should there be a central location for device trees?
>
> Because with a .dtsi for SoC and SoM we can share DT code across boards
> and bootloaders. And at least one .dts is needed for compile-testing it.
> From a central location files can be either individually copied or
> potentially aggregated as submodules.
>
> DT patch reviews have resulted in GIC nodes growing virtualization
> support for instance, and there have been in-tree refactorings fixing
> the arch timer's interrupt type iirc. Comparing modeling across vendors
> is also useful to not live in silos.
>
> Also considering that drivers are spread over subsystem rather than SoC
> directories these days, the central location being Linux facilitates
> checking which platforms have been enabled already and to which degree.
>

I understand all that. But being able to review SoC DTs is one thing,
and deciding that the kernel repository shall be the authoritative
source is another.

In my view, this argues for having a shared repository, mailing list
etc between the Linux, u-boot, freebsd and EDK2 communities, because
it would increase review coverage, and make it easier to push back
against frivolous DT changes.

>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>>
>>> If you're unfamiliar with that, talk to your Linaro colleagues please!
>>
>> Please don't lecture me on this.
>
> If you ask questions, you may get answers. Blame yourself if you
> intended them as rhetorical questions.
>
>> The bindings are the contract between the OS and the platform, and I
>> agree that those need to be reviewed and maintained in a central
>> location, and the kernel tree, while not optimal, is a suitable place
>> for that.
>>
>> However, the existence of such contracts means that there is no need
>> to have a central location for device trees, nor should there be a
>> need for distros to ever ship device trees with the kernel. That
>> practice defeats the entire purpose of having contracts in the first
>> place, especially with the pathetic churn we are seeing in device
>> trees that are kept in the kernel.
>
> Please don't argue with me about these fundamentals. Not my decisions!
>
> This is not about distros shipping things; there is no openSUSE on these
> platforms precisely because code is not in central repositories.
>

By 'these platforms' you mean 96boards? Fair point. But please don't
extrapolate from Hikey (and FYI, Cello has been running mainline Linux
and EDK2 from the beginning)

> It's rather about three platforms by one vendor all going into different
> directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
> vendor kernel / U-Boot tarballs (and my kernel patches here), and
> UniPhier as only one in mainline kernel and mainline U-Boot.
>
> Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
> kernel you are trying to boot? Good luck... Even server vendors
> occasionally change their device trees with firmware updates.
>

You say that like it's a bad thing. Do you honestly think it is better
for the OS to pick its own DT from some tarball that shipped with it?

If the kernel driver developers wouldn't keep making backward
incompatible changes to the bindings, they could actually stabilize to
the point where it makes even more sense for the platform vendor to
fix bugs in their DT descriptions.

> Fact is, as platforms get enabled, device trees grow additional nodes
> and properties. DTs don't fall from skies in some final form for new SoCs.
>
> Especially not if they keep getting written by volunteers like me - I'm
> already enabling the fourth 96board because Linaro and its partners keep
> throwing ~3.10 kernels at users again and again and again, which as I've
> pointed out at BUD17 is highly annoying! Even more annoying every single
> time Linaro marketing asks people to join as paying members because
> Linaro supposedly does so awesome Open Source work and such great
> 96Boards. Just this Friday again.

Who's ranting now?

Again, please don't extrapolate. For the SynQuacer based platform we
are involved with, there will be no vendor trees whatsoever. And I
share your frustration, especially when it comes to HiKey, because
they claim to implement UEFI (but building your own bootloader from
some random collection of EDK2 source files != UEFI), and keep trying
to upstream it.

> Nobody needs Reference Platform kernels if everything just timely gets
> merged into linux-next and mainline, where code belongs.

Agreed.

> Same for device trees, until the powers that be decide on a different
> location - which would not change the problem at all: Every review will
> be regarded as churn by someone else, and some people will always be
> lazy in submitting patches to whatever widely agreed-upon location, be
> it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.
>
> We wouldn't be having this argument if everything were great with the
> various non-central 96boards trees and downstream DTs.
>

Everything we need in the kernel and EDK2 will be upstream before the
product ships, and we are trying to do the same for ARM Trusted
Firmware, but this is a bit problematic due to the sorry state the
code is in.

Again, I am not the one who is ranting here. You hit a nerve by
accusing me of 'rebelling against linux.git' while this is quite the
opposite of what I am doing.

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 4 November 2017 at 20:06, Andreas F?rber <afaerber@suse.de> wrote:
> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>> On 4 November 2017 at 15:30, Andreas F?rber <afaerber@suse.de> wrote:
>>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>>> On 4 November 2017 at 13:44, Andreas F?rber <afaerber@suse.de> wrote:
>>>>> Hi everyone,
>>>>>
>>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>>> seems stuck on matters of naming and maintenance...
>>>>>
>>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>>> Hi Andreas,
>>>>>>
>>>>>> 2017-06-29 21:53 GMT+09:00 Andreas F?rber <afaerber@suse.de>:
>>>>>>> Hi Masahiro-san,
>>>>>>>
>>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>>> socionext.txt.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>>>>>>>>> ---
>>>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>>
>>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>>> --
>>>>>>>>
>>>>>>>> I do not mind this, but
>>>>>>>> please note there are multiple product lines in Socionext
>>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>>
>>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>>
>>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>>> for Uniphier:
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>>
>>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>>> only finds derived clk and reset bindings.
>>>>>>
>>>>>> I can care to send a patch later, but it is off-topic here.
>>>>>
>>>>> [The relevance was that had there been any bindings precedence from
>>>>> UniPhier, it would've influenced my naming choices.]
>>>>>
>>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>>
>>>>>> I was thinking of this way.
>>>>>>
>>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>>> in this directory level.
>>>>>>
>>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>>
>>>>>> I have no idea.
>>>>>> Actually, I am not familiar with those SoCs.
>>>>>>
>>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>>
>>>>>> I see some Socionext guys CC'ed in this mail,
>>>>>> somebody might have information about this.
>>>>>>
>>>>>> As I said before, I do not mind adding socionext.txt
>>>>>> and it seems reasonable enough
>>>>>> if there is no common name for those SoCs.
>>>>>>
>>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>>> new SoCs in fsl.txt, it seems.
>>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>>
>>>>>> Right, vendor names are not future-proof in some cases.
>>>>>>
>>>>>> We use "uniphier" because it is convenient to
>>>>>> make a group of SoCs with similar architecture,
>>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>>> future.  :-)
>>>>>
>>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>>> to indicate I'll again have to set up a new repository and start
>>>>> maintaining it myself.
>>>>>
>>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>>> also being Socionext.
>>>>>
>>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>>> against linux.git.
>>>>
>>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>>> to mean exactly?
>>>
>>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>>> and merged into the Linux tree before compatible strings may be used in
>>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
>>
>> OK, so where did we deviate from this in your opinion?
>
> I was very clear which new Socionext 96board platform my remark was
> about. There not being a socionext.txt file before this patch here hints
> at there being no official SoC binding defined for any.
>
> Adding one would require coordinating how to go about these platforms,
> as unsuccessfully attempted here.
>
> I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
> could've well come from you, given your rant.

I honestly have no idea what you are talking about here. You see
rebellion and argument where there is none.

>  Note that both the
> bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
> you're essentially fighting against your colleagues here...
>

I am not fighting anyone, but you seem to think we are rebelling.

The reality is that the platform topology is not finalized yet, and
submitting and merging what are essentially draft version of DT
descriptions and then having to update them is something we are trying
very hard to avoid. There is enough churn in upstream DTs as it is.

> Last but not least pretty much every shipping 96Board to date had a
> pre-installed DT that did not have official bindings submitted (I don't
> count the Cello as shipping) and thus later changed incompatibly.
>

We are working very hard to make sure the upstream bindings and
drivers in the kernel are in shape to support the SoC we are
developing firmware support for. When the time comes, we may or may
not decide to propose the SoC DT for inclusion in the kernel. But
those are two different things.

This has nothing to do with 'rebelling against linux.git' (your words)

>>> U-Boot only allows import of new .dts files from Linux, too.
>>>
>>> So Linus' linux.git is the location to merge any vendor prefixes and
>>> device tree bindings,
>>
>> Agreed.
>>
>>> as well as the central location for device trees.
>>
>> Why should there be a central location for device trees?
>
> Because with a .dtsi for SoC and SoM we can share DT code across boards
> and bootloaders. And at least one .dts is needed for compile-testing it.
> From a central location files can be either individually copied or
> potentially aggregated as submodules.
>
> DT patch reviews have resulted in GIC nodes growing virtualization
> support for instance, and there have been in-tree refactorings fixing
> the arch timer's interrupt type iirc. Comparing modeling across vendors
> is also useful to not live in silos.
>
> Also considering that drivers are spread over subsystem rather than SoC
> directories these days, the central location being Linux facilitates
> checking which platforms have been enabled already and to which degree.
>

I understand all that. But being able to review SoC DTs is one thing,
and deciding that the kernel repository shall be the authoritative
source is another.

In my view, this argues for having a shared repository, mailing list
etc between the Linux, u-boot, freebsd and EDK2 communities, because
it would increase review coverage, and make it easier to push back
against frivolous DT changes.

>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>>
>>> If you're unfamiliar with that, talk to your Linaro colleagues please!
>>
>> Please don't lecture me on this.
>
> If you ask questions, you may get answers. Blame yourself if you
> intended them as rhetorical questions.
>
>> The bindings are the contract between the OS and the platform, and I
>> agree that those need to be reviewed and maintained in a central
>> location, and the kernel tree, while not optimal, is a suitable place
>> for that.
>>
>> However, the existence of such contracts means that there is no need
>> to have a central location for device trees, nor should there be a
>> need for distros to ever ship device trees with the kernel. That
>> practice defeats the entire purpose of having contracts in the first
>> place, especially with the pathetic churn we are seeing in device
>> trees that are kept in the kernel.
>
> Please don't argue with me about these fundamentals. Not my decisions!
>
> This is not about distros shipping things; there is no openSUSE on these
> platforms precisely because code is not in central repositories.
>

By 'these platforms' you mean 96boards? Fair point. But please don't
extrapolate from Hikey (and FYI, Cello has been running mainline Linux
and EDK2 from the beginning)

> It's rather about three platforms by one vendor all going into different
> directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
> vendor kernel / U-Boot tarballs (and my kernel patches here), and
> UniPhier as only one in mainline kernel and mainline U-Boot.
>
> Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
> kernel you are trying to boot? Good luck... Even server vendors
> occasionally change their device trees with firmware updates.
>

You say that like it's a bad thing. Do you honestly think it is better
for the OS to pick its own DT from some tarball that shipped with it?

If the kernel driver developers wouldn't keep making backward
incompatible changes to the bindings, they could actually stabilize to
the point where it makes even more sense for the platform vendor to
fix bugs in their DT descriptions.

> Fact is, as platforms get enabled, device trees grow additional nodes
> and properties. DTs don't fall from skies in some final form for new SoCs.
>
> Especially not if they keep getting written by volunteers like me - I'm
> already enabling the fourth 96board because Linaro and its partners keep
> throwing ~3.10 kernels at users again and again and again, which as I've
> pointed out at BUD17 is highly annoying! Even more annoying every single
> time Linaro marketing asks people to join as paying members because
> Linaro supposedly does so awesome Open Source work and such great
> 96Boards. Just this Friday again.

Who's ranting now?

Again, please don't extrapolate. For the SynQuacer based platform we
are involved with, there will be no vendor trees whatsoever. And I
share your frustration, especially when it comes to HiKey, because
they claim to implement UEFI (but building your own bootloader from
some random collection of EDK2 source files != UEFI), and keep trying
to upstream it.

> Nobody needs Reference Platform kernels if everything just timely gets
> merged into linux-next and mainline, where code belongs.

Agreed.

> Same for device trees, until the powers that be decide on a different
> location - which would not change the problem at all: Every review will
> be regarded as churn by someone else, and some people will always be
> lazy in submitting patches to whatever widely agreed-upon location, be
> it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.
>
> We wouldn't be having this argument if everything were great with the
> various non-central 96boards trees and downstream DTs.
>

Everything we need in the kernel and EDK2 will be upstream before the
product ships, and we are trying to do the same for ARM Trusted
Firmware, but this is a bit problematic due to the sorry state the
code is in.

Again, I am not the one who is ranting here. You hit a nerve by
accusing me of 'rebelling against linux.git' while this is quite the
opposite of what I am doing.

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 20:06, Andreas Färber <afaerber@suse.de> wrote:
>> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 15:30, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>>>> On 4 November 2017 at 13:44, Andreas Färber <afaerber@suse.de> wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>>>> seems stuck on matters of naming and maintenance...
>>>>>>
>>>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>>>> Hi Andreas,
>>>>>>>
>>>>>>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
>>>>>>>> Hi Masahiro-san,
>>>>>>>>
>>>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>>>> socionext.txt.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>>>>>>>> ---
>>>>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>>>
>>>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> I do not mind this, but
>>>>>>>>> please note there are multiple product lines in Socionext
>>>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>>>
>>>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>>>
>>>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>>>> for Uniphier:
>>>>>>>>
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>>>
>>>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>>>> only finds derived clk and reset bindings.
>>>>>>>
>>>>>>> I can care to send a patch later, but it is off-topic here.
>>>>>>
>>>>>> [The relevance was that had there been any bindings precedence from
>>>>>> UniPhier, it would've influenced my naming choices.]
>>>>>>
>>>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>>>
>>>>>>> I was thinking of this way.
>>>>>>>
>>>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>>>> in this directory level.
>>>>>>>
>>>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>>>
>>>>>>> I have no idea.
>>>>>>> Actually, I am not familiar with those SoCs.
>>>>>>>
>>>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>>>
>>>>>>> I see some Socionext guys CC'ed in this mail,
>>>>>>> somebody might have information about this.
>>>>>>>
>>>>>>> As I said before, I do not mind adding socionext.txt
>>>>>>> and it seems reasonable enough
>>>>>>> if there is no common name for those SoCs.
>>>>>>>
>>>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>>>> new SoCs in fsl.txt, it seems.
>>>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>>>
>>>>>>> Right, vendor names are not future-proof in some cases.
>>>>>>>
>>>>>>> We use "uniphier" because it is convenient to
>>>>>>> make a group of SoCs with similar architecture,
>>>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>>>> future.  :-)
>>>>>>
>>>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>>>> to indicate I'll again have to set up a new repository and start
>>>>>> maintaining it myself.
>>>>>>
>>>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>>>> also being Socionext.
>>>>>>
>>>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>>>> against linux.git.
>>>>>
>>>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>>>> to mean exactly?
>>>>
>>>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>>>> and merged into the Linux tree before compatible strings may be used in
>>>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
>>>
>>> OK, so where did we deviate from this in your opinion?
>>
>> I was very clear which new Socionext 96board platform my remark was
>> about. There not being a socionext.txt file before this patch here hints
>> at there being no official SoC binding defined for any.
>>
>> Adding one would require coordinating how to go about these platforms,
>> as unsuccessfully attempted here.
>>
>> I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
>> could've well come from you, given your rant.
> 
> I honestly have no idea what you are talking about here. You see
> rebellion and argument where there is none.
> 
>>  Note that both the
>> bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
>> you're essentially fighting against your colleagues here...
>>
> 
> I am not fighting anyone, but you seem to think we are rebelling.
> 
> The reality is that the platform topology is not finalized yet, and
> submitting and merging what are essentially draft version of DT
> descriptions and then having to update them is something we are trying
> very hard to avoid. There is enough churn in upstream DTs as it is.
> 
>> Last but not least pretty much every shipping 96Board to date had a
>> pre-installed DT that did not have official bindings submitted (I don't
>> count the Cello as shipping) and thus later changed incompatibly.
>>
> 
> We are working very hard to make sure the upstream bindings and
> drivers in the kernel are in shape to support the SoC we are
> developing firmware support for. When the time comes, we may or may
> not decide to propose the SoC DT for inclusion in the kernel. But
> those are two different things.
> 
> This has nothing to do with 'rebelling against linux.git' (your words)
> 
>>>> U-Boot only allows import of new .dts files from Linux, too.
>>>>
>>>> So Linus' linux.git is the location to merge any vendor prefixes and
>>>> device tree bindings,
>>>
>>> Agreed.
>>>
>>>> as well as the central location for device trees.
>>>
>>> Why should there be a central location for device trees?
>>
>> Because with a .dtsi for SoC and SoM we can share DT code across boards
>> and bootloaders. And at least one .dts is needed for compile-testing it.
>> From a central location files can be either individually copied or
>> potentially aggregated as submodules.
>>
>> DT patch reviews have resulted in GIC nodes growing virtualization
>> support for instance, and there have been in-tree refactorings fixing
>> the arch timer's interrupt type iirc. Comparing modeling across vendors
>> is also useful to not live in silos.
>>
>> Also considering that drivers are spread over subsystem rather than SoC
>> directories these days, the central location being Linux facilitates
>> checking which platforms have been enabled already and to which degree.
>>
> 
> I understand all that. But being able to review SoC DTs is one thing,
> and deciding that the kernel repository shall be the authoritative
> source is another.
> 
> In my view, this argues for having a shared repository, mailing list
> etc between the Linux, u-boot, freebsd and EDK2 communities, because
> it would increase review coverage, and make it easier to push back
> against frivolous DT changes.
> 
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>>>
>>>> If you're unfamiliar with that, talk to your Linaro colleagues please!
>>>
>>> Please don't lecture me on this.
>>
>> If you ask questions, you may get answers. Blame yourself if you
>> intended them as rhetorical questions.
>>
>>> The bindings are the contract between the OS and the platform, and I
>>> agree that those need to be reviewed and maintained in a central
>>> location, and the kernel tree, while not optimal, is a suitable place
>>> for that.
>>>
>>> However, the existence of such contracts means that there is no need
>>> to have a central location for device trees, nor should there be a
>>> need for distros to ever ship device trees with the kernel. That
>>> practice defeats the entire purpose of having contracts in the first
>>> place, especially with the pathetic churn we are seeing in device
>>> trees that are kept in the kernel.
>>
>> Please don't argue with me about these fundamentals. Not my decisions!
>>
>> This is not about distros shipping things; there is no openSUSE on these
>> platforms precisely because code is not in central repositories.
>>
> 
> By 'these platforms' you mean 96boards? Fair point. But please don't
> extrapolate from Hikey (and FYI, Cello has been running mainline Linux
> and EDK2 from the beginning)
> 
>> It's rather about three platforms by one vendor all going into different
>> directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
>> vendor kernel / U-Boot tarballs (and my kernel patches here), and
>> UniPhier as only one in mainline kernel and mainline U-Boot.
>>
>> Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
>> kernel you are trying to boot? Good luck... Even server vendors
>> occasionally change their device trees with firmware updates.
>>
> 
> You say that like it's a bad thing. Do you honestly think it is better
> for the OS to pick its own DT from some tarball that shipped with it?
> 
> If the kernel driver developers wouldn't keep making backward
> incompatible changes to the bindings, they could actually stabilize to
> the point where it makes even more sense for the platform vendor to
> fix bugs in their DT descriptions.
> 
>> Fact is, as platforms get enabled, device trees grow additional nodes
>> and properties. DTs don't fall from skies in some final form for new SoCs.
>>
>> Especially not if they keep getting written by volunteers like me - I'm
>> already enabling the fourth 96board because Linaro and its partners keep
>> throwing ~3.10 kernels at users again and again and again, which as I've
>> pointed out at BUD17 is highly annoying! Even more annoying every single
>> time Linaro marketing asks people to join as paying members because
>> Linaro supposedly does so awesome Open Source work and such great
>> 96Boards. Just this Friday again.
> 
> Who's ranting now?
> 
> Again, please don't extrapolate. For the SynQuacer based platform we
> are involved with, there will be no vendor trees whatsoever. And I
> share your frustration, especially when it comes to HiKey, because
> they claim to implement UEFI (but building your own bootloader from
> some random collection of EDK2 source files != UEFI), and keep trying
> to upstream it.

Thanks for that.

>> Nobody needs Reference Platform kernels if everything just timely gets
>> merged into linux-next and mainline, where code belongs.
> 
> Agreed.
> 
>> Same for device trees, until the powers that be decide on a different
>> location - which would not change the problem at all: Every review will
>> be regarded as churn by someone else, and some people will always be
>> lazy in submitting patches to whatever widely agreed-upon location, be
>> it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.
>>
>> We wouldn't be having this argument if everything were great with the
>> various non-central 96boards trees and downstream DTs.
>>
> 
> Everything we need in the kernel and EDK2 will be upstream before the
> product ships, and we are trying to do the same for ARM Trusted
> Firmware, but this is a bit problematic due to the sorry state the
> code is in.
> 
> Again, I am not the one who is ranting here. You hit a nerve by
> accusing me of 'rebelling against linux.git' while this is quite the
> opposite of what I am doing.

Actually you did confirm that point by starting an argument about not
needing a central repository and you not liking Linux as the location.
That was exactly what I meant with my original comment.

Adding Actions Semi was somewhat easy as a new vendor and now - roughly
a year after the board went to market - there's Linaro contributions
from Mani that I'm thankful for.

Whereas patches keep falling into a dark hole when there's already other
work for a certain vendor, such as Marvell and now Socionext, with no
one feeling responsible for either taking them or saying, "hey, we're
not going to submit any conflicting DT bindings for SynQuacer because we
use ACPI, so please go ahead with proposal X, thanks for your efforts".

Don't complain about me ranting if you belittle my volunteer work that I
believe Linaro and its partners should've done in the first place: If I
can get an initial mainline PoC done as an individual on a few
evenings/weekends, then the same should be super-easy for an
organization with lots of engineers and paying member companies.
As I've pointed out, an ever-increasing frustration builds over Linaro
continuing to announce new boards (such as SynQuacer) that will be the
best since sliced bread, while neglecting the 96boards that are already
on the market and equally are promoted under the "96Boards" brand.
The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
management is aware of that hardware, and yet not a single patch came
from Xunlong, RDA Micro or Linaro. No patch review from RDA either. And
my patches got stuck on the bindings not including interrupts property
for the UART yet, since I still do not have their custom interrupt
controller working... So the context here is that not just my 4.14+
pulls got stuck but three other 96Boards patch series, too.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 20:06, Andreas F?rber <afaerber@suse.de> wrote:
>> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 15:30, Andreas F?rber <afaerber@suse.de> wrote:
>>>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>>>> On 4 November 2017 at 13:44, Andreas F?rber <afaerber@suse.de> wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>>>> seems stuck on matters of naming and maintenance...
>>>>>>
>>>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>>>> Hi Andreas,
>>>>>>>
>>>>>>> 2017-06-29 21:53 GMT+09:00 Andreas F?rber <afaerber@suse.de>:
>>>>>>>> Hi Masahiro-san,
>>>>>>>>
>>>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>>>> socionext.txt.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>>>>>>>>>> ---
>>>>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>>>
>>>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> I do not mind this, but
>>>>>>>>> please note there are multiple product lines in Socionext
>>>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>>>
>>>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>>>
>>>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>>>> for Uniphier:
>>>>>>>>
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>>>
>>>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>>>> only finds derived clk and reset bindings.
>>>>>>>
>>>>>>> I can care to send a patch later, but it is off-topic here.
>>>>>>
>>>>>> [The relevance was that had there been any bindings precedence from
>>>>>> UniPhier, it would've influenced my naming choices.]
>>>>>>
>>>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>>>
>>>>>>> I was thinking of this way.
>>>>>>>
>>>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>>>> in this directory level.
>>>>>>>
>>>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>>>
>>>>>>> I have no idea.
>>>>>>> Actually, I am not familiar with those SoCs.
>>>>>>>
>>>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>>>
>>>>>>> I see some Socionext guys CC'ed in this mail,
>>>>>>> somebody might have information about this.
>>>>>>>
>>>>>>> As I said before, I do not mind adding socionext.txt
>>>>>>> and it seems reasonable enough
>>>>>>> if there is no common name for those SoCs.
>>>>>>>
>>>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>>>> new SoCs in fsl.txt, it seems.
>>>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>>>
>>>>>>> Right, vendor names are not future-proof in some cases.
>>>>>>>
>>>>>>> We use "uniphier" because it is convenient to
>>>>>>> make a group of SoCs with similar architecture,
>>>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>>>> future.  :-)
>>>>>>
>>>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>>>> to indicate I'll again have to set up a new repository and start
>>>>>> maintaining it myself.
>>>>>>
>>>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>>>> also being Socionext.
>>>>>>
>>>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>>>> against linux.git.
>>>>>
>>>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>>>> to mean exactly?
>>>>
>>>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>>>> and merged into the Linux tree before compatible strings may be used in
>>>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
>>>
>>> OK, so where did we deviate from this in your opinion?
>>
>> I was very clear which new Socionext 96board platform my remark was
>> about. There not being a socionext.txt file before this patch here hints
>> at there being no official SoC binding defined for any.
>>
>> Adding one would require coordinating how to go about these platforms,
>> as unsuccessfully attempted here.
>>
>> I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
>> could've well come from you, given your rant.
> 
> I honestly have no idea what you are talking about here. You see
> rebellion and argument where there is none.
> 
>>  Note that both the
>> bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
>> you're essentially fighting against your colleagues here...
>>
> 
> I am not fighting anyone, but you seem to think we are rebelling.
> 
> The reality is that the platform topology is not finalized yet, and
> submitting and merging what are essentially draft version of DT
> descriptions and then having to update them is something we are trying
> very hard to avoid. There is enough churn in upstream DTs as it is.
> 
>> Last but not least pretty much every shipping 96Board to date had a
>> pre-installed DT that did not have official bindings submitted (I don't
>> count the Cello as shipping) and thus later changed incompatibly.
>>
> 
> We are working very hard to make sure the upstream bindings and
> drivers in the kernel are in shape to support the SoC we are
> developing firmware support for. When the time comes, we may or may
> not decide to propose the SoC DT for inclusion in the kernel. But
> those are two different things.
> 
> This has nothing to do with 'rebelling against linux.git' (your words)
> 
>>>> U-Boot only allows import of new .dts files from Linux, too.
>>>>
>>>> So Linus' linux.git is the location to merge any vendor prefixes and
>>>> device tree bindings,
>>>
>>> Agreed.
>>>
>>>> as well as the central location for device trees.
>>>
>>> Why should there be a central location for device trees?
>>
>> Because with a .dtsi for SoC and SoM we can share DT code across boards
>> and bootloaders. And at least one .dts is needed for compile-testing it.
>> From a central location files can be either individually copied or
>> potentially aggregated as submodules.
>>
>> DT patch reviews have resulted in GIC nodes growing virtualization
>> support for instance, and there have been in-tree refactorings fixing
>> the arch timer's interrupt type iirc. Comparing modeling across vendors
>> is also useful to not live in silos.
>>
>> Also considering that drivers are spread over subsystem rather than SoC
>> directories these days, the central location being Linux facilitates
>> checking which platforms have been enabled already and to which degree.
>>
> 
> I understand all that. But being able to review SoC DTs is one thing,
> and deciding that the kernel repository shall be the authoritative
> source is another.
> 
> In my view, this argues for having a shared repository, mailing list
> etc between the Linux, u-boot, freebsd and EDK2 communities, because
> it would increase review coverage, and make it easier to push back
> against frivolous DT changes.
> 
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>>>
>>>> If you're unfamiliar with that, talk to your Linaro colleagues please!
>>>
>>> Please don't lecture me on this.
>>
>> If you ask questions, you may get answers. Blame yourself if you
>> intended them as rhetorical questions.
>>
>>> The bindings are the contract between the OS and the platform, and I
>>> agree that those need to be reviewed and maintained in a central
>>> location, and the kernel tree, while not optimal, is a suitable place
>>> for that.
>>>
>>> However, the existence of such contracts means that there is no need
>>> to have a central location for device trees, nor should there be a
>>> need for distros to ever ship device trees with the kernel. That
>>> practice defeats the entire purpose of having contracts in the first
>>> place, especially with the pathetic churn we are seeing in device
>>> trees that are kept in the kernel.
>>
>> Please don't argue with me about these fundamentals. Not my decisions!
>>
>> This is not about distros shipping things; there is no openSUSE on these
>> platforms precisely because code is not in central repositories.
>>
> 
> By 'these platforms' you mean 96boards? Fair point. But please don't
> extrapolate from Hikey (and FYI, Cello has been running mainline Linux
> and EDK2 from the beginning)
> 
>> It's rather about three platforms by one vendor all going into different
>> directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
>> vendor kernel / U-Boot tarballs (and my kernel patches here), and
>> UniPhier as only one in mainline kernel and mainline U-Boot.
>>
>> Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
>> kernel you are trying to boot? Good luck... Even server vendors
>> occasionally change their device trees with firmware updates.
>>
> 
> You say that like it's a bad thing. Do you honestly think it is better
> for the OS to pick its own DT from some tarball that shipped with it?
> 
> If the kernel driver developers wouldn't keep making backward
> incompatible changes to the bindings, they could actually stabilize to
> the point where it makes even more sense for the platform vendor to
> fix bugs in their DT descriptions.
> 
>> Fact is, as platforms get enabled, device trees grow additional nodes
>> and properties. DTs don't fall from skies in some final form for new SoCs.
>>
>> Especially not if they keep getting written by volunteers like me - I'm
>> already enabling the fourth 96board because Linaro and its partners keep
>> throwing ~3.10 kernels at users again and again and again, which as I've
>> pointed out at BUD17 is highly annoying! Even more annoying every single
>> time Linaro marketing asks people to join as paying members because
>> Linaro supposedly does so awesome Open Source work and such great
>> 96Boards. Just this Friday again.
> 
> Who's ranting now?
> 
> Again, please don't extrapolate. For the SynQuacer based platform we
> are involved with, there will be no vendor trees whatsoever. And I
> share your frustration, especially when it comes to HiKey, because
> they claim to implement UEFI (but building your own bootloader from
> some random collection of EDK2 source files != UEFI), and keep trying
> to upstream it.

Thanks for that.

>> Nobody needs Reference Platform kernels if everything just timely gets
>> merged into linux-next and mainline, where code belongs.
> 
> Agreed.
> 
>> Same for device trees, until the powers that be decide on a different
>> location - which would not change the problem at all: Every review will
>> be regarded as churn by someone else, and some people will always be
>> lazy in submitting patches to whatever widely agreed-upon location, be
>> it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.
>>
>> We wouldn't be having this argument if everything were great with the
>> various non-central 96boards trees and downstream DTs.
>>
> 
> Everything we need in the kernel and EDK2 will be upstream before the
> product ships, and we are trying to do the same for ARM Trusted
> Firmware, but this is a bit problematic due to the sorry state the
> code is in.
> 
> Again, I am not the one who is ranting here. You hit a nerve by
> accusing me of 'rebelling against linux.git' while this is quite the
> opposite of what I am doing.

Actually you did confirm that point by starting an argument about not
needing a central repository and you not liking Linux as the location.
That was exactly what I meant with my original comment.

Adding Actions Semi was somewhat easy as a new vendor and now - roughly
a year after the board went to market - there's Linaro contributions
from Mani that I'm thankful for.

Whereas patches keep falling into a dark hole when there's already other
work for a certain vendor, such as Marvell and now Socionext, with no
one feeling responsible for either taking them or saying, "hey, we're
not going to submit any conflicting DT bindings for SynQuacer because we
use ACPI, so please go ahead with proposal X, thanks for your efforts".

Don't complain about me ranting if you belittle my volunteer work that I
believe Linaro and its partners should've done in the first place: If I
can get an initial mainline PoC done as an individual on a few
evenings/weekends, then the same should be super-easy for an
organization with lots of engineers and paying member companies.
As I've pointed out, an ever-increasing frustration builds over Linaro
continuing to announce new boards (such as SynQuacer) that will be the
best since sliced bread, while neglecting the 96boards that are already
on the market and equally are promoted under the "96Boards" brand.
The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
management is aware of that hardware, and yet not a single patch came
from Xunlong, RDA Micro or Linaro. No patch review from RDA either. And
my patches got stuck on the bindings not including interrupts property
for the UART yet, since I still do not have their custom interrupt
controller working... So the context here is that not just my 4.14+
pulls got stuck but three other 96Boards patch series, too.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 20:06, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote:
>> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 15:30, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote:
>>>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>>>> On 4 November 2017 at 13:44, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>>>> seems stuck on matters of naming and maintenance...
>>>>>>
>>>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>>>> Hi Andreas,
>>>>>>>
>>>>>>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>:
>>>>>>>> Hi Masahiro-san,
>>>>>>>>
>>>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>>>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>>>> socionext.txt.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
>>>>>>>>>>> ---
>>>>>>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>>>  1 file changed, 17 insertions(+)
>>>>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>>>
>>>>>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> I do not mind this, but
>>>>>>>>> please note there are multiple product lines in Socionext
>>>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>>>
>>>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>>>
>>>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>>>> for Uniphier:
>>>>>>>>
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>>>
>>>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>>>> only finds derived clk and reset bindings.
>>>>>>>
>>>>>>> I can care to send a patch later, but it is off-topic here.
>>>>>>
>>>>>> [The relevance was that had there been any bindings precedence from
>>>>>> UniPhier, it would've influenced my naming choices.]
>>>>>>
>>>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>>>
>>>>>>> I was thinking of this way.
>>>>>>>
>>>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>>>> in this directory level.
>>>>>>>
>>>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>>>
>>>>>>> I have no idea.
>>>>>>> Actually, I am not familiar with those SoCs.
>>>>>>>
>>>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>>>
>>>>>>> I see some Socionext guys CC'ed in this mail,
>>>>>>> somebody might have information about this.
>>>>>>>
>>>>>>> As I said before, I do not mind adding socionext.txt
>>>>>>> and it seems reasonable enough
>>>>>>> if there is no common name for those SoCs.
>>>>>>>
>>>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>>>> new SoCs in fsl.txt, it seems.
>>>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>>>
>>>>>>> Right, vendor names are not future-proof in some cases.
>>>>>>>
>>>>>>> We use "uniphier" because it is convenient to
>>>>>>> make a group of SoCs with similar architecture,
>>>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>>>> future.  :-)
>>>>>>
>>>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>>>> to indicate I'll again have to set up a new repository and start
>>>>>> maintaining it myself.
>>>>>>
>>>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>>>> also being Socionext.
>>>>>>
>>>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>>>> against linux.git.
>>>>>
>>>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>>>> to mean exactly?
>>>>
>>>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>>>> and merged into the Linux tree before compatible strings may be used in
>>>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
>>>
>>> OK, so where did we deviate from this in your opinion?
>>
>> I was very clear which new Socionext 96board platform my remark was
>> about. There not being a socionext.txt file before this patch here hints
>> at there being no official SoC binding defined for any.
>>
>> Adding one would require coordinating how to go about these platforms,
>> as unsuccessfully attempted here.
>>
>> I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
>> could've well come from you, given your rant.
> 
> I honestly have no idea what you are talking about here. You see
> rebellion and argument where there is none.
> 
>>  Note that both the
>> bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
>> you're essentially fighting against your colleagues here...
>>
> 
> I am not fighting anyone, but you seem to think we are rebelling.
> 
> The reality is that the platform topology is not finalized yet, and
> submitting and merging what are essentially draft version of DT
> descriptions and then having to update them is something we are trying
> very hard to avoid. There is enough churn in upstream DTs as it is.
> 
>> Last but not least pretty much every shipping 96Board to date had a
>> pre-installed DT that did not have official bindings submitted (I don't
>> count the Cello as shipping) and thus later changed incompatibly.
>>
> 
> We are working very hard to make sure the upstream bindings and
> drivers in the kernel are in shape to support the SoC we are
> developing firmware support for. When the time comes, we may or may
> not decide to propose the SoC DT for inclusion in the kernel. But
> those are two different things.
> 
> This has nothing to do with 'rebelling against linux.git' (your words)
> 
>>>> U-Boot only allows import of new .dts files from Linux, too.
>>>>
>>>> So Linus' linux.git is the location to merge any vendor prefixes and
>>>> device tree bindings,
>>>
>>> Agreed.
>>>
>>>> as well as the central location for device trees.
>>>
>>> Why should there be a central location for device trees?
>>
>> Because with a .dtsi for SoC and SoM we can share DT code across boards
>> and bootloaders. And at least one .dts is needed for compile-testing it.
>> From a central location files can be either individually copied or
>> potentially aggregated as submodules.
>>
>> DT patch reviews have resulted in GIC nodes growing virtualization
>> support for instance, and there have been in-tree refactorings fixing
>> the arch timer's interrupt type iirc. Comparing modeling across vendors
>> is also useful to not live in silos.
>>
>> Also considering that drivers are spread over subsystem rather than SoC
>> directories these days, the central location being Linux facilitates
>> checking which platforms have been enabled already and to which degree.
>>
> 
> I understand all that. But being able to review SoC DTs is one thing,
> and deciding that the kernel repository shall be the authoritative
> source is another.
> 
> In my view, this argues for having a shared repository, mailing list
> etc between the Linux, u-boot, freebsd and EDK2 communities, because
> it would increase review coverage, and make it easier to push back
> against frivolous DT changes.
> 
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>>>
>>>> If you're unfamiliar with that, talk to your Linaro colleagues please!
>>>
>>> Please don't lecture me on this.
>>
>> If you ask questions, you may get answers. Blame yourself if you
>> intended them as rhetorical questions.
>>
>>> The bindings are the contract between the OS and the platform, and I
>>> agree that those need to be reviewed and maintained in a central
>>> location, and the kernel tree, while not optimal, is a suitable place
>>> for that.
>>>
>>> However, the existence of such contracts means that there is no need
>>> to have a central location for device trees, nor should there be a
>>> need for distros to ever ship device trees with the kernel. That
>>> practice defeats the entire purpose of having contracts in the first
>>> place, especially with the pathetic churn we are seeing in device
>>> trees that are kept in the kernel.
>>
>> Please don't argue with me about these fundamentals. Not my decisions!
>>
>> This is not about distros shipping things; there is no openSUSE on these
>> platforms precisely because code is not in central repositories.
>>
> 
> By 'these platforms' you mean 96boards? Fair point. But please don't
> extrapolate from Hikey (and FYI, Cello has been running mainline Linux
> and EDK2 from the beginning)
> 
>> It's rather about three platforms by one vendor all going into different
>> directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
>> vendor kernel / U-Boot tarballs (and my kernel patches here), and
>> UniPhier as only one in mainline kernel and mainline U-Boot.
>>
>> Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
>> kernel you are trying to boot? Good luck... Even server vendors
>> occasionally change their device trees with firmware updates.
>>
> 
> You say that like it's a bad thing. Do you honestly think it is better
> for the OS to pick its own DT from some tarball that shipped with it?
> 
> If the kernel driver developers wouldn't keep making backward
> incompatible changes to the bindings, they could actually stabilize to
> the point where it makes even more sense for the platform vendor to
> fix bugs in their DT descriptions.
> 
>> Fact is, as platforms get enabled, device trees grow additional nodes
>> and properties. DTs don't fall from skies in some final form for new SoCs.
>>
>> Especially not if they keep getting written by volunteers like me - I'm
>> already enabling the fourth 96board because Linaro and its partners keep
>> throwing ~3.10 kernels at users again and again and again, which as I've
>> pointed out at BUD17 is highly annoying! Even more annoying every single
>> time Linaro marketing asks people to join as paying members because
>> Linaro supposedly does so awesome Open Source work and such great
>> 96Boards. Just this Friday again.
> 
> Who's ranting now?
> 
> Again, please don't extrapolate. For the SynQuacer based platform we
> are involved with, there will be no vendor trees whatsoever. And I
> share your frustration, especially when it comes to HiKey, because
> they claim to implement UEFI (but building your own bootloader from
> some random collection of EDK2 source files != UEFI), and keep trying
> to upstream it.

Thanks for that.

>> Nobody needs Reference Platform kernels if everything just timely gets
>> merged into linux-next and mainline, where code belongs.
> 
> Agreed.
> 
>> Same for device trees, until the powers that be decide on a different
>> location - which would not change the problem at all: Every review will
>> be regarded as churn by someone else, and some people will always be
>> lazy in submitting patches to whatever widely agreed-upon location, be
>> it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.
>>
>> We wouldn't be having this argument if everything were great with the
>> various non-central 96boards trees and downstream DTs.
>>
> 
> Everything we need in the kernel and EDK2 will be upstream before the
> product ships, and we are trying to do the same for ARM Trusted
> Firmware, but this is a bit problematic due to the sorry state the
> code is in.
> 
> Again, I am not the one who is ranting here. You hit a nerve by
> accusing me of 'rebelling against linux.git' while this is quite the
> opposite of what I am doing.

Actually you did confirm that point by starting an argument about not
needing a central repository and you not liking Linux as the location.
That was exactly what I meant with my original comment.

Adding Actions Semi was somewhat easy as a new vendor and now - roughly
a year after the board went to market - there's Linaro contributions
from Mani that I'm thankful for.

Whereas patches keep falling into a dark hole when there's already other
work for a certain vendor, such as Marvell and now Socionext, with no
one feeling responsible for either taking them or saying, "hey, we're
not going to submit any conflicting DT bindings for SynQuacer because we
use ACPI, so please go ahead with proposal X, thanks for your efforts".

Don't complain about me ranting if you belittle my volunteer work that I
believe Linaro and its partners should've done in the first place: If I
can get an initial mainline PoC done as an individual on a few
evenings/weekends, then the same should be super-easy for an
organization with lots of engineers and paying member companies.
As I've pointed out, an ever-increasing frustration builds over Linaro
continuing to announce new boards (such as SynQuacer) that will be the
best since sliced bread, while neglecting the 96boards that are already
on the market and equally are promoted under the "96Boards" brand.
The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
management is aware of that hardware, and yet not a single patch came
from Xunlong, RDA Micro or Linaro. No patch review from RDA either. And
my patches got stuck on the bindings not including interrupts property
for the UART yet, since I still do not have their custom interrupt
controller working... So the context here is that not just my 4.14+
pulls got stuck but three other 96Boards patch series, too.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Yang Zhang]

> On 6 Nov 2017, at 06:58, Andreas Färber <afaerber@suse.de> wrote:
> 
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 20:06, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>>>>> On 4 November 2017 at 15:30, Andreas Färber <afaerber@suse.de> wrote:
>>>>>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>>>>>> On 4 November 2017 at 13:44, Andreas Färber <afaerber@suse.de> wrote:
>>>>>>> Hi everyone,
>>>>>>> 
>>>>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>>>>> seems stuck on matters of naming and maintenance...
>>>>>>> 
>>>>>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>>>>> Hi Andreas,
>>>>>>>> 
>>>>>>>> 2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
>>>>>>>>> Hi Masahiro-san,
>>>>>>>>> 
>>>>>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>>>>> socionext.txt.
>>>>>>>>>>>> 
>>>>>>>>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>>>>>>>>> ---
>>>>>>>>>>>> Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>>>> 1 file changed, 17 insertions(+)
>>>>>>>>>>>> create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>>>> 
>>>>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>>>>> --
>>>>>>>>>> 
>>>>>>>>>> I do not mind this, but
>>>>>>>>>> please note there are multiple product lines in Socionext
>>>>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>>>> 
>>>>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>>>> 
>>>>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>>>>> for Uniphier:
>>>>>>>>> 
>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>>>> 
>>>>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>>>>> only finds derived clk and reset bindings.
>>>>>>>> 
>>>>>>>> I can care to send a patch later, but it is off-topic here.
>>>>>>> 
>>>>>>> [The relevance was that had there been any bindings precedence from
>>>>>>> UniPhier, it would've influenced my naming choices.]
>>>>>>> 
>>>>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>>>> 
>>>>>>>> I was thinking of this way.
>>>>>>>> 
>>>>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>>>>> in this directory level.
>>>>>>>> 
>>>>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>>>> 
>>>>>>>> I have no idea.
>>>>>>>> Actually, I am not familiar with those SoCs.
>>>>>>>> 
>>>>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>>>> 
>>>>>>>> I see some Socionext guys CC'ed in this mail,
>>>>>>>> somebody might have information about this.
>>>>>>>> 
>>>>>>>> As I said before, I do not mind adding socionext.txt
>>>>>>>> and it seems reasonable enough
>>>>>>>> if there is no common name for those SoCs.
>>>>>>>> 
>>>>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>>>>> new SoCs in fsl.txt, it seems.
>>>>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>>>> 
>>>>>>>> Right, vendor names are not future-proof in some cases.
>>>>>>>> 
>>>>>>>> We use "uniphier" because it is convenient to
>>>>>>>> make a group of SoCs with similar architecture,
>>>>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>>>>> future.  :-)
>>>>>>> 
>>>>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>>>>> to indicate I'll again have to set up a new repository and start
>>>>>>> maintaining it myself.
>>>>>>> 
>>>>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>>>>> also being Socionext.
>>>>>>> 
>>>>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>>>>> against linux.git.
>>>>>> 
>>>>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>>>>> to mean exactly?
>>>>> 
>>>>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>>>>> and merged into the Linux tree before compatible strings may be used in
>>>>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
>>>> 
>>>> OK, so where did we deviate from this in your opinion?
>>> 
>>> I was very clear which new Socionext 96board platform my remark was
>>> about. There not being a socionext.txt file before this patch here hints
>>> at there being no official SoC binding defined for any.
>>> 
>>> Adding one would require coordinating how to go about these platforms,
>>> as unsuccessfully attempted here.
>>> 
>>> I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
>>> could've well come from you, given your rant.
>> 
>> I honestly have no idea what you are talking about here. You see
>> rebellion and argument where there is none.
>> 
>>> Note that both the
>>> bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
>>> you're essentially fighting against your colleagues here...
>>> 
>> 
>> I am not fighting anyone, but you seem to think we are rebelling.
>> 
>> The reality is that the platform topology is not finalized yet, and
>> submitting and merging what are essentially draft version of DT
>> descriptions and then having to update them is something we are trying
>> very hard to avoid. There is enough churn in upstream DTs as it is.
>> 
>>> Last but not least pretty much every shipping 96Board to date had a
>>> pre-installed DT that did not have official bindings submitted (I don't
>>> count the Cello as shipping) and thus later changed incompatibly.
>>> 
>> 
>> We are working very hard to make sure the upstream bindings and
>> drivers in the kernel are in shape to support the SoC we are
>> developing firmware support for. When the time comes, we may or may
>> not decide to propose the SoC DT for inclusion in the kernel. But
>> those are two different things.
>> 
>> This has nothing to do with 'rebelling against linux.git' (your words)
>> 
>>>>> U-Boot only allows import of new .dts files from Linux, too.
>>>>> 
>>>>> So Linus' linux.git is the location to merge any vendor prefixes and
>>>>> device tree bindings,
>>>> 
>>>> Agreed.
>>>> 
>>>>> as well as the central location for device trees.
>>>> 
>>>> Why should there be a central location for device trees?
>>> 
>>> Because with a .dtsi for SoC and SoM we can share DT code across boards
>>> and bootloaders. And at least one .dts is needed for compile-testing it.
>>> From a central location files can be either individually copied or
>>> potentially aggregated as submodules.
>>> 
>>> DT patch reviews have resulted in GIC nodes growing virtualization
>>> support for instance, and there have been in-tree refactorings fixing
>>> the arch timer's interrupt type iirc. Comparing modeling across vendors
>>> is also useful to not live in silos.
>>> 
>>> Also considering that drivers are spread over subsystem rather than SoC
>>> directories these days, the central location being Linux facilitates
>>> checking which platforms have been enabled already and to which degree.
>>> 
>> 
>> I understand all that. But being able to review SoC DTs is one thing,
>> and deciding that the kernel repository shall be the authoritative
>> source is another.
>> 
>> In my view, this argues for having a shared repository, mailing list
>> etc between the Linux, u-boot, freebsd and EDK2 communities, because
>> it would increase review coverage, and make it easier to push back
>> against frivolous DT changes.
>> 
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>>>> 
>>>>> If you're unfamiliar with that, talk to your Linaro colleagues please!
>>>> 
>>>> Please don't lecture me on this.
>>> 
>>> If you ask questions, you may get answers. Blame yourself if you
>>> intended them as rhetorical questions.
>>> 
>>>> The bindings are the contract between the OS and the platform, and I
>>>> agree that those need to be reviewed and maintained in a central
>>>> location, and the kernel tree, while not optimal, is a suitable place
>>>> for that.
>>>> 
>>>> However, the existence of such contracts means that there is no need
>>>> to have a central location for device trees, nor should there be a
>>>> need for distros to ever ship device trees with the kernel. That
>>>> practice defeats the entire purpose of having contracts in the first
>>>> place, especially with the pathetic churn we are seeing in device
>>>> trees that are kept in the kernel.
>>> 
>>> Please don't argue with me about these fundamentals. Not my decisions!
>>> 
>>> This is not about distros shipping things; there is no openSUSE on these
>>> platforms precisely because code is not in central repositories.
>>> 
>> 
>> By 'these platforms' you mean 96boards? Fair point. But please don't
>> extrapolate from Hikey (and FYI, Cello has been running mainline Linux
>> and EDK2 from the beginning)
>> 
>>> It's rather about three platforms by one vendor all going into different
>>> directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
>>> vendor kernel / U-Boot tarballs (and my kernel patches here), and
>>> UniPhier as only one in mainline kernel and mainline U-Boot.
>>> 
>>> Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
>>> kernel you are trying to boot? Good luck... Even server vendors
>>> occasionally change their device trees with firmware updates.
>>> 
>> 
>> You say that like it's a bad thing. Do you honestly think it is better
>> for the OS to pick its own DT from some tarball that shipped with it?
>> 
>> If the kernel driver developers wouldn't keep making backward
>> incompatible changes to the bindings, they could actually stabilize to
>> the point where it makes even more sense for the platform vendor to
>> fix bugs in their DT descriptions.
>> 
>>> Fact is, as platforms get enabled, device trees grow additional nodes
>>> and properties. DTs don't fall from skies in some final form for new SoCs.
>>> 
>>> Especially not if they keep getting written by volunteers like me - I'm
>>> already enabling the fourth 96board because Linaro and its partners keep
>>> throwing ~3.10 kernels at users again and again and again, which as I've
>>> pointed out at BUD17 is highly annoying! Even more annoying every single
>>> time Linaro marketing asks people to join as paying members because
>>> Linaro supposedly does so awesome Open Source work and such great
>>> 96Boards. Just this Friday again.
>> 
>> Who's ranting now?
>> 
>> Again, please don't extrapolate. For the SynQuacer based platform we
>> are involved with, there will be no vendor trees whatsoever. And I
>> share your frustration, especially when it comes to HiKey, because
>> they claim to implement UEFI (but building your own bootloader from
>> some random collection of EDK2 source files != UEFI), and keep trying
>> to upstream it.
> 
> Thanks for that.
> 
>>> Nobody needs Reference Platform kernels if everything just timely gets
>>> merged into linux-next and mainline, where code belongs.
>> 
>> Agreed.
>> 
>>> Same for device trees, until the powers that be decide on a different
>>> location - which would not change the problem at all: Every review will
>>> be regarded as churn by someone else, and some people will always be
>>> lazy in submitting patches to whatever widely agreed-upon location, be
>>> it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.
>>> 
>>> We wouldn't be having this argument if everything were great with the
>>> various non-central 96boards trees and downstream DTs.
>>> 
>> 
>> Everything we need in the kernel and EDK2 will be upstream before the
>> product ships, and we are trying to do the same for ARM Trusted
>> Firmware, but this is a bit problematic due to the sorry state the
>> code is in.
>> 
>> Again, I am not the one who is ranting here. You hit a nerve by
>> accusing me of 'rebelling against linux.git' while this is quite the
>> opposite of what I am doing.
> 
> Actually you did confirm that point by starting an argument about not
> needing a central repository and you not liking Linux as the location.
> That was exactly what I meant with my original comment.
> 
> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
> a year after the board went to market - there's Linaro contributions
> from Mani that I'm thankful for.

Thanks for your comments Andreas. Cc Mani as due to his joining, we continue to improve our upstream efforts. 
> 
> Whereas patches keep falling into a dark hole when there's already other
> work for a certain vendor, such as Marvell and now Socionext, with no
> one feeling responsible for either taking them or saying, "hey, we're
> not going to submit any conflicting DT bindings for SynQuacer because we
> use ACPI, so please go ahead with proposal X, thanks for your efforts".
> 
> Don't complain about me ranting if you belittle my volunteer work that I
> believe Linaro and its partners should've done in the first place

No one is belittling the work you have put in place. We certainly appreciate all you have helped to put together so far and we do not claim 96Boards is a perfect child as far as cross SoC upstreaming efforts is concerned. We are quite constrained when there’s little or none at all or initial resource from SoC vendors pulling away from a platform. But we are still trying very hard. And we are exploring different ways of doing this too.

> : If I
> can get an initial mainline PoC done as an individual on a few
> evenings/weekends, then the same should be super-easy for an
> organization with lots of engineers and paying member companies.

No it’s not. 96Boards (in Linaro) has bare minimum amount budget and is relying heavily on volunteering efforts from people such as Ard and yourself.

> As I've pointed out, an ever-increasing frustration builds over Linaro
> continuing to announce new boards (such as SynQuacer) that will be the
> best since sliced bread, while neglecting the 96boards that are already
> on the market and equally are promoted under the "96Boards" brand.
> The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
> management is aware of that hardware, and yet not a single patch came
> from Xunlong, RDA Micro or Linaro. No patch review from RDA either.

You are correct. We have been struggling to get commitment from parties to sort out the 3.10 based old code line on a SoC, although still very useful but now EoL. 96Boards simply does not have such resource to carry out each platform upstreaming work in absence of other vendors commitment.

> And
> my patches got stuck on the bindings not including interrupts property
> for the UART yet, since I still do not have their custom interrupt
> controller working... So the context here is that not just my 4.14+
> pulls got stuck but three other 96Boards patch series, too.
> Regards,
> Andreas

We could certainly have a discussion regarding multiple 96Boards software status (or lack of it) but I feel we are hijacking the original topic of this thread.
> 
> -- 
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Yang Zhang]

> On 6 Nov 2017, at 06:58, Andreas F?rber <afaerber@suse.de> wrote:
> 
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 20:06, Andreas F?rber <afaerber@suse.de> wrote:
>>>> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>>>>> On 4 November 2017 at 15:30, Andreas F?rber <afaerber@suse.de> wrote:
>>>>>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>>>>>> On 4 November 2017 at 13:44, Andreas F?rber <afaerber@suse.de> wrote:
>>>>>>> Hi everyone,
>>>>>>> 
>>>>>>> The non-building clk driver has been removed for 4.14, but this patchset
>>>>>>> seems stuck on matters of naming and maintenance...
>>>>>>> 
>>>>>>>> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>>>>>>>> Hi Andreas,
>>>>>>>> 
>>>>>>>> 2017-06-29 21:53 GMT+09:00 Andreas F?rber <afaerber@suse.de>:
>>>>>>>>> Hi Masahiro-san,
>>>>>>>>> 
>>>>>>>>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>>>>>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>>>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas F?rber wrote:
>>>>>>>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>>>>>>>> socionext.txt.
>>>>>>>>>>>> 
>>>>>>>>>>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>>>>>>>>>>> ---
>>>>>>>>>>>> Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>>>>>>> 1 file changed, 17 insertions(+)
>>>>>>>>>>>> create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>>>>>>> 
>>>>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>>>>> --
>>>>>>>>>> 
>>>>>>>>>> I do not mind this, but
>>>>>>>>>> please note there are multiple product lines in Socionext
>>>>>>>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>>>>>>> 
>>>>>>>>>> I maintain documents for Socionext UniPhier SoC family
>>>>>>>>>> (which inherits SoC architecture of Panasonic)
>>>>>>>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>>>>>>> 
>>>>>>>>> Actually you seemed to be lacking bindings beyond the cache controller
>>>>>>>>> for Uniphier:
>>>>>>>>> 
>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>>>>>>> 
>>>>>>>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>>>>>>>> somewhere too, as done here. A git-grep for that particular compatible
>>>>>>>>> only finds derived clk and reset bindings.
>>>>>>>> 
>>>>>>>> I can care to send a patch later, but it is off-topic here.
>>>>>>> 
>>>>>>> [The relevance was that had there been any bindings precedence from
>>>>>>> UniPhier, it would've influenced my naming choices.]
>>>>>>> 
>>>>>>>>> Using socionext.txt allows you to add those bindings to a shared file;
>>>>>>>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>>>>>>> 
>>>>>>>> I was thinking of this way.
>>>>>>>> 
>>>>>>>> For example, TI has omap/, keystone/, davinci.txt, etc.
>>>>>>>> in this directory level.
>>>>>>>> 
>>>>>>>>> do you have a better name suggestion for this one? I was trying to keep
>>>>>>>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>>>>>>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>>>>>>>> don't know a good common name for the non-Panasonic parts. And if we
>>>>>>>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>>>>>>>> need a separate file for the new SC2A11 IIUC.
>>>>>>>> 
>>>>>>>> I have no idea.
>>>>>>>> Actually, I am not familiar with those SoCs.
>>>>>>>> 
>>>>>>>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>>>>>>>> I think a SoC family name will be helpful to avoid proliferating
>>>>>>>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>>>>>>> 
>>>>>>>> I see some Socionext guys CC'ed in this mail,
>>>>>>>> somebody might have information about this.
>>>>>>>> 
>>>>>>>> As I said before, I do not mind adding socionext.txt
>>>>>>>> and it seems reasonable enough
>>>>>>>> if there is no common name for those SoCs.
>>>>>>>> 
>>>>>>>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>>>>>>>> should be done, we can certainly adapt. NXP is still adding all their
>>>>>>>>> new SoCs in fsl.txt, it seems.
>>>>>>>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>>>>>>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>>>>>> 
>>>>>>>> Right, vendor names are not future-proof in some cases.
>>>>>>>> 
>>>>>>>> We use "uniphier" because it is convenient to
>>>>>>>> make a group of SoCs with similar architecture,
>>>>>>>> and it will work even if UniPhier product lines are sold again in the
>>>>>>>> future.  :-)
>>>>>>> 
>>>>>>> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
>>>>>>> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
>>>>>>> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
>>>>>>> to indicate I'll again have to set up a new repository and start
>>>>>>> maintaining it myself.
>>>>>>> 
>>>>>>> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
>>>>>>> also being Socionext.
>>>>>>> 
>>>>>>> It's also unclear whether and by whom there may be SC2A11 patches - I
>>>>>>> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
>>>>>>> against linux.git.
>>>>>> 
>>>>>> Eh, wait, what? "Rebelling against linux.git"? What is that supposed
>>>>>> to mean exactly?
>>>>> 
>>>>> Bindings must be submitted to the devicetree mailing list, acked by Rob
>>>>> and merged into the Linux tree before compatible strings may be used in
>>>>> Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that.
>>>> 
>>>> OK, so where did we deviate from this in your opinion?
>>> 
>>> I was very clear which new Socionext 96board platform my remark was
>>> about. There not being a socionext.txt file before this patch here hints
>>> at there being no official SoC binding defined for any.
>>> 
>>> Adding one would require coordinating how to go about these platforms,
>>> as unsuccessfully attempted here.
>>> 
>>> I was also referring to off-list remarks wrt EDK2 DT vs. Linux, which
>>> could've well come from you, given your rant.
>> 
>> I honestly have no idea what you are talking about here. You see
>> rebellion and argument where there is none.
>> 
>>> Note that both the
>>> bindings maintainer and one arm-soc maintainer are from Linaro afaik, so
>>> you're essentially fighting against your colleagues here...
>>> 
>> 
>> I am not fighting anyone, but you seem to think we are rebelling.
>> 
>> The reality is that the platform topology is not finalized yet, and
>> submitting and merging what are essentially draft version of DT
>> descriptions and then having to update them is something we are trying
>> very hard to avoid. There is enough churn in upstream DTs as it is.
>> 
>>> Last but not least pretty much every shipping 96Board to date had a
>>> pre-installed DT that did not have official bindings submitted (I don't
>>> count the Cello as shipping) and thus later changed incompatibly.
>>> 
>> 
>> We are working very hard to make sure the upstream bindings and
>> drivers in the kernel are in shape to support the SoC we are
>> developing firmware support for. When the time comes, we may or may
>> not decide to propose the SoC DT for inclusion in the kernel. But
>> those are two different things.
>> 
>> This has nothing to do with 'rebelling against linux.git' (your words)
>> 
>>>>> U-Boot only allows import of new .dts files from Linux, too.
>>>>> 
>>>>> So Linus' linux.git is the location to merge any vendor prefixes and
>>>>> device tree bindings,
>>>> 
>>>> Agreed.
>>>> 
>>>>> as well as the central location for device trees.
>>>> 
>>>> Why should there be a central location for device trees?
>>> 
>>> Because with a .dtsi for SoC and SoM we can share DT code across boards
>>> and bootloaders. And at least one .dts is needed for compile-testing it.
>>> From a central location files can be either individually copied or
>>> potentially aggregated as submodules.
>>> 
>>> DT patch reviews have resulted in GIC nodes growing virtualization
>>> support for instance, and there have been in-tree refactorings fixing
>>> the arch timer's interrupt type iirc. Comparing modeling across vendors
>>> is also useful to not live in silos.
>>> 
>>> Also considering that drivers are spread over subsystem rather than SoC
>>> directories these days, the central location being Linux facilitates
>>> checking which platforms have been enabled already and to which degree.
>>> 
>> 
>> I understand all that. But being able to review SoC DTs is one thing,
>> and deciding that the kernel repository shall be the authoritative
>> source is another.
>> 
>> In my view, this argues for having a shared repository, mailing list
>> etc between the Linux, u-boot, freebsd and EDK2 communities, because
>> it would increase review coverage, and make it easier to push back
>> against frivolous DT changes.
>> 
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts
>>>>> 
>>>>> If you're unfamiliar with that, talk to your Linaro colleagues please!
>>>> 
>>>> Please don't lecture me on this.
>>> 
>>> If you ask questions, you may get answers. Blame yourself if you
>>> intended them as rhetorical questions.
>>> 
>>>> The bindings are the contract between the OS and the platform, and I
>>>> agree that those need to be reviewed and maintained in a central
>>>> location, and the kernel tree, while not optimal, is a suitable place
>>>> for that.
>>>> 
>>>> However, the existence of such contracts means that there is no need
>>>> to have a central location for device trees, nor should there be a
>>>> need for distros to ever ship device trees with the kernel. That
>>>> practice defeats the entire purpose of having contracts in the first
>>>> place, especially with the pathetic churn we are seeing in device
>>>> trees that are kept in the kernel.
>>> 
>>> Please don't argue with me about these fundamentals. Not my decisions!
>>> 
>>> This is not about distros shipping things; there is no openSUSE on these
>>> platforms precisely because code is not in central repositories.
>>> 
>> 
>> By 'these platforms' you mean 96boards? Fair point. But please don't
>> extrapolate from Hikey (and FYI, Cello has been running mainline Linux
>> and EDK2 from the beginning)
>> 
>>> It's rather about three platforms by one vendor all going into different
>>> directions: SC2A11 into some seemingly non-mainline EDK2, MB86S71 as
>>> vendor kernel / U-Boot tarballs (and my kernel patches here), and
>>> UniPhier as only one in mainline kernel and mainline U-Boot.
>>> 
>>> Have you ever tried to boot e.g. a HiKey with a DT not from the mainline
>>> kernel you are trying to boot? Good luck... Even server vendors
>>> occasionally change their device trees with firmware updates.
>>> 
>> 
>> You say that like it's a bad thing. Do you honestly think it is better
>> for the OS to pick its own DT from some tarball that shipped with it?
>> 
>> If the kernel driver developers wouldn't keep making backward
>> incompatible changes to the bindings, they could actually stabilize to
>> the point where it makes even more sense for the platform vendor to
>> fix bugs in their DT descriptions.
>> 
>>> Fact is, as platforms get enabled, device trees grow additional nodes
>>> and properties. DTs don't fall from skies in some final form for new SoCs.
>>> 
>>> Especially not if they keep getting written by volunteers like me - I'm
>>> already enabling the fourth 96board because Linaro and its partners keep
>>> throwing ~3.10 kernels at users again and again and again, which as I've
>>> pointed out at BUD17 is highly annoying! Even more annoying every single
>>> time Linaro marketing asks people to join as paying members because
>>> Linaro supposedly does so awesome Open Source work and such great
>>> 96Boards. Just this Friday again.
>> 
>> Who's ranting now?
>> 
>> Again, please don't extrapolate. For the SynQuacer based platform we
>> are involved with, there will be no vendor trees whatsoever. And I
>> share your frustration, especially when it comes to HiKey, because
>> they claim to implement UEFI (but building your own bootloader from
>> some random collection of EDK2 source files != UEFI), and keep trying
>> to upstream it.
> 
> Thanks for that.
> 
>>> Nobody needs Reference Platform kernels if everything just timely gets
>>> merged into linux-next and mainline, where code belongs.
>> 
>> Agreed.
>> 
>>> Same for device trees, until the powers that be decide on a different
>>> location - which would not change the problem at all: Every review will
>>> be regarded as churn by someone else, and some people will always be
>>> lazy in submitting patches to whatever widely agreed-upon location, be
>>> it kernel drivers or DTs or U-Boot or EDK2 or ATF or something else.
>>> 
>>> We wouldn't be having this argument if everything were great with the
>>> various non-central 96boards trees and downstream DTs.
>>> 
>> 
>> Everything we need in the kernel and EDK2 will be upstream before the
>> product ships, and we are trying to do the same for ARM Trusted
>> Firmware, but this is a bit problematic due to the sorry state the
>> code is in.
>> 
>> Again, I am not the one who is ranting here. You hit a nerve by
>> accusing me of 'rebelling against linux.git' while this is quite the
>> opposite of what I am doing.
> 
> Actually you did confirm that point by starting an argument about not
> needing a central repository and you not liking Linux as the location.
> That was exactly what I meant with my original comment.
> 
> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
> a year after the board went to market - there's Linaro contributions
> from Mani that I'm thankful for.

Thanks for your comments Andreas. Cc Mani as due to his joining, we continue to improve our upstream efforts. 
> 
> Whereas patches keep falling into a dark hole when there's already other
> work for a certain vendor, such as Marvell and now Socionext, with no
> one feeling responsible for either taking them or saying, "hey, we're
> not going to submit any conflicting DT bindings for SynQuacer because we
> use ACPI, so please go ahead with proposal X, thanks for your efforts".
> 
> Don't complain about me ranting if you belittle my volunteer work that I
> believe Linaro and its partners should've done in the first place

No one is belittling the work you have put in place. We certainly appreciate all you have helped to put together so far and we do not claim 96Boards is a perfect child as far as cross SoC upstreaming efforts is concerned. We are quite constrained when there?s little or none at all or initial resource from SoC vendors pulling away from a platform. But we are still trying very hard. And we are exploring different ways of doing this too.

> : If I
> can get an initial mainline PoC done as an individual on a few
> evenings/weekends, then the same should be super-easy for an
> organization with lots of engineers and paying member companies.

No it?s not. 96Boards (in Linaro) has bare minimum amount budget and is relying heavily on volunteering efforts from people such as Ard and yourself.

> As I've pointed out, an ever-increasing frustration builds over Linaro
> continuing to announce new boards (such as SynQuacer) that will be the
> best since sliced bread, while neglecting the 96boards that are already
> on the market and equally are promoted under the "96Boards" brand.
> The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
> management is aware of that hardware, and yet not a single patch came
> from Xunlong, RDA Micro or Linaro. No patch review from RDA either.

You are correct. We have been struggling to get commitment from parties to sort out the 3.10 based old code line on a SoC, although still very useful but now EoL. 96Boards simply does not have such resource to carry out each platform upstreaming work in absence of other vendors commitment.

> And
> my patches got stuck on the bindings not including interrupts property
> for the UART yet, since I still do not have their custom interrupt
> controller working... So the context here is that not just my 4.14+
> pulls got stuck but three other 96Boards patch series, too.
> Regards,
> Andreas

We could certainly have a discussion regarding multiple 96Boards software status (or lack of it) but I feel we are hijacking the original topic of this thread.
> 
> -- 
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Felix Imend?rffer, Jane Smithard, Graham Norton
> HRB 21284 (AG N?rnberg)

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 6 November 2017 at 06:58, Andreas Färber <afaerber@suse.de> wrote:
> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
[...]
>>
>> Again, I am not the one who is ranting here. You hit a nerve by
>> accusing me of 'rebelling against linux.git' while this is quite the
>> opposite of what I am doing.
>
> Actually you did confirm that point by starting an argument about not
> needing a central repository and you not liking Linux as the location.
> That was exactly what I meant with my original comment.
>
> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
> a year after the board went to market - there's Linaro contributions
> from Mani that I'm thankful for.
>
> Whereas patches keep falling into a dark hole when there's already other
> work for a certain vendor, such as Marvell and now Socionext, with no
> one feeling responsible for either taking them or saying, "hey, we're
> not going to submit any conflicting DT bindings for SynQuacer because we
> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>
> Don't complain about me ranting if you belittle my volunteer work that I
> believe Linaro and its partners should've done in the first place: If I
> can get an initial mainline PoC done as an individual on a few
> evenings/weekends, then the same should be super-easy for an
> organization with lots of engineers and paying member companies.

The only person doing the ranting, rebelling and belittling in this
thread is you. I have never commented on the nature of your work, let
alone belittle it.

I understand you are frustrated with how some of the upstreaming of
96boards is handled. I don't have anything to do with that. The only
96boards i have in my drawer (and never use) is an original HiKey.

I work for the enterprise group, not the 96boards team, and I make a
point of not working with vendor trees at all. The only reason I
submitted some patches to the upcoming release of the ERP is so that
we have an installer that works out of the box, but all the patches I
did contribute were already queued for v4.15 at that point.

> As I've pointed out, an ever-increasing frustration builds over Linaro
> continuing to announce new boards (such as SynQuacer) that will be the
> best since sliced bread, while neglecting the 96boards that are already
> on the market and equally are promoted under the "96Boards" brand.
> The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
> management is aware of that hardware, and yet not a single patch came
> from Xunlong, RDA Micro or Linaro. No patch review from RDA either. And
> my patches got stuck on the bindings not including interrupts property
> for the UART yet, since I still do not have their custom interrupt
> controller working... So the context here is that not just my 4.14+
> pulls got stuck but three other 96Boards patch series, too.
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 6 November 2017 at 06:58, Andreas F?rber <afaerber@suse.de> wrote:
> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
[...]
>>
>> Again, I am not the one who is ranting here. You hit a nerve by
>> accusing me of 'rebelling against linux.git' while this is quite the
>> opposite of what I am doing.
>
> Actually you did confirm that point by starting an argument about not
> needing a central repository and you not liking Linux as the location.
> That was exactly what I meant with my original comment.
>
> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
> a year after the board went to market - there's Linaro contributions
> from Mani that I'm thankful for.
>
> Whereas patches keep falling into a dark hole when there's already other
> work for a certain vendor, such as Marvell and now Socionext, with no
> one feeling responsible for either taking them or saying, "hey, we're
> not going to submit any conflicting DT bindings for SynQuacer because we
> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>
> Don't complain about me ranting if you belittle my volunteer work that I
> believe Linaro and its partners should've done in the first place: If I
> can get an initial mainline PoC done as an individual on a few
> evenings/weekends, then the same should be super-easy for an
> organization with lots of engineers and paying member companies.

The only person doing the ranting, rebelling and belittling in this
thread is you. I have never commented on the nature of your work, let
alone belittle it.

I understand you are frustrated with how some of the upstreaming of
96boards is handled. I don't have anything to do with that. The only
96boards i have in my drawer (and never use) is an original HiKey.

I work for the enterprise group, not the 96boards team, and I make a
point of not working with vendor trees at all. The only reason I
submitted some patches to the upcoming release of the ERP is so that
we have an installer that works out of the box, but all the patches I
did contribute were already queued for v4.15 at that point.

> As I've pointed out, an ever-increasing frustration builds over Linaro
> continuing to announce new boards (such as SynQuacer) that will be the
> best since sliced bread, while neglecting the 96boards that are already
> on the market and equally are promoted under the "96Boards" brand.
> The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
> management is aware of that hardware, and yet not a single patch came
> from Xunlong, RDA Micro or Linaro. No patch review from RDA either. And
> my patches got stuck on the bindings not including interrupts property
> for the UART yet, since I still do not have their custom interrupt
> controller working... So the context here is that not just my 4.14+
> pulls got stuck but three other 96Boards patch series, too.
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Felix Imend?rffer, Jane Smithard, Graham Norton
> HRB 21284 (AG N?rnberg)

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 6 November 2017 at 06:58, Andreas Färber <afaerber@suse.de> wrote:
> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
[...]
>>
>> Again, I am not the one who is ranting here. You hit a nerve by
>> accusing me of 'rebelling against linux.git' while this is quite the
>> opposite of what I am doing.
>
> Actually you did confirm that point by starting an argument about not
> needing a central repository and you not liking Linux as the location.
> That was exactly what I meant with my original comment.
>
> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
> a year after the board went to market - there's Linaro contributions
> from Mani that I'm thankful for.
>
> Whereas patches keep falling into a dark hole when there's already other
> work for a certain vendor, such as Marvell and now Socionext, with no
> one feeling responsible for either taking them or saying, "hey, we're
> not going to submit any conflicting DT bindings for SynQuacer because we
> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>
> Don't complain about me ranting if you belittle my volunteer work that I
> believe Linaro and its partners should've done in the first place: If I
> can get an initial mainline PoC done as an individual on a few
> evenings/weekends, then the same should be super-easy for an
> organization with lots of engineers and paying member companies.

The only person doing the ranting, rebelling and belittling in this
thread is you. I have never commented on the nature of your work, let
alone belittle it.

I understand you are frustrated with how some of the upstreaming of
96boards is handled. I don't have anything to do with that. The only
96boards i have in my drawer (and never use) is an original HiKey.

I work for the enterprise group, not the 96boards team, and I make a
point of not working with vendor trees at all. The only reason I
submitted some patches to the upcoming release of the ERP is so that
we have an installer that works out of the box, but all the patches I
did contribute were already queued for v4.15 at that point.

> As I've pointed out, an ever-increasing frustration builds over Linaro
> continuing to announce new boards (such as SynQuacer) that will be the
> best since sliced bread, while neglecting the 96boards that are already
> on the market and equally are promoted under the "96Boards" brand.
> The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
> management is aware of that hardware, and yet not a single patch came
> from Xunlong, RDA Micro or Linaro. No patch review from RDA either. And
> my patches got stuck on the bindings not including interrupts property
> for the UART yet, since I still do not have their custom interrupt
> controller working... So the context here is that not just my 4.14+
> pulls got stuck but three other 96Boards patch series, too.
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
> On 6 November 2017 at 06:58, Andreas Färber <afaerber@suse.de> wrote:
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> [...]
>>>
>>> Again, I am not the one who is ranting here. You hit a nerve by
>>> accusing me of 'rebelling against linux.git' while this is quite the
>>> opposite of what I am doing.
>>
>> Actually you did confirm that point by starting an argument about not
>> needing a central repository and you not liking Linux as the location.
>> That was exactly what I meant with my original comment.
>>
>> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
>> a year after the board went to market - there's Linaro contributions
>> from Mani that I'm thankful for.
>>
>> Whereas patches keep falling into a dark hole when there's already other
>> work for a certain vendor, such as Marvell and now Socionext, with no
>> one feeling responsible for either taking them or saying, "hey, we're
>> not going to submit any conflicting DT bindings for SynQuacer because we
>> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>>
>> Don't complain about me ranting if you belittle my volunteer work that I
>> believe Linaro and its partners should've done in the first place: If I
>> can get an initial mainline PoC done as an individual on a few
>> evenings/weekends, then the same should be super-easy for an
>> organization with lots of engineers and paying member companies.
> 
> The only person doing the ranting, rebelling and belittling in this
> thread is you. I have never commented on the nature of your work, let
> alone belittle it.

You have stated your opinion that Device Trees don't belong in a central
repository and that Linux was the wrong place for them. My contributions
to Linux have been mainly such Device Trees and bindings, such as this
patch series here. Quod erat demonstrandum.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
> On 6 November 2017 at 06:58, Andreas F?rber <afaerber@suse.de> wrote:
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> [...]
>>>
>>> Again, I am not the one who is ranting here. You hit a nerve by
>>> accusing me of 'rebelling against linux.git' while this is quite the
>>> opposite of what I am doing.
>>
>> Actually you did confirm that point by starting an argument about not
>> needing a central repository and you not liking Linux as the location.
>> That was exactly what I meant with my original comment.
>>
>> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
>> a year after the board went to market - there's Linaro contributions
>> from Mani that I'm thankful for.
>>
>> Whereas patches keep falling into a dark hole when there's already other
>> work for a certain vendor, such as Marvell and now Socionext, with no
>> one feeling responsible for either taking them or saying, "hey, we're
>> not going to submit any conflicting DT bindings for SynQuacer because we
>> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>>
>> Don't complain about me ranting if you belittle my volunteer work that I
>> believe Linaro and its partners should've done in the first place: If I
>> can get an initial mainline PoC done as an individual on a few
>> evenings/weekends, then the same should be super-easy for an
>> organization with lots of engineers and paying member companies.
> 
> The only person doing the ranting, rebelling and belittling in this
> thread is you. I have never commented on the nature of your work, let
> alone belittle it.

You have stated your opinion that Device Trees don't belong in a central
repository and that Linux was the wrong place for them. My contributions
to Linux have been mainly such Device Trees and bindings, such as this
patch series here. Quod erat demonstrandum.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
> On 6 November 2017 at 06:58, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote:
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> [...]
>>>
>>> Again, I am not the one who is ranting here. You hit a nerve by
>>> accusing me of 'rebelling against linux.git' while this is quite the
>>> opposite of what I am doing.
>>
>> Actually you did confirm that point by starting an argument about not
>> needing a central repository and you not liking Linux as the location.
>> That was exactly what I meant with my original comment.
>>
>> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
>> a year after the board went to market - there's Linaro contributions
>> from Mani that I'm thankful for.
>>
>> Whereas patches keep falling into a dark hole when there's already other
>> work for a certain vendor, such as Marvell and now Socionext, with no
>> one feeling responsible for either taking them or saying, "hey, we're
>> not going to submit any conflicting DT bindings for SynQuacer because we
>> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>>
>> Don't complain about me ranting if you belittle my volunteer work that I
>> believe Linaro and its partners should've done in the first place: If I
>> can get an initial mainline PoC done as an individual on a few
>> evenings/weekends, then the same should be super-easy for an
>> organization with lots of engineers and paying member companies.
> 
> The only person doing the ranting, rebelling and belittling in this
> thread is you. I have never commented on the nature of your work, let
> alone belittle it.

You have stated your opinion that Device Trees don't belong in a central
repository and that Linux was the wrong place for them. My contributions
to Linux have been mainly such Device Trees and bindings, such as this
patch series here. Quod erat demonstrandum.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 13 November 2017 at 15:40, Andreas Färber <afaerber@suse.de> wrote:
> Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
>> On 6 November 2017 at 06:58, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>> [...]
>>>>
>>>> Again, I am not the one who is ranting here. You hit a nerve by
>>>> accusing me of 'rebelling against linux.git' while this is quite the
>>>> opposite of what I am doing.
>>>
>>> Actually you did confirm that point by starting an argument about not
>>> needing a central repository and you not liking Linux as the location.
>>> That was exactly what I meant with my original comment.
>>>
>>> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
>>> a year after the board went to market - there's Linaro contributions
>>> from Mani that I'm thankful for.
>>>
>>> Whereas patches keep falling into a dark hole when there's already other
>>> work for a certain vendor, such as Marvell and now Socionext, with no
>>> one feeling responsible for either taking them or saying, "hey, we're
>>> not going to submit any conflicting DT bindings for SynQuacer because we
>>> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>>>
>>> Don't complain about me ranting if you belittle my volunteer work that I
>>> believe Linaro and its partners should've done in the first place: If I
>>> can get an initial mainline PoC done as an individual on a few
>>> evenings/weekends, then the same should be super-easy for an
>>> organization with lots of engineers and paying member companies.
>>
>> The only person doing the ranting, rebelling and belittling in this
>> thread is you. I have never commented on the nature of your work, let
>> alone belittle it.
>
> You have stated your opinion that Device Trees don't belong in a central
> repository and that Linux was the wrong place for them.

Not as strongly as that, but ok.

> My contributions
> to Linux have been mainly such Device Trees and bindings, such as this
> patch series here.

Again, I don't have a clue what it is you work on, although I just
found out (from the other thread you started) that it involves a
Fujitsu not-quite-96board that shares IP with the SynQuacer SoC? It
was my understanding (from information I received from Socionext) that
any upstreaming efforts involving that SoC had been discarded. I guess
the Socionext and Fujitsu engineers are not talking to each other
either.

> Quod erat demonstrandum.

Mathematical proof usually involves inferring new facts from existing
facts. You have done nothing of the kind, and I am not sure what you
are so angry about, but I think it would be better to leave the
emotions out of it, and try to remain factual. Especially when it
comes to representing other people's statements.

-- 
Ard.

[PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 13 November 2017 at 15:40, Andreas F?rber <afaerber@suse.de> wrote:
> Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
>> On 6 November 2017 at 06:58, Andreas F?rber <afaerber@suse.de> wrote:
>>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>> [...]
>>>>
>>>> Again, I am not the one who is ranting here. You hit a nerve by
>>>> accusing me of 'rebelling against linux.git' while this is quite the
>>>> opposite of what I am doing.
>>>
>>> Actually you did confirm that point by starting an argument about not
>>> needing a central repository and you not liking Linux as the location.
>>> That was exactly what I meant with my original comment.
>>>
>>> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
>>> a year after the board went to market - there's Linaro contributions
>>> from Mani that I'm thankful for.
>>>
>>> Whereas patches keep falling into a dark hole when there's already other
>>> work for a certain vendor, such as Marvell and now Socionext, with no
>>> one feeling responsible for either taking them or saying, "hey, we're
>>> not going to submit any conflicting DT bindings for SynQuacer because we
>>> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>>>
>>> Don't complain about me ranting if you belittle my volunteer work that I
>>> believe Linaro and its partners should've done in the first place: If I
>>> can get an initial mainline PoC done as an individual on a few
>>> evenings/weekends, then the same should be super-easy for an
>>> organization with lots of engineers and paying member companies.
>>
>> The only person doing the ranting, rebelling and belittling in this
>> thread is you. I have never commented on the nature of your work, let
>> alone belittle it.
>
> You have stated your opinion that Device Trees don't belong in a central
> repository and that Linux was the wrong place for them.

Not as strongly as that, but ok.

> My contributions
> to Linux have been mainly such Device Trees and bindings, such as this
> patch series here.

Again, I don't have a clue what it is you work on, although I just
found out (from the other thread you started) that it involves a
Fujitsu not-quite-96board that shares IP with the SynQuacer SoC? It
was my understanding (from information I received from Socionext) that
any upstreaming efforts involving that SoC had been discarded. I guess
the Socionext and Fujitsu engineers are not talking to each other
either.

> Quod erat demonstrandum.

Mathematical proof usually involves inferring new facts from existing
facts. You have done nothing of the kind, and I am not sure what you
are so angry about, but I think it would be better to leave the
emotions out of it, and try to remain factual. Especially when it
comes to representing other people's statements.

-- 
Ard.

[PATCH 4/5] ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Add Device Trees for Socionext MB86S71 SoC and Fujitsu F-Cue board.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 arch/arm/boot/dts/Makefile          |   2 +
 arch/arm/boot/dts/mb86s71-f-cue.dts |  38 ++++++++
 arch/arm/boot/dts/mb86s71.dtsi      | 178 ++++++++++++++++++++++++++++++++++++
 3 files changed, 218 insertions(+)
 create mode 100644 arch/arm/boot/dts/mb86s71-f-cue.dts
 create mode 100644 arch/arm/boot/dts/mb86s71.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4b17f35dc9a7..48dda2de0a3d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -526,6 +526,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
 	imx28-m28evk.dtb \
 	imx28-sps1.dtb \
 	imx28-tx28.dtb
+dtb-$(CONFIG_ARCH_MB86S7X) += \
+	mb86s71-f-cue.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
 	ste-nomadik-s8815.dtb \
 	ste-nomadik-nhk15.dtb
diff --git a/arch/arm/boot/dts/mb86s71-f-cue.dts b/arch/arm/boot/dts/mb86s71-f-cue.dts
new file mode 100644
index 000000000000..148d1aee11a6
--- /dev/null
+++ b/arch/arm/boot/dts/mb86s71-f-cue.dts
@@ -0,0 +1,38 @@
+/*
+ * Fujitsu F-Cue board
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "mb86s71.dtsi"
+
+/ {
+	compatible = "fujitsu,f-cue", "fujitsu,mb86s71";
+	model = "Fujitsu F-Cue";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	/* vendor U-Boot looks for /memory */
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+};
+
+&arch_timer {
+	clock-frequency = <125000000>;
+};
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/mb86s71.dtsi b/arch/arm/boot/dts/mb86s71.dtsi
new file mode 100644
index 000000000000..154f1ab89f0a
--- /dev/null
+++ b/arch/arm/boot/dts/mb86s71.dtsi
@@ -0,0 +1,178 @@
+/*
+ * Socionext MB86S71 SoC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "fujitsu,mb86s71";
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x0>;
+			cci-control-port = <&cci_control4>;
+			next-level-cache = <&l2_big>;
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x1>;
+			cci-control-port = <&cci_control4>;
+			next-level-cache = <&l2_big>;
+		};
+
+		cpu2: cpu@100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x100>;
+			cci-control-port = <&cci_control3>;
+			next-level-cache = <&l2_little>;
+		};
+
+		cpu3: cpu@101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x101>;
+			cci-control-port = <&cci_control3>;
+			next-level-cache = <&l2_little>;
+		};
+
+		l2_big: l2-cache-big {
+			compatible = "cache";
+		};
+
+		l2_little: l2-cache-little {
+			compatible = "cache";
+		};
+	};
+
+	arch_timer: timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+		             <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	pmu-big {
+		compatible = "arm,cortex-a15-pmu";
+		interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+		             <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>;
+	};
+
+	pmu-little {
+		compatible = "arm,cortex-a7-pmu";
+		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+		             <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu2>, <&cpu3>;
+	};
+
+	cci@2c090000 {
+		compatible = "arm,cci-400";
+		reg = <0x2c090000 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x2c090000 0x10000>;
+
+		cci_control0: slave-if@1000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x1000 0x1000>;
+			interface-type = "ace-lite";
+		};
+
+		cci_control1: slave-if@2000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x2000 0x1000>;
+			interface-type = "ace-lite";
+		};
+
+		cci_control2: slave-if@3000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x3000 0x1000>;
+			interface-type = "ace-lite";
+		};
+
+		cci_control3: slave-if@4000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x4000 0x1000>;
+			interface-type = "ace";
+		};
+
+		cci_control4: slave-if@5000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x5000 0x1000>;
+			interface-type = "ace";
+		};
+
+		pmu@9000 {
+			compatible = "arm,cci-400-pmu,r0";
+			reg = <0x9000 0x5000>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0x80000000>;
+
+		gic: interrupt-controller@2c001000 {
+			compatible = "arm,cortex-a15-gic";
+			reg = <0x2c001000 0x1000>,
+			      <0x2c002000 0x2000>,
+			      <0x2c004000 0x2000>,
+			      <0x2c006000 0x2000>;
+			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+
+		uart0: serial@31040000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x31040000 0x100>;
+			arm,primecell-periphid = <0x00341011>;
+			interrupts = <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart1: serial@31050000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x31050000 0x100>;
+			arm,primecell-periphid = <0x00341011>;
+			interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart2: serial@31060000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x31060000 0x100>;
+			arm,primecell-periphid = <0x00341011>;
+			interrupts = <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		timer@31080000 {
+			compatible = "arm,sp804";
+			reg = <0x31080000 0x10000>;
+			interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+};
-- 
2.12.3

[PATCH 4/5] ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue

[Andreas Färber]

Add Device Trees for Socionext MB86S71 SoC and Fujitsu F-Cue board.

Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
 arch/arm/boot/dts/Makefile          |   2 +
 arch/arm/boot/dts/mb86s71-f-cue.dts |  38 ++++++++
 arch/arm/boot/dts/mb86s71.dtsi      | 178 ++++++++++++++++++++++++++++++++++++
 3 files changed, 218 insertions(+)
 create mode 100644 arch/arm/boot/dts/mb86s71-f-cue.dts
 create mode 100644 arch/arm/boot/dts/mb86s71.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4b17f35dc9a7..48dda2de0a3d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -526,6 +526,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
 	imx28-m28evk.dtb \
 	imx28-sps1.dtb \
 	imx28-tx28.dtb
+dtb-$(CONFIG_ARCH_MB86S7X) += \
+	mb86s71-f-cue.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
 	ste-nomadik-s8815.dtb \
 	ste-nomadik-nhk15.dtb
diff --git a/arch/arm/boot/dts/mb86s71-f-cue.dts b/arch/arm/boot/dts/mb86s71-f-cue.dts
new file mode 100644
index 000000000000..148d1aee11a6
--- /dev/null
+++ b/arch/arm/boot/dts/mb86s71-f-cue.dts
@@ -0,0 +1,38 @@
+/*
+ * Fujitsu F-Cue board
+ *
+ * Copyright (c) 2017 Andreas F?rber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "mb86s71.dtsi"
+
+/ {
+	compatible = "fujitsu,f-cue", "fujitsu,mb86s71";
+	model = "Fujitsu F-Cue";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	/* vendor U-Boot looks for /memory */
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+};
+
+&arch_timer {
+	clock-frequency = <125000000>;
+};
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/mb86s71.dtsi b/arch/arm/boot/dts/mb86s71.dtsi
new file mode 100644
index 000000000000..154f1ab89f0a
--- /dev/null
+++ b/arch/arm/boot/dts/mb86s71.dtsi
@@ -0,0 +1,178 @@
+/*
+ * Socionext MB86S71 SoC
+ *
+ * Copyright (c) 2017 Andreas F?rber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "fujitsu,mb86s71";
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x0>;
+			cci-control-port = <&cci_control4>;
+			next-level-cache = <&l2_big>;
+		};
+
+		cpu1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x1>;
+			cci-control-port = <&cci_control4>;
+			next-level-cache = <&l2_big>;
+		};
+
+		cpu2: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x100>;
+			cci-control-port = <&cci_control3>;
+			next-level-cache = <&l2_little>;
+		};
+
+		cpu3: cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x101>;
+			cci-control-port = <&cci_control3>;
+			next-level-cache = <&l2_little>;
+		};
+
+		l2_big: l2-cache-big {
+			compatible = "cache";
+		};
+
+		l2_little: l2-cache-little {
+			compatible = "cache";
+		};
+	};
+
+	arch_timer: timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+		             <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	pmu-big {
+		compatible = "arm,cortex-a15-pmu";
+		interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+		             <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>;
+	};
+
+	pmu-little {
+		compatible = "arm,cortex-a7-pmu";
+		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+		             <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu2>, <&cpu3>;
+	};
+
+	cci at 2c090000 {
+		compatible = "arm,cci-400";
+		reg = <0x2c090000 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x2c090000 0x10000>;
+
+		cci_control0: slave-if at 1000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x1000 0x1000>;
+			interface-type = "ace-lite";
+		};
+
+		cci_control1: slave-if at 2000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x2000 0x1000>;
+			interface-type = "ace-lite";
+		};
+
+		cci_control2: slave-if at 3000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x3000 0x1000>;
+			interface-type = "ace-lite";
+		};
+
+		cci_control3: slave-if at 4000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x4000 0x1000>;
+			interface-type = "ace";
+		};
+
+		cci_control4: slave-if at 5000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x5000 0x1000>;
+			interface-type = "ace";
+		};
+
+		pmu at 9000 {
+			compatible = "arm,cci-400-pmu,r0";
+			reg = <0x9000 0x5000>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0x80000000>;
+
+		gic: interrupt-controller at 2c001000 {
+			compatible = "arm,cortex-a15-gic";
+			reg = <0x2c001000 0x1000>,
+			      <0x2c002000 0x2000>,
+			      <0x2c004000 0x2000>,
+			      <0x2c006000 0x2000>;
+			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+
+		uart0: serial at 31040000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x31040000 0x100>;
+			arm,primecell-periphid = <0x00341011>;
+			interrupts = <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart1: serial at 31050000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x31050000 0x100>;
+			arm,primecell-periphid = <0x00341011>;
+			interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart2: serial at 31060000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x31060000 0x100>;
+			arm,primecell-periphid = <0x00341011>;
+			interrupts = <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		timer at 31080000 {
+			compatible = "arm,sp804";
+			reg = <0x31080000 0x10000>;
+			interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+};
-- 
2.12.3

[PATCH 5/5] ARM: dts: mb86s71-f-cue: Add fake UART0 clock

[Andreas Färber]

As long as the clk driver is not building, use a fixed-clock for the UART.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 arch/arm/boot/dts/mb86s71-f-cue.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/mb86s71-f-cue.dts b/arch/arm/boot/dts/mb86s71-f-cue.dts
index 148d1aee11a6..726bf189e8e7 100644
--- a/arch/arm/boot/dts/mb86s71-f-cue.dts
+++ b/arch/arm/boot/dts/mb86s71-f-cue.dts
@@ -27,6 +27,12 @@
 		device_type = "memory";
 		reg = <0x80000000 0x80000000>;
 	};
+
+	uart0_clk: uart0-clk {
+		compatible = "fixed-clock";
+		clock-frequency = <7813000>;
+		#clock-cells = <0>;
+	};
 };
 
 &arch_timer {
@@ -35,4 +41,6 @@
 
 &uart0 {
 	status = "okay";
+	clocks = <&uart0_clk>;
+	clock-names = "apb_pclk";
 };
-- 
2.12.3

[PATCH 5/5] ARM: dts: mb86s71-f-cue: Add fake UART0 clock

[Andreas Färber]

As long as the clk driver is not building, use a fixed-clock for the UART.

Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
 arch/arm/boot/dts/mb86s71-f-cue.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/mb86s71-f-cue.dts b/arch/arm/boot/dts/mb86s71-f-cue.dts
index 148d1aee11a6..726bf189e8e7 100644
--- a/arch/arm/boot/dts/mb86s71-f-cue.dts
+++ b/arch/arm/boot/dts/mb86s71-f-cue.dts
@@ -27,6 +27,12 @@
 		device_type = "memory";
 		reg = <0x80000000 0x80000000>;
 	};
+
+	uart0_clk: uart0-clk {
+		compatible = "fixed-clock";
+		clock-frequency = <7813000>;
+		#clock-cells = <0>;
+	};
 };
 
 &arch_timer {
@@ -35,4 +41,6 @@
 
 &uart0 {
 	status = "okay";
+	clocks = <&uart0_clk>;
+	clock-names = "apb_pclk";
 };
-- 
2.12.3