summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
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
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
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 23:54:05 +0300