arm64: first set of Kconfig patches for Tegra132 support
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] arm64: first set of Kconfig patches for Tegra132 support
Quoted 23 lines · Thierry Reding
Quoted 17 lines · Will Deacon
Quoted 11 lines · Paul Walmsley
These patches start the ARM64
Kconfigand defconfig changes to support the Tegra132 (aka Tegra K1 64-bit) SoC and the NVIDIA Norrin64 FFD board.Tegra132 support is made conditional on
CONFIG_BROKEN, since there are some patches pending for other maintainers to fix compilation whenCONFIG_ARCH_TEGRAis set during an ARM64 build. Once those patches have been merged, a subsequent patch will be sent to remove theCONFIG_BROKENdependency and to make a few other defconfig changes that are dependent onCONFIG_ARCH_TEGRA.Quoted 4 lines
These patches apply on the arm64 fixes/core branch, commit
5d96e0cba263. They have been boot-tested on QEMU 2.2.0 AArch64, and (after other patches have been applied) have been boot-tested on the Tegra132 Norrin64 FFD board.Quoted 4 lines
Whilst I'm happy to take the second patch for 3.20 (getting those dependencies building and keeping them building is a Good Thing), can we hold off on the first patch until it's not broken? Having an unconditional depends on BROKEN isn't really that useful.
Quoted 8 lines
The two patches that require the BROKEN dependency are fairly trivial, so I don't think it would be a stretch to merge them for 3.20. But they apply to different trees (one to the clocksource tree, the other to the Tegra tree).
How do you usually handle the ARM64 patches? Do you manually pick up the patches that touch
arch/arm64or would you prefer for me to collect them in a pull request?
Either is fine; if it's a large series then a pull request tends to work better. Catalin is handling the 3.20 merge window (we take it in turns).
Quoted 3 lines
Either way I could probably provide a stable branch for you to pull into the arm64 tree to resolve the build dependencies provided that Daniel or Thomas will ack the clocksource patch.
Sure; if you have dependencies in other subsystems then we'd need either an ack from the relevant subsystem maintainer or for them to publish a stable branch that we can pull in. There's not really a hard-and-fast rule for this but we can work something out.
Will