mbox series

[00/17] dt-bindings: samsung: add specific compatibles for existing SoC

Message ID 20231108104343.24192-1-krzysztof.kozlowski@linaro.org
Headers show
Series dt-bindings: samsung: add specific compatibles for existing SoC | expand

Message

Krzysztof Kozlowski Nov. 8, 2023, 10:43 a.m. UTC
Hi,

Merging
=======
I propose to take entire patchset through my tree (Samsung SoC), because:
1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
   they will touch the same lines in some of the DT bindings (not all, though).
   It is reasonable for me to take the bindings for the new SoCs, to have clean
   `make dtbs_check` on the new DTS.
2. Having it together helps me to have clean `make dtbs_check` within my tree
   on the existing DTS.
3. No drivers are affected by this change.
4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
   follow up patchsets.

If folks agree, please kindly Ack the patches.

Description
===========
Samsung Exynos SoCs reuse several devices from older designs, thus historically
we kept the old (block's) compatible only.  This works fine and there is no bug
here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like compatibles.
This will also help reviews of new code using existing DTS as template.  No
functional impact on Linux drivers behavior.

Future
======
If reasonable, I will do similar work for Tesla FSD and ARMv7/ARM32 Exynos
bindings and DTS.

Best regards,
Krzysztof

Krzysztof Kozlowski (17):
  dt-bindings: hwinfo: samsung,exynos-chipid: add specific compatibles
    for existing SoC
  dt-bindings: i2c: exynos5: add specific compatibles for existing SoC
  dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for
    existing SoC
  dt-bindings: mmc: samsung,exynos-dw-mshc: add specific compatibles for
    existing SoC
  dt-bindings: pinctrl: samsung: add specific compatibles for existing
    SoC
  dt-bindings: rtc: s3c-rtc: add specific compatibles for existing SoC
  dt-bindings: serial: samsung: add specific compatibles for existing
    SoC
  dt-bindings: samsung: exynos-pmu: add specific compatibles for
    existing SoC
  dt-bindings: gpu: arm,mali-midgard: add specific compatibles for
    existing Exynos SoC
  dt-bindings: iio: samsung,exynos-adc: add specific compatibles for
    existing SoC
  ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing
    SoC
  dt-bindings: pwm: samsung: add specific compatibles for existing SoC
  arm64: dts: exynos5433: add specific compatibles to several blocks
  arm64: dts: exynos7: add specific compatibles to several blocks
  arm64: dts: exynos7885: add specific compatibles to several blocks
  arm64: dts: exynos850: add specific compatibles to several blocks
  arm64: dts: exynosautov9: add specific compatibles to several blocks

 .../bindings/gpu/arm,mali-midgard.yaml        |  5 ++
 .../hwinfo/samsung,exynos-chipid.yaml         | 17 +++++-
 .../devicetree/bindings/i2c/i2c-exynos5.yaml  | 10 +++-
 .../bindings/i2c/samsung,s3c2410-i2c.yaml     | 22 ++++---
 .../bindings/iio/adc/samsung,exynos-adc.yaml  | 29 +++++----
 .../mfd/samsung,exynos5433-lpass.yaml         |  2 +-
 .../bindings/mmc/samsung,exynos-dw-mshc.yaml  | 25 +++++---
 .../samsung,pinctrl-wakeup-interrupt.yaml     | 24 +++++---
 .../bindings/pinctrl/samsung,pinctrl.yaml     |  3 +-
 .../devicetree/bindings/pwm/pwm-samsung.yaml  |  2 +
 .../devicetree/bindings/rtc/s3c-rtc.yaml      |  5 ++
 .../bindings/serial/samsung_uart.yaml         | 14 ++++-
 .../bindings/soc/samsung/exynos-pmu.yaml      |  6 ++
 .../bindings/soc/samsung/exynos-usi.yaml      |  2 +-
 .../bindings/sound/samsung-i2s.yaml           | 19 +++---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi    | 60 ++++++++++++-------
 arch/arm64/boot/dts/exynos/exynos7.dtsi       | 18 +++---
 arch/arm64/boot/dts/exynos/exynos7885.dtsi    | 45 +++++++++-----
 arch/arm64/boot/dts/exynos/exynos850.dtsi     | 34 ++++++-----
 arch/arm64/boot/dts/exynos/exynosautov9.dtsi  |  6 +-
 20 files changed, 233 insertions(+), 115 deletions(-)

Comments

Alim Akhtar Nov. 9, 2023, 6:05 p.m. UTC | #1
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Wednesday, November 8, 2023 4:13 PM
> To: David Airlie <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>;
> Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; Maxime Ripard
> <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>;
> Rob Herring <robh+dt@kernel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> <conor+dt@kernel.org>; Alim Akhtar <alim.akhtar@samsung.com>; Andi
> Shyti <andi.shyti@kernel.org>; Jonathan Cameron <jic23@kernel.org>; Lars-
> Peter Clausen <lars@metafoo.de>; Lee Jones <lee@kernel.org>; Ulf
> Hansson <ulf.hansson@linaro.org>; Tomasz Figa <tomasz.figa@gmail.com>;
> Sylwester Nawrocki <s.nawrocki@samsung.com>; Linus Walleij
> <linus.walleij@linaro.org>; Thierry Reding <thierry.reding@gmail.com>; Uwe
> Kleine-König <u.kleine-koenig@pengutronix.de>; Alessandro Zummo
> <a.zummo@towertech.it>; Alexandre Belloni
> <alexandre.belloni@bootlin.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Jiri Slaby <jirislaby@kernel.org>; Liam
> Girdwood <lgirdwood@gmail.com>; Mark Brown <broonie@kernel.org>;
> Jaehoon Chung <jh80.chung@samsung.com>; Sam Protsenko
> <semen.protsenko@linaro.org>; dri-devel@lists.freedesktop.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; linux-
> i2c@vger.kernel.org; linux-iio@vger.kernel.org; linux-mmc@vger.kernel.org;
> linux-gpio@vger.kernel.org; linux-pwm@vger.kernel.org; linux-
> rtc@vger.kernel.org; linux-serial@vger.kernel.org; alsa-devel@alsa-
> project.org; linux-sound@vger.kernel.org
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Subject: [PATCH 02/17] dt-bindings: i2c: exynos5: add specific compatibles for
> existing SoC
> 
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine and
> there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter for
> explanation.
> ---
>  Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 10 +++++++++-
>  .../devicetree/bindings/soc/samsung/exynos-usi.yaml    |  2 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> index 3e52a0db6c41..c1f5d2cb7709 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> @@ -25,7 +25,15 @@ properties:
>            - samsung,exynos5250-hsi2c    # Exynos5250 and Exynos5420
>            - samsung,exynos5260-hsi2c    # Exynos5260
>            - samsung,exynos7-hsi2c       # Exynos7
> -          - samsung,exynosautov9-hsi2c  # ExynosAutoV9 and Exynos850
> +          - samsung,exynosautov9-hsi2c
> +      - items:
> +          - enum:
> +              - samsung,exynos5433-hsi2c
> +          - const: samsung,exynos7-hsi2c
> +      - items:
> +          - enum:
> +              - samsung,exynos850-hsi2c
Does this need an entry in allOf:? to indicate exynos850 also has 2 clocks?

> +          - const: samsung,exynosautov9-hsi2c
>        - const: samsung,exynos5-hsi2c    # Exynos5250 and Exynos5420
>          deprecated: true
> 
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-
> usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-
> usi.yaml
> index a6836904a4f8..5b7ab69546c4 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> @@ -155,7 +155,7 @@ examples:
>          };
> 
>          hsi2c_0: i2c@13820000 {
> -            compatible = "samsung,exynosautov9-hsi2c";
> +            compatible = "samsung,exynos850-hsi2c",
> + "samsung,exynosautov9-hsi2c";
>              reg = <0x13820000 0xc0>;
>              interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
>              #address-cells = <1>;
> --
> 2.34.1
Wolfram Sang Nov. 9, 2023, 7:21 p.m. UTC | #2
On Wed, Nov 08, 2023 at 11:43:28AM +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.

I am fine that you take it once all review comments are addressed. Given
that:

Acked-by: Wolfram Sang <wsa@kernel.org>
Wolfram Sang Nov. 9, 2023, 7:22 p.m. UTC | #3
On Wed, Nov 08, 2023 at 11:43:29AM +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.

I am fine that you take it once all review comments are addressed. Given
that:

Acked-by: Wolfram Sang <wsa@kernel.org>
Linus Walleij Nov. 9, 2023, 8:06 p.m. UTC | #4
On Wed, Nov 8, 2023 at 11:44 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:

> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
>
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Makes perfect sense to me:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
Krzysztof Kozlowski Nov. 10, 2023, 7:58 a.m. UTC | #5
On 09/11/2023 19:05, Alim Akhtar wrote:

(...)

Please trim unrelated parts of response/quote before and after your message.

>> @@ -25,7 +25,15 @@ properties:
>>            - samsung,exynos5250-hsi2c    # Exynos5250 and Exynos5420
>>            - samsung,exynos5260-hsi2c    # Exynos5260
>>            - samsung,exynos7-hsi2c       # Exynos7
>> -          - samsung,exynosautov9-hsi2c  # ExynosAutoV9 and Exynos850
>> +          - samsung,exynosautov9-hsi2c
>> +      - items:
>> +          - enum:
>> +              - samsung,exynos5433-hsi2c
>> +          - const: samsung,exynos7-hsi2c
>> +      - items:
>> +          - enum:
>> +              - samsung,exynos850-hsi2c
> Does this need an entry in allOf:? to indicate exynos850 also has 2 clocks?
> 

No, autov9 is there already.

>> +          - const: samsung,exynosautov9-hsi2c


Best regards,
Krzysztof
Rob Herring (Arm) Nov. 10, 2023, 8:38 p.m. UTC | #6
On Wed, 08 Nov 2023 11:43:28 +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 10 +++++++++-
>  .../devicetree/bindings/soc/samsung/exynos-usi.yaml    |  2 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh@kernel.org>
Rob Herring (Arm) Nov. 10, 2023, 8:39 p.m. UTC | #7
On Wed, Nov 08, 2023 at 11:43:29AM +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  .../bindings/i2c/samsung,s3c2410-i2c.yaml     | 22 ++++++++++++-------
>  1 file changed, 14 insertions(+), 8 deletions(-)

Acked-by: Rob Herring <robh@kernel.org>
Rob Herring (Arm) Nov. 10, 2023, 8:40 p.m. UTC | #8
On Wed, 08 Nov 2023 11:43:31 +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  .../samsung,pinctrl-wakeup-interrupt.yaml     | 24 ++++++++++++-------
>  .../bindings/pinctrl/samsung,pinctrl.yaml     |  3 ++-
>  2 files changed, 17 insertions(+), 10 deletions(-)
> 

Acked-by: Rob Herring <robh@kernel.org>
Rob Herring (Arm) Nov. 10, 2023, 8:41 p.m. UTC | #9
On Wed, 08 Nov 2023 11:43:34 +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  .../devicetree/bindings/soc/samsung/exynos-pmu.yaml         | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>
Rob Herring (Arm) Nov. 10, 2023, 8:41 p.m. UTC | #10
On Wed, 08 Nov 2023 11:43:35 +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>
Rob Herring (Arm) Nov. 10, 2023, 8:43 p.m. UTC | #11
On Wed, 08 Nov 2023 11:43:37 +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  .../mfd/samsung,exynos5433-lpass.yaml         |  2 +-
>  .../bindings/sound/samsung-i2s.yaml           | 19 ++++++++++++-------
>  2 files changed, 13 insertions(+), 8 deletions(-)
> 

Acked-by: Rob Herring <robh@kernel.org>
Alim Akhtar Nov. 11, 2023, 12:55 a.m. UTC | #12
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Wednesday, November 8, 2023 4:13 PM
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine and
> there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---

Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>

> 
> I propose to take the patch through Samsung SoC (me). See cover letter for
> explanation.
> ---
>  .../bindings/i2c/samsung,s3c2410-i2c.yaml     | 22 ++++++++++++-------
>  1 file changed, 14 insertions(+), 8 deletions(-)
(...)
Alim Akhtar Nov. 11, 2023, 1:09 a.m. UTC | #13
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine and
> there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>

> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter for
> explanation.
> ---
>  .../devicetree/bindings/soc/samsung/exynos-pmu.yaml         | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
(...)
Alim Akhtar Nov. 11, 2023, 1:44 a.m. UTC | #14
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Wednesday, November 8, 2023 4:14 PM
> Exynos850 reuses several devices from older designs, thus historically we
> kept the old (block's) compatible only.  This works fine and there is no bug
> here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to Exynos850 in front of all old-SoC-like compatibles.
> This will also help reviews of new code using existing DTS as template.  No
> functional impact on Linux drivers behavior.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>

>  arch/arm64/boot/dts/exynos/exynos850.dtsi | 34 +++++++++++++----------
>  1 file changed, 20 insertions(+), 14 deletions(-)
> 
(...)
Sam Protsenko Nov. 21, 2023, 5:48 p.m. UTC | #15
On Wed, Nov 8, 2023 at 4:44 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> Exynos850 reuses several devices from older designs, thus historically
> we kept the old (block's) compatible only.  This works fine and there is
> no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
>
> Add compatibles specific to Exynos850 in front of all old-SoC-like
> compatibles.  This will also help reviews of new code using existing
> DTS as template.  No functional impact on Linux drivers behavior.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>

>  arch/arm64/boot/dts/exynos/exynos850.dtsi | 34 +++++++++++++----------
>  1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> index 53104e65b9c6..df5ea43ebcad 100644
> --- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> @@ -396,7 +396,7 @@ pinctrl_aud: pinctrl@14a60000 {
>                 };
>
>                 rtc: rtc@11a30000 {
> -                       compatible = "samsung,s3c6410-rtc";
> +                       compatible = "samsung,exynos850-rtc", "samsung,s3c6410-rtc";
>                         reg = <0x11a30000 0x100>;
>                         interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
>                                      <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
> @@ -406,7 +406,8 @@ rtc: rtc@11a30000 {
>                 };
>
>                 mmc_0: mmc@12100000 {
> -                       compatible = "samsung,exynos7-dw-mshc-smu";
> +                       compatible = "samsung,exynos850-dw-mshc-smu",
> +                                    "samsung,exynos7-dw-mshc-smu";
>                         reg = <0x12100000 0x2000>;
>                         interrupts = <GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>;
>                         #address-cells = <1>;
> @@ -419,7 +420,7 @@ mmc_0: mmc@12100000 {
>                 };
>
>                 i2c_0: i2c@13830000 {
> -                       compatible = "samsung,s3c2440-i2c";
> +                       compatible = "samsung,exynos850-i2c", "samsung,s3c2440-i2c";
>                         reg = <0x13830000 0x100>;
>                         interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>;
>                         #address-cells = <1>;
> @@ -432,7 +433,7 @@ i2c_0: i2c@13830000 {
>                 };
>
>                 i2c_1: i2c@13840000 {
> -                       compatible = "samsung,s3c2440-i2c";
> +                       compatible = "samsung,exynos850-i2c", "samsung,s3c2440-i2c";
>                         reg = <0x13840000 0x100>;
>                         interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>;
>                         #address-cells = <1>;
> @@ -445,7 +446,7 @@ i2c_1: i2c@13840000 {
>                 };
>
>                 i2c_2: i2c@13850000 {
> -                       compatible = "samsung,s3c2440-i2c";
> +                       compatible = "samsung,exynos850-i2c", "samsung,s3c2440-i2c";
>                         reg = <0x13850000 0x100>;
>                         interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>;
>                         #address-cells = <1>;
> @@ -458,7 +459,7 @@ i2c_2: i2c@13850000 {
>                 };
>
>                 i2c_3: i2c@13860000 {
> -                       compatible = "samsung,s3c2440-i2c";
> +                       compatible = "samsung,exynos850-i2c", "samsung,s3c2440-i2c";
>                         reg = <0x13860000 0x100>;
>                         interrupts = <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
>                         #address-cells = <1>;
> @@ -471,7 +472,7 @@ i2c_3: i2c@13860000 {
>                 };
>
>                 i2c_4: i2c@13870000 {
> -                       compatible = "samsung,s3c2440-i2c";
> +                       compatible = "samsung,exynos850-i2c", "samsung,s3c2440-i2c";
>                         reg = <0x13870000 0x100>;
>                         interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
>                         #address-cells = <1>;
> @@ -485,7 +486,7 @@ i2c_4: i2c@13870000 {
>
>                 /* I2C_5 (also called CAM_PMIC_I2C in TRM) */
>                 i2c_5: i2c@13880000 {
> -                       compatible = "samsung,s3c2440-i2c";
> +                       compatible = "samsung,exynos850-i2c", "samsung,s3c2440-i2c";
>                         reg = <0x13880000 0x100>;
>                         interrupts = <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>;
>                         #address-cells = <1>;
> @@ -499,7 +500,7 @@ i2c_5: i2c@13880000 {
>
>                 /* I2C_6 (also called MOTOR_I2C in TRM) */
>                 i2c_6: i2c@13890000 {
> -                       compatible = "samsung,s3c2440-i2c";
> +                       compatible = "samsung,exynos850-i2c", "samsung,s3c2440-i2c";
>                         reg = <0x13890000 0x100>;
>                         interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>;
>                         #address-cells = <1>;
> @@ -640,7 +641,8 @@ usi_hsi2c_0: usi@138a00c0 {
>                         status = "disabled";
>
>                         hsi2c_0: i2c@138a0000 {
> -                               compatible = "samsung,exynosautov9-hsi2c";
> +                               compatible = "samsung,exynos850-hsi2c",
> +                                            "samsung,exynosautov9-hsi2c";
>                                 reg = <0x138a0000 0xc0>;
>                                 interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
>                                 #address-cells = <1>;
> @@ -668,7 +670,8 @@ usi_hsi2c_1: usi@138b00c0 {
>                         status = "disabled";
>
>                         hsi2c_1: i2c@138b0000 {
> -                               compatible = "samsung,exynosautov9-hsi2c";
> +                               compatible = "samsung,exynos850-hsi2c",
> +                                            "samsung,exynosautov9-hsi2c";
>                                 reg = <0x138b0000 0xc0>;
>                                 interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
>                                 #address-cells = <1>;
> @@ -696,7 +699,8 @@ usi_hsi2c_2: usi@138c00c0 {
>                         status = "disabled";
>
>                         hsi2c_2: i2c@138c0000 {
> -                               compatible = "samsung,exynosautov9-hsi2c";
> +                               compatible = "samsung,exynos850-hsi2c",
> +                                            "samsung,exynosautov9-hsi2c";
>                                 reg = <0x138c0000 0xc0>;
>                                 interrupts = <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>;
>                                 #address-cells = <1>;
> @@ -738,7 +742,8 @@ usi_cmgp0: usi@11d000c0 {
>                         status = "disabled";
>
>                         hsi2c_3: i2c@11d00000 {
> -                               compatible = "samsung,exynosautov9-hsi2c";
> +                               compatible = "samsung,exynos850-hsi2c",
> +                                            "samsung,exynosautov9-hsi2c";
>                                 reg = <0x11d00000 0xc0>;
>                                 interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>                                 #address-cells = <1>;
> @@ -778,7 +783,8 @@ usi_cmgp1: usi@11d200c0 {
>                         status = "disabled";
>
>                         hsi2c_4: i2c@11d20000 {
> -                               compatible = "samsung,exynosautov9-hsi2c";
> +                               compatible = "samsung,exynos850-hsi2c",
> +                                            "samsung,exynosautov9-hsi2c";
>                                 reg = <0x11d20000 0xc0>;
>                                 interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
>                                 #address-cells = <1>;
> --
> 2.34.1
>
Thierry Reding Nov. 28, 2023, 5:49 p.m. UTC | #16
On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
> Merging
> =======
> I propose to take entire patchset through my tree (Samsung SoC), because:
> 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
>    they will touch the same lines in some of the DT bindings (not all, though).
>    It is reasonable for me to take the bindings for the new SoCs, to have clean
>    `make dtbs_check` on the new DTS.
> 2. Having it together helps me to have clean `make dtbs_check` within my tree
>    on the existing DTS.
> 3. No drivers are affected by this change.
> 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
>    follow up patchsets.
> 
> [...]

Applied, thanks!

[12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
        commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f

Best regards,
Uwe Kleine-König Nov. 28, 2023, 8:58 p.m. UTC | #17
On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
> 
> On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
> > Merging
> > =======
> > I propose to take entire patchset through my tree (Samsung SoC), because:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> > 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
> >    they will touch the same lines in some of the DT bindings (not all, though).
> >    It is reasonable for me to take the bindings for the new SoCs, to have clean
> >    `make dtbs_check` on the new DTS.
> > 2. Having it together helps me to have clean `make dtbs_check` within my tree
> >    on the existing DTS.
> > 3. No drivers are affected by this change.
> > 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
> >    follow up patchsets.
> > 
> > [...]
> 
> Applied, thanks!
> 
> [12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
>         commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f

You didn't honor (or even comment) Krzysztof's proposal to take the
whole patchset via his tree (marked above). Was there some off-list
agreement?

Best regards
Uwe
Krzysztof Kozlowski Dec. 5, 2023, 9:16 a.m. UTC | #18
On 28/11/2023 21:58, Uwe Kleine-König wrote:
> On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
>>
>> On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
>>> Merging
>>> =======
>>> I propose to take entire patchset through my tree (Samsung SoC), because:
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>>> 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
>>>    they will touch the same lines in some of the DT bindings (not all, though).
>>>    It is reasonable for me to take the bindings for the new SoCs, to have clean
>>>    `make dtbs_check` on the new DTS.
>>> 2. Having it together helps me to have clean `make dtbs_check` within my tree
>>>    on the existing DTS.
>>> 3. No drivers are affected by this change.
>>> 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
>>>    follow up patchsets.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
>>         commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f
> 
> You didn't honor (or even comment) Krzysztof's proposal to take the
> whole patchset via his tree (marked above). Was there some off-list
> agreement?
> 

It was also written in the PWM patch itself (under changelog ---) and
expressed with my "applied" response when I took everything. I am
sending now another set, also touching PWM.

Best regards,
Krzysztof
Thierry Reding Dec. 5, 2023, 12:36 p.m. UTC | #19
On Tue, Nov 28, 2023 at 09:58:41PM +0100, Uwe Kleine-König wrote:
> On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
> > 
> > On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
> > > Merging
> > > =======
> > > I propose to take entire patchset through my tree (Samsung SoC), because:
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> > > 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
> > >    they will touch the same lines in some of the DT bindings (not all, though).
> > >    It is reasonable for me to take the bindings for the new SoCs, to have clean
> > >    `make dtbs_check` on the new DTS.
> > > 2. Having it together helps me to have clean `make dtbs_check` within my tree
> > >    on the existing DTS.
> > > 3. No drivers are affected by this change.
> > > 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
> > >    follow up patchsets.
> > > 
> > > [...]
> > 
> > Applied, thanks!
> > 
> > [12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
> >         commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f
> 
> You didn't honor (or even comment) Krzysztof's proposal to take the
> whole patchset via his tree (marked above). Was there some off-list
> agreement?

I had read all that and then looking at patchwork saw that you had
marked all other patches in the series as "handled-elsewhere" and only
this one was left as "new", so I assumed that, well, everything else was
handled elsewhere and I was supposed to pick this one up...

I'll drop this one.

Thierry
Uwe Kleine-König Dec. 5, 2023, 4:12 p.m. UTC | #20
Hello Thierry,

On Tue, Dec 05, 2023 at 01:36:05PM +0100, Thierry Reding wrote:
> On Tue, Nov 28, 2023 at 09:58:41PM +0100, Uwe Kleine-König wrote:
> > On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
> > > 
> > > On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
> > > > Merging
> > > > =======
> > > > I propose to take entire patchset through my tree (Samsung SoC), because:
> >     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > > > 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
> > > >    they will touch the same lines in some of the DT bindings (not all, though).
> > > >    It is reasonable for me to take the bindings for the new SoCs, to have clean
> > > >    `make dtbs_check` on the new DTS.
> > > > 2. Having it together helps me to have clean `make dtbs_check` within my tree
> > > >    on the existing DTS.
> > > > 3. No drivers are affected by this change.
> > > > 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
> > > >    follow up patchsets.
> > > > 
> > > > [...]
> > > 
> > > Applied, thanks!
> > > 
> > > [12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
> > >         commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f
> > 
> > You didn't honor (or even comment) Krzysztof's proposal to take the
> > whole patchset via his tree (marked above). Was there some off-list
> > agreement?
> 
> I had read all that and then looking at patchwork saw that you had
> marked all other patches in the series as "handled-elsewhere" and only
> this one was left as "new", so I assumed that, well, everything else was
> handled elsewhere and I was supposed to pick this one up...

I didn't mark it as handled-elsewhere, but my expectation was that you
might want to send an Ack only.

For today's series by Krzysztof I acked and marked the patch as
handled-elsewhere (together with the rest of the series that isn't pwm
related). So you have to consult your inbox if you still want to send an
Ack for that one.

Best regards
Uwe