Merging
=======
I propose to take entire patchset through my tree (Samsung SoC), because:
1. I already took similar work this cycle:
https://lore.kernel.org/all/[email protected]/
2. Two new SoCs are coming (Google GS101 and ExynosAutov920) and they might
touch the same lines. It is reasonable for me to take the bindings for the new
SoCs, to have clean `make dtbs_check` on the new DTS.
3. Having it together helps me to have clean `make dtbs_check` within my tree
on the existing DTS.
4. No drivers are affected by this change.
If folks agree, please kindly Ack the patches.
Description
===========
See:
https://lore.kernel.org/all/[email protected]/
Best regards,
Krzysztof
Krzysztof Kozlowski (6):
dt-bindings: i2c: exynos5: add specific compatible for Tesla FSD
dt-bindings: pwm: samsung: add specific compatible for Tesla FSD
dt-bindings: serial: samsung: add specific compatible for Tesla FSD
dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla
FSD
dt-bindings: watchdog: samsung: add specific compatible for Tesla FSD
arm64: dts: fsd: add specific compatibles for Tesla FSD
.../devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
.../devicetree/bindings/pwm/pwm-samsung.yaml | 1 +
.../bindings/serial/samsung_uart.yaml | 1 +
.../bindings/soc/samsung/exynos-pmu.yaml | 1 +
.../bindings/watchdog/samsung-wdt.yaml | 21 +++++++-----
arch/arm64/boot/dts/tesla/fsd.dtsi | 32 +++++++++----------
6 files changed, 33 insertions(+), 24 deletions(-)
--
2.34.1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
others it reuses several devices from older designs. 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 Tesla FSD compatible specific to be used with an existing fallback.
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 <[email protected]>
---
I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
arch/arm64/boot/dts/tesla/fsd.dtsi | 32 +++++++++++++++---------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/boot/dts/tesla/fsd.dtsi b/arch/arm64/boot/dts/tesla/fsd.dtsi
index bb50a9f7db4a..9db162afc834 100644
--- a/arch/arm64/boot/dts/tesla/fsd.dtsi
+++ b/arch/arm64/boot/dts/tesla/fsd.dtsi
@@ -581,7 +581,7 @@ pdma1: dma-controller@14290000 {
};
serial_0: serial@14180000 {
- compatible = "samsung,exynos4210-uart";
+ compatible = "tesla,fsd-uart", "samsung,exynos4210-uart";
reg = <0x0 0x14180000 0x0 0x100>;
interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&pdma1 1>, <&pdma1 0>;
@@ -593,7 +593,7 @@ serial_0: serial@14180000 {
};
serial_1: serial@14190000 {
- compatible = "samsung,exynos4210-uart";
+ compatible = "tesla,fsd-uart", "samsung,exynos4210-uart";
reg = <0x0 0x14190000 0x0 0x100>;
interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&pdma1 3>, <&pdma1 2>;
@@ -605,12 +605,12 @@ serial_1: serial@14190000 {
};
pmu_system_controller: system-controller@11400000 {
- compatible = "samsung,exynos7-pmu", "syscon";
+ compatible = "tesla,fsd-pmu", "samsung,exynos7-pmu", "syscon";
reg = <0x0 0x11400000 0x0 0x5000>;
};
watchdog_0: watchdog@100a0000 {
- compatible = "samsung,exynos7-wdt";
+ compatible = "tesla,fsd-wdt", "samsung,exynos7-wdt";
reg = <0x0 0x100a0000 0x0 0x100>;
interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>;
samsung,syscon-phandle = <&pmu_system_controller>;
@@ -619,7 +619,7 @@ watchdog_0: watchdog@100a0000 {
};
watchdog_1: watchdog@100b0000 {
- compatible = "samsung,exynos7-wdt";
+ compatible = "tesla,fsd-wdt", "samsung,exynos7-wdt";
reg = <0x0 0x100b0000 0x0 0x100>;
interrupts = <GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>;
samsung,syscon-phandle = <&pmu_system_controller>;
@@ -628,7 +628,7 @@ watchdog_1: watchdog@100b0000 {
};
watchdog_2: watchdog@100c0000 {
- compatible = "samsung,exynos7-wdt";
+ compatible = "tesla,fsd-wdt", "samsung,exynos7-wdt";
reg = <0x0 0x100c0000 0x0 0x100>;
interrupts = <GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>;
samsung,syscon-phandle = <&pmu_system_controller>;
@@ -637,7 +637,7 @@ watchdog_2: watchdog@100c0000 {
};
pwm_0: pwm@14100000 {
- compatible = "samsung,exynos4210-pwm";
+ compatible = "tesla,fsd-pwm", "samsung,exynos4210-pwm";
reg = <0x0 0x14100000 0x0 0x100>;
samsung,pwm-outputs = <0>, <1>, <2>, <3>;
#pwm-cells = <3>;
@@ -647,7 +647,7 @@ pwm_0: pwm@14100000 {
};
pwm_1: pwm@14110000 {
- compatible = "samsung,exynos4210-pwm";
+ compatible = "tesla,fsd-pwm", "samsung,exynos4210-pwm";
reg = <0x0 0x14110000 0x0 0x100>;
samsung,pwm-outputs = <0>, <1>, <2>, <3>;
#pwm-cells = <3>;
@@ -657,7 +657,7 @@ pwm_1: pwm@14110000 {
};
hsi2c_0: i2c@14200000 {
- compatible = "samsung,exynos7-hsi2c";
+ compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
reg = <0x0 0x14200000 0x0 0x1000>;
interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
@@ -670,7 +670,7 @@ hsi2c_0: i2c@14200000 {
};
hsi2c_1: i2c@14210000 {
- compatible = "samsung,exynos7-hsi2c";
+ compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
reg = <0x0 0x14210000 0x0 0x1000>;
interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
@@ -683,7 +683,7 @@ hsi2c_1: i2c@14210000 {
};
hsi2c_2: i2c@14220000 {
- compatible = "samsung,exynos7-hsi2c";
+ compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
reg = <0x0 0x14220000 0x0 0x1000>;
interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
@@ -696,7 +696,7 @@ hsi2c_2: i2c@14220000 {
};
hsi2c_3: i2c@14230000 {
- compatible = "samsung,exynos7-hsi2c";
+ compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
reg = <0x0 0x14230000 0x0 0x1000>;
interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
@@ -709,7 +709,7 @@ hsi2c_3: i2c@14230000 {
};
hsi2c_4: i2c@14240000 {
- compatible = "samsung,exynos7-hsi2c";
+ compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
reg = <0x0 0x14240000 0x0 0x1000>;
interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
@@ -722,7 +722,7 @@ hsi2c_4: i2c@14240000 {
};
hsi2c_5: i2c@14250000 {
- compatible = "samsung,exynos7-hsi2c";
+ compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
reg = <0x0 0x14250000 0x0 0x1000>;
interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
@@ -735,7 +735,7 @@ hsi2c_5: i2c@14250000 {
};
hsi2c_6: i2c@14260000 {
- compatible = "samsung,exynos7-hsi2c";
+ compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
reg = <0x0 0x14260000 0x0 0x1000>;
interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
@@ -748,7 +748,7 @@ hsi2c_6: i2c@14260000 {
};
hsi2c_7: i2c@14270000 {
- compatible = "samsung,exynos7-hsi2c";
+ compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
reg = <0x0 0x14270000 0x0 0x1000>;
interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
--
2.34.1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
others it reuses several devices from older designs. 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 Tesla FSD compatible specific to be used with an existing fallback.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
.../bindings/watchdog/samsung-wdt.yaml | 21 ++++++++++++-------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
index 8fb6656ba0c2..ea2d206b05ab 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -16,14 +16,19 @@ description: |+
properties:
compatible:
- enum:
- - samsung,s3c2410-wdt # for S3C2410
- - samsung,s3c6410-wdt # for S3C6410, S5PV210 and Exynos4
- - samsung,exynos5250-wdt # for Exynos5250
- - samsung,exynos5420-wdt # for Exynos5420
- - samsung,exynos7-wdt # for Exynos7
- - samsung,exynos850-wdt # for Exynos850
- - samsung,exynosautov9-wdt # for Exynosautov9
+ oneOf:
+ - enum:
+ - samsung,s3c2410-wdt # for S3C2410
+ - samsung,s3c6410-wdt # for S3C6410, S5PV210 and Exynos4
+ - samsung,exynos5250-wdt # for Exynos5250
+ - samsung,exynos5420-wdt # for Exynos5420
+ - samsung,exynos7-wdt # for Exynos7
+ - samsung,exynos850-wdt # for Exynos850
+ - samsung,exynosautov9-wdt # for Exynosautov9
+ - items:
+ - enum:
+ - tesla,fsd-wdt
+ - const: samsung,exynos7-wdt
reg:
maxItems: 1
--
2.34.1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
others it reuses several devices from older designs. 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 Tesla FSD compatible specific to be used with an existing fallback.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index 28e2cb50d85e..65f77442ff23 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -53,6 +53,7 @@ properties:
- samsung,exynos7885-pmu
- samsung,exynosautov9-pmu
- samsung,exynosautov920-pmu
+ - tesla,fsd-pmu
- const: samsung,exynos7-pmu
- const: syscon
- items:
--
2.34.1
On Tue, Dec 05, 2023 at 10:22:23AM +0100, Krzysztof Kozlowski wrote:
> Merging
> =======
> I propose to take entire patchset through my tree (Samsung SoC), because:
> 1. I already took similar work this cycle:
> https://lore.kernel.org/all/[email protected]/
> 2. Two new SoCs are coming (Google GS101 and ExynosAutov920) and they might
> touch the same lines. It is reasonable for me to take the bindings for the new
> SoCs, to have clean `make dtbs_check` on the new DTS.
> 3. Having it together helps me to have clean `make dtbs_check` within my tree
> on the existing DTS.
> 4. No drivers are affected by this change.
>
> If folks agree, please kindly Ack the patches.
Acked-by: Conor Dooley <[email protected]>
Cheers,
Conor.
On Tue, 05 Dec 2023 10:22:27 +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs. 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 Tesla FSD compatible specific to be used with an existing fallback.
>
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>
> ---
>
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
> Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <[email protected]>
On Tue, 05 Dec 2023 10:22:28 +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs. 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 Tesla FSD compatible specific to be used with an existing fallback.
>
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>
> ---
>
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
> .../bindings/watchdog/samsung-wdt.yaml | 21 ++++++++++++-------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
Acked-by: Rob Herring <[email protected]>
On Tue, 05 Dec 2023 10:22:23 +0100, Krzysztof Kozlowski wrote:
> Merging
> =======
> I propose to take entire patchset through my tree (Samsung SoC), because:
> 1. I already took similar work this cycle:
> https://lore.kernel.org/all/[email protected]/
> 2. Two new SoCs are coming (Google GS101 and ExynosAutov920) and they might
> touch the same lines. It is reasonable for me to take the bindings for the new
> SoCs, to have clean `make dtbs_check` on the new DTS.
> 3. Having it together helps me to have clean `make dtbs_check` within my tree
> on the existing DTS.
> 4. No drivers are affected by this change.
>
> [...]
Applied, thanks!
[1/6] dt-bindings: i2c: exynos5: add specific compatible for Tesla FSD
https://git.kernel.org/krzk/linux/c/7677fdbc036b93a882f660ca2484a6807e72f0be
[2/6] dt-bindings: pwm: samsung: add specific compatible for Tesla FSD
https://git.kernel.org/krzk/linux/c/edb32ec3cea79b518e6af841ecb01c839818f562
[3/6] dt-bindings: serial: samsung: add specific compatible for Tesla FSD
https://git.kernel.org/krzk/linux/c/921f4f1db7f5bf6798349db8a4382c032f144b98
[4/6] dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla FSD
https://git.kernel.org/krzk/linux/c/54772f1d61cd99ea1ed0febd4187bf24ef63bccd
[5/6] dt-bindings: watchdog: samsung: add specific compatible for Tesla FSD
https://git.kernel.org/krzk/linux/c/bf1e24c5330af06b2f7f1a166a1011d8d48e8651
[6/6] arm64: dts: fsd: add specific compatibles for Tesla FSD
https://git.kernel.org/krzk/linux/c/5f257922c5948c58669346d5cda371632108f266
Best regards,
--
Krzysztof Kozlowski <[email protected]>