IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
- Include upper 5 address bits of physical address in iitlbp
- Prevent booting 64-bit kernels on PA1.x machines
- parport-gsc: mark init function static
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZVB1AgAKCRD3ErUQojoP
Xy+GAP0TlgE7ExHBB4jBpGf6uFuP0broznCeclPD4Bd0gngVhQEAz5v5m0FkJVVI
5nOlKbBzLU4Mt9WYEbqNhmoNrklvYQo=
=T1IA
-----END PGP SIGNATURE-----
Merge tag 'parisc-for-6.7-rc1-2' of 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
