summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-18MAINTAINERS: adjust file entry in GOOGLE TENSOR SoC SUPPORTLukas Bulwahn1-1/+1
Commit 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings") adds the file google,gs101.h in include/dt-bindings/clock/. However, commit 9d71df3e6eb7 ("MAINTAINERS: add entry for Google Tensor SoC") wrongly refers to the file google,clk-gs101.h in that directory. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken reference. Adjust the file entry to the actual file in GOOGLE TENSOR SoC SUPPORT. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20231218101225.27637-1-lukas.bulwahn@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-13MAINTAINERS: add entry for Google Tensor SoCPeter Griffin1-0/+10
Add maintainers entry for the Google tensor SoC based platforms. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20231211162331.435900-17-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-13arm64: dts: exynos: google: Add initial Oriole/pixel 6 board supportPeter Griffin3-0/+111
Add initial board support for the Pixel 6 phone code named Oriole. This has been tested with a minimal busybox initramfs and boots to a shell. Tested-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20231211162331.435900-16-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-13arm64: dts: exynos: google: Add initial Google gs101 SoC supportPeter Griffin3-0/+1755
Google gs101 SoC is a ARMv8 mobile SoC found in the Pixel 6 (oriole), Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile phones. It features: * 4xA55 Little cluster * 2xA76 Mid cluster * 2xX1 Big cluster This commit adds the basic device tree for gs101 (SoC). Further platform support will be added over time. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-15-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-13dt-bindings: arm: google: Add bindings for Google ARM platformsPeter Griffin1-0/+53
This introduces bindings and dt-schema for the Google Tensor SoCs. Currently just gs101 and pixel 6 are supported. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231211162331.435900-3-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-13arm64: dts: fsd: Add MFC related DT enteriesAakarsh Jain1-0/+21
Add MFC DT node and reserve memory node for MFC usage. Cc: <linux-fsd@tesla.com> Signed-off-by: Smitha T Murthy <smithatmurthy@gmail.com> Signed-off-by: Aakarsh Jain <aakarsh.jain@samsung.com> Link: https://lore.kernel.org/r/20231206063045.97234-12-aakarsh.jain@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-11Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64Krzysztof Kozlowski4-5/+505
2023-12-11arm64: dts: exynos: add minimal support for exynosautov920 sadk boardJaewon Kim2-1/+90
ExynosAutov920 SADK is ExynosAutov920 SoC based SADK(Samsung Automotive Development Kit) board. It has 16GB(8GB + 8GB) LPDDR5 RAM and 256GB (128GB + 128GB) UFS. This is minimal support board device-tree. * Serial console * GPIO Key * PWM FAN Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231208074527.50840-3-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
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-11dt-bindings: samsung: exynos-sysreg: combine exynosautov920 with other enumKrzysztof Kozlowski1-5/+2
No need to create a new enum every time we bring-up new SoC. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231210134834.43943-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-10dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to ↵Peter Griffin1-0/+3
GS101 GS101 has three different SYSREG controllers, add dedicated compatibles for them to the documentation. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231209233106.147416-4-peter.griffin@linaro.org [krzysztof: move Google entries to existing enum] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-10dt-bindings: clock: Add Google gs101 clock management unit bindingsPeter Griffin2-0/+498
Provide dt-schema documentation for Google gs101 SoC clock controller. Currently this adds support for cmu_top, cmu_misc and cmu_apm. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231209233106.147416-3-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-10dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatiblePeter Griffin1-0/+2
Add gs101-pmu compatible to the bindings documentation. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231209233106.147416-2-peter.griffin@linaro.org 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
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 03:49:34 +0300