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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
1, Support PREEMPT_DYNAMIC with static keys;
2, Relax memory ordering for atomic operations;
3, Support BPF CPU v4 instructions for LoongArch;
4, Some build and runtime warning fixes.
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEzOlt8mkP+tbeiYy5AoYrw/LiJnoFAmVQWXgWHGNoZW5odWFj
YWlAa2VybmVsLm9yZwAKCRAChivD8uImepDTEACS808EsgSNIM1+JwldhdqKOErt
XDWlLuIddVpenInx8F+9GnZJzKBU+wl+Ow5ejcVarjcecIJDv5UhoVrbhpeOHkfv
RszRXQR4p/ZNSFvdraYDjjJ9UX6bp5rq7vMUC2d9bLazMauAfwf7T/HJ5qj9OYZi
RLlcwaKo2UQHYsT7nJicjh0qpH1YpZQBYTaUUCwzilzB6vAIOTf6X12vFmhtM/i+
5RIPnesMA1IQSm2ywUODpDHCs7Pirvy8aJvx0CsYdi3xl1yg3pUS6u69Ms61uWlw
29yYhNbWmVnDikTVLTNISDb/jwto5SAVB2KQKBhF1trF4ZBNE6r7sP4m2tfllYo9
KXK9tm0U8McS5o46Qd5er6eEnxL7mEeAsc12tNKUYOMe3SIkmHJmj/rZQOtpsiBg
zqQsYkGUfO2VAwMWiGke8dxPZElOYwZ3UCOpbEpXEXy3NW71VJTIuQFGmsYKJhdy
3xaAtQxdffE5yUTt2j3Y8Mex2b2oSUBSF263imsZjzWOOxd480iaoejtamf1V779
bElevzZjMDmbiQ7kiVSf96TWc7iYcSv33jhP4DorKIqnPseYPfrXEeD1xY7JV+IU
kkvSlO0hAJzVMmQgu5n0PPT1wrVpuvwtbsfcRobIkr1vktZyLaKHRq7rh4R5HTRL
ZUUm6c0kUDywGT+J4A==
=bmFe
-----END PGP SIGNATURE-----
Merge tag 'loongarch-6.7' of 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
- 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, Thomas Zimmermann.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmVQIV8THG1wZUBlbGxl
cm1hbi5pZC5hdQAKCRBR6+o8yOGlgKTmEACKY2QHnc8ppY2V3W2D62q336OXU8Jj
ljJdPj/4dMlbFxi7RcUHhENGx97KN7pJX/bIOYv+iK4C34B1sM/sMG6OxXzWrlJw
ff2MnxE3ekljFerPdtx0fu3upCsr93hB3spm+/9pb/5V5SViK/gJt70dLUJuZ4ei
Y4AW0mnS4dMNMPZDGwI9GHbjCdq1GAbG9JdfDWbltKu2G3zNuM4MTa0IVJY/kHgU
8dbrPcs4LooC/RXJDTVdpBpShKg4i5sejcK30BP8qV0EXuez09lIRSk464n4aBEi
LWnKavsLOAAGYhEFCuBsn/ZFbWUWCmV6ARcC7ydZ+ukhZi+0iioPMh1dGO0Bo+rP
qesGLMddvsRZHInFN44NLDFVv03NA4V97LazvLQoUKSw8Oyt7aglLCmy+3YZL5Pd
Zny/Pi5Vq3Ma45lqGuafoaT2qhERz4Z3tbedtRcdO3APVnvtGtgWUUPym8xNKAe4
mOx0R1EzVdD3QXjh1Fwi9We69tdu5yRDmu+qne07x2T/vJN5zPR9k6sZXkuv85zH
jX53GlVyLTLXVuD00pFcL9/wjlWhzFHk2BUCg8scKgkqdadN323uZ9qhyn1/VJFt
E+2j0vLUlRA3Bj+WqcbY8TNq7HsDo91nt1ceYDtnHmRiZcSjRj/rh+cNyd28j+Zk
Z4hXJkznVjBHAw==
=Qaeg
-----END PGP SIGNATURE-----
Merge tag 'powerpc-6.7-2' of 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
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAmVP3VMACgkQiiy9cAdy
T1HlPAwAoeklucnmjVZJny15qsDHErR9I/CQseMksGHBomAFk2iUjUEL8cjozMMU
3gZuXnYT07Gd95Tk4oytVqEFn4pXl4rdi1gsppr9ewPu0XYZBL0yt9L9rt7g9lm9
yWvwa6skIOjJIeLs+Thzz7MBj3T759TT0O4J4Hl2LQ8QnDPvR9Zh0N01B6boRw7i
qG8jcCgJRRHlj6B/e24wGdu7wTUxDxWCXGkyos30VfojdrQwfWJ45Hhn7MiytRfx
qeEW2bYdSBZhqpQs6MbpkBz+nUZQf7oxhXbqfxqx8CsjaN7X//qA+mWl47n64t52
h7A73LP8rDe6JJNZRY/LWGNK4vtqEVw2AvvbETqxiteLA61Xp/+3SBt3upepH6eT
/EvSXuMmfeHUf/Od2u00ynos4VbFzFelHuzmGatv/s7VeHqRu4ImWHtRhI3BbmjK
runuFRNcY8YrGfpu+niXIeYDI0a9zIeCKl75GYbf/Ns53EYYwfKJIrG+BX0i2CUO
g72piup1
=xjGh
-----END PGP SIGNATURE-----
Merge tag '6.7-rc-smb3-client-fixes-part2' of 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
- 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.
-----BEGIN PGP SIGNATURE-----
iQFPBAABCgA5FiEEh7BulGwFlgAOi5DV2/sHvwUrPxsFAmVOwAQbHG1hc2FtaS5o
aXJhbWF0c3VAZ21haWwuY29tAAoJENv7B78FKz8bItMH/0F/vyiirgLrRVvQ+5Tr
Hm32oc1BQzxnQ0+9bjzk3r90KYk5cysBEEqxKzgxq9/RsJdyCczQUpxYehU0BoZT
1B4pB5eQ0DwcdGAVk4TyBRYVBb3uhCyyZNXv+F60AsO8i87fHHoJXT9SoKK+Vgx4
MAklE1gnxFFlRoYCBQpks89NajRx6n3aEL4/oXO3WYSrv+H2WGtZamB+RhpufkDx
Qx5TkIGnjulcW6J5m7Px5N3z9AX00SbfooZHAae3fqsek5RPNecfc1/WiANNXrSm
SYsG/i1jcHVvmk2YmCVokVLPKzhCOsKIuiW91rBu/Tu6lqiJmC+fxWxuZqAdXFUi
+kw=
=uymB
-----END PGP SIGNATURE-----
Merge tag 'probes-fixes-v6.7-rc1' of 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
- 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
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZU6s8AAKCRD3ErUQojoP
X1bVAQCzMS+ZEuKKUGKeoUKvQjHe6wWPopgnnWlzbGLunTSdFAEApDLjXOT9QYez
iHbEDcLNfwhGURIu0qOQDQ6NEe9ayQE=
=0D+E
-----END PGP SIGNATURE-----
Merge tag 'fbdev-for-6.7-rc1' of 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
...
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>
