summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-11arm64: dts: exynos: add initial support for exynosautov920 SoCJaewon Kim2-0/+1578
Samsung ExynosAutov920 is ARMv8-based automotive-oriented SoC. It has AE(Automotive Enhanced) IPs for safety. * Cortex-A78AE 10-cores * GIC-600AE This is minimal support for ExynosAutov920 SoC. * Enumerate all pinctrl nodes * Enable Chip-Id * Serial0 for console * PWM Since the clock driver is not yet implemented, it is supported as fixed-clock. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231208074527.50840-2-jaewon02.kim@samsung.com [krzysztof: Re-order nodes to match coding style: UFS reset pins, gpg/gpp in peric0 and peric1, all nodes in the soc@0; drop fallback compatibles from wakeup-interrupt-controller] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07arm64: dts: fsd: add specific compatibles for Tesla FSDKrzysztof Kozlowski1-16/+16
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. Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-7-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64Krzysztof Kozlowski5-8/+17
2023-12-07dt-bindings: watchdog: samsung: add specific compatible for Tesla FSDKrzysztof Kozlowski1-8/+13
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. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-6-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+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. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-5-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: serial: samsung: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+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. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: pwm: samsung: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+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. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: i2c: exynos5: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+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. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-24arm64: dts: exynosautov9: use Exynos7 fallbacks for pin wake-up controllerKrzysztof Kozlowski1-1/+3
ExynosAutov9 pin controller capable of wake-ups is still compatible with Exynos7, however it does not mux interrupts. Add Exynos7 compatible fallback to annotate that compatibility and match the bindings. Link: https://lore.kernel.org/r/20231122200407.423264-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-24arm64: dts: exynos850: use Exynos7 fallbacks for pin wake-up controllersKrzysztof Kozlowski1-2/+4
Exynos850 pin controller capable of wake-ups is still compatible with Exynos7, however it does not mux interrupts. Add Exynos7 compatible fallback to annotate that compatibility and match the bindings. Link: https://lore.kernel.org/r/20231122200407.423264-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64Krzysztof Kozlowski7-2/+20
2023-11-15dt-bindings: hwinfo: samsung,exynos-chipid: add exynosautov920 compatibleJaewon Kim1-0/+1
Add "samsung,exynosautov920-chipid" compatible string to binding document. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-9-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: arm: samsung: Document exynosautov920 SADK board bindingJaewon Kim1-0/+6
Add binding for the ExynosAutov920 SADK(Samsung Automotive Development Kit) board. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-8-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: pwm: samsung: add exynosautov920 compatibleJaewon Kim1-0/+1
Add samsung,exynosautov920-pwm compatible string to binding document. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231115095609.39883-6-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: serial: samsung: add exynosautov920-uart compatibleJaewon Kim1-1/+3
Add samsung,exynosautov9-uart dedicated compatible for representing uart of ExynosAutov920 SoC. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-5-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: samsung: usi: add exynosautov920-usi compatibleJaewon Kim1-1/+3
Add samsung,exynosautov920-usi dedicated compatible for representing USI of ExynosAutoV920 SoC. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-4-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: samsung: exynos-pmu: add exynosautov920 compatibleJaewon Kim1-0/+1
Add samsung,exynosautov920-pmu compatible for representing pmu of ExynosAutov920 SoC. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-3-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: samsung: exynos-sysreg: add exynosautov920 sysregJaewon Kim1-0/+5
Add compatible for ExynosAutov920 sysreg controllers. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-2-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15arm64: dts: exynos: add gpio-key node for exynosautov9-sadkJaewon Kim1-0/+51
ExynosAutov9 SADK board has 3 keys to test external GPIO interrupt. To support this, add 3 gpio-key(Wakeup, Volume Down, Volume Up) node. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231027040338.63088-1-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15arm64: dts: exynosautov9: add specific compatibles to several blocksKrzysztof Kozlowski1-2/+4
ExynosAutov9 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 ExynosAutov9 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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20231108104343.24192-18-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15arm64: dts: exynos850: add specific compatibles to several blocksKrzysztof Kozlowski1-14/+20
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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20231108104343.24192-17-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15arm64: dts: exynos7885: add specific compatibles to several blocksKrzysztof Kozlowski1-15/+30
Exynos7885 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 Exynos7885 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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20231108104343.24192-16-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15arm64: dts: exynos7: add specific compatibles to several blocksKrzysztof Kozlowski1-8/+10
Exynos7 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 Exynos7 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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20231108104343.24192-15-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15arm64: dts: exynos5433: add specific compatibles to several blocksKrzysztof Kozlowski1-21/+39
Exynos5433 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 Exynos5433 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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20231108104343.24192-14-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: pwm: samsung: add specific compatibles for existing SoCKrzysztof Kozlowski1-0/+2
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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231108104343.24192-13-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing SoCKrzysztof Kozlowski2-8/+13
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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Lee Jones <lee@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-12-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: iio: samsung,exynos-adc: add specific compatibles for existing SoCKrzysztof Kozlowski1-12/+17
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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-11-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: gpu: arm,mali-midgard: add specific compatibles for existing ↵Krzysztof Kozlowski1-0/+5
Exynos 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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-10-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: samsung: exynos-pmu: add specific compatibles for existing SoCKrzysztof Kozlowski1-0/+6
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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-9-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: serial: samsung: add specific compatibles for existing SoCKrzysztof Kozlowski1-3/+11
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. Re-shuffle also the entries in compatibles, so the one-compatible-enum is the first. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-8-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: rtc: s3c-rtc: add specific compatibles for existing SoCKrzysztof Kozlowski1-0/+5
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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20231108104343.24192-7-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-14dt-bindings: mmc: samsung,exynos-dw-mshc: add specific compatibles for ↵Krzysztof Kozlowski1-9/+16
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. While re-indenting the first enum, put also axis,artpec8-dw-mshc in alphabetical order. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20231108104343.24192-5-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-14dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for existing SoCKrzysztof Kozlowski1-8/+14
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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-14dt-bindings: i2c: exynos5: add specific compatibles for existing SoCKrzysztof Kozlowski2-2/+10
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. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-14dt-bindings: hwinfo: samsung,exynos-chipid: add specific compatibles for ↵Krzysztof Kozlowski1-3/+14
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. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-13Linux 6.7-rc1Linus Torvalds1-2/+2
2023-11-12wifi: iwlwifi: fix system commands group orderingMiri Korenblit1-1/+1
The commands should be sorted inside the group definition. Fix the ordering so we won't get following warning: WARN_ON(iwl_cmd_groups_verify_sorted(trans_cfg)) Link: https://lore.kernel.org/regressions/2fa930bb-54dd-4942-a88d-05a47c8e9731@gmail.com/ Link: https://lore.kernel.org/linux-wireless/CAHk-=wix6kqQ5vHZXjOPpZBfM7mMm9bBZxi2Jh7XnaKCqVf94w@mail.gmail.com/ Fixes: b6e3d1ba4fcf ("wifi: iwlwifi: mvm: implement new firmware API for statistics") Tested-by: Niklāvs Koļesņikovs <pinkflames.linux@gmail.com> Tested-by: Damian Tometzki <damian@riscv-rocks.de> Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-11-12Merge tag 'parisc-for-6.7-rc1-2' of ↵Linus Torvalds3-8/+6
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc architecture fixes from Helge Deller: - Include the upper 5 address bits when inserting TLB entries on a 64-bit kernel. On physical machines those are ignored, but in qemu it's nice to have them included and to be correct. - Stop the 64-bit kernel and show a warning if someone tries to boot on a machine with a 32-bit CPU - Fix a "no previous prototype" warning in parport-gsc * tag 'parisc-for-6.7-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Prevent booting 64-bit kernels on PA1.x machines parport: gsc: mark init function static parisc/pgtable: Do not drop upper 5 address bits of physical address
2023-11-12Merge tag 'loongarch-6.7' of ↵Linus Torvalds13-63/+215
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch updates from Huacai Chen: - support PREEMPT_DYNAMIC with static keys - relax memory ordering for atomic operations - support BPF CPU v4 instructions for LoongArch - some build and runtime warning fixes * tag 'loongarch-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: selftests/bpf: Enable cpu v4 tests for LoongArch LoongArch: BPF: Support signed mod instructions LoongArch: BPF: Support signed div instructions LoongArch: BPF: Support 32-bit offset jmp instructions LoongArch: BPF: Support unconditional bswap instructions LoongArch: BPF: Support sign-extension mov instructions LoongArch: BPF: Support sign-extension load instructions LoongArch: Add more instruction opcodes and emit_* helpers LoongArch/smp: Call rcutree_report_cpu_starting() earlier LoongArch: Relax memory ordering for atomic operations LoongArch: Mark __percpu functions as always inline LoongArch: Disable module from accessing external data directly LoongArch: Support PREEMPT_DYNAMIC with static keys
2023-11-12Merge tag 'powerpc-6.7-2' of ↵Linus Torvalds8-24/+24
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Finish a refactor of pgprot_framebuffer() which dependend on some changes that were merged via the drm tree - Fix some kernel-doc warnings to quieten the bots Thanks to Nathan Lynch and Thomas Zimmermann. * tag 'powerpc-6.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/rtas: Fix ppc_rtas_rmo_buf_show() kernel-doc powerpc/pseries/rtas-work-area: Fix rtas_work_area_reserve_arena() kernel-doc powerpc/fb: Call internal __phys_mem_access_prot() in fbdev code powerpc: Remove file parameter from phys_mem_access_prot() powerpc/machdep: Remove trailing whitespaces
2023-11-12Merge tag '6.7-rc-smb3-client-fixes-part2' of ↵Linus Torvalds16-88/+491
git://git.samba.org/sfrench/cifs-2.6 Pull smb client fixes from Steve French: - ctime caching fix (for setxattr) - encryption fix - DNS resolver mount fix - debugging improvements - multichannel fixes including cases where server stops or starts supporting multichannel after mount - reconnect fix - minor cleanups * tag '6.7-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6: cifs: update internal module version number for cifs.ko cifs: handle when server stops supporting multichannel cifs: handle when server starts supporting multichannel Missing field not being returned in ioctl CIFS_IOC_GET_MNT_INFO smb3: allow dumping session and tcon id to improve stats analysis and debugging smb: client: fix mount when dns_resolver key is not available smb3: fix caching of ctime on setxattr smb3: minor cleanup of session handling code cifs: reconnect work should have reference on server struct cifs: do not pass cifs_sb when trying to add channels cifs: account for primary channel in the interface list cifs: distribute channels across interfaces based on speed cifs: handle cases where a channel is closed smb3: more minor cleanups for session handling routines smb3: minor RDMA cleanup cifs: Fix encryption of cleared, but unset rq_iter data buffers
2023-11-11Merge tag 'probes-fixes-v6.7-rc1' of ↵Linus Torvalds15-31/+25
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull probes fixes from Masami Hiramatsu: - Documentation update: Add a note about argument and return value fetching is the best effort because it depends on the type. - objpool: Fix to make internal global variables static in test_objpool.c. - kprobes: Unify kprobes_exceptions_nofify() prototypes. There are the same prototypes in asm/kprobes.h for some architectures, but some of them are missing the prototype and it causes a warning. So move the prototype into linux/kprobes.h. - tracing: Fix to check the tracepoint event and return event at parsing stage. The tracepoint event doesn't support %return but if $retval exists, it will be converted to %return silently. This finds that case and rejects it. - tracing: Fix the order of the descriptions about the parameters of __kprobe_event_gen_cmd_start() to be consistent with the argument list of the function. * tag 'probes-fixes-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing/kprobes: Fix the order of argument descriptions tracing: fprobe-event: Fix to check tracepoint event and return kprobes: unify kprobes_exceptions_nofify() prototypes lib: test_objpool: make global variables static Documentation: tracing: Add a note about argument and retval access
2023-11-11Merge tag 'fbdev-for-6.7-rc1' of ↵Linus Torvalds18-110/+70
git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev Pull fbdev fixes and cleanups from Helge Deller: - fix double free and resource leaks in imsttfb - lots of remove callback cleanups and section mismatch fixes in omapfb, amifb and atmel_lcdfb - error code fix and memparse simplification in omapfb * tag 'fbdev-for-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: (31 commits) fbdev: fsl-diu-fb: mark wr_reg_wa() static fbdev: amifb: Convert to platform remove callback returning void fbdev: amifb: Mark driver struct with __refdata to prevent section mismatch warning fbdev: hyperv_fb: fix uninitialized local variable use fbdev: omapfb/tpd12s015: Convert to platform remove callback returning void fbdev: omapfb/tfp410: Convert to platform remove callback returning void fbdev: omapfb/sharp-ls037v7dw01: Convert to platform remove callback returning void fbdev: omapfb/opa362: Convert to platform remove callback returning void fbdev: omapfb/hdmi: Convert to platform remove callback returning void fbdev: omapfb/dvi: Convert to platform remove callback returning void fbdev: omapfb/dsi-cm: Convert to platform remove callback returning void fbdev: omapfb/dpi: Convert to platform remove callback returning void fbdev: omapfb/analog-tv: Convert to platform remove callback returning void fbdev: atmel_lcdfb: Convert to platform remove callback returning void fbdev: omapfb/tpd12s015: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/tfp410: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/sharp-ls037v7dw01: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/opa362: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/hdmi: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/dvi: Don't put .remove() in .exit.text and drop suppress_bind_attrs ...
2023-11-11tracing/kprobes: Fix the order of argument descriptionsYujie Liu1-1/+1
The order of descriptions should be consistent with the argument list of the function, so "kretprobe" should be the second one. int __kprobe_event_gen_cmd_start(struct dynevent_cmd *cmd, bool kretprobe, const char *name, const char *loc, ...) Link: https://lore.kernel.org/all/20231031041305.3363712-1-yujie.liu@intel.com/ Fixes: 2a588dd1d5d6 ("tracing: Add kprobe event command generation functions") Suggested-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Yujie Liu <yujie.liu@intel.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2023-11-11Merge tag 'drm-next-2023-11-10' of git://anongit.freedesktop.org/drm/drmLinus Torvalds97-812/+1760
Pull drm fixes from Daniel Vetter: "Dave's VPN to the big machine died, so it's on me to do fixes pr this and next week while everyone else is at plumbers. - big pile of amd fixes, but mostly for hw support newly added in 6.7 - i915 fixes, mostly minor things - qxl memory leak fix - vc4 uaf fix in mock helpers - syncobj fix for DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE" * tag 'drm-next-2023-11-10' of git://anongit.freedesktop.org/drm/drm: (78 commits) drm/amdgpu: fix error handling in amdgpu_vm_init drm/amdgpu: Fix possible null pointer dereference drm/amdgpu: move UVD and VCE sched entity init after sched init drm/amdgpu: move kfd_resume before the ip late init drm/amd: Explicitly check for GFXOFF to be enabled for s0ix drm/amdgpu: Change WREG32_RLC to WREG32_SOC15_RLC where inst != 0 (v2) drm/amdgpu: Use correct KIQ MEC engine for gfx9.4.3 (v5) drm/amdgpu: add smu v13.0.6 pcs xgmi ras error query support drm/amdgpu: fix software pci_unplug on some chips drm/amd/display: remove duplicated argument drm/amdgpu: correct mca debugfs dump reg list drm/amdgpu: correct acclerator check architecutre dump drm/amdgpu: add pcs xgmi v6.4.0 ras support drm/amdgpu: Change extended-scope MTYPE on GC 9.4.3 drm/amdgpu: disable smu v13.0.6 mca debug mode by default drm/amdgpu: Support multiple error query modes drm/amdgpu: refine smu v13.0.6 mca dump driver drm/amdgpu: Do not program PF-only regs in hdp_v4_0.c under SRIOV (v2) drm/amdgpu: Skip PCTL0_MMHUB_DEEPSLEEP_IB write in jpegv4.0.3 under SRIOV drm: amd: Resolve Sphinx unexpected indentation warning ...
2023-11-10Merge tag 'arm64-fixes' of ↵Linus Torvalds9-86/+78
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: "Mostly PMU fixes and a reworking of the pseudo-NMI disabling on broken MediaTek firmware: - Move the MediaTek GIC quirk handling from irqchip to core. Before the merging window commit 44bd78dd2b88 ("irqchip/gic-v3: Disable pseudo NMIs on MediaTek devices w/ firmware issues") temporarily addressed this issue. Fixed now at a deeper level in the arch code - Reject events meant for other PMUs in the CoreSight PMU driver, otherwise some of the core PMU events would disappear - Fix the Armv8 PMUv3 driver driver to not truncate 64-bit registers, causing some events to be invisible - Remove duplicate declaration of __arm64_sys##name following the patch to avoid prototype warning for syscalls - Typos in the elf_hwcap documentation" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64/syscall: Remove duplicate declaration Revert "arm64: smp: avoid NMI IPIs with broken MediaTek FW" arm64: Move MediaTek GIC quirk handling from irqchip to core arm64/arm: arm_pmuv3: perf: Don't truncate 64-bit registers perf: arm_cspmu: Reject events meant for other PMUs Documentation/arm64: Fix typos in elf_hwcaps
2023-11-10Merge tag 'sound-fix-6.7-rc1' of ↵Linus Torvalds18-51/+171
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of fixes for rc1. The majority of changes are various ASoC driver-specific small fixes and usual HD-audio quirks, while there are a couple of core changes: a fix in ALSA core procfs code to avoid deadlocks at disconnection and an ASoC core fix for DAPM clock widgets" * tag 'sound-fix-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: OSS: dmasound/paula: Convert to platform remove callback returning void ALSA: hda: ASUS UM5302LA: Added quirks for cs35L41/10431A83 on i2c bus ALSA: info: Fix potential deadlock at disconnection ASoC: nau8540: Add self recovery to improve capture quility ALSA: hda/realtek: Add support dual speaker for Dell ALSA: hda: Add ASRock X670E Taichi to denylist ALSA: hda/realtek: Add quirk for ASUS UX7602ZM ASoC: SOF: sof-client: trivial: fix comment typo ASoC: dapm: fix clock get name ASoC: hdmi-codec: register hpd callback on component probe ASoC: mediatek: mt8186_mt6366_rt1019_rt5682s: trivial: fix error messages ASoC: da7219: Improve system suspend and resume handling ASoC: codecs: Modify macro value error ASoC: codecs: Modify the wrong judgment of re value ASoC: codecs: Modify the maximum value of calib ASoC: amd: acp: fix for i2s mode register field update ASoC: codecs: aw88399: Fix -Wuninitialized in aw_dev_set_vcalb() ASoC: rt712-sdca: fix speaker route missing issue ASoC: rockchip: Fix unused rockchip_i2s_tdm_match warning for !CONFIG_OF ASoC: ti: omap-mcbsp: Fix runtime PM underflow warnings
2023-11-10Merge tag 'amd-drm-next-6.7-2023-11-10' of ↵Daniel Vetter85-773/+1688
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.7-2023-11-10: amdgpu: - SR-IOV fixes - DMCUB fixes - DCN3.5 fixes - DP2 fixes - SubVP fixes - SMU14 fixes - SDMA4.x fixes - Suspend/resume fixes - AGP regression fix - UAF fixes for some error cases - SMU 13.0.6 fixes - Documentation fixes - RAS fixes - Hotplug fixes - Scheduling entity ordering fix - GPUVM fixes Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231110190703.4741-1-alexander.deucher@amd.com
2023-11-10Merge tag 'spi-fix-v6.7-merge-window' of ↵Linus Torvalds3-17/+41
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A couple of fixes that came in during the merge window: one Kconfig dependency fix and another fix for a long standing issue where a sync transfer races with system suspend" * tag 'spi-fix-v6.7-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: Fix null dereference on suspend spi: spi-zynq-qspi: add spi-mem to driver kconfig dependencies
2023-11-10Merge tag 'mmc-v6.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmcLinus Torvalds8-8/+38
Pull MMC fixes from Ulf Hansson: "MMC core: - Fix broken cache-flush support for Micron eMMCs - Revert 'mmc: core: Capture correct oemid-bits for eMMC cards' MMC host: - sdhci_am654: Fix TAP value parsing for legacy speed mode - sdhci-pci-gli: Fix support for ASPM mode for GL9755/GL9750 - vub300: Fix an error path in probe" * tag 'mmc-v6.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci-pci-gli: GL9750: Mask the replay timer timeout of AER mmc: sdhci-pci-gli: GL9755: Mask the replay timer timeout of AER Revert "mmc: core: Capture correct oemid-bits for eMMC cards" mmc: vub300: fix an error code mmc: Add quirk MMC_QUIRK_BROKEN_CACHE_FLUSH for Micron eMMC Q2J54A mmc: sdhci_am654: fix start loop index for TAP value parsing