- Plug a buffer overflow due to the use of the user-provided register
width for firmware regs. Outright reject accesses where the
user register width does not match the kernel representation.
- Protect non-atomic RMW operations on vCPU flags against preemption,
as an update to the flags by an intervening preemption could be lost.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCZEALwAAKCRCivnWIJHzd
Fq2nAQDPwWpuMOrQYZCM5RF5/8yai5OPKB0NcvK00UDM4f6E1AEAxDud/KT9i15c
dmBfGn1zDzW4XAENrOkxjQWuBqi/tQg=
=Lxvf
-----END PGP SIGNATURE-----
Merge tag 'kvmarm-fixes-6.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 fixes for 6.3, part #4
- Plug a buffer overflow due to the use of the user-provided register
width for firmware regs. Outright reject accesses where the
user register width does not match the kernel representation.
- Protect non-atomic RMW operations on vCPU flags against preemption,
as an update to the flags by an intervening preemption could be lost.
- Large RISC-V IPI rework to make way for a new interrupt
architecture
- More Loongarch fixes from Lianmin Lv, fixing issues in the so
called "dual-bridge" systems.
- Workaround for the nvidia T241 chip that gets confused in
3 and 4 socket configurations, leading to the GIC
malfunctionning in some contexts
- Drop support for non-firmware driven GIC configurarations
now that the old ARM11MP Cavium board is gone
- Workaround for the Rockchip 3588 chip that doesn't
correctly deal with the shareability attributes.
- Replace uses of of_find_property() with the more appropriate
of_property_read_bool()
- Make bcm-6345-l1 request its MMIO region
- Add suspend support to the SiFive PLIC
- Drop support for stih415, stih416 and stid127 platforms
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAmRCjF0PHG1hekBrZXJu
ZWwub3JnAAoJECPQ0LrRPXpDfAcQAMCqxwZcMPtMDcj1pfuiPM4mcPnb81nB80ms
0Clc+O/fLvW4bduVQN9S+P4aJ3WNYUw0nTrF13CzUZpPOLGt8NlylSZ0+EQV6+th
60+YoJ0X5ovlQ6tMUzhJjuU2HFQxXyvNmkXsrr4xaPlZaOt01OCNGhKVwuq+f7nJ
U87id3M3Nt6dSj//NonBdy+61y/XZiPQXZZP6act71f5Rz+REnBdEESzWLbzV9jo
UiVZD24OWLE+A0N4JqTXI4ruXIaOdwfOi31hN/OF3JrWWrM99RYK/pLJM/mEvCdw
HA0acS/uj9wQLUD9OFPCKE3aGOA4rdcWUrwzQvINZMIezHgaWfuOT/J5BbF9iH+Y
nrySLQB9xl9TVtMsfCOmjc+yPDDQ0AycrV++pn6CH59dx4WR3e2wTe68arHMoO9h
ljvEHVb2inDYJqHhyYKhNehlD1YGNFcOT4QRrduWxQezl3RKdYEjJngmm7QBfRT1
ee62Jm2RodPAknuDnnJNsFnHAE8emu9RLdKviEmPT66oclhw2sgn/V2JC+O+Oe0e
TkXrn4AzrIpEjbEUMJAow7RTSpzIGx921fcqbSpZrf6k75rgxaKBPPxtV4uANfII
gbOKklj15pljuPuxsputWzkdU9xVvgdg/5CHw6+AA68rNeB16NbTMe9RsiYNzlF6
7XBGnW3Q
=TsID
-----END PGP SIGNATURE-----
Merge tag 'irqchip-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core
Pull irqchip changes from Marc Zyngier:
- Large RISC-V IPI rework to make way for a new interrupt
architecture
- More Loongarch fixes from Lianmin Lv, fixing issues in the so
called "dual-bridge" systems.
- Workaround for the nvidia T241 chip that gets confused in
3 and 4 socket configurations, leading to the GIC
malfunctionning in some contexts
- Drop support for non-firmware driven GIC configurarations
now that the old ARM11MP Cavium board is gone
- Workaround for the Rockchip 3588 chip that doesn't
correctly deal with the shareability attributes.
- Replace uses of of_find_property() with the more appropriate
of_property_read_bool()
- Make bcm-6345-l1 request its MMIO region
- Add suspend support to the SiFive PLIC
- Drop support for stih415, stih416 and stid127 platforms
Link: https://lore.kernel.org/lkml/20230421132104.3021536-1-maz@kernel.org
* irq/gic-6.4:
: .
: Collection of GIC/GICv3 fixes and cleanups
:
: - Workaround for the nvidia T241 chip that gets confused
: in 3 and 4 socket configurations, leading to the GIC
: malfunctionning in some contexts
:
: - Drop support for non-firmware driven GIC configurarations
: now that the old ARM11MP Cavium board is gone
:
: - Workaround for the Rockchip 3588 chip that doesn't
: correctly deal with the shareability attributes.
: .
irqchip/gic-v3: Add Rockchip 3588001 erratum workaround
irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4
irqchip/gic: Drop support for board files
Signed-off-by: Marc Zyngier <maz@kernel.org>
Normally when running a guest we do not touch the floating point
register state until first use of floating point by the guest, saving
the current state and loading the guest state at that point. This has
been found to offer a performance benefit in common cases. However
currently if SME is active when switching to a guest then we exit
streaming mode, disable ZA and invalidate the floating point register
state prior to starting the guest.
The exit from streaming mode is required for correct guest operation, if
we leave streaming mode enabled then many non-SME operations can
generate SME traps (eg, SVE operations will become streaming SVE
operations). If EL1 leaves CPACR_EL1.SMEN disabled then the host is
unable to intercept these traps. This will mean that a SME unaware guest
will see SME exceptions which will confuse it. Disabling streaming mode
also avoids creating spurious indications of usage of the SME hardware
which could impact system performance, especially with shared SME
implementations. Document the requirement to exit streaming mode
clearly.
There is no issue with guest operation caused by PSTATE.ZA so we can
defer handling for that until first floating point usage, do so if the
register state is not that of the current task and hence has already
been saved. We could also do this for the case where the register state
is that for the current task however this is very unlikely to happen and
would require disproportionate effort so continue to save the state in
that case.
Saving this state on first use would require that we map and unmap
storage for the host version of these registers for use by the
hypervisor, taking care to deal with protected KVM and the fact that the
host can free or reallocate the backing storage. Given that the strong
recommendation is that applications should only keep PSTATE.ZA enabled
when the state it enables is in active use it is difficult to see a case
where a VMM would wish to do this, it would need to not only be using
SME but also running the guest in the middle of SME usage. This can be
revisited in the future if a use case does arises, in the interim such
tasks will work but experience a performance overhead.
This brings our handling of SME more into line with our handling of
other floating point state and documents more clearly the constraints we
have, especially around streaming mode.
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221214-kvm-arm64-sme-context-switch-v2-3-57ba0082e9ff@kernel.org
We share the same handler for general floating point and SVE traps with a
check to make sure we don't handle any SVE traps if the system doesn't
have SVE support. Since we will be adding SME support and wishing to handle
that along with other FP related traps rewrite the check to be more scalable
and a bit clearer too, ensuring we don't misidentify SME traps as SVE ones.
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221214-kvm-arm64-sme-context-switch-v2-2-57ba0082e9ff@kernel.org
In kvm_arch_vcpu_load_fp() we unconditionally set the current FP state
to FP_STATE_HOST_OWNED, this will be overridden to FP_STATE_NONE if
TIF_FOREIGN_FPSTATE is set but the check is deferred until
kvm_arch_vcpu_ctxflush_fp() where we are no longer preemptable. Add a
comment to this effect to help avoid people being concerned about the
lack of a check and discover where the check is done.
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221214-kvm-arm64-sme-context-switch-v2-1-57ba0082e9ff@kernel.org
As we are revamping the way the pgtable walker evaluates some of the
data, make it clear that we rely on somew of the fields to be constant
across the lifetime of a walk.
For this, flag the start, end and phys fields of the walk data as
'const', which will generate an error if we were to accidentally
update these fields again.
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Similar to the recently fixed stage-2 walker, the hyp map walker
increments the PA and VA of a walk separately. Unlike stage-2, there is
no bug here as the map walker has exclusive access to the stage-1 page
tables.
Nonetheless, in the interest of continuity throughout the page table
code, tweak the hyp map walker to avoid incrementing the PA and instead
use the VA as the authoritative source of how far along a table walk has
gotten. Calculate the PA to use for a leaf PTE by adding the offset of
the VA from the start of the walk to the starting PA.
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230421071606.1603916-3-oliver.upton@linux.dev
Until now, the page table walker counted increments to the PA and IPA
of a walk in two separate places. While the PA is incremented as soon as
a leaf PTE is installed in stage2_map_walker_try_leaf(), the IPA is
actually bumped in the generic table walker context. Critically,
__kvm_pgtable_visit() rereads the PTE after the LEAF callback returns
to work out if a table or leaf was installed, and only bumps the IPA for
a leaf PTE.
This arrangement worked fine when we handled faults behind the write lock,
as the walker had exclusive access to the stage-2 page tables. However,
commit 1577cb5823 ("KVM: arm64: Handle stage-2 faults in parallel")
started handling all stage-2 faults behind the read lock, opening up a
race where a walker could increment the PA but not the IPA of a walk.
Nothing good ensues, as the walker starts mapping with the incorrect
IPA -> PA relationship.
For example, assume that two vCPUs took a data abort on the same IPA.
One observes that dirty logging is disabled, and the other observed that
it is enabled:
vCPU attempting PMD mapping vCPU attempting PTE mapping
====================================== =====================================
/* install PMD */
stage2_make_pte(ctx, leaf);
data->phys += granule;
/* replace PMD with a table */
stage2_try_break_pte(ctx, data->mmu);
stage2_make_pte(ctx, table);
/* table is observed */
ctx.old = READ_ONCE(*ptep);
table = kvm_pte_table(ctx.old, level);
/*
* map walk continues w/o incrementing
* IPA.
*/
__kvm_pgtable_walk(..., level + 1);
Bring an end to the whole mess by using the IPA as the single source of
truth for how far along a walk has gotten. Work out the correct PA to
map by calculating the IPA offset from the beginning of the walk and add
that to the starting physical address.
Cc: stable@vger.kernel.org
Fixes: 1577cb5823 ("KVM: arm64: Handle stage-2 faults in parallel")
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230421071606.1603916-2-oliver.upton@linux.dev
* kvm-arm64/spec-ptw:
: .
: On taking an exception from EL1&0 to EL2(&0), the page table walker is
: allowed to carry on with speculative walks started from EL1&0 while
: running at EL2 (see R_LFHQG). Given that the PTW may be actively using
: the EL1&0 system registers, the only safe way to deal with it is to
: issue a DSB before changing any of it.
:
: We already did the right thing for SPE and TRBE, but ignored the PTW
: for unknown reasons (probably because the architecture wasn't crystal
: clear at the time).
:
: This requires a bit of surgery in the nvhe code, though most of these
: patches are comments so that my future self can understand the purpose
: of these barriers. The VHE code is largely unaffected, thanks to the
: DSB in the context switch.
: .
KVM: arm64: vhe: Drop extra isb() on guest exit
KVM: arm64: vhe: Synchronise with page table walker on MMU update
KVM: arm64: pkvm: Document the side effects of kvm_flush_dcache_to_poc()
KVM: arm64: nvhe: Synchronise with page table walker on TLBI
KVM: arm64: nvhe: Synchronise with page table walker on vcpu run
Signed-off-by: Marc Zyngier <maz@kernel.org>
* kvm-arm64/smccc-filtering:
: .
: SMCCC call filtering and forwarding to userspace, courtesy of
: Oliver Upton. From the cover letter:
:
: "The Arm SMCCC is rather prescriptive in regards to the allocation of
: SMCCC function ID ranges. Many of the hypercall ranges have an
: associated specification from Arm (FF-A, PSCI, SDEI, etc.) with some
: room for vendor-specific implementations.
:
: The ever-expanding SMCCC surface leaves a lot of work within KVM for
: providing new features. Furthermore, KVM implements its own
: vendor-specific ABI, with little room for other implementations (like
: Hyper-V, for example). Rather than cramming it all into the kernel we
: should provide a way for userspace to handle hypercalls."
: .
KVM: selftests: Fix spelling mistake "KVM_HYPERCAL_EXIT_SMC" -> "KVM_HYPERCALL_EXIT_SMC"
KVM: arm64: Test that SMC64 arch calls are reserved
KVM: arm64: Prevent userspace from handling SMC64 arch range
KVM: arm64: Expose SMC/HVC width to userspace
KVM: selftests: Add test for SMCCC filter
KVM: selftests: Add a helper for SMCCC calls with SMC instruction
KVM: arm64: Let errors from SMCCC emulation to reach userspace
KVM: arm64: Return NOT_SUPPORTED to guest for unknown PSCI version
KVM: arm64: Introduce support for userspace SMCCC filtering
KVM: arm64: Add support for KVM_EXIT_HYPERCALL
KVM: arm64: Use a maple tree to represent the SMCCC filter
KVM: arm64: Refactor hvc filtering to support different actions
KVM: arm64: Start handling SMCs from EL1
KVM: arm64: Rename SMC/HVC call handler to reflect reality
KVM: arm64: Add vm fd device attribute accessors
KVM: arm64: Add a helper to check if a VM has ran once
KVM: x86: Redefine 'longmode' as a flag for KVM_EXIT_HYPERCALL
Signed-off-by: Marc Zyngier <maz@kernel.org>
* kvm-arm64/timer-vm-offsets: (21 commits)
: .
: This series aims at satisfying multiple goals:
:
: - allow a VMM to atomically restore a timer offset for a whole VM
: instead of updating the offset each time a vcpu get its counter
: written
:
: - allow a VMM to save/restore the physical timer context, something
: that we cannot do at the moment due to the lack of offsetting
:
: - provide a framework that is suitable for NV support, where we get
: both global and per timer, per vcpu offsetting, and manage
: interrupts in a less braindead way.
:
: Conflict resolution involves using the new per-vcpu config lock instead
: of the home-grown timer lock.
: .
KVM: arm64: Handle 32bit CNTPCTSS traps
KVM: arm64: selftests: Augment existing timer test to handle variable offset
KVM: arm64: selftests: Deal with spurious timer interrupts
KVM: arm64: selftests: Add physical timer registers to the sysreg list
KVM: arm64: nv: timers: Support hyp timer emulation
KVM: arm64: nv: timers: Add a per-timer, per-vcpu offset
KVM: arm64: Document KVM_ARM_SET_CNT_OFFSETS and co
KVM: arm64: timers: Abstract the number of valid timers per vcpu
KVM: arm64: timers: Fast-track CNTPCT_EL0 trap handling
KVM: arm64: Elide kern_hyp_va() in VHE-specific parts of the hypervisor
KVM: arm64: timers: Move the timer IRQs into arch_timer_vm_data
KVM: arm64: timers: Abstract per-timer IRQ access
KVM: arm64: timers: Rationalise per-vcpu timer init
KVM: arm64: timers: Allow save/restoring of the physical timer
KVM: arm64: timers: Allow userspace to set the global counter offset
KVM: arm64: Expose {un,}lock_all_vcpus() to the rest of KVM
KVM: arm64: timers: Allow physical offset without CNTPOFF_EL2
KVM: arm64: timers: Use CNTPOFF_EL2 to offset the physical timer
arm64: Add HAS_ECV_CNTPOFF capability
arm64: Add CNTPOFF_EL2 register definition
...
Signed-off-by: Marc Zyngier <maz@kernel.org>
* for-next/sysreg:
arm64/sysreg: Convert HFGITR_EL2 to automatic generation
arm64/idreg: Don't disable SME when disabling SVE
arm64/sysreg: Update ID_AA64PFR1_EL1 for DDI0601 2022-12
arm64/sysreg: Convert HFG[RW]TR_EL2 to automatic generation
arm64/sysreg: allow *Enum blocks in SysregFields blocks
* for-next/stacktrace:
arm64: move PAC masks to <asm/pointer_auth.h>
arm64: use XPACLRI to strip PAC
arm64: avoid redundant PAC stripping in __builtin_return_address()
arm64: stacktrace: always inline core stacktrace functions
arm64: stacktrace: move dump functions to end of file
arm64: stacktrace: recover return address for first entry
* for-next/perf: (24 commits)
KVM: arm64: Ensure CPU PMU probes before pKVM host de-privilege
drivers/perf: hisi: add NULL check for name
drivers/perf: hisi: Remove redundant initialized of pmu->name
perf/arm-cmn: Fix port detection for CMN-700
arm64: pmuv3: dynamically map PERF_COUNT_HW_BRANCH_INSTRUCTIONS
perf/arm-cmn: Validate cycles events fully
Revert "ARM: mach-virt: Select PMUv3 driver by default"
drivers/perf: apple_m1: Add Apple M2 support
dt-bindings: arm-pmu: Add PMU compatible strings for Apple M2 cores
perf: arm_cspmu: Fix variable dereference warning
perf/amlogic: Fix config1/config2 parsing issue
drivers/perf: Use devm_platform_get_and_ioremap_resource()
kbuild, drivers/perf: remove MODULE_LICENSE in non-modules
perf: qcom: Use devm_platform_get_and_ioremap_resource()
perf: arm: Use devm_platform_get_and_ioremap_resource()
perf/arm-cmn: Move overlapping wp_combine field
ARM: mach-virt: Select PMUv3 driver by default
ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM
ARM: Make CONFIG_CPU_V7 valid for 32bit ARMv8 implementations
perf: pmuv3: Change GENMASK to GENMASK_ULL
...
Although pKVM supports CPU PMU emulation for non-protected guests since
722625c6f4 ("KVM: arm64: Reenable pmu in Protected Mode"), this relies
on the PMU driver probing before the host has de-privileged so that the
'kvm_arm_pmu_available' static key can still be enabled by patching the
hypervisor text.
As it happens, both of these events hang off device_initcall() but the
PMU consistently won the race until 7755cec63a ("arm64: perf: Move
PMUv3 driver to drivers/perf"). Since then, the host will fail to boot
when pKVM is enabled:
| hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 counters available
| kvm [1]: nVHE hyp BUG at: [<ffff8000090366e0>] __kvm_nvhe_handle_host_mem_abort+0x270/0x284!
| kvm [1]: Cannot dump pKVM nVHE stacktrace: !CONFIG_PROTECTED_NVHE_STACKTRACE
| kvm [1]: Hyp Offset: 0xfffea41fbdf70000
| Kernel panic - not syncing: HYP panic:
| PS:a00003c9 PC:0000dbe04b0c66e0 ESR:00000000f2000800
| FAR:fffffbfffddfcf00 HPFAR:00000000010b0bf0 PAR:0000000000000000
| VCPU:0000000000000000
| CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7-00083-g0bce6746d154 #1
| Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
| Call trace:
| dump_backtrace+0xec/0x108
| show_stack+0x18/0x2c
| dump_stack_lvl+0x50/0x68
| dump_stack+0x18/0x24
| panic+0x13c/0x33c
| nvhe_hyp_panic_handler+0x10c/0x190
| aarch64_insn_patch_text_nosync+0x64/0xc8
| arch_jump_label_transform+0x4c/0x5c
| __jump_label_update+0x84/0xfc
| jump_label_update+0x100/0x134
| static_key_enable_cpuslocked+0x68/0xac
| static_key_enable+0x20/0x34
| kvm_host_pmu_init+0x88/0xa4
| armpmu_register+0xf0/0xf4
| arm_pmu_acpi_probe+0x2ec/0x368
| armv8_pmu_driver_init+0x38/0x44
| do_one_initcall+0xcc/0x240
Fix the race properly by deferring the de-privilege step to
device_initcall_sync(). This will also be needed in future when probing
IOMMU devices and allows us to separate the pKVM de-privilege logic from
the core hypervisor initialisation path.
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Fixes: 7755cec63a ("arm64: perf: Move PMUv3 driver to drivers/perf")
Tested-by: Fuad Tabba <tabba@google.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230420123356.2708-1-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Add some plumbing to the zboot EFI header generation to set the newly
introduced DllCharacteristicsEx flag associated with forward edge CFI
enforcement instructions (BTI on arm64, IBT on x86)
x86 does not currently uses the zboot infrastructure, so let's wire it
up only for arm64.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
UEFI heavily relies on so-called protocols, which are essentially
tables populated with pointers to executable code, and these are invoked
indirectly using BR or BLR instructions.
This makes the EFI execution context vulnerable to attacks on forward
edge control flow, and so it would help if we could enable hardware
enforcement (BTI) on CPUs that implement it.
So let's no longer disable BTI codegen for the EFI stub, and set the
newly introduced PE/COFF header flag when the kernel is built with BTI
landing pads.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
* for-next/misc:
arm64: kexec: include reboot.h
arm64: delete dead code in this_cpu_set_vectors()
arm64: kernel: Fix kernel warning when nokaslr is passed to commandline
arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step
arm64/sme: Fix some comments of ARM SME
arm64/signal: Alloc tpidr2 sigframe after checking system_supports_tpidr2()
arm64/signal: Use system_supports_tpidr2() to check TPIDR2
arm64: compat: Remove defines now in asm-generic
arm64: kexec: remove unnecessary (void*) conversions
arm64: armv8_deprecated: remove unnecessary (void*) conversions
firmware: arm_sdei: Fix sleep from invalid context BUG
* for-next/kdump:
arm64: kdump: defer the crashkernel reservation for platforms with no DMA memory zones
arm64: kdump: do not map crashkernel region specifically
arm64: kdump : take off the protection on crashkernel memory region
* for-next/ftrace:
arm64: ftrace: Simplify get_ftrace_plt
arm64: ftrace: Add direct call support
ftrace: selftest: remove broken trace_direct_tramp
ftrace: Make DIRECT_CALLS work WITH_ARGS and !WITH_REGS
ftrace: Store direct called addresses in their ops
ftrace: Rename _ftrace_direct_multi APIs to _ftrace_direct APIs
ftrace: Remove the legacy _ftrace_direct API
ftrace: Replace uses of _ftrace_direct APIs with _ftrace_direct_multi
ftrace: Let unregister_ftrace_direct_multi() call ftrace_free_filter()
* for-next/cpufeature:
arm64/cpufeature: Use helper macro to specify ID register for capabilites
arm64/cpufeature: Consistently use symbolic constants for min_field_value
arm64/cpufeature: Pull out helper for CPUID register definitions
Include reboot.h in machine_kexec.c for declaration of
machine_crash_shutdown.
gcc-12 with W=1 reports:
arch/arm64/kernel/machine_kexec.c:257:6: warning: no previous prototype for 'machine_crash_shutdown' [-Wmissing-prototypes]
257 | void machine_crash_shutdown(struct pt_regs *regs)
No functional changes intended.
Compile tested only.
Signed-off-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20230418-arm64-kexec-include-reboot-v1-1-8453fd4fb3fb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
The "slot" variable is an enum, and in this context it is an unsigned
int. So the type means it can never be negative and also we never pass
invalid data to this function. If something did pass invalid data then
this check would be insufficient protection.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/73859c9e-dea0-4764-bf01-7ae694fa2e37@kili.mountain
Signed-off-by: Will Deacon <will@kernel.org>
All accessors of kvm_vcpu_arch::mp_state should be {READ,WRITE}_ONCE(),
since readers of the mp_state don't acquire the mp_state_lock.
Nonetheless, kvm_psci_vcpu_on() updates the mp_state without using
WRITE_ONCE(). So, fix the code to update the mp_state using WRITE_ONCE.
Signed-off-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230419021852.2981107-3-reijiw@google.com
kvm_arch_vcpu_ioctl_vcpu_init() doesn't acquire mp_state_lock
when setting the mp_state to KVM_MP_STATE_RUNNABLE. Fix the
code to acquire the lock.
Signed-off-by: Reiji Watanabe <reijiw@google.com>
[maz: minor refactor]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230419021852.2981107-2-reijiw@google.com
The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
between 0-32768 but if it is more than sizeof(long) this will corrupt
memory.
Fixes: 99adb56763 ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/4efbab8c-640f-43b2-8ac6-6d68e08280fe@kili.mountain
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
The cache information can be extracted from either a Device Tree(DT),
the PPTT ACPI table, or arch registers (clidr_el1 for arm64).
When the DT is used but no cache properties are advertised, the current
code doesn't correctly fallback to using arch information. The changes
fixes the same and also assuse the that L1 data/instruction caches
are private and L2/higher caches are shared when the cache information
is missing in DT/ACPI and is derived form clidr_el1/arch registers.
Currently the cacheinfo is built from the primary CPU prior to secondary
CPUs boot, if the DT/ACPI description contains cache information.
However, if not present, it still reverts to the old behavior, which
allocates the cacheinfo memory on each secondary CPUs which causes
RT kernels to triggers a "BUG: sleeping function called from invalid
context".
The changes here attempts to enable automatic detection for RT kernels
when no DT/ACPI cache information is available, by pre-allocating
cacheinfo memory on the primary CPU.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmQ9bmEACgkQAEG6vDF+
4pggDhAAo75vFky/U63PV9x4IMvVTkNGIK/DSihvG+s5GsujiSS78f4tSSpLAY1X
yWTEYsU+1q03cE8rv0Xmkw+cxLerjOGisvPZCdnKVljUF5TWez6OlwKw5V1QqWk9
faOmWBSb8fH4X0ys73e0SBsF3bzyJB/cORmbOL8OnCE7rGkyMQ0plhYVOBQ3CoV8
KMrw7rnPlc5Aoq/8LgTY+Gojqf82njacCIQPrn1TjS/V0SdobC8xm7ZoepZgG9Q1
MHzBtTmKzGrVxWawxcfTaE89t2rudAafa3noYr4xy+dI8ptSkTQNKCG9pvTxIcFo
KXKfBO6+hTWNREf7a4ginKdKcIKDD7Oo2oTnPBYr9O9/2r727c5Wa5FEGsXa4c14
0dN3vFbhwWIDc5sA7eBOCDYycJm6XyTGJ6iPR+fmaWKwgXhIM2WxakeO8aptuwhn
sV+XO7IJxSF79GrrAkSN6AtVj6NHvNpzwRx9mBwHkT3ajDGb04P23AOuqoNDt7kh
wcz217ng3hG4CDEbOk9JCQqtFhJeSuIWP5T3wofUfYeXy2opQhwzmiOL+NVROuGY
h/cwQCcXCEYUohJhln2PvbMS7w0bBNserpetzEFJfc5aLLdocaH3aQ/AFnCXmCdN
YPXP6bp0WdbmfcMskVY8vlb/TBlcOzu6+W0qB1dXTWuib7cwm3o=
=4hhJ
-----END PGP SIGNATURE-----
Merge tag 'cacheinfo-updates-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into driver-core-next
Sudeep writes:
cacheinfo and arch_topology updates for v6.4
The cache information can be extracted from either a Device Tree(DT),
the PPTT ACPI table, or arch registers (clidr_el1 for arm64).
When the DT is used but no cache properties are advertised, the current
code doesn't correctly fallback to using arch information. The changes
fixes the same and also assuse the that L1 data/instruction caches
are private and L2/higher caches are shared when the cache information
is missing in DT/ACPI and is derived form clidr_el1/arch registers.
Currently the cacheinfo is built from the primary CPU prior to secondary
CPUs boot, if the DT/ACPI description contains cache information.
However, if not present, it still reverts to the old behavior, which
allocates the cacheinfo memory on each secondary CPUs which causes
RT kernels to triggers a "BUG: sleeping function called from invalid
context".
The changes here attempts to enable automatic detection for RT kernels
when no DT/ACPI cache information is available, by pre-allocating
cacheinfo memory on the primary CPU.
* tag 'cacheinfo-updates-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
cacheinfo: Add use_arch[|_cache]_info field/function
arch_topology: Remove early cacheinfo error message if -ENOENT
cacheinfo: Check cache properties are present in DT
cacheinfo: Check sib_leaf in cache_leaves_are_shared()
cacheinfo: Allow early level detection when DT/ACPI info is missing/broken
cacheinfo: Add arm64 early level initializer implementation
cacheinfo: Add arch specific early level initializer
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
[rppt@kernel.org: change ARCH_FORCE_MAX_ORDER dependencies]
Link: https://lkml.kernel.org/r/20230325060828.2662773-4-rppt@kernel.org
Link: https://lkml.kernel.org/r/20230324052233.2654090-4-rppt@kernel.org
Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Zi Yan <ziy@nvidia.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: David Miller <davem@davemloft.net>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Guo Ren <guoren@kernel.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Rich Felker <dalias@libc.org>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
It is not a good idea to change fundamental parameters of core memory
management. Having predefined ranges suggests that the values within
those ranges are sensible, but one has to *really* understand implications
of changing MAX_ORDER before actually amending it and ranges don't help
here.
Drop ranges in definition of ARCH_FORCE_MAX_ORDER and make its prompt
visible only if EXPERT=y
Link: https://lkml.kernel.org/r/20230324052233.2654090-3-rppt@kernel.org
Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
Reviewed-by: Zi Yan <ziy@nvidia.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: David Miller <davem@davemloft.net>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Guo Ren <guoren@kernel.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Rich Felker <dalias@libc.org>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Per-vcpu flags are updated using a non-atomic RMW operation.
Which means it is possible to get preempted between the read and
write operations.
Another interesting thing to note is that preemption also updates
flags, as we have some flag manipulation in both the load and put
operations.
It is thus possible to lose information communicated by either
load or put, as the preempted flag update will overwrite the flags
when the thread is resumed. This is specially critical if either
load or put has stored information which depends on the physical
CPU the vcpu runs on.
This results in really elusive bugs, and kudos must be given to
Mostafa for the long hours of debugging, and finally spotting
the problem.
Fix it by disabling preemption during the RMW operation, which
ensures that the state stays consistent. Also upgrade vcpu_get_flag
path to use READ_ONCE() to make sure the field is always atomically
accessed.
Fixes: e87abb73e5 ("KVM: arm64: Add helpers to manipulate vcpu flags among a set")
Reported-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230418125737.2327972-1-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Rockchip RK3588/RK3588s GIC600 integration does not support the
sharability feature. Rockchip assigned Erratum ID #3588001 for this
issue.
Note, that the 0x0201743b ID is not Rockchip specific and thus
there is an extra of_machine_is_compatible() check.
The flags are named FORCE_NON_SHAREABLE to be vendor agnostic,
since apparently similar integration design errors exist in other
platforms and they can reuse the same flag.
Co-developed-by: XiaoDong Huang <derrick.huang@rock-chips.com>
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
Co-developed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Co-developed-by: Lucas Tanure <lucas.tanure@collabora.com>
Signed-off-by: Lucas Tanure <lucas.tanure@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230418142109.49762-2-sebastian.reichel@collabora.com
There are a number of updates for devicetree files for Qualcomm,
Rockchips, and NXP i.MX platforms, addressing mistakes in the DT
contents:
- Wrong GPIO polarity on some boards
- Lower SD card interface speed for better stability
- Incorrect power supply, clock, pmic, cache properties
- Disable broken hbr3 on sc7280-herobrine
- Devicetree warning fixes
The only other changes are:
- A regression fix for the Amlogic performance monitoring unit driver,
along with two related DT changes.
- imx_v6_v7_defconfig enables PCI support again.
- Trivial fixes for tee, optee and psci firmware drivers, addressing
compiler warning and error output
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ+sQgACgkQYKtH/8kJ
UiftwQ/9G4zUbL4KZMZXmIrLTE/RYcJVLwnIk1Qh36Kj04tYE+uADRyxBdDcTCE6
hSwgQ98hvM8hDAgGUIEscO7FsoTWFs/ADXVQmJ/kgMzLdfldLkjJYsXiatmZFIlQ
7DW6ZtXV8ePUi/2Dk3al0bRuR+4xBAQf+0u/p9W7dFwttxeTyL87ApLgfQ9eoq9u
I60vwr9QNeUY19QpzHXX+AZRWS2R+uLqfBNEVV2NHl4Fy6iGqaBRc2q1Fby9Tt1h
793vDwNZz3+65xXL/XGDlKxh5OQtRK3FiWHXD9qTHzohUrYu3zMG2/ls8GczF3Vk
HYOtQp5xYNWI37JU2XlLIjWA4tuc0LUInVB2yK5uniIGKXaygnwnRI0IaEQkvWtW
tI89MOsPne7BgQv2boJh0FBA1yXYgL5WYFBx1x11kP71IRFf2LHrgutvuiIKzPF8
UiuxdrakT5FMZVr7pJTDr5Gk52qgR7PXXAGKc/oDj37JhXE1XuqSyNkbGRtujkkc
3x6etgAkuYcUQtuka0VVCLmG6Y/2Otn3dj+y+RYHFH7ljUDN6PfwveUqXNX9o0nz
AdI9gULbYWOf8iUc3hvT1tyJNudSIBeBXiqq/ovIklAme1scpKfjT54vQLyS4HYB
2repRE5v1LtXSyF2A3877EY4m6Tbcm4t+cUK2vl7NKVtYE4P8n8=
=5Uki
-----END PGP SIGNATURE-----
Merge tag 'arm-fixes-6.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC fixes from Arnd Bergmann:
"There are a number of updates for devicetree files for Qualcomm,
Rockchips, and NXP i.MX platforms, addressing mistakes in the DT
contents:
- Wrong GPIO polarity on some boards
- Lower SD card interface speed for better stability
- Incorrect power supply, clock, pmic, cache properties
- Disable broken hbr3 on sc7280-herobrine
- Devicetree warning fixes
The only other changes are:
- A regression fix for the Amlogic performance monitoring unit
driver, along with two related DT changes.
- imx_v6_v7_defconfig enables PCI support again.
- Trivial fixes for tee, optee and psci firmware drivers, addressing
compiler warning and error output"
* tag 'arm-fixes-6.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (32 commits)
firmware/psci: demote suspend-mode warning to info level
arm64: dts: qcom: sc7280: remove hbr3 support on herobrine boards
ARM: imx_v6_v7_defconfig: Fix unintentional disablement of PCI
arm64: dts: rockchip: correct panel supplies on some rk3326 boards
arm64: dts: rockchip: use just "port" in panel on RockPro64
arm64: dts: rockchip: use just "port" in panel on Pinebook Pro
ARM: dts: imx6ull-colibri: Remove unnecessary #address-cells/#size-cells
ARM: dts: imx7d-remarkable2: Remove unnecessary #address-cells/#size-cells
arm64: dts: imx8mp-verdin: correct off-on-delay
arm64: dts: imx8mm-verdin: correct off-on-delay
arm64: dts: imx8mm-evk: correct pmic clock source
arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and registers
arm64: dts: rockchip: Remove non-existing pwm-delay-us property
arm64: dts: rockchip: Add clk_rtc_32k to Anbernic xx3 Devices
tee: Pass a pointer to virt_to_page()
perf/amlogic: adjust register offsets
arm64: dts: meson-g12-common: resolve conflict between canvas & pmu
arm64: dts: meson-g12-common: specify full DMC range
arm64: dts: imx8mp: fix address length for LCDIF2
riscv: dts: canaan: drop invalid spi-max-frequency
...
cluster. Volume-keys (via adc) for the Pinephone Pro, display support for
the Anbernic RG353. As well as gpio-ranges for rk356x and fixes for the
audio-codec node-names on two boards.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmQ92RgQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgcXBB/43meqk8lbSdnOl12+ct+JC6U7wK6WB3RHk
1vVlzxQTL5myaKlVdXbA55FoxkETs2fL4oBeekJ/ajlRysQkW3nEQl6QsnbPY2gn
sDVDvogX7EKsp7X2ECLmzxxgJl/R2PY2Jsl5mbqMt3tXAl3J75fSIrPwptd4JTqg
IxtN16IHBmTPwlyDY/AXSDICudMET/URUkjaYOR4S6BcN2+7oR5M9NP4DD9/0P6f
1FV0FxTMSNAMiEpDCtHPfa29pjh83CtIpW57v2yvXthsiSR3McmNXPhnYbuZKCvD
ZE7NzhgXHvbRatR0YHj+vj8HHoYDYkRYTrbIRoWMvc2tT/ht34QQ
=4xMh
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ+pEUACgkQYKtH/8kJ
UifF7RAA1hp77ZVpV6LElyFAF+SsiVb46Vn6vD54pvYmPno6AcdKmei8blv2QLWQ
UfjZWj0k84Mg+GfB0CSO+Aey+oiugnRVAeYxHoaAH2K2lJozRhbVpAU4qatSB9N/
0w3pQoJPiBfHmQqGKcTEmmfrR7aFKmDrw8P4UlG58Oawv2kN80Ntw0DeOSKyOXSR
RiOGGrEh7LJ24F+uGaVyAejC6km/eVDaCovJ/EISNG3MUpd5M3Z6amKGIDHLoJPR
avk8OAWoSh1dYnrk+jeW+Yuc7JLjlDsORuZNq+a+0mL5Hi+5E2VLT8sZ3ff/RGYu
+if9OY3ooNj7RVgE8+su3g2U6o07pc9Gr4pFuTHKhXmT7L1qQn6x8koLq+PdZbyk
E26EyUiwF4RZ/q3MK8OQxIGfjW5VgADvwXxpw4VPo3F4qRX7igK6aPLWZ1VS61mt
cHShMNQPLzlHXlcMEice3693gIXu1izeOBRVDL6gkp/d6SQhENP51NmYuZyfEk/z
XG3KM+8DIqAzQq5M+AIpsGvg6E7fqd8ihQDhM0TAkSYTX1CBcTNF0b0s0dOAZCG6
Mgw8W7U36NUCF0D1RGSeIxckNLBXjOIMDRY4g8VqP4EtcmFKosdyHOU2cVzViisI
OIHLz6C32zafKZTxQP2BC5l/N6Z0sd7JAwLM6mbqahsFBJcuJlk=
=d/86
-----END PGP SIGNATURE-----
Merge tag 'v6.4-rockchip-dts64-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
On the Rock5b a fix the newly added rtc node and cpu-regulators for the big
cluster. Volume-keys (via adc) for the Pinephone Pro, display support for
the Anbernic RG353. As well as gpio-ranges for rk356x and fixes for the
audio-codec node-names on two boards.
* tag 'v6.4-rockchip-dts64-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: Add support for volume keys to rk3399-pinephone-pro
arm64: dts: rockchip: Add vdd_cpu_big regulators to rk3588-rock-5b
arm64: dts: rockchip: Use generic name for es8316 on Pinebook Pro and Rock 5B
arm64: dts: rockchip: Drop RTC clock-frequency on rk3588-rock-5b
arm64: dts: rockchip: Add pinctrl gpio-ranges for rk356x
arm64: dts: rockchip: add panel to Anbernic RG353 series
Link: https://lore.kernel.org/r/5144826.MHq7AAxBmi@phil
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
These are implemented via regular ADC, so regular polling is needed,
for these keys to work.
Co-developed-by: Martijn Braam <martijn@brixit.nl>
Signed-off-by: Martijn Braam <martijn@brixit.nl>
Co-developed-by: Kamil Trzciński <ayufan@ayufan.eu>
Signed-off-by: Kamil Trzciński <ayufan@ayufan.eu>
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Tested-by: Ondrej Jirman <megi@xff.cz>
Link: https://lore.kernel.org/r/20230405123813.2272919-1-pbrobinson@gmail.com
[increased Volume-Down voltage to 600mV as suggested by Ondrej]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This module is used by the Qualcomm sa8775p platform for passing the
reboot reason to the bootloader. Enable building it in the arm64
defconfig as a module.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Enable ADC driver to be built as a module which will
add support for ADC in TI K3 specific SoCs.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Enable TSCADC driver to be built as a module which will
add support for TI's TSC/ADC MFDevice.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Enable TI's SA2UL driver to support security acceleration on TI K3 SoCs.
Signed-off-by: Kamlesh Gurudasani <kamlesh@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A late addition to the tree, adding the PWM controllers and associated
keyboard backlight nodes, since that driver and its bindings are now
on the way to 6.4.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSByI3Ki0mXziclZJcd+FPLCI8zYgUCZD0PuAAKCRAd+FPLCI8z
YljSAP9IWstTYTmoFOga4Ba4S8LBcmuTBUqHmVbHNZYCO3JrfwD/T4Xn2qvHfdsd
/ajLodjmHoLh/E6HuSai55u6YLGi6As=
=e3Zh
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ9VI4ACgkQYKtH/8kJ
UifvERAAjeIQ215j/PgBivMcYy28eF7aL0TB56ztVq8LEQoC0rwEQu8vdgKGHECW
qvyjviWlg50aFbL2dRphsdtmeQsjc4cUfiH//UyehcTxFKkqaegVwi41bXktqUC6
vMRwoUBKOmAWSKZtOVy6gxNFETxf+nS72ZJUwUX/ckQZ+qFHFOOOy4jsqbe5KUnp
tK/dKNn51dHvrWRQ+8x+ZqpGFwF71SLtmKfHWyraSIQOSL94RDj5JrDzGGzYaXAs
57ZfBF6Fmpro0tKhJz7fDLvqpYSthgi9aYoHarTui52eJzcAIc7OGhl+CuQF4rfZ
2K9vWnKkRMP2Faj2B/sKZB26my3rby3ir4YprLEMCeGFhKsvOh3k9B8AMhz3XCPU
AeM2hXI+lL09cwbcW5remgNA5ctSWK/Yy5ZvN5aV2xM1hpJFco9WHKNBJi9RJpvn
Z5E4bDGy1nzyUfHGEPeJxlXAAyc8aqCJj9ELNr8YvqbZ9fKN57w3Za/mVYJgIB2e
EVmIdmsXrmrwm1cssd2wt977Fk6oty5Ett6sp45Vbxqd/rLzFW6/BkKTW4N6+YEI
H7gtjZyJ0WXFy40lgQSWuSBtDEhmmCAiyXM7VMVB0TGVTQcHLsgPlg4ksnPJ40Xo
110vdJr6N0+hW2va3Hjp3+Wma6/3I3sbgtIOEsUowZjaRPxdF5Y=
=sofq
-----END PGP SIGNATURE-----
Merge tag 'asahi-soc-dt-6.4-v2' of https://github.com/AsahiLinux/linux into soc/dt
Apple SoC DT updates for 6.4 (v2).
A late addition to the tree, adding the PWM controllers and associated
keyboard backlight nodes, since that driver and its bindings are now
on the way to 6.4.
* tag 'asahi-soc-dt-6.4-v2' of https://github.com/AsahiLinux/linux:
arm64: dts: apple: t8112: Add PWM controller
arm64: dts: apple: t600x: Add PWM controller
arm64: dts: apple: t8103: Add PWM controller
Link: https://lore.kernel.org/r/d0862463-acb3-ce83-6493-281a833ec87e@marcan.st
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When defining which value to look for in a system register field we
currently manually specify the register, field shift, width and sign and
the value to look for. This opens the potential for error with for example
the wrong field width or sign being specified, an enumeration value for
a different similarly named field or letting something be initialised to 0.
Since we now generate defines for all the ID registers we now have named
constants for all of these things generated from the system register
description, meaning that we can generate initialisation for all the fields
used in matching from a minimal specification of register, field and match
value. This is both shorter and eliminates or makes build failures several
potential errors.
No change in the generated binary.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230303-arm64-cpufeature-helpers-v2-3-4c8f28a6f203@kernel.org
[will: Drop explicit '.sign' assignment for BTI feature]
Signed-off-by: Will Deacon <will@kernel.org>
A number of the cpufeatures use raw numbers for the minimum field values
specified rather than symbolic constants. In preparation for the use of
helper macros replace all these with the appropriate constants.
No change in the generated binary.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230303-arm64-cpufeature-helpers-v2-2-4c8f28a6f203@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
We use the same structure to match hwcaps and CPU features so we can use
the same helper to generate the fields required. Pull the portion of the
current hwcaps helper that initialises the fields out into a separate
define placed earlier in the file so we can use it for cpufeatures.
No functional change.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230303-arm64-cpufeature-helpers-v2-1-4c8f28a6f203@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Automatically generate the Hypervisor Fine-Grained Instruction Trap
Register as per DDI0601 2023-03, currently we only have a definition for
the register name not any of the contents. No functional change.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230306-arm64-fgt-reg-gen-v5-1-516a89cb50f6@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
The RK8602 and RK8603 voltage regulators on the Rock 5B board provide
the power lines vdd_cpu_big0 and vdd_cpu_big1, respectively.
Add the necessary device tree nodes and bind them to the corresponding
CPU big core nodes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230414125425.124994-4-cristian.ciocaltea@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The hym8563 RTC driver doesn't handle the 'clock-frequency' property,
which is also indicated by the following dtbs_check warning:
rk3588-rock-5b.dtb: rtc@51: Unevaluated properties are not allowed ('clock-frequency' was unexpected)
From schema: Documentation/devicetree/bindings/rtc/haoyu,hym8563.yaml
Drop the unsupported property.
Fixes: 1e9c2404d8 ("arm64: dts: rockchip: Enable RTC support for Rock 5B")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230414125425.124994-2-cristian.ciocaltea@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This patch adds the device tree entries for the PWM controller
present on M2 macbooks that is connected to the keyboard backlight.
Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Adds PWM controller and keyboard backlight bindings for M1 MacBooks
Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
Acked-by: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Hector Martin <marcan@marcan.st>
Devicetree for the QCM2210/QCM2290 is introduced. Support for the RB1
board is introduced on QRB2210, RB2 on QRB4210, the AL02 board on
IPQ9574, the MI01.6 board is introduced on IPQ5332 and initial support
for Xiaomi Mi A3 is introduced on SM6125.
Support for the output-enable/disable flag is introduced in the
pinctrl-msm driver, and the non-standard "input-enable" is dropped from
a range of platforms.
A wide range of smaller fixes are introduced, based on Devicetree
validation.
MSM8953 gains LPASS, MPSS and Wireless subsystem support.
The iommus property is removed from PCIe nodes in all platforms, as the
only the child devices should be associated with iommu groups, through
the existing iommu-map property.
A few QUP instances are introduced on the IPQ5332 platform, and support
for the MI01.6 board is introduced.
The reserved-memory map on Huawei Nexus 6P is updated with the addition
of splash screen framebuffer memory and adjustment to the reserved
memory region overlapping the smem region.
Regulators are introduces for the SA8775P Ride platform.
A regulator is marked always-on, for correctness, on Trogdor. Pinconf
fixes are introduced to both sc7180 and sc7280 devices. A dedicated
reviewers list is added for boards relevant to the Chromebook engineers.
A set of pinconf fixes are introduced for sc8280xp, labels are
introduced for Soundwire nodes.
The sensor core remoteproc and FastRPC thereon, is introduce in SDM845
and enabled for OnePlus 6/6T and Shift Shift6mq.
RMTFS, remoteprocs, ath10k and ramoops is introduced for the Lenovo Tab
P11.
UFS support is introduced on SM6125.
SM8150 no longer defines the GPU to be in headless mode by default, GPU
speedbins are introduced.
GPU speedbins are introduced for SM8250 as well, as is support for
display on Xiaomi Mi Pad 5 Pro, with two different panels supported.
Soundwire controllers, ADSP audio codec macros and the Inline Crypto
Engine support is added to the SM8550 platform.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmQ4xScVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FyAEQANkYPPmcATVeCMu8ABqOGr2YpN2v
d1e8/Kdtrg0qWtqnXgkcec/+HvOqxTYlqW/iYLGf2fkgheQhbY8YOv3AU7FEG9Jr
RNsPiyZ/2o2VPcskS6jQSsbAGKaWbhSh7Ao2lSUNSsPuhHOYw/Nu3iRxKCE1FdHn
yqF2b+cipMwogKgx4LFCLwRTAG6f9HumDb3dwLeiUFPZH321MeJu8FzHnLt/wU5Z
64EzST7W2J5PlWdFEoJOXGDmxnM35hKJrzliRf5oqTHhUMUlyxQI6W61vSfsz5PP
7AE8DEMHD9b5fbRUf2mcMffPmhdvL194dSx10eTFMEuyoe+19CaMiZV86Cf8HeZ7
8K6ZZJ/tF/UrOBc7zMDtCUTm5f9MYyfiKqQNJekcpYWugQSsKw8TQZ58q4jM352R
vvq2ywMDk2olt4Jn0on7L6M8x+uOGIMQG3B32jJijE0fRFdMcHJMwfxEBsrGmsUW
vZvDdhQtIQSy6aLHFqwzFbGePq1GeYLjEh+PbT8EHkaCHFx0dA+EobLnwcyqJYky
AmWA2wjbIYU96KahSZ4Sz3MWTy9MrhHa10bwWoBvOsp1AAM/gpx5nIgoHXmzp2pg
cXgCqzUBgdMrWfjEFgtLY1HyRMGbQ7T+fQhaS5xn9TnHNqnvqLAW/APhyhrAWWXx
475V7NXAQMDd5FQX
=vVPv
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5eO4ACgkQYKtH/8kJ
UifICRAAz4I3XrqaTmlk8HtHwCSxhQfpF/6B+HmFbRG/tNFzWu4rbCyju2Gja6bi
lQDxP42uuH78m35rXtAA848bZ8BpUQesJcGuwQoPYRwCPTLZH493QryEZ2DM4rp1
IjKe1FmuHlToBiPxBgk+3EqaulXM9wSvV6lb7HlsEx6vt8TC9i0IhnfD6jHJ7ESs
Pln0nmTREAyNpdcGOfmCZ3m4Rc6rvz8WHu+pX/nYZIdF44txYJaVh4mU7T0DuxUo
KF2rfpPko4FXxqN6V3fYBRuRihu9lAqPwg86imQruqHnc0Lrfw2IMAdnUtXcmJOo
qrYvQgifJKd5TZ1aYrkiQk5jSA9Wy5Wt66rzu7XGC8XhEftYcs3D/gYkqfRifI+a
d+dqYLYXOLTopdDRfGgnCa74cNs7A+Y/mUC+WZQmWFI4q7I9SUnipRfzZt44Vbmp
mn1C6XIoeseO8HOHDx0dNUsgiDH/JDLZv1/RTT6fWj3+9R2fQKmtdq8i9ZBdKL7r
M/bAsS8PENmV6Dv3bHWxIa4xC380bDgCrjsLdHh5Oqfvbv2NHpftHkOaCK8BgE/t
8YubTKxaxw0YQ0NtI+ku6Km9VJCG1zDEiQPMYEcklEzUj09CfkfCqBg4EkI92u2i
P215llOlgIUzAgad/S0H2YhIIdnhsacU4adPEDD3devtKWdH+PE=
=HFrk
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-for-6.4-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt
More Qualcomm ARM64 Devicetree updated for v6.4
Devicetree for the QCM2210/QCM2290 is introduced. Support for the RB1
board is introduced on QRB2210, RB2 on QRB4210, the AL02 board on
IPQ9574, the MI01.6 board is introduced on IPQ5332 and initial support
for Xiaomi Mi A3 is introduced on SM6125.
Support for the output-enable/disable flag is introduced in the
pinctrl-msm driver, and the non-standard "input-enable" is dropped from
a range of platforms.
A wide range of smaller fixes are introduced, based on Devicetree
validation.
MSM8953 gains LPASS, MPSS and Wireless subsystem support.
The iommus property is removed from PCIe nodes in all platforms, as the
only the child devices should be associated with iommu groups, through
the existing iommu-map property.
A few QUP instances are introduced on the IPQ5332 platform, and support
for the MI01.6 board is introduced.
The reserved-memory map on Huawei Nexus 6P is updated with the addition
of splash screen framebuffer memory and adjustment to the reserved
memory region overlapping the smem region.
Regulators are introduces for the SA8775P Ride platform.
A regulator is marked always-on, for correctness, on Trogdor. Pinconf
fixes are introduced to both sc7180 and sc7280 devices. A dedicated
reviewers list is added for boards relevant to the Chromebook engineers.
A set of pinconf fixes are introduced for sc8280xp, labels are
introduced for Soundwire nodes.
The sensor core remoteproc and FastRPC thereon, is introduce in SDM845
and enabled for OnePlus 6/6T and Shift Shift6mq.
RMTFS, remoteprocs, ath10k and ramoops is introduced for the Lenovo Tab
P11.
UFS support is introduced on SM6125.
SM8150 no longer defines the GPU to be in headless mode by default, GPU
speedbins are introduced.
GPU speedbins are introduced for SM8250 as well, as is support for
display on Xiaomi Mi Pad 5 Pro, with two different panels supported.
Soundwire controllers, ADSP audio codec macros and the Inline Crypto
Engine support is added to the SM8550 platform.
* tag 'qcom-arm64-for-6.4-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (85 commits)
arm64: dts: qcom: Add base qrb4210-rb2 board dts
arm64: dts: qcom: sm8550: add Soundwire controllers
arm64: dts: qcom: sm8250: Add GPU speedbin support
arm64: dts: qcom: sm8150: Add GPU speedbin support
arm64: dts: qcom: sm8150: Don't start Adreno in headless mode
arm64: dts: qcom: ipq5332: add support for the RDP468 variant
arm64: dts: qcom: sdm630: move DSI opp-table out of DSI node
arm64: dts: qcom: sm6115p-j606f: Enable ATH10K WiFi
arm64: dts: qcom: sm6115p-j606f: Enable remoteprocs
arm64: dts: qcom: sm6115: Add RMTFS
arm64: dts: qcom: sm6115-j606f: Add ramoops node
arm64: dts: qcom: msm8916-thwc-ufi001c: add function to pin config
arm64: dts: qcom: sm8550: Add the Inline Crypto Engine node
arm64: dts: MSM8953: Add lpass nodes
arm64: dts: MSM8953: Add mpss nodes
arm64: dts: MSM8953: Add wcnss nodes
arm64: dts: qcom: sm8350: remove superfluous "input-enable"
arm64: dts: qcom: sm8150: remove superfluous "input-enable"
arm64: dts: qcom: apq8016: remove superfluous "input-enable"
arm64: dts: qcom: sc8280xp-lenovo-thinkpad: correct pin drive-strength
...
Link: https://lore.kernel.org/r/20230414031550.2412379-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
for 6.4, please pull the following:
- Rob fixes the GICv3 ITS node name for the Stingray platforms
- William adds the new-style High Speed SPI controller nodes to the BCA
SocS
- Rafal fixes the NAND controller interrupt name for BCM4908, LED
node(s) and procmon for BCM4908. He also adds support for the USB
ports, and declares USB triggered LEDs for the Netgear R8000P and
TP-Link C2300.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmQ0mjwACgkQh9CWnEQH
BwR0nQ//f9Q6E83ROQ3eNdRrCQuvxHeJ5EQgXRM+4F3jiazJdKpAxiNSg2uoM7/T
haom+DYrkeG6Jv6yqlDJIbFccHeaJUmFBzXxZ42ly5M0HliMF5jnsdqqdPdcwoPB
hzhuSI0pWU2OUESJpVxoPnjCywrz8FnjnVpeIUOLricJm3oleju5Wrcj2AWv04bx
3Vkxag1YUDj1W8boR4T0WIK+dJ4ZBdRKsFZhFtkuIP0+EI2NzFgS9Rk2tWpiCb5W
06mIytL4LFkliUmlECQIMup+Dgx8z9AkwxTPhE1or/CtYw5xw4JKOG3Gf8M5FX+g
LNEZzQ4227TFioztmBNHkQ0Ht1wE/wD5Jw8i8qy87SwTvOEEX8abmQ2hRSXzJAo0
QRqfSE2WIZzA6cV4IGuud/GeeDDm7jKmz3SxzMkAMjin0tkf2OxkoicQeJUxxEXx
J71wSYuZuQPrW/QjD10QbdClgAjB9sdiCWYnRljoKxJttq0ro4qxEPLm0ovKiyb/
KIhqz8sGoJ20CPKcGmki7eF9f8A3uLYzn7q6+fzYvd31QbDSbA4aOuyzCVqgFM/5
eoitbk3jrNmxbeGNqWopf9cJqgRpiiid3U9GzhFctj07+u/zY4buVlnH8fcVtug5
2wQR4po996ul0+E5hpnk8OPBZ6Be76/no8nyaxJiajqpGbFqsrQ=
=vioZ
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5eCIACgkQYKtH/8kJ
UifNLg/+Mu/sNCH2A0pIjolcR7Umn0Uvx9frZiusZdACa4+hA2N8EVj1NV3MW4z3
SvcwWy+ALDy6CjYzBbMFQYrVpu46TEjBvDNMgh4VA73bVemJg5F8WXoFRv6IaXXT
XUzJVm5GbPbCkLXHemxs+MEgHanNAqHZfGRN+hMxaKy9kxqrxZq60IYIw90t1eJk
NH/QbPcq0ck3WHwaVZluxCGCdb+ApiL5uHbsKfrDDcG6iUgu0LBw8moseb0e2tJp
HJhNTYaFC7VLsx+IUD3zBUtMyVNT28A3hwfuqRDZ7ceVWOXd4Qu7ESJ9g/GaW33T
RgdC6rnEWhKYVXEgN2x8KR3aMymwzwKGKgWTlNldImWyVkIUhWCkMJ7uUU69oyCS
3z4D2jAMIZE80vCWPH+oORcCGOk8tn+KX1IK0kfEzgrRaBpCHvHvTUVs/b7RDHAi
MBr4FETixQXh49wmT4BvdKz1MsA9gKw2JZ0jYnO99uNLttMdRlwpO+4ZDP4uI4Jk
2TPILd4lGnyW5NcXc8muvDtPaooZO1l/8TIMThmfH9ITNPWD6jIhCa3VeJ6ntXSA
nXrAew9ZBKGQcJ4NFSXq2H8rP6aeBLUtmotPqx+PlW5w6Um7PjuRdcx0xPyvcKrh
t4v/o8KjPrLAQhAEg7PvmJA8bZqiZxvr2OBnJjRPMR58FKPThAo=
=4E45
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.4/devicetree-arm64' of https://github.com/Broadcom/stblinux into soc/dt
This pull request contains Broadcom ARM64-based SoCs Device Tree changes
for 6.4, please pull the following:
- Rob fixes the GICv3 ITS node name for the Stingray platforms
- William adds the new-style High Speed SPI controller nodes to the BCA
SocS
- Rafal fixes the NAND controller interrupt name for BCM4908, LED
node(s) and procmon for BCM4908. He also adds support for the USB
ports, and declares USB triggered LEDs for the Netgear R8000P and
TP-Link C2300.
* tag 'arm-soc/for-6.4/devicetree-arm64' of https://github.com/Broadcom/stblinux:
arm64: dts: broadcom: bcmbca: bcm4908: add TP-Link C2300 USB LED triggers
arm64: dts: broadcom: bcmbca: bcm4908: add Netgear R8000P USB LED triggers
arm64: dts: broadcom: bcmbca: bcm4908: add on-SoC USB ports
arm64: dts: broadcom: bcmbca: bcm4908: fix procmon nodename
arm64: dts: broadcom: bcmbca: bcm4908: fix LED nodenames
arm64: dts: broadcom: bcmbca: bcm4908: fix NAND interrupt name
arm64: dts: broadcom: bcmbca: Add spi controller node
arm64: dts: broadcom: stringray: Fix GICv3 ITS node name
Link: https://lore.kernel.org/r/20230410232606.1917803-2-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
PCI I/O and MEM ranges are corrected across all targets with PCIe
enabled. Likewise is CPU clocks defined to be provided from CPUfreq for
a wide range of platforms, to satisfy the OPP definitions, and LLCC bank
information is corrected for all relevant platforms.
IPQ5332 gains SMEM, CPUfreq and support for triggering download mode.
The MI01.2 board is introduced.
On MSM8916 WCN compatibles are moved to be defined per board, to avoid
issues when boards rely on the incorrect defaults. Support for Yiming
UZ801 4G modem stick is introduced.
XO clock is defined and fed to RPMCC on MSM8953 and MSM8976, to ensure
clock trees are properly rooted. DSI clocks feeding into gcc are
described on MSM8953.
On MSM8996 the external audio components are moved from the SoC dtsi. A
few DWC3 quirks are added.
On MSM8998 GPIO names are introduced for Sony Xperia XZ Premium, XZ1 and
XZ1 Compact. A numbe of boards have GPIO keys properly marked as
wakeup-source.
The SA8775P platform is extended with CPUfreq, UARTs, I2C controllers,
SPI controllers, SPMI and PMICs, PDC support. The associated PMICs gains
reset and power key support, as well as thermal zones defined. Nodes are
sorted. On top of this the SA8775P Ride board/platform is introduced.
On SC7180 and SC7280 a range of fixes coming from DeviceTree validation are
introduced, some clearing up unused properties, others correcting
errors. A number of Google rev0 boards on SC7180 are dropped, as these
are not considered to be in use by anyone anymore.
On SC8280XP RTC support is introduced and enabled for the CRD and Lenovo
Thinkpad X13s. It gains another UART, upon which Bluetooth is enabled on
the Lenovo ThinkPad X13s. The touchpad definition is altered to attempt
to probe both devices seen in the wild. A number of bug fixes are also
introduced, and the regulator definitions on X13s are corrected.
On SDM845 dynamic power coefficients are improved. BWMON compatible is
corrected. Xiaomi Pocophone F1 gains notification LED. Sony Xperia XZ2,
XZ2 Compact and XZ3 gains display, touchscreen, gpu and remoteproc
support. OnePlus 6 and 6T gains hall sensor.
GPU clock controller and remoteproc nodes are added for SM6115. CPU
clock are defined to come from CPUfreq. Board-specific USB-properties
are moved out of the SoC dtsi.
On SM6375 L3 scaling, IMEM, RMTFS, RPM sleep stats, Tsens, modem
remoteproc and WiFi nodes are added. Tsens thermal zones are defined and additional low power states
are defined. Sony Xperia 10 IV gains volume down key support.
On SM8150 another UART is introduced, to be used by GNSS on the SA8155
ADP. Support for the Flash LED block in PM8150L is added.
On SM8250 TPDM MM and PRNG is defined, MHI region is added to PCIe node.
A few bug fixes are introduced after Devicetree validation.
The DisplayPort controller on both SM8350 and SM8450 is defined and the
related QMP instance is transitioned to the USB3/DP combo variant. IMEM
and PIL info is introduced, for post mortem debugging of remoteprocs. On
the HDK PMIC GLINK is enabled and role switch is enabled. Some audio
resources are corrected.
A typo in the USB role property of the Microsoft Surface is corrected,
thanks to DeviceTree validation.
PCIe controllers and PHYs descriptions are corrected, and pinctrl state
definitions are moved from the soc to the board definition. BWMON
compatibles are corrected. PM8550B gains the definition of the eUSB2
repeater and this is enabled on the MTP. PMIC GLINK is also defined for
the MTP and connected to DWC3, for role switching support.
In addition to this, a range of cleanups based on Devicetree validation
is introduced.
A few clock bindings are introduced, from topic-branches shared with the
clock tree, to aid introduction of references to these.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmQ0QQEVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3F3WgQALGaxeK2rYNfVVR8YMrsjDYow2vq
Uup1AxG2sAGdLBiegf0btiIlw6y+t7pdUuP+elKx3sLrx/UiJfa7/fqdMhfft3Qo
16xhKIHQwokgGyl6hFJg2WTLrbC/qq60rB2YP/aR3pBCovu1nL/jX/9de28jNXUe
FydCDCAfa1Zd3fDdp0uqGWA9mCSDDnlL0UuiP7PIkUFEEkPHdif/a3H1O5y1S+LW
Eq38bJeMoQUYOYx4hYTxzmkCjbZVFEhho2lVyfHLy2fIaGuA4Gm4THnXMu5P9vIL
Q4dNR6/XnquH2G9LcDLIcPWkWg8KkFDNnRQBkIkNZQAUqqY2klY/8sa0aZZJk53f
KD393N/aWUV7tGYynLLc5oluoKLIlFFMdWVdxxR36zP70hu6Q2kGj4NUIB+odMdS
QgJIyBBJ2dafvB5llXGaUXMOFYJYolcoss0EWfCU5jCg2XhxC8Q6mvpF1vAuCTTZ
aueb0RlXxzdTcCy0jkqCl1GsBOuQONtAOnQ8nRE+8ookzLGJ8RBnoUmWUifzxnqe
ueYdGPu2nnmqrbYAJqzr1Y9G7ImsX0V72iwC0wFFL8woZzDPGgEcDIyOaGCI3Hus
P3weJ9WScj6ScRvRTI4EdZL03oaPPsF8zMA8xyXoCzeWtp3wsrtFNbVqAZSEvcAq
a92owWcK+flh9Ckj
=ZyN2
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5d90ACgkQYKtH/8kJ
UifbkRAA0tH8h0ehQRsfgaijE+KNM5IOwi7iszD7NObNG+5Nal5QO6H9CvrEEbgv
4c6qwkC7F+ZN+zTVeKTufqZ6/zkylW+AMzL4UuAl5BxhMMrWzsg1NR1+NlbKssEb
EBbLll7uxohuK79JNjmor/VV+zJX+hOyAhsf6yo6gpYFiJdgrRGwWVFVflNTNQis
mpw5U4SyFNo4lq/HDERuxWbbsTl+VmoCeezCRgolaVkq4RTeMNcIxbm/kJ+t9ela
HNm6mpJWqUUGeNpos5VdCqLApxBQgYmwz1mPHTQfC0V9v8YlVnTTKVmw4lHoGnZp
ADN7iQSqqpsOLjML3+7HfQ8FWTTpj6FbE+vcSTiLjnstv9oDYd2wf9FPzJqcDVTl
MucZVPk75zutakDuHOxizdfSTXPnpyEXnpnEUla6E+BntkB5eCTz45NN9B35gowA
fY437FQ95eY2mV2vpya91rH2Rtw5BJbZW6jsw+WxT29A67LBa+sJrTayDNzYLuUz
GjSb2vmRr2r3WG1jy8QQxVC3R/t4rlqXBnmJ91nHNIgrGl5ExrIEt+IDRsqHlS7T
V1xX4fl9Ge2zfZeoFPFhgIBpPtvEkW5mUKIjRX6EBvRnG9+T8CWuWSnJDuFa6AMZ
kxAhqUojmDO8f1E/BPiHHCP31dfUrMOVor0fu9qu7o8/H/WPo04=
=OcHF
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt
Qualcomm ARM64 updates for v6.4
PCI I/O and MEM ranges are corrected across all targets with PCIe
enabled. Likewise is CPU clocks defined to be provided from CPUfreq for
a wide range of platforms, to satisfy the OPP definitions, and LLCC bank
information is corrected for all relevant platforms.
IPQ5332 gains SMEM, CPUfreq and support for triggering download mode.
The MI01.2 board is introduced.
On MSM8916 WCN compatibles are moved to be defined per board, to avoid
issues when boards rely on the incorrect defaults. Support for Yiming
UZ801 4G modem stick is introduced.
XO clock is defined and fed to RPMCC on MSM8953 and MSM8976, to ensure
clock trees are properly rooted. DSI clocks feeding into gcc are
described on MSM8953.
On MSM8996 the external audio components are moved from the SoC dtsi. A
few DWC3 quirks are added.
On MSM8998 GPIO names are introduced for Sony Xperia XZ Premium, XZ1 and
XZ1 Compact. A numbe of boards have GPIO keys properly marked as
wakeup-source.
The SA8775P platform is extended with CPUfreq, UARTs, I2C controllers,
SPI controllers, SPMI and PMICs, PDC support. The associated PMICs gains
reset and power key support, as well as thermal zones defined. Nodes are
sorted. On top of this the SA8775P Ride board/platform is introduced.
On SC7180 and SC7280 a range of fixes coming from DeviceTree validation are
introduced, some clearing up unused properties, others correcting
errors. A number of Google rev0 boards on SC7180 are dropped, as these
are not considered to be in use by anyone anymore.
On SC8280XP RTC support is introduced and enabled for the CRD and Lenovo
Thinkpad X13s. It gains another UART, upon which Bluetooth is enabled on
the Lenovo ThinkPad X13s. The touchpad definition is altered to attempt
to probe both devices seen in the wild. A number of bug fixes are also
introduced, and the regulator definitions on X13s are corrected.
On SDM845 dynamic power coefficients are improved. BWMON compatible is
corrected. Xiaomi Pocophone F1 gains notification LED. Sony Xperia XZ2,
XZ2 Compact and XZ3 gains display, touchscreen, gpu and remoteproc
support. OnePlus 6 and 6T gains hall sensor.
GPU clock controller and remoteproc nodes are added for SM6115. CPU
clock are defined to come from CPUfreq. Board-specific USB-properties
are moved out of the SoC dtsi.
On SM6375 L3 scaling, IMEM, RMTFS, RPM sleep stats, Tsens, modem
remoteproc and WiFi nodes are added. Tsens thermal zones are defined and additional low power states
are defined. Sony Xperia 10 IV gains volume down key support.
On SM8150 another UART is introduced, to be used by GNSS on the SA8155
ADP. Support for the Flash LED block in PM8150L is added.
On SM8250 TPDM MM and PRNG is defined, MHI region is added to PCIe node.
A few bug fixes are introduced after Devicetree validation.
The DisplayPort controller on both SM8350 and SM8450 is defined and the
related QMP instance is transitioned to the USB3/DP combo variant. IMEM
and PIL info is introduced, for post mortem debugging of remoteprocs. On
the HDK PMIC GLINK is enabled and role switch is enabled. Some audio
resources are corrected.
A typo in the USB role property of the Microsoft Surface is corrected,
thanks to DeviceTree validation.
PCIe controllers and PHYs descriptions are corrected, and pinctrl state
definitions are moved from the soc to the board definition. BWMON
compatibles are corrected. PM8550B gains the definition of the eUSB2
repeater and this is enabled on the MTP. PMIC GLINK is also defined for
the MTP and connected to DWC3, for role switching support.
In addition to this, a range of cleanups based on Devicetree validation
is introduced.
A few clock bindings are introduced, from topic-branches shared with the
clock tree, to aid introduction of references to these.
* tag 'qcom-arm64-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (256 commits)
arm64: dts: qcom: sc8280xp-x13s: Add bluetooth
arm64: dts: qcom: sc8280xp: Define uart2
arm64: dts: qcom: sc8280xp: Add "mhi" region to the PCIe nodes
arm64: dts: qcom: sm8250: Add "mhi" region to the PCIe nodes
arm64: dts: qcom: sdm845: Add "mhi" region to the PCIe nodes
arm64: dts: qcom: sa8775p-ride: set gpio-line-names for PMIC GPIOs
arm64: dts: qcom: sa8775p: add PMIC GPIO controller nodes
arm64: dts: qcom: sa8775p: pmic: add thermal zones
arm64: dts: qcom: sa8775p: pmic: add support for the pmm8654 RESIN input
arm64: dts: qcom: sa8775p: pmic: add the power key
arm64: dts: qcom: sa8775p: add the Power On device node
arm64: dts: qcom: sa8775p: add support for the on-board PMICs
arm64: dts: qcom: sa8775p: add the spmi node
arm64: dts: qcom: sa8775p: add the pdc node
arm64: dts: qcom: sa8775p: sort soc nodes by reg property
arm64: dts: qcom: sa8775p: pad reg properties to 8 digits
arm64: dts: qcom: sc8280xp: correct Soundwire wakeup interrupt name
arm64: dts: qcom: sdm845-tama: Enable GPI_DMA0/1
arm64: dts: qcom: sdm845-tama: Enable GPU
arm64: dts: qcom: sdm845-tama: Enable remoteprocs
...
Link: https://lore.kernel.org/r/20230410170233.5931-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Add PWM support for the R-Car H1 and H2 SoCs,
- Add slide switch and I2C support for the Marzen development board,
- Add SCI (serial) and Camera support for the RZ/G2L SoC and the
RZ/G2L SMARC EVK development board,
- Add IOMMU support for the R-Car V4H SoC,
- Miscellaneous fixes and improvements.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCZDO9eAAKCRCKwlD9ZEnx
cDqrAP4wBrYlD0ih3wMZbcrHAZpIfhLLLlUBDT0JfYYy/mSGXwEA69C5A00Gx47o
R4eLM6rSfPKw4KNJcLFwO5eqMsPzEQs=
=uYv8
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5daMACgkQYKtH/8kJ
UicMmw/9EPKDe59WyKOze/gv1OYbAChIIhU6ofuLe8ot3d5W9aqUq9ua3WFnXj4l
yA96A8GElmTWLa1XXc6tl25HqAOVuacOTyrSWSfzknWj2w2AY8sssw1BCunxyZLK
EG+FNakdYJsTDYUisG1dYFAe8uY/bcagnaJYOVX/+ofX8IaTEddC5pRSv7ytgHZt
uK/Jk/S4rAK2XZPRU+xtZgbbD3fmBgVEbofWhYMalZJ5hBFLUfSSBt42LBKFg91J
MfDpzfy8gz58G0B9Aoq80WLHdx15MHRdMwT8zmHaPYxOMiufxKCKztfpU9G6aktl
PZ7RQgSelL7ZCrfJpJRi5Nd3YrcnNKC2MQulFCbs4BMfF5oLeyjxEsSxQIPum4rq
T/yEgsNGK9VgWhYM6as80d+kLFQhEF3DQXcJK3RdpXemS2Yj2s3MXcsQrjQ8zQYY
GMH999L0VpC0dgpB5SGWZyBRTX+h8Y0X+tg4OrkWYSVKkShGi6WJ/3GdqyNK2D3o
ic8sx+IFrOKDr/mmbcJ2RiYdo16wQp6c/UkZ97Lq9vaXVi4lA6C8oymCEMpdsvbm
bvSGI11hGEGsUOA2axbx7XxmkFfBPqUbiNgRWx1YT0u4ILYxRtL+IrFtYKcWcdHM
Z5nzWC5Xv/XEvvnNYE/9NQWBEA2MEQG23AwwYvNYtYGwv48PO5w=
=UIZB
-----END PGP SIGNATURE-----
Merge tag 'renesas-dts-for-v6.4-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt
Renesas DTS updates for v6.4 (take two)
- Add PWM support for the R-Car H1 and H2 SoCs,
- Add slide switch and I2C support for the Marzen development board,
- Add SCI (serial) and Camera support for the RZ/G2L SoC and the
RZ/G2L SMARC EVK development board,
- Add IOMMU support for the R-Car V4H SoC,
- Miscellaneous fixes and improvements.
* tag 'renesas-dts-for-v6.4-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: dts: renesas: r8a779a0: Revise renesas,ipmmu-main
arm64: dts: renesas: falcon-csi-dsi: Set bus-type for MAX96712
arm64: dts: renesas: r8a779g0: Add iommus to MMC node
arm64: dts: renesas: r8a779g0: Add iommus to DMAC nodes
arm64: dts: renesas: r8a779g0: Add IPMMU nodes
arm64: dts: renesas: r8a779f0: Revise renesas,ipmmu-main
arm64: dts: renesas: rzg2l-smarc: Enable CRU, CSI support
arm64: dts: renesas: r9a07g044: Add CSI and CRU nodes
arm64: dts: renesas: r9a07g044: Enable SCI0 using DT overlay
ARM: dts: r8a7790: Add PWM device nodes
ARM: dts: r8a7790: Add TPU device node
ARM: dts: marzen: Enable I2C support
ARM: dts: marzen: Add slide switches
ARM: dts: r8a7779: Add PWM support
dt-bindings: clock: r8a7779: Add PWM module clock
arm64: dts: renesas: rzg2l: Add clock-names and reset-names to DMAC nodes
Link: https://lore.kernel.org/r/cover.1681113117.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- New board device trees: Apalis quadmax, DH electronics i.MX8M Plus
DHCOM and PDK3, Data Modul i.MX8M Plus eDM SBC, Colibri Aster and
Iris, etc.
- Add FlexSPI, BBNSM and TPM PWM devices for i.MX93 SoC.
- A series of imx8mq-librem5 udpates which includes minor fixes,
magnetometer, CSI/camera support, and powersaving improvements.
- Add Cadence USB3 support for i.MX8QXP.
- Add FlexCAN support for i.MX8QXP and i.MX8QM.
- Add UART DMA support for i.MX8MQ.
- Add GPT devices for i.MX8MP.
- Add VPU decoder and encoder support for i.MX8QM.
- Add display pipeline and PCIe EP support for i.MX8M family SoCs.
- A series from Peng Fan updating various i.MX8M device trees to pinctrl
nodes match DT schema.
- A series from Philippe Schenker improving colibri-imx8x device trees
in various aspects.
- Other random device tree updates.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmQxOOAUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM6mqwf8CYJZwCv3TEUHtV8U8wKnQddPPeyo
M62FQYTS2NBcLNPv3wqus3QaED2AmuY9ibFG/R7CBpNgs89QtTJfGbGrQnFea9Kt
ylXVHj4OtF0edAG1YpRfg+1kWx1If61OO1yuVGxbGZEwCgVMkBVQfNgTT+awZWOX
CCAe9m6TM7mNWMPoIrymaUuTFQDkG9WisSyafAdQUBVRaIUpYzWVkBLK130mpxLo
/J4jYv58beoZmd4eh942c5Ui8SYg0bGmxNdrtsvsmE7IWRkB77JxFgVrh6OokS70
c+zBU+9epWBRW4d7J4QCHCNhlXqKPF6XHuxeW8Q0OxvC/sLCSTK2QD7puQ==
=aFxm
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5cToACgkQYKtH/8kJ
Uid09g//YYAY/H/f7j7Fz8K3+bS9Yg57RKK1MrxRv63B/YHKECCrBAp3xnwA4sRO
ZV+MyqXOfHGdQSpYhUEzWkI2so2mA6AGRz8T2uCJuTB1ktoWe3XEJUqjJCRMZaq2
5YIWTi2Oct4fX/qS1fC5UqFsrM77TGA3+7NxI5SDgCMmdzoNuNXjiOA1UxfBnOhF
v2kOt9yC41eWogBSxiiE97f7DE+lYw0DvdyDhKe+RkpqhkK3aLLhlXUI85TJVOhr
5hbXg/nWKK0wORXI3i3vPy+IFOjt9tKniLZX7CMpG/+F9xkKMbgwFzYhJjeBm2LL
27gkNqUGNDkWBg9yKHbvUA9iucTzvZnowrjV+Tigm2VFIMMAZX448yc9mIvqXWjc
Oimo2M/7JiaPa6ernF4fmiLPkU+4OoPCeVaW7tEBxrJh318GxanzOd/4LxGLhpxB
CBoW8UN/Jt0Fd5NQgkTVAiGgZzZV9kWiEeVY4sMHvWBxh6BYs0TvLlMd9uzxu226
bzKnO19X1Q49sUy6bCZsIpXRoVkRrFNgTm5QtEw4IoHSGDPZpTHJmGQkcdGFfnHM
Wo0ESSO/SeP65vl+vW669XyQUcEd12SQYWOMhIWz/cUI0o30ePO2sGclNmbRHyeh
rNWyvnjCnpEqw1ntD98HdZImlwFGq0zJbkhPz76Gzhl7CJ94+/8=
=8OCT
-----END PGP SIGNATURE-----
Merge tag 'imx-dt64-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/dt
i.MX arm64 device tree changes for 6.4:
- New board device trees: Apalis quadmax, DH electronics i.MX8M Plus
DHCOM and PDK3, Data Modul i.MX8M Plus eDM SBC, Colibri Aster and
Iris, etc.
- Add FlexSPI, BBNSM and TPM PWM devices for i.MX93 SoC.
- A series of imx8mq-librem5 udpates which includes minor fixes,
magnetometer, CSI/camera support, and powersaving improvements.
- Add Cadence USB3 support for i.MX8QXP.
- Add FlexCAN support for i.MX8QXP and i.MX8QM.
- Add UART DMA support for i.MX8MQ.
- Add GPT devices for i.MX8MP.
- Add VPU decoder and encoder support for i.MX8QM.
- Add display pipeline and PCIe EP support for i.MX8M family SoCs.
- A series from Peng Fan updating various i.MX8M device trees to pinctrl
nodes match DT schema.
- A series from Philippe Schenker improving colibri-imx8x device trees
in various aspects.
- Other random device tree updates.
* tag 'imx-dt64-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: (87 commits)
arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC
arm64: dts: imx8mp: Add display pipeline components
arm64: dts: imx8mn: Add display pipeline components
arm64: dts: imx8mm: Add display pipeline components
arm64: dts: freescale: imx8qxp-mek: enable cadence usb3
arm64: dts: imx8qxp: add cadence usb3 support
arm64: dts: imx8mq-librem5: add missing #clock-cells
arm64: dts: imx8mm-prt8mm: update pinctrl to match dtschema
arm64: dts: imx8mn-bsh-smm: update pinctrl to match dtschema
arm64: dts: imx8mm-emcon: update pinctrl to match dtschema
arm64: dts: imx8mq-librem5: update pinctrl to match dtschema
arm64: dts: imx8mm-ddr4-evk: update gpmi pinctrl to match dtschema
arm64: dts: imx8mn-evk: update i2c pinctrl to match dtschema
arm64: dts: imx8mp: Add GPT blocks
arm64: dts: imx8-apalis-v1.1: drop ci-disable-lpm
arm64: dts: imx8dxl: drop clocks from scu clock controller
arm64: dts: imx8mp: verdin-yavia: drop disable-over-current
arm64: dts: imx8mq: tqma8mq-mba8mx: drop disable-over-current
arm64: dts: imx8mp: Add support for DH electronics i.MX8M Plus DHCOM and PDK3
arm64: dts: colibri-imx8x: Add iris v2 carrier board
...
Link: https://lore.kernel.org/r/20230408101928.280271-5-shawnguo@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
'Unknown kernel command line parameters "nokaslr", will be passed to
user space' message is noticed in the dmesg when nokaslr is passed to
the kernel commandline on ARM64 platform. This is because nokaslr param
is handled by early cpufeature detection infrastructure and the parameter
is never consumed by a kernel param handler. Fix this warning by
providing a dummy kernel param handler for nokaslr.
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Link: https://lore.kernel.org/r/20230412043258.397455-1-quic_pkondeti@quicinc.com
Signed-off-by: Will Deacon <will@kernel.org>
This adds support for the Jetson Orin NX and includes updates for Jetson
AGX Orin (audio codec, USB Type-C support).
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmQuvmMTHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zobhBD/91ilxKV1gNw07qyoLk+pp7vw/yi5p9
iIXCE5P/sPXzWDaVOUaqxk1v7C28IaAqMU1s11nd5oHq5y4pLigb9zslOWn4bFzO
NBA4CrFdXTBX0oquuWYtAsDJQjhKhYrbSjTg6+J92ADSETqWBRabOfAOJH8m1Fu9
2ru+RhzqGftlyc+LGr2UVWLbAuvygTouuIpYJEO8b7ofF7iXHwaL4zRdDqkMgl0k
ML7MijzdjynPD63YmKSYUajsyZILyNl8Vep43+Ae+gfzTL1vTQdzlx9p5Koo89fJ
sa9Pui3vsPGCecaJau7plVLUY7YC0+x+G8lzPF3Ev9yA3ghwvglwHJV7wtkJOF2v
7FsC93GcduSfa74UZ5twT7dEKfJCyOzahtLHNvJPkNAw2RmqsJV5P9jbX6Id6cj+
Ap/dFJVqOQGt6yZXMpqniT46eO3Zb9wFok+jj7kxlnqGMvl6zSRmkGzWPqpgUug5
AnQgzY0+sozoalcpVPt28eYK1i/GtXny+XHPRRMsggWNBDUcY955MBbo1ZvPggmU
ayAZpQ6OlOi+hWb58QIScvpftxwrSpM6wrub9LwhlX+L2CCbia6mvZB0jZM9XvoM
k+zjuNk5qQ01w4mkxCyPu7eGPZtUTrHHmKrN6swCqzuJO6jcFfDOvDhG0RhViO0d
UZC7AVR4a2aWGQ==
=qCDN
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5U6UACgkQYKtH/8kJ
UieYJxAAtZHSqDiiz8wi1VSUUb/v0ibrmakdXzRur9tTYcgyBElJVGS04/DOkMZk
rtkHonO1v/xawzHx74ezqLAHDS3Z/KqbFFQfUAJYNJ8vmrdxJXj62nK0bd7zBtDE
faU5DfsTjfi9qx97hIp+3BjQ4cWvH2Q+KuJpG807fVhdKtDzVFbFx/j5hnEFP7t4
jffy0OtyhF9bKxk0OmhuJLgR0CxPQBLwrRu3+RYu32TbVMl0VOBWGdhYpAh6D/GZ
KHX/xBJi9GYeJBvGvzLwxUJs7UWIMWkR1VPjzTJXRy7p9lm6VUSP9vyHf594snxF
EUx9eTHiC556HvIFhv36sogxMWVHLV0vZcvqjjx5xqXPRs9yGLSBNc+mkaQZAgWz
6rs5fPp46q3agAbKouJ0V5v62cYff0SRo7+r4sCbW7kxQ4qxHW2O2ws05HnXEQfL
Y+0bhTeOQfrq1V1dj/6UMQagVqJGyNeGXDlGwYF2HlQQs5Qt53FCdgvjbnzp5Apn
LwRif+WBTbVgv5kj0tKz3q70WpHfXraNEsImLugweZOqvyrIFim4blAwhU4cfjYw
SQWceP3WYclLkKFDjYLmbQXOl1H/59aGo3gT6d56mJSpS75Z6chFmUMzw/weTZEI
iKFQHhKdsLh9oUFfEIR0fzzyBjb1TU9BTcFiK05TF9ND0rUaACU=
=xfIt
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-6.4-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt
arm64: tegra: Device tree changes for v6.4-rc1
This adds support for the Jetson Orin NX and includes updates for Jetson
AGX Orin (audio codec, USB Type-C support).
* tag 'tegra-for-6.4-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Add vccmq on Jetson TX2
arm64: tegra: Populate USB Type-C Controller for Jetson AGX Orin
arm64: tegra: Audio codec support on Jetson AGX Orin
arm64: tegra: Support Jetson Orin NX reference platform
arm64: tegra: Support Jetson Orin NX
dt-bindings: tegra: Document Jetson Orin NX reference platform
dt-bindings: tegra: Document Jetson Orin NX
arm64: tegra: Add DSU PMUs for Tegra234
arm64: tegra: Drop serial clock-names and reset-names
Link: https://lore.kernel.org/r/20230406124804.970394-6-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
1. Exynos850: add headers with AUD, G3D and HSI clock controller clock
IDs. Add G3D (GPU) clock controller node.
2. Exynos5433: fixes for dtbs_check: move MIPI phy to PMU node.
3. Drop old MSHC aliases (while adding proper mmc-ddr-1_8v which was
selected by the driver based on the MSHC alias) and add generic MMC
aliases in each board. The aliases match known numbering in
the schematics.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmQtH74QHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD13t+EACNzP7QHTq8+ORmxBcvNkujWtKd4XbRgO7O
3ls8EFBRfmBRfBqSN3MdpoDonvBTMFZxuN36XIU+tfCkbpqu8L3Kok6TXHOMiDEx
ZQ1RD6EBQgMiE+FdjXLhdgfmS5wWaLuY04t1nqfDnjKO+3dqzJ4gUQbytSVtDkQ5
l6Pj2kr6V7H2Qc7xvQbVFiRCLZnHNFP5qc38l4eG/sXADaO56JuYjmTEeSYI8V70
bQEIdCalirCyOBO3CzrxgfyEBRmiuNNq8XjcFYAVe5hmsSZos39hHoOQhby+8Ndr
SZP72NKkFsnkPsIcn03CaxiOtdBQFgoFRuzH1KK91QHTEkSek6Y2oebrV1/C150w
SixaNpy6+3JlZMKfujQrI1DaOnJMjv0FwOsfA1SaAPmdqoyjCzjaiA5xfqpNqNjz
8aZJbZo0xgMIABR02HqfmiA+n5fz/IikE/PSUAqipyZI82eo0EgHR2DnYZgXbkrX
PxFC3Wz+9fOc9uEJ4g+5crYSFW6GbP9OMUcxuwfNd/apPErQ54MpQ99eUryxfBfA
z/yC6xdUUO5k8kYEEeDIhZZSXaO90LKlBN2W435wBptS510+aEcg/Ymhd4F4JuWY
PZKpn1+5JHlP8+2JxpR978zYQtjbDNZgECw0ve3D8lX4KxTLREMlUyojCfmTbX+w
zYziW6NTHA==
=GkR1
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5UXQACgkQYKtH/8kJ
UiecJBAAigVcnzJLOg8svBse6juL3tpV3bl0Er7SBTP6FFZkjBzFgEIfzRTgBieU
tD/g2aNur2ivESzhKVBFcVTOn7Rpec3vzZ78MCZOUaADjxWKvBlL5ZGQYXp66Esv
KSAA9AKNQy208l9PyEgZnsp/LVkY8iygnXvUPOAijf+PiR7FI8yon7s1J/W14ZMB
yDeP4vJ+EquHXIm0F068DlzPljX2B+lh9gFPyamSdA4NvGFnuzez+I0z6pY2hKO2
jMXTr6MBk0VbCHUBSTHSXz+h/Ck7ECoeIB/avv04Uu9mDIejPm6w5IPh8GzfiIae
ERvRrj9n+4H+YX8Wpkg9ugDHzy2ma9ZWxM+kP2DlbJ9H4KJk+dieoi+GNEoS2QGf
fINi6v0yfS5+uYEQnHV7sy9JtZy4dyGZ0JVf35tmYS54KmygR/n15dNlUqRVg/cK
z/JtgLKsONisqoqozXZkdf84kJ8U5Bhi2SBycXGcblUOxgu/CQerhJox6GbLcCWH
thQ+ZXsPUT9iDqrFEX9Lkl+wFzTW+jq1k9VyUINnEBhXaygLmKE3vcr80wuEVhO5
GkbbSloGqQKEIWzOO20PiGs0hwIelMG+2YgJ07NPTthL7NVs+oEQAdYMsaXZZCxK
0jUesPJ2sXOMBIIkDg4BL3XqrDaOv8+uxPmac1cUmEMqsiCLnEI=
=kJMa
-----END PGP SIGNATURE-----
Merge tag 'samsung-dt64-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/dt
Samsung DTS ARM64 changes for v6.4
1. Exynos850: add headers with AUD, G3D and HSI clock controller clock
IDs. Add G3D (GPU) clock controller node.
2. Exynos5433: fixes for dtbs_check: move MIPI phy to PMU node.
3. Drop old MSHC aliases (while adding proper mmc-ddr-1_8v which was
selected by the driver based on the MSHC alias) and add generic MMC
aliases in each board. The aliases match known numbering in
the schematics.
* tag 'samsung-dt64-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
arm64: dts: exynos: add mmc aliases
arm64: dts: exynos: drop mshc aliases
arm64: dts: exynos: Add CMU_G3D node for Exynos850 SoC
arm64: dts: exynos: move MIPI phy to PMU node in Exynos5433
dt-bindings: clock: exynos850: Add AUD and HSI main gate clocks
dt-bindings: clock: exynos850: Add Exynos850 CMU_G3D
Link: https://lore.kernel.org/r/20230405080438.156805-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Currently only the first attempt to single-step has any effect. After
that all further stepping remains "stuck" at the same program counter
value.
Refer to the ARM Architecture Reference Manual (ARM DDI 0487E.a) D2.12,
PSTATE.SS=1 should be set at each step before transferring the PE to the
'Active-not-pending' state. The problem here is PSTATE.SS=1 is not set
since the second single-step.
After the first single-step, the PE transferes to the 'Inactive' state,
with PSTATE.SS=0 and MDSCR.SS=1, thus PSTATE.SS won't be set to 1 due to
kernel_active_single_step()=true. Then the PE transferes to the
'Active-pending' state when ERET and returns to the debugger by step
exception.
Before this patch:
==================
Entering kdb (current=0xffff3376039f0000, pid 1) on processor 0 due to Keyboard Entry
[0]kdb>
[0]kdb>
[0]kdb> bp write_sysrq_trigger
Instruction(i) BP #0 at 0xffffa45c13d09290 (write_sysrq_trigger)
is enabled addr at ffffa45c13d09290, hardtype=0 installed=0
[0]kdb> go
$ echo h > /proc/sysrq-trigger
Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to Breakpoint @ 0xffffad651a309290
[1]kdb> ss
Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
[1]kdb> ss
Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
[1]kdb>
After this patch:
=================
Entering kdb (current=0xffff6851c39f0000, pid 1) on processor 0 due to Keyboard Entry
[0]kdb> bp write_sysrq_trigger
Instruction(i) BP #0 at 0xffffc02d2dd09290 (write_sysrq_trigger)
is enabled addr at ffffc02d2dd09290, hardtype=0 installed=0
[0]kdb> go
$ echo h > /proc/sysrq-trigger
Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to Breakpoint @ 0xffffc02d2dd09290
[1]kdb> ss
Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09294
[1]kdb> ss
Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09298
[1]kdb> ss
Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd0929c
[1]kdb>
Fixes: 44679a4f14 ("arm64: KGDB: Add step debugging support")
Co-developed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20230202073148.657746-3-sumit.garg@linaro.org
Signed-off-by: Will Deacon <will@kernel.org>
This enables a range of TLMM pinctrl drivers, needed to boot related
platforms. Multimedia clock drivers for MSM8994 and MSM8998 are enabled
and the MSM8996 is flagged as a module instead of builtin.
The PMIC_GLINK drivers are enabled, providing USB Type-C and battery
support on various platforms, and eUSB2 drivers found on SM8550 are
enabled.
Base drivers for IPQ5332 and IPQ9574 are enabled.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmQ0MmUVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FkGsP/2PH493n6sB3fFCOR5oMO1Y6aEcg
0/4SLGZzdxkS+wc2MshL8IUixh0fdgQZaav0dvwyMS6PExki303bocQeGp0WMmrH
G+30i2g5dMxRyKSAtsDXoVLOBe34usKsy6xkfGsvpDUHT2b9j9pXXw95a69XS3iZ
gIFXB0DVwrpv2U9LJD+RjlHfH2aS3IMFbEa5eX+2TgPfNOCw+zNcdjbd83ofvPIV
4n1S4ENRgJuCzHMA4K9DZXTtDmHLm+3byt8ZE75zQ61JGDIz9pK88owvfF9FNKMw
mbiOugkGpRkU4/wWkS+ZjPLfHBGJcedsA90NH3lyduJ5Rk+8nNt2R12K8X2ucohX
2exx+zV6CYjDQnqakZ6T4Sd9iAMKkigkSIaeINKmMvFl2LplAmLNrvHt18F7Amcm
JtMJx/J7+uJ0AbTI39DVA9KV1KBmq3TJzBVu23S8Yr3UhzMEYqeaYUmXPSquqJKG
luQU48rcxXIWA0akGIw36aNiST40ZZeUhVGFH3AMtJfzcYdNUsFMXvbOQ8mpsbre
VnE/JWRIK/KakQQni4kF9apH53HDHICzdeu5bx0s1hKiKzENMX99bJMA1h5hecO5
vob5TfX6EWt8u7V03VW6t0IoLsbES/XJOZd2wys+BDVK7VCpWJKzvVRH+9dqcFDt
hKkbymrKRrjuQqJy
=9aIE
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5P1cACgkQYKtH/8kJ
Uiffsw/9EWlWc2xp1AuFLSChSMXtb3uOwL/6W0kMEI3ZgEXvgxLjFX/3cR7C3OzB
hvFrdrL0JJoZBxQVN7b6p19xzUEQFTjNf35EjjNFZXYNV607CTCrCTz3ULSXVFBB
UcXB5vqRh9+1C4w2sLVkEgLO9sTzIPxvYHsFhYSpK91eqOvT7W/drjRR1DE9oSTc
wdIK204L3d8rnDaVfhSM+Hkj+kZoqtE4oNodM3IN2GQ2l2lioOFJtlPHMQtX3vK2
uG30LUrx7E77YAxMLEd9FwL0J9WePanij7Ryxp+kAdAstLkzQhB3Y36DZ7sxPtn1
7BJq8gbiCJg+MJE8XleKstfJfo3C9NGpzXE6JYlNq0ME1NcPZKUo4QLs9NSEODPj
G08ysj9xNBxPd6MQELn91v/aLiOyhFeV4dM5ZHj1fvb/zpJ5uPB8mWFEAexHmfHw
zLncYXhCLeI87tz6YjORoS+M3VPB2WZ3Db+gVEjenvSj0Z8xV574m8VswEJNYuy0
Rr8sMsadfGf5kqsSIqQ5HWfII+QKTDiACJMjk9uAnbimz8RdS7h4evktS/BdJl+a
y4dsmXPkeIJUNseWqVgEDUNQo5+K3z2Z3JUMYxx+N4bI+ufsR4KlhD7Bl+nFdZsv
Osf58MOOA2YXHgJ1hnF6ZRA6pvXXdaMJu3mG4iG3UGEMtfvyZ+Q=
=slvv
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/defconfig
Qualcomm ARM64 defconfig updates for v6.4
This enables a range of TLMM pinctrl drivers, needed to boot related
platforms. Multimedia clock drivers for MSM8994 and MSM8998 are enabled
and the MSM8996 is flagged as a module instead of builtin.
The PMIC_GLINK drivers are enabled, providing USB Type-C and battery
support on various platforms, and eUSB2 drivers found on SM8550 are
enabled.
Base drivers for IPQ5332 and IPQ9574 are enabled.
* tag 'qcom-arm64-defconfig-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: Enable IPQ9574 SoC base configs
arm64: defconfig: remove duplicate TYPEC_UCSI & QCOM_PMIC_GLINK
arm64: defconfig: add PMIC GLINK modules
arm64: defconfig: enable Qualcomm pin controller drivers
arm64: defconfig: Enable qcom msm899{4,8} clk drivers
arm64: defconfig: Switch msm8996 clk drivers to module
arm64: defconfig: Enable QCOM eUSB2 SNPS PHY and repeater
arm64: defconfig: Enable IPQ5332 SoC base configs
Link: https://lore.kernel.org/r/20230410155955.5329-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The GPIO polarity of the WSA881x shutdown GPIO was inconsistent and had
to be corrected in the driver, this fixes the polarity in the DeviceTree
for QRB5165 RB5, SM8250 MTP, Samsung Galaxy Book 2 and Lenovo Yoga C630.
The recent rearrangement of nodes among the IPQ8074 accidentally enabled
the PCIe PHYs, rather than the PCIe controllers. This is being
corrected, to restore PCIe functionality.
PMK8280 PON node has the wrong compatible, which recently caused the
driver to stop probing. This is corrected and the required "pbs" region
is added.
With support for HBR3 introduced, it's noted that SC7280 Herobrine
devices are having trouble running at this rate. This drops the claim
that it's supported, until further analysis can be done.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmQ0LU8VHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3Fa+wP/23+62lBn+5sfsUMo5k/ajYel0Ug
sfqMS7PDvTPG3AsVhk1R95NrKWb9eWmkpvkwVKsBHD75BeRkuDovIx9yxSLSDZm2
yWlV514AOLWlhgBu75XzOIDy/J9BQccZPmkBHPJY2I9vpnvlhWnQhaPx4tKgQM8T
5qKuQUf2Q1sQy/QDcbOrMEpHCBHl+Zm11ffmnFosXtVsF0xEzcGyHcKwCOMSaxg1
KVxeK0wS3Mt09D4SiPwVNaMA+c0vcexp2jpySoQBMbEmbYOZr3DEU+b5lyZDQqOi
odMwF4EhMHaGvUCRwM+c4GgdcdXP8IT4eex9ZjdgYblzJsAUfdpFQ5NBB4PeoHPt
9GOp1n+s4+L3pVm9oyeqUDAUNhE3X6PinOfEScwtgFnQAob45k+6vznVgWt66Apg
uZAXRE1kONxtJO7bR8hzH+NH395mtb18lHh1MF09KdIR48wl8bK2f91yP0NkSTY8
N4mKcdy9GwBAmTK3FpEmExOWfmwq0EXdeV2j2RdrVTGNBvTuX9nzpKHUdckk77Ay
sOS5KfUANAHy/7UIOZHwerPKImRyo+y7gZ8kRcihtUgGOXaESeT1s1KPsTUE2ZqX
xWuJWRxYizPHdn809iEr5jgAHOAZlKh5RsJ6QQijY1XKNwNLU5/8iLb61x55PbHv
fnvqlKTO04pDSWD9
=3Uaf
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5PpEACgkQYKtH/8kJ
Uic7Vw/8CTiwm+gErIrED6Wm7eCNkzvENkruXboy5437tyrPsnd68sJ+KFs7lznz
0cXSA06bGKp6rj/i1nodfwO8A0PtEl+RAtCaRuesCI8hQRfkF9o6BOEjpmQ4mYbn
09nr0ehIatVdwl+RxFn9GZEBQT4yPIt8cTjjgT/zyxUsomYJjDv6dl9iODyX8TBY
w3J2VInSUW1GRrlf+GD7XPxbIHhHl7tqWG1neBENQirWb7N0xjDuq2X7absWyzgt
TaPaKYiaqr9X5cE1cfDff+RDoBVZRdtG5H7Gs1u28UaVvmziP04oCxgD8L5cHbX5
niT8cq0d0+f367o+B9WXfcqJXHk/0q3clWP+Ad5q6Bt7HhAkfxY5eezYUMgoDpN4
3+fRrdBJBVK7e2OobxK8+tUt5Zu97zIrNL1b0k9+RkauhBL1efuOQ/tAfh4AY4LR
tguyJ6RBIneNYlAWsWPW7f4TpkR/2XmnFYityjFMLLj75rVK2oC+q1kYU/4/Un6a
Z9G20Uotr3YXThGQJasZSwh+R0maymIEN7pugg9mrImC5zvGOUXA1DC+6MqdLmd1
ocqSr3a0p6jRe9t0xSBxS8YtFT33zU9pevOTnIIYrQhyQ1xL8DFXjmoEFbuQdvWG
Ks2x83/F5OefLoGYXG5Q/K10eKmodaWsuyPsSePOkOTo4VWZEoE=
=ikZD
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-fixes-for-6.3-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
A few more Qualcomm ARM64 DeviceTree fixes for 6.3
The GPIO polarity of the WSA881x shutdown GPIO was inconsistent and had
to be corrected in the driver, this fixes the polarity in the DeviceTree
for QRB5165 RB5, SM8250 MTP, Samsung Galaxy Book 2 and Lenovo Yoga C630.
The recent rearrangement of nodes among the IPQ8074 accidentally enabled
the PCIe PHYs, rather than the PCIe controllers. This is being
corrected, to restore PCIe functionality.
PMK8280 PON node has the wrong compatible, which recently caused the
driver to stop probing. This is corrected and the required "pbs" region
is added.
With support for HBR3 introduced, it's noted that SC7280 Herobrine
devices are having trouble running at this rate. This drops the claim
that it's supported, until further analysis can be done.
* tag 'qcom-arm64-fixes-for-6.3-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: sc7280: remove hbr3 support on herobrine boards
arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and registers
arm64: dts: qcom: ipq8074-hk10: enable QMP device, not the PHY node
arm64: dts: qcom: ipq8074-hk01: enable QMP device, not the PHY node
arm64: dts: qcom: qrb5165-rb5: Use proper WSA881x shutdown GPIO polarity
arm64: dts: qcom: sm8250-mtp: Use proper WSA881x shutdown GPIO polarity
arm64: dts: qcom: sdm850-samsung-w737: Use proper WSA881x shutdown GPIO polarity
arm64: dts: qcom: sdm850-lenovo-yoga-c630: Use proper WSA881x shutdown GPIO polarity
Link: https://lore.kernel.org/r/20230410153850.4752-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
missing 32k clock definition for Anbric xx3 devices, missing cache-levels
for rk3588, fixed rk3326-board display supplies and more dt-schema fixes.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmQx/6UQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgYMiB/45skI/LcajSjuqIJpAC+cDeCs/IaQb6aev
4fnwBRYgb836JvThTGeOn4KRe2avnZMfyjn3IlkHhYBHtLukS8jcuNuU+T+oD1/n
Yss63kUSbMCvNl13uCSz/dqsaFZJ1x8hHth0b19PlGWnnBgtzWWWScr371m+PsF6
2x2dnteRvQcUyWa8/5Xavgc8bseMds2SiKEc9Y58MTwRVL/pqfh9AFJhsWRJYFsN
x0SU+Gwopg2qW+Mfdm6DOK1m08Vu6Uaw1zftF06/oAnDqvYMiVSWfsFIpW5eEi/T
kb5ovzTTDwnLz/n8jkG1ldB7hQY362NQjyIc/GoUab/03yxyFE63
=JS4f
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmQ5PlAACgkQYKtH/8kJ
UifHPRAAwF4jqjWejgzFnHsB7RPmjvUtvuobU0gmI25HIjKnWLdcuS4IFXWvFgLU
gxc1oQS1m4C7eM8ceI/jGR3oDZfhKXCIrpif9Tg+LxtmwRaeo3tbpasPANwiO+Eq
BI6LssLFStBblwwaaMzC1E/8fCdBsZYVbQe4LqsJmzb9hOvFCih4At1YFHKQXcHM
L+1sCdpKMo/f/AQ3sjS3kEYnFwrIYdskxImHXmYkYe2e1OMkXSQcWjz958A7GPB1
kdm5yMPARR8FZxY9RZBf6QLg3xnIc/OqraeHYCjpFLs+gDGGoEMGwwBW5u3/JJmE
SLTq2EYYf6szdVh156zjfMtCFCIM51BXoWwlB3swhWI80WD87lzrKzYYRbW5H6jp
5SIW74a8vR2OxOKyQu00Qb8S0SsTJF5Ord9EImYsm6rXpQnSs894kp18zNjmjUDh
FLxNhMMuY8aiwbypYUm4YRFN9BJJth3SKLXIyP1xxBEpN3IIeQSIXeD9ZoA+sc6e
OdEREqMwQV9xPq84JQLsxTqjcSCwO1MJECqwNvKj07w0qdaIMgDAgirLCTXSPJPh
b8b2p07Dpb5wFKw/FwGSBuvi3DEzSLhK7zbJzky8zNhmWNAx0VS7gR/koFQDGxR0
gNcVU5vPB2ujvBdW76MegqynP2UowsGdD3Sy3KlB/FAZ+LTGMGY=
=Yjl8
-----END PGP SIGNATURE-----
Merge tag 'v6.3-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes
Lower sd card speeds for two boards to make them run more reliable,
missing 32k clock definition for Anbric xx3 devices, missing cache-levels
for rk3588, fixed rk3326-board display supplies and more dt-schema fixes.
* tag 'v6.3-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: correct panel supplies on some rk3326 boards
arm64: dts: rockchip: use just "port" in panel on RockPro64
arm64: dts: rockchip: use just "port" in panel on Pinebook Pro
arm64: dts: rockchip: Remove non-existing pwm-delay-us property
arm64: dts: rockchip: Add clk_rtc_32k to Anbernic xx3 Devices
arm64: dts: rockchip: add rk3588 cache level information
arm64: dts: rockchip: Lower SD card speed on rk3399 Pinebook Pro
arm64: dts: rockchip: Lower sd speed on rk3566-soquartz
ARM: dts: rockchip: fix a typo error for rk3288 spdif node
arm64: dts: rockchip: Fix rk3399 GICv3 ITS node name
Link: https://lore.kernel.org/r/10559306.CDJkKcVGEf@phil
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
__kvm_vcpu_run_vhe() end on VHE with an isb(). However, this
function is only reachable via kvm_call_hyp_ret(), which already
contains an isb() in order to mimick the behaviour of nVHE and
provide a context synchronisation event.
We thus have two isb()s back to back, which is one too many.
Drop the first one and solely rely on the one in the helper.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
Contrary to nVHE, VHE is a lot easier when it comes to dealing
with speculative page table walks started at EL1. As we only change
EL1&0 translation regime when context-switching, we already benefit
from the effect of the DSB that sits in the context switch code.
We only need to take care of it in the NV case, where we can
flip between between two EL1 contexts (one of them being the virtual
EL2) without a context switch.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
We rely on the presence of a DSB at the end of kvm_flush_dcache_to_poc()
that, on top of ensuring completion of the cache clean, also covers
the speculative page table walk started from EL1.
Document this dependency.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
A TLBI from EL2 impacting EL1 involves messing with the EL1&0
translation regime, and the page table walker may still be
performing speculative walks.
Piggyback on the existing DSBs to always have a DSB ISH that
will synchronise all load/store operations that the PTW may
still have.
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Not all that quiet given spring celebrations, but "current" fixes
are thinning out, which is encouraging. One outstanding regression
in the mlx5 driver when using old FW, not blocking but we're pushing
for a fix.
Current release - new code bugs:
- eth: enetc: workaround for unresponsive pMAC after receiving
express traffic
Previous releases - regressions:
- rtnetlink: restore RTM_NEW/DELLINK notification behavior,
keep the pid/seq fields 0 for backward compatibility
Previous releases - always broken:
- sctp: fix a potential overflow in sctp_ifwdtsn_skip
- mptcp:
- use mptcp_schedule_work instead of open-coding it and make
the worker check stricter, to avoid scheduling work on closed
sockets
- fix NULL pointer dereference on fastopen early fallback
- skbuff: fix memory corruption due to a race between skb coalescing
and releasing clones confusing page_pool reference counting
- bonding: fix neighbor solicitation validation on backup slaves
- bpf: tcp: use sock_gen_put instead of sock_put in bpf_iter_tcp
- bpf: arm64: fixed a BTI error on returning to patched function
- openvswitch: fix race on port output leading to inf loop
- sfp: initialize sfp->i2c_block_size at sfp allocation to avoid
returning a different errno than expected
- phy: nxp-c45-tja11xx: unregister PTP, purge queues on remove
- Bluetooth: fix printing errors if LE Connection times out
- Bluetooth: assorted UaF, deadlock and data race fixes
- eth: macb: fix memory corruption in extended buffer descriptor mode
Misc:
- adjust the XDP Rx flow hash API to also include the protocol layers
over which the hash was computed
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE6jPA+I1ugmIBA4hXMUZtbf5SIrsFAmQ4ZrsACgkQMUZtbf5S
IruWUQ/9F+HlnHf3Sv08zGlnV++vLaJ/Ld8C2YNYNxRwuoJvcCyikQ/ZfUKdKAoS
kCf0XqFD2SMl8wHpCQBhK4uXvKBdBMx6L6wEp7dbDciGl/+5yihe9opBBXKekWbB
ULRZcZE7RACri/QsXQhD7Y8p530xnYWQXO8ZMjR3vOAWxplJtBDNDnXi7hqtxQpW
Vzwl1ntvD1msmxhvy0UZrgeesL8R3UckFvqYEqnINeyd8E8HB1dAOg899/ZPUbjA
UoEw5VsSBSr9DE7+Fs6uD8trBxQ1CrdRVJjhRhwivHk8/Ro7dIzjcVV30ei3wucz
0RiNvCqypkeLeRrcVlSk8lR5r9FBGvhDMFbcGM8lHnxSc0WB+Sj+2iup4fpTE8/p
VUIvhhzuBuXU4Sc022pm6BL5DBSKdnJRquFq6XCTwnQM6v7fvzu1yWNXsQom8Nbi
1/ZcFdj27FHwMpU0JPZ4PFxT7Ta830UyulVZuyWA+zEzlN7DvW3O7bGQC72GEuID
Xc58D4kVtywzbntFmUjuhXCD/6vvD5WW5orLpMWg5SH9F14prt3C9OFSpTwTTq+W
uPBEslhnhhCPecTNo2iFPLX3bN67n8KDVUWua1AHaqmcK7QFGs0njJGGLpFdHMll
SuNgrNrtQE9EHH8XL6VbSD2zf35ZfoKVg6qvL3oeLzXkGkZrnls=
=W+J2
-----END PGP SIGNATURE-----
Merge tag 'net-6.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from bpf, and bluetooth.
Not all that quiet given spring celebrations, but "current" fixes are
thinning out, which is encouraging. One outstanding regression in the
mlx5 driver when using old FW, not blocking but we're pushing for a
fix.
Current release - new code bugs:
- eth: enetc: workaround for unresponsive pMAC after receiving
express traffic
Previous releases - regressions:
- rtnetlink: restore RTM_NEW/DELLINK notification behavior, keep the
pid/seq fields 0 for backward compatibility
Previous releases - always broken:
- sctp: fix a potential overflow in sctp_ifwdtsn_skip
- mptcp:
- use mptcp_schedule_work instead of open-coding it and make the
worker check stricter, to avoid scheduling work on closed
sockets
- fix NULL pointer dereference on fastopen early fallback
- skbuff: fix memory corruption due to a race between skb coalescing
and releasing clones confusing page_pool reference counting
- bonding: fix neighbor solicitation validation on backup slaves
- bpf: tcp: use sock_gen_put instead of sock_put in bpf_iter_tcp
- bpf: arm64: fixed a BTI error on returning to patched function
- openvswitch: fix race on port output leading to inf loop
- sfp: initialize sfp->i2c_block_size at sfp allocation to avoid
returning a different errno than expected
- phy: nxp-c45-tja11xx: unregister PTP, purge queues on remove
- Bluetooth: fix printing errors if LE Connection times out
- Bluetooth: assorted UaF, deadlock and data race fixes
- eth: macb: fix memory corruption in extended buffer descriptor mode
Misc:
- adjust the XDP Rx flow hash API to also include the protocol layers
over which the hash was computed"
* tag 'net-6.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (50 commits)
selftests/bpf: Adjust bpf_xdp_metadata_rx_hash for new arg
mlx4: bpf_xdp_metadata_rx_hash add xdp rss hash type
veth: bpf_xdp_metadata_rx_hash add xdp rss hash type
mlx5: bpf_xdp_metadata_rx_hash add xdp rss hash type
xdp: rss hash types representation
selftests/bpf: xdp_hw_metadata remove bpf_printk and add counters
skbuff: Fix a race between coalescing and releasing SKBs
net: macb: fix a memory corruption in extended buffer descriptor mode
selftests: add the missing CONFIG_IP_SCTP in net config
udp6: fix potential access to stale information
selftests: openvswitch: adjust datapath NL message declaration
selftests: mptcp: userspace pm: uniform verify events
mptcp: fix NULL pointer dereference on fastopen early fallback
mptcp: stricter state check in mptcp_worker
mptcp: use mptcp_schedule_work instead of open-coding it
net: enetc: workaround for unresponsive pMAC after receiving express traffic
sctp: fix a potential overflow in sctp_ifwdtsn_skip
net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()
rtnetlink: Restore RTM_NEW/DELLINK notification behavior
net: ti/cpsw: Add explicit platform_device.h and of_platform.h includes
...
When CNTPOFF isn't implemented and that we have a non-zero counter
offset, CNTPCT and CNTPCTSS are trapped. We properly handle the
former, but not the latter, as it is not present in the sysreg
table (despite being actually handled in the code). Bummer.
Just populate the cp15_64 table with the missing register.
Reported-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Now that we use XPACLRI to strip PACs within the kernel, the
ptrauth_user_pac_mask() and ptrauth_kernel_pac_mask() definitions no
longer need to live in <asm/compiler.h>.
Move them to <asm/pointer_auth.h>, and ensure that this header is
included where they are used.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20230412160134.306148-4-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Currently we strip the PAC from pointers using C code, which requires
generating bitmasks, and conditionally clearing/setting bits depending
on bit 55. We can do better by using XPACLRI directly.
When the logic was originally written to strip PACs from user pointers,
contemporary toolchains used for the kernel had assemblers which were
unaware of the PAC instructions. As stripping the PAC from userspace
pointers required unconditional clearing of a fixed set of bits (which
could be performed with a single instruction), it was simpler to
implement the masking in C than it was to make use of XPACI or XPACLRI.
When support for in-kernel pointer authentication was added, the
stripping logic was extended to cover TTBR1 pointers, requiring several
instructions to handle whether to clear/set bits dependent on bit 55 of
the pointer.
This patch simplifies the stripping of PACs by using XPACLRI directly,
as contemporary toolchains do within __builtin_return_address(). This
saves a number of instructions, especially where
__builtin_return_address() does not implicitly strip the PAC but is
heavily used (e.g. with tracepoints). As the kernel might be compiled
with an assembler without knowledge of XPACLRI, it is assembled using
the 'HINT #7' alias, which results in an identical opcode.
At the same time, I've split ptrauth_strip_insn_pac() into
ptrauth_strip_user_insn_pac() and ptrauth_strip_kernel_insn_pac()
helpers so that we can avoid unnecessary PAC stripping when pointer
authentication is not in use in userspace or kernel respectively.
The underlying xpaclri() macro uses inline assembly which clobbers x30.
The clobber causes the compiler to save/restore the original x30 value
in a frame record (protected with PACIASP and AUTIASP when in-kernel
authentication is enabled), so this does not provide a gadget to alter
the return address. Similarly this does not adversely affect unwinding
due to the presence of the frame record.
The ptrauth_user_pac_mask() and ptrauth_kernel_pac_mask() are exported
from the kernel in ptrace and core dumps, so these are retained. A
subsequent patch will move them out of <asm/compiler.h>.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20230412160134.306148-3-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
In old versions of GCC and Clang, __builtin_return_address() did not
strip the PAC. This was not the behaviour we desired, and so we wrapped
this with code to strip the PAC in commit:
689eae42af ("arm64: mask PAC bits of __builtin_return_address")
Since then, both GCC and Clang decided that __builtin_return_address()
*should* strip the PAC, and the existing behaviour was a bug.
GCC was fixed in 11.1.0, with those fixes backported to 10.2.0, 9.4.0,
8.5.0, but not earlier:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891
Clang was fixed in 12.0.0, though this was not backported:
https://reviews.llvm.org/D75044
When using a compiler whose __builtin_return_address() strips the PAC,
our wrapper to strip the PAC is redundant. Similarly, when pointer
authentication is not in use within the kernel pointers will not have a
PAC, and so there's no point stripping those pointers.
To avoid this redundant work, this patch updates the
__builtin_return_address() wrapper to only be used when in-kernel
pointer authentication is configured and the compiler's
__builtin_return_address() does not strip the PAC.
This is a cleanup/optimization, and not a fix that requires backporting.
Stripping a PAC should be an idempotent operation, and so redundantly
stripping the PAC is not harmful.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20230412160134.306148-2-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Prepare for the MM nodes whose dma-ranges(iova range) is 16GB.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230411093144.2690-15-yong.wu@mediatek.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
After commit f1ad5338a4 ("of: Fix "dma-ranges" handling for bus
controllers"), the dma-ranges property is not allowed for
the leaf node. But our iommu/dma-ranges is 16GB, we still expect
separate the 16GB dma-range like:
a) display is in 0 - 4GB;
b) vcodec is in 4GB - 8GB;
c) camera is in 8GB - 12GB.
We can not expect all the masters add a parent node for them,
especial for the existed drivers/nodes.
Thus, we add whole the 16GB dma-ranges in the parent "soc" node.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230411093144.2690-14-yong.wu@mediatek.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
After we add the dma-ranges in the parent "soc" node,
this property is unnecessary for the leaf node.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230411093144.2690-13-yong.wu@mediatek.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
This patch adds an architecture specific early cache level detection
handler for arm64. This is basically the CLIDR_EL1 based detection that
was previously done (only) in init_cache_level().
This is part of a patch series that attempts to further the work in
commit 5944ce092b ("arch_topology: Build cacheinfo from primary CPU").
Previously, in the absence of any DT/ACPI cache info, architecture
specific cache detection and info allocation for secondary CPUs would
happen in non-preemptible context during early CPU initialization and
trigger a "BUG: sleeping function called from invalid context" splat on
an RT kernel.
This patch does not solve the problem completely for RT kernels. It
relies on the assumption that on most systems, the CPUs are symmetrical
and therefore have the same number of cache leaves. The cacheinfo memory
is allocated early (on the primary CPU), relying on the new handler. If
later (when CLIDR_EL1 based detection runs again on the secondary CPU)
the initial assumption proves to be wrong and the CPU has in fact more
leaves, the cacheinfo memory is reallocated, and that still triggers a
splat on an RT kernel.
In other words, asymmetrical CPU systems *must* still provide cacheinfo
data in DT/ACPI to avoid the splat on RT kernels (unless secondary CPUs
happen to have less leaves than the primary CPU). But symmetrical CPU
systems (the majority) can now get away without the additional DT/ACPI
data and rely on CLIDR_EL1 based detection.
Signed-off-by: Radu Rendec <rrendec@redhat.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Link: https://lore.kernel.org/r/20230412185759.755408-3-rrendec@redhat.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
When taking an exception between the EL1&0 translation regime and
the EL2 translation regime, the page table walker is allowed to
complete the walks started from EL0 or EL1 while running at EL2.
It means that altering the system registers that define the EL1&0
translation regime is fraught with danger *unless* we wait for
the completion of such walk with a DSB (R_LFHQG and subsequent
statements in the ARM ARM). We already did the right thing for
other external agents (SPE, TRBE), but not the PTW.
Rework the existing SPE/TRBE synchronisation to include the PTW,
and add the missing DSB on guest exit.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
commit f003277311 ("KVM: arm64: Use config_lock to protect vgic
state") was meant to rectify a longstanding lock ordering issue in KVM
where the kvm->lock is taken while holding vcpu->mutex. As it so
happens, the aforementioned commit introduced yet another locking issue
by acquiring the its_lock before acquiring the config lock.
This is obviously wrong, especially considering that the lock ordering
is well documented in vgic.c. Reshuffle the locks once more to take the
config_lock before the its_lock. While at it, sprinkle in the lockdep
hinting that has become popular as of late to keep lockdep apprised of
our ordering.
Cc: stable@vger.kernel.org
Fixes: f003277311 ("KVM: arm64: Use config_lock to protect vgic state")
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230412062733.988229-1-oliver.upton@linux.dev
This smartphone features a Bosch BMM050 Magnetometer on I2C3: enable
it with the BMM150 binding, as that driver supports BMM050 as well.
For this sensor, there is no interrupt pin;
readings were validated in sysfs.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230412112739.160376-28-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
The PWM at 0x11006000 is the tertiary PWM; unlike PWM0, PWM1, this is
not display specific and can be used as a generic PWM controller.
This node is left disabled as usage is board-specific.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230412112739.160376-21-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
When TIF_SME is clear, fpsimd_restore_current_state will disable
SME trap during ret_to_user, then SME access trap is impossible
in userspace, not SVE.
Besides, fix typo: alocated->allocated.
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230317124915.1263-5-sundongxu3@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Move tpidr2 sigframe allocation from under the checking of
system_supports_sme() to the checking of system_supports_tpidr2().
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230317124915.1263-3-sundongxu3@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Since commit a9d6915859501("arm64/sme: Implement support
for TPIDR2"), We introduced system_supports_tpidr2() for
TPIDR2 handling. Let's use the specific check instead.
No functional changes.
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230317124915.1263-2-sundongxu3@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
SVE and SME are separate features which can be implemented without each
other but currently if the user specifies arm64.nosve then we disable SME
as well as SVE. There is already a separate override for SME so remove the
implicit disablement from the SVE override.
One usecase for this would be testing SME only support on a system which
implements both SVE and SME.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230315-arm64-override-sve-sme-v2-1-bab7593e842b@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
In commit 031495635b ("arm64: Do not defer reserve_crashkernel() for
platforms with no DMA memory zones"), reserve_crashkernel() is called
much earlier in arm64_memblock_init() to avoid causing base apge
mapping on platforms with no DMA meomry zones.
With taking off protection on crashkernel memory region, no need to call
reserve_crashkernel() specially in advance. The deferred invocation of
reserve_crashkernel() in bootmem_init() can cover all cases. So revert
the whole commit now.
Signed-off-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20230407011507.17572-4-bhe@redhat.com
Signed-off-by: Will Deacon <will@kernel.org>
After taking off the protection functions on crashkernel memory region,
there's no need to map crashkernel region with page granularity during
linear mapping.
With this change, the system can make use of block or section mapping
on linear region to largely improve perforcemence during system bootup
and running.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20230407011507.17572-3-bhe@redhat.com
Signed-off-by: Will Deacon <will@kernel.org>
Problem:
=======
On arm64, block and section mapping is supported to build page tables.
However, currently it enforces to take base page mapping for the whole
linear mapping if CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabled and
crashkernel kernel parameter is set. This will cause longer time of the
linear mapping process during bootup and severe performance degradation
during running time.
Root cause:
==========
On arm64, crashkernel reservation relies on knowing the upper limit of
low memory zone because it needs to reserve memory in the zone so that
devices' DMA addressing in kdump kernel can be satisfied. However, the
upper limit of low memory on arm64 is variant. And the upper limit can
only be decided late till bootmem_init() is called [1].
And we need to map the crashkernel region with base page granularity when
doing linear mapping, because kdump needs to protect the crashkernel region
via set_memory_valid(,0) after kdump kernel loading. However, arm64 doesn't
support well on splitting the built block or section mapping due to some
cpu reststriction [2]. And unfortunately, the linear mapping is done before
bootmem_init().
To resolve the above conflict on arm64, the compromise is enforcing to
take base page mapping for the entire linear mapping if crashkernel is
set, and CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabed. Hence
performance is sacrificed.
Solution:
=========
Comparing with the base page mapping for the whole linear region, it's
better to take off the protection on crashkernel memory region for the
time being because the anticipated stamping on crashkernel memory region
could only happen in a chance in one million, while the base page mapping
for the whole linear region is mitigating arm64 systems with crashkernel
set always.
[1]
https://lore.kernel.org/all/YrIIJkhKWSuAqkCx@arm.com/T/#u
[2]
https://lore.kernel.org/linux-arm-kernel/20190911182546.17094-1-nsaenzjulienne@suse.de/T/
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20230407011507.17572-2-bhe@redhat.com
Signed-off-by: Will Deacon <will@kernel.org>
Some generic COMPAT definitions have been consolidated in
asm-generic/compat.h by commit 84a0c977ab
("asm-generic: compat: Cleanup duplicate definitions")
Remove those that are already defined to the same value there from
arm64 asm/compat.h.
Signed-off-by: Teo Couprie Diaz <teo.coupriediaz@arm.com>
Reviewed-by: Guo Ren <guoren@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230314140038.252908-1-teo.coupriediaz@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Today the fixmap code largely maps elements at PAGE_SIZE granularity,
but we special-case the FDT mapping such that it can be mapped with 2M
block mappings when 4K pages are in use. The original rationale for this
was simplicity, but it has some unfortunate side-effects, and
complicates portions of the fixmap code (i.e. is not so simple after
all).
The FDT can be up to 2M in size but is only required to have 8-byte
alignment, and so it may straddle a 2M boundary. Thus when using 2M
block mappings we may map up to 4M of memory surrounding the FDT. This
is unfortunate as most of that memory will be unrelated to the FDT, and
any pages which happen to share a 2M block with the FDT will by mapped
with Normal Write-Back Cacheable attributes, which might not be what we
want elsewhere (e.g. for carve-outs using Non-Cacheable attributes).
The logic to handle mapping the FDT with 2M blocks requires some special
cases in the fixmap code, and ties it to the early page table
configuration by virtue of the SWAPPER_TABLE_SHIFT and
SWAPPER_BLOCK_SIZE constants used to determine the granularity used to
map the FDT.
This patch simplifies the FDT logic and removes the unnecessary mappings
of surrounding pages by always mapping the FDT at page granularity as
with all other fixmap mappings. To do so we statically reserve multiple
PTE tables to cover the fixmap VA range. Since the FDT can be at most
2M, for 4K pages we only need to allocate a single additional PTE table,
and for 16K and 64K pages the existing single PTE table is sufficient.
The PTE table allocation scales with the number of slots reserved in the
fixmap, and so this also makes it easier to add more fixmap entries if
we require those in future.
Our VA layout means that the fixmap will always fall within a single PMD
table (and consequently, within a single PUD/P4D/PGD entry), which we
can verify at compile time with a static_assert(). With that assert a
number of runtime warnings become impossible, and are removed.
I've boot-tested this patch with both 4K and 64K pages.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Link: https://lore.kernel.org/r/20230406152759.4164229-4-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Over time, arm64's mm/mmu.c has become increasingly large and painful to
navigate. Move the fixmap code to its own file where it can be understood in
isolation.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Link: https://lore.kernel.org/r/20230406152759.4164229-3-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Currently arm64's FIXADDR_{START,SIZE} definitions only cover the
runtime fixmap slots (and not the boot-time fixmap slots), but the code
for creating the fixmap assumes that these definitions cover the entire
fixmap range. This means that the ptdump boundaries are reported in a
misleading way, missing the VA region of the runtime slots. In theory
this could also cause the fixmap creation to go wrong if the boot-time
fixmap slots end up spilling into a separate PMD entry, though luckily
this is not currently the case in any configuration.
While it seems like we could extend FIXADDR_{START,SIZE} to cover the
entire fixmap area, core code relies upon these *only* covering the
runtime slots. For example, fix_to_virt() and virt_to_fix() try to
reject manipulation of the boot-time slots based upon
FIXADDR_{START,SIZE}, while __fix_to_virt() and __virt_to_fix() can
handle any fixmap slot.
This patch follows the lead of x86 in commit:
55f49fcb87 ("x86/mm: Fix overlap of i386 CPU_ENTRY_AREA with FIX_BTMAP")
... and add new FIXADDR_TOT_{START,SIZE} definitions which cover the
entire fixmap area, using these for the fixmap creation and ptdump code.
As the boot-time fixmap slots are now rejected by fix_to_virt(),
the early_fixmap_init() code is changed to consistently use
__fix_to_virt(), as it already does in a few cases.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Link: https://lore.kernel.org/r/20230406152759.4164229-2-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
The arm64 stacktrace code can be used in kprobe context, and so cannot
be safely probed. Some (but not all) of the unwind functions are
annotated with `NOKPROBE_SYMBOL()` to ensure this, with others markes as
`__always_inline`, relying on the top-level unwind function being marked
as `noinstr`.
This patch has stacktrace.c consistently mark the internal stacktrace
functions as `__always_inline`, removing the need for NOKPROBE_SYMBOL()
as the top-level unwind function (arch_stack_walk()) is marked as
`noinstr`. This is more consistent and is a simpler pattern to follow
for future additions to stacktrace.c.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Kalesh Singh <kaleshsingh@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20230411162943.203199-4-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
For historical reasons, the backtrace dumping functions are placed in
the middle of stacktrace.c, despite using functions defined later. For
clarity, and to make subsequent refactoring easier, move the dumping
functions to the end of stacktrace.c
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Kalesh Singh <kaleshsingh@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20230411162943.203199-3-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
The function which calls the top-level backtracing function may have
been instrumented with ftrace and/or kprobes, and hence the first return
address may have been rewritten.
Factor out the existing fgraph / kretprobes address recovery, and use
this for the first address. As the comment for the fgraph case isn't all
that helpful, I've also dropped that.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Kalesh Singh <kaleshsingh@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20230411162943.203199-2-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Following recent refactorings, the get_ftrace_plt function only ever
gets called with addr = FTRACE_ADDR so its code can be simplified to
always return the ftrace trampoline plt.
Signed-off-by: Florent Revest <revest@chromium.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20230405180250.2046566-3-revest@chromium.org
Signed-off-by: Will Deacon <will@kernel.org>
This builds up on the CALL_OPS work which extends the ftrace patchsite
on arm64 with an ops pointer usable by the ftrace trampoline.
This ops pointer is valid at all time. Indeed, it is either pointing to
ftrace_list_ops or to the single ops which should be called from that
patchsite.
There are a few cases to distinguish:
- If a direct call ops is the only one tracing a function:
- If the direct called trampoline is within the reach of a BL
instruction
-> the ftrace patchsite jumps to the trampoline
- Else
-> the ftrace patchsite jumps to the ftrace_caller trampoline which
reads the ops pointer in the patchsite and jumps to the direct
call address stored in the ops
- Else
-> the ftrace patchsite jumps to the ftrace_caller trampoline and its
ops literal points to ftrace_list_ops so it iterates over all
registered ftrace ops, including the direct call ops and calls its
call_direct_funcs handler which stores the direct called
trampoline's address in the ftrace_regs and the ftrace_caller
trampoline will return to that address instead of returning to the
traced function
Signed-off-by: Florent Revest <revest@chromium.org>
Co-developed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20230405180250.2046566-2-revest@chromium.org
Signed-off-by: Will Deacon <will@kernel.org>
In prepration for adding the IOMMUs and LARBs of this SoC, add the
VDECSYS and VENCSYS clock controller nodes, providing clocks for the
vcodec stateful decoder and stateful decoder hardware.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230327083647.22017-11-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
* Ensure the guest PMU context is restored before the first KVM_RUN,
fixing an issue where EL0 event counting is broken after vCPU
save/restore
* Actually initialize ID_AA64PFR0_EL1.{CSV2,CSV3} based on the
sanitized, system-wide values for protected VMs
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmQ0944UHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroO3mAf8CpzKs1SSfx4OpH1rPHgnZBmMyb9x
cJe+W330RCuM96sUXFah7kealS8KIVLFk1E1k2gUIKBtm7cExWeWm6NFpazeu4aT
c4R6dOGoXZ9i0E0l807onh0NCZp/cV6FnTnfYnS44Re6Bpo1V7QODP8cVWww1IIK
w+4I4Fvcz/ensjgzh8z3h6o0Jz8YWWgAS17Vcic6ezVCEX5HC1sltXB9y1NKMduc
vYvT7At8Rb4GhqvfCfsAiNW7iV5dftZe5LHup0Rd6FmzvQGkaTGd7aoekf46IQV2
Kl7yNpOH6GAUjxCjf8Dvfat4IsFsrfTESGPI15s0cS9BG2d1dXzwLVcHaQ==
=bYva
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"Two ARM fixes:
- Ensure the guest PMU context is restored before the first KVM_RUN,
fixing an issue where EL0 event counting is broken after vCPU
save/restore
- Actually initialize ID_AA64PFR0_EL1.{CSV2,CSV3} based on the
sanitized, system-wide values for protected VMs"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: arm64: Advertise ID_AA64PFR0_EL1.CSV2/3 to protected VMs
KVM: arm64: PMU: Restore the guest's EL0 event counting after migration
Add DTS for Qualcomm qrb4210-rb2 board which uses SM4250 SoC.
This adds debug uart, emmc, uSD and tlmm support along with
regulators found on this board.
Also defines the 'xo_board' and 'sleep_clk' frequencies for
this board.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
[bjorn: Squashed separate patch specifying regulator-system-load]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230411072840.2751813-3-bhupesh.sharma@linaro.org
We need the USB fixes in here for testing, and this resolves two merge
conflicts, one pointed out by linux-next:
drivers/usb/dwc3/dwc3-pci.c
drivers/usb/host/xhci-pci.c
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Though presently unused, there is an SMC64 view of the Arm architecture
calls defined by the SMCCC. The documentation of the SMCCC filter states
that the SMC64 range is reserved, but nothing actually prevents
userspace from applying a filter to the range.
Insert a range with the HANDLE action for the SMC64 arch range, thereby
preventing userspace from imposing filtering/forwarding on it.
Fixes: fb88707dd3 ("KVM: arm64: Use a maple tree to represent the SMCCC filter")
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230408121732.3411329-2-oliver.upton@linux.dev
Add support for Data Modul i.MX8M Plus eDM SBC board. This is an
evaluation board for various custom display units. Currently
supported are serial console, ethernet, eMMC, SD, SPI NOR,
USB host and USB OTG.
Reviewed-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTFp0I1jqZrAX+hPRXbK58LschIgwUCZDCaHgAKCRDbK58LschI
g2CXAP9sgjqCaRhfSSYWbESKWxokJAa1j6v7phNjR9iqHrBjzwEAg6aDHOUqcYpD
Zlp/5JV9HIkc1wTmuIUuI74YAVZBJAU=
=V2jo
-----END PGP SIGNATURE-----
Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Daniel Borkmann says:
====================
pull-request: bpf 2023-04-08
We've added 4 non-merge commits during the last 11 day(s) which contain
a total of 5 files changed, 39 insertions(+), 6 deletions(-).
The main changes are:
1) Fix BPF TCP socket iterator to use correct helper for dropping
socket's refcount, that is, sock_gen_put instead of sock_put,
from Martin KaFai Lau.
2) Fix a BTI exception splat in BPF trampoline-generated code on arm64,
from Xu Kuohai.
3) Fix a LongArch JIT error from missing BPF_NOSPEC no-op, from George Guo.
4) Fix dynamic XDP feature detection of veth in xdp_redirect selftest,
from Lorenzo Bianconi.
* tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
selftests/bpf: fix xdp_redirect xdp-features selftest for veth driver
bpf, arm64: Fixed a BTI error on returning to patched function
LoongArch, bpf: Fix jit to skip speculation barrier opcode
bpf: tcp: Use sock_gen_put instead of sock_put in bpf_iter_tcp
====================
Link: https://lore.kernel.org/r/20230407224642.30906-1-daniel@iogearbox.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add nodes for LPASS Soundwire v2.0.0 controllers. Use labels with
indices matching downstream DTS, to make any comparisons easier.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230405061129.143553-1-krzysztof.kozlowski@linaro.org
SM8250 has (at least) four GPU speed bins. With the support added on the
driver side, wire up bin detection in the DTS to restrict lower-quality
SKUs from running at frequencies they were not validated at.
Tested-by: Marijn Suijten <marijn.suijten@somainline.org> # On Sony Xperia 5 II (speed bin 0x7)
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230331-topic-konahana_speedbin-v3-5-2dede22dd7f7@linaro.org
SM8150 has (at least) two GPU speed bins. With the support added on the
driver side, wire up bin detection in the DTS to restrict lower-quality
SKUs from running at frequencies they were not validated at.
Tested-by: Marijn Suijten <marijn.suijten@somainline.org> # On Sony Xperia 5 (speed bin 0x3)
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230331-topic-konahana_speedbin-v3-4-2dede22dd7f7@linaro.org
Now that there's display support, there is no reason to assume the default
mode for Adreno should be headless. Keep it like that for boards that
previously enabled it, so as not to create regressions though.
Tested-by: Marijn Suijten <marijn.suijten@somainline.org> # On Sony Xperia 5
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230331-topic-konahana_speedbin-v3-3-2dede22dd7f7@linaro.org
Add the initial device tree support for the Reference Design
Platform(RDP) 468 based on IPQ5332 family of SoCs. This patch carries the
support for Console UART, SPI NOR, eMMC.
Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323093120.20558-3-quic_kathirav@quicinc.com
The DSI OPP table on SDM630 is used by one DSI0, but on SDM660 is shared
by two nodes (DSI0 and DSI1), thus it should be rather in top-level, not
in DSI0.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407192605.168666-1-krzysztof.kozlowski@linaro.org
Add a node for RMTFS and associate it with MSA and NAV IDs to enable
modem functionality on SM6115.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230406-topic-lenovo_features-v2-2-625d7cb4a944@linaro.org
Bindings require pin configuration nodes to have the function, even if
it is GPIO:
msm8916-thwc-ufi001c.dtb: pinctrl@1000000: sim-ctrl-default-state: 'oneOf' conditional failed, one must be fixed:
'esim-sel-pins', 'sim-en-pins', 'sim-sel-pins' do not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230324202244.744271-1-krzysztof.kozlowski@linaro.org
Add nodes for remoteproc, smp2p and smsm in preparation
for audio support on this platform.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407165345.42800-4-a39.skl@gmail.com
Add nodes for remoteproc, smp2p and smsm to make it possible to use
modem functionality on this platform.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407165345.42800-3-a39.skl@gmail.com
Add nodes for remoteproc, smp2p and smsm to make it possible to use
wifi/bt functionality on this platform.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407165345.42800-2-a39.skl@gmail.com
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407180655.128771-2-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407180655.128771-1-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407180045.126952-1-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-10-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-9-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-8-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-7-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-6-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-5-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-4-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-3-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-2-krzysztof.kozlowski@linaro.org
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not
input-enable") the property is not accepted anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407175807.124394-1-krzysztof.kozlowski@linaro.org
Add support for the Xiaomi Mi A3 (xiaomi-laurel-sprout). Here's a
summary on what's defined.
- dmesg output to bootloader preconfigured display
- USB
- UFS
- SD card
- SMD RPM regulators
- Volume Up, Down and Power buttons
- Thermistors
Signed-off-by: Lux Aliaga <they@mint.lgbt>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230306170817.3806-7-they@mint.lgbt
Add support for the Xiaomi Mi Pad 5 Pro CSOT variant. The CSOT variant
uses China Star Optoelectronics Technology (CSOT) panel based on NT36523
display controller.
Signed-off-by: Jianhua Lu <lujianhua000@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323005925.23179-3-lujianhua000@gmail.com
Add nodes for BOE NT36523 panel found in xiaomi-elish. This panel
is a dual dsi mode panel and the dsi phy type is cphy.
Signed-off-by: Jianhua Lu <lujianhua000@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323005925.23179-2-lujianhua000@gmail.com
There are two panel variants of xiaomi-elish, BOE and CSOT panels.
In order to support both panels, so split elish dts into common dtsi
and elish-boe dts.
Signed-off-by: Jianhua Lu <lujianhua000@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323005925.23179-1-lujianhua000@gmail.com
Add an initial device tree for the QTI RB1 development board, based on
the QRB2210 (QCM2290 derivative) SoC. This device tree targets the SoM
revision 4, a.k.a. the Mass Production SKU.
To get a successful boot, run:
cat arch/arm64/boot/Image.gz arch/arm64/boot/dts/qcom/qrb2210-rb1.dtb >\
.Image.gz-dtb
mkbootimg \
--kernel .Image.gz-dtb \
--ramdisk some_initrd \
--output rb1-boot.img \
--pagesize 4096 \
--base 0x8000 \
--cmdline 'some cmdline'
fastboot boot rb1-boot.img
There's no dtbo or other craziness to worry about.
For the best dev experience, you can erase boot and use fastboot boot
everytime, so that the bootloader doesn't mess with you.
If you have a SoM revision 3 or older (there should be a sticker on it
with text like -r00, where r is the revision), you will need to apply
this additional diff:
aliases {
- serial0 = &uart0;
+ serial0 = &uart4;
/* UART connected to the Micro-USB port via a FTDI chip */
- &uart0 {
+ &uart4 {
That should however only concern preproduction boards.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230403-topic-rb1_qcm-v2-5-dae06f8830dc@linaro.org
Add an initial device tree for the QCM2290 low-end SoC, featuring 4
"customized" Cortex-A53 cores and up to 4 GiB of LPDDR(3/4X).
This revision brings support for:
- TSENS & thermal zones
- SDHCI1/2
- I2C, SPI, UART
- MPSS
- ADSP
- Wi-Fi
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230403-topic-rb1_qcm-v2-3-dae06f8830dc@linaro.org
Drop the qcom,snoc-host-cap-skip-quirk that was never introduced to
solve schema warnings.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230406-topic-ath10k_bindings-v3-2-00895afc7764@linaro.org
Enable the SLPI DSP on the SHIFTPHONES SHIFT6mq phone with a
Qualcomm SDM845 SoC.
Signed-off-by: Dylan Van Assche <me@dylanvanassche.be>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230406173148.28309-6-me@dylanvanassche.be
Enable the SLPI DSP on the Oneplus 6 phone with a Qualcomm SDM845 SoC.
Signed-off-by: Dylan Van Assche <me@dylanvanassche.be>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230406173148.28309-5-me@dylanvanassche.be
Qualcomm SDM845 SoC features a SLPI DSP which uses FastRPC through
an allocated memory region to load files from the host filesystem
such as sensor configuration files.
Add a FastRPC node at /dev/fastrpc-sdsp and a DMA region, similar to
downstream, to allow userspace to communicate with the SLPI via the
FastRPC interface for initializing the sensors on the SLPI.
Signed-off-by: Dylan Van Assche <me@dylanvanassche.be>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230406173148.28309-4-me@dylanvanassche.be
Add the SLPI remoteproc to the SDM845 Qualcomm SoC which is responsible
for exposing the sensors connected to the SoC. The SLPI communicates
over GLink edge 'dsps' and is similar to other DSPs e.g. ADSP or CDSP.
This patch allows the SLPI to boot and expose itself over QRTR as
service 400.
Signed-off-by: Dylan Van Assche <me@dylanvanassche.be>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230406173148.28309-2-me@dylanvanassche.be
Drop the unnecessary mux{} level to make dtbs check happy.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407-topic-msm_dtb-v1-6-6efb4196f51f@linaro.org
Fix the node name to make dtbs_check happy:
qcom/apq8016-sbc.dtb: pmic@0: 'extcon@1300' does not match any of the
regexes: '(.*)?(wled|leds)@[0-9a-f]+$', '^adc-tm@[0-9a-f]+$',
'^adc@[0-9a-f]+$', '^audio-codec@[0-9a-f]+$', '^charger@[0-9a-f]+$',
'^mpps@[0-9a-f]+$', '^nvram@[0-9a-f]+$', '^rtc@[0-9a-f]+$',
'^temp-alarm@[0-9a-f]+$', '^usb-detect@[0-9a-f]+$',
'^usb-vbus-regulator@[0-9a-f]+$', '^vibrator@[0-9a-f]+$',
'gpio@[0-9a-f]+$', 'pinctrl-[0-9]+', 'pon@[0-9a-f]+$'
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407-topic-msm_dtb-v1-5-6efb4196f51f@linaro.org
Fix the following schema warning:
gic-its@17a40000: False schema does not allow {'compatible':
['arm,gic-v3-its'], 'msi-controller': True, '#msi-cells': [[1]],
'reg': [[0, 396623872, 0, 131072]], 'status': ['disabled']}
And reorder the properties to be more in order with all other nodes.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407-topic-msm_dtb-v1-4-6efb4196f51f@linaro.org
Cheza's SPI flash hookups (qspi) are exactly the same as trogdor's.
Apply the same solution that's described in the patch ("arm64: dts:
qcom: sc7180: Fix trogdor qspi pin config")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.14.I82951106ab8170f973a4c1c7d9b034655bbe2f60@changeid
Similar to sc7180 (see the patch ("arm64: dts: qcom: sc7180: Fix
trogdor qspi pin config")), we should adjust the qspi pin config for
sc7280.
I won't re-describe all the research/arguments in the sc7180 patch
here, but there are a few differences for sc7280 worth noting:
1. On herobrine the SPI flash (qspi) is wired up differently on the
board. Rather than Cr50 and the AP being wired directly together,
there's actually a mux that will _either_ connect the AP to the
flash or Cr50 to the flash. This means that the internal pulls on
Cr50 don't affect us and we should enable our own pulldowns.
2. On herobrine, EEs added an external pulldown on the MISO line. The
argument in the schematic said that we added it (but not one on
MOSI and CLK) because Cr50 already enabled pulldowns on MOSI and
CLK. ...though, as per #1, those Cr50 pulldowns would only affect
the line when the mux was swung to Cr50.
The ironic result of #1 and #2 is that the external pulldowns on
CLK/MISO/MOSI on herobrine are _exactly opposite_ of the ones on
trogdor.
3. While I still don't have the actual exact schematics for all
variants of IDP/CRD that were produced, I have some reference
schematics that give me a belief of how the qspi is hooked up
there. From this, I'm fairly certain that all of the older variants
of IDP/CRD either have a pulldown on the CLK/MOSI/MISO lines (maybe
through a direct connect to Cr50) or have no pull (in other words,
they don't have a pullup). I'll go ahead and enable internal
pulldowns on all the lines since that won't hurt to double-pull if
there's an external pulldown and it's nice to have a pulldown if
there's nothing external. Note that this only affects _older_
CRDs. Newer revs are considered "herobrine" (see the hoglin/zoglin
device trees).
4. I didn't find the same strange "auto-switch-to-keeper" at suspend
when probing on sc7280. Whatever pulls (or lack thereof) I left at
suspend time seemed to persist into suspend.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.13.Ib44c3e417c414a4227db8def75ded37ad368212c@changeid
In commit 7ec3e67307 ("arm64: dts: qcom: sc7180-trogdor: add initial
trogdor and lazor dt") we specified the pull settings on the boot SPI
(the qspi) data lines as pullups to "park" the lines. This seemed like
the right thing to do, but I never really probed the lines to confirm.
Since that time, I've done A LOT of research, experiements and poking
of the lines with a voltmeter.
A first batch of discoveries:
- There is an external pullup on CS (clearly shown on schematics)
- There are weak external pulldowns on CLK/MOSI (believed to be Cr50's
internal pulldowns)
- There is no pull on MISO.
- When qspi isn't actively transferring it still drives CS, CLK, and
MOSI. CS and MOSI are driven high and CLK is driven low. It does not
drive MISO and (if no internal pulls are enabled) the line floats.
The above means that it's good to have some sort of pull on MISO, at
the very least. The pullup that we had before was actually fine (and
my voltmeter confirms that it actually affected the state of the pin)
but a pulldown would work equally well (and would match MOSI and CLK
better).
The above also means that we could save a tiny bit of power (not
measurable by my setup) by setting up a sleep state for these pins. If
nothing else this prevents us from driving high against Cr50's
internal pulldown on MOSI. However, Qualcomm has also asserted in the
past that it burns a little extra power to drive a pin, especially
since these are configured with a slightly higher drive strength
Let's fix all this. Since the external pulls are different for the two
data lines, we'll split them into separate configs. Then we'll change
the MISO pin to a pulldown and add a sleep state.
On a slightly tangental (but not totally unrelated note), I also
discovered some interesting things with these pins in suspend. First,
I found that if we don't switch the pins to GPIO that the qspi
peripheral continues to drive them in suspend. That'll be solved by
what we're already doing above. Second, I found that something in the
system suspend path (after Linux stops running) reconfigures these
pins so that they don't have their normal pulls enabled but instead
change to "keepers" (bias-bus-hold in DT speak). If a pin was floating
before we entered suspend then it would stop floating. I found that I
could manually pull a pin to a different level and then probe it and
it would stay there. This is exactly keeper behavior. With the
solution we have the switch to "keeper" doesn't matter too much but
it's good to document.
While talking about "keepers", it can also be noted that I found that
the "keepers" on these pins were at least enough to win a fight
against Cr50's internal pulls. That means it's best to make sure that
the state of the pins are already correct before the mysterious
transition to a keeper. Otherwise we'll burn (a small amount of) power
in S3 via this fight. Luckily with the current solution we don't hit
this case.
NOTE: I've left "sc7180-idp" behavior totally alone in this patch. I
didn't add a sleep state and I didn't change any pulls--I just adapted
it to the fact that the data lines have separate configs. Qualcomm
doesn't provide me with schematics for IDP and thus I don't actually
know how the pulls are configured. Since this is just a development
platform and worked well enough, it seems safer to leave it alone.
Dependencies:
- This patch has a hard dependency on ("pinctrl: qcom: Support
OUTPUT_ENABLE; deprecate INPUT_ENABLE"). Something in the boot code
seemed to have been confused and thought it needed to set the
"OUTPUT ENABLE" bit for these pins even though it was using them as
SPI. Thus if we don't honor the "output-disable" property we could
end up driving the SPI pins while in sleep mode.
- In general, it's probably best not to backport this to a kernel that
doesn't have commit d21f4b7ffc ("pinctrl: qcom: Avoid glitching
lines when we first mux to output"). That landed a while ago, but
it's still good to be explicit in case someone was backporting. If
we don't have that then there might be a glitch when we first switch
over to GPIO before we disable the output.
- This patch _doesn't_ really have any dependency on the qspi driver
patch that supports setting the pinctrl sleep state--they can go in
either order. If we define the sleep state and the driver never
selects it that's fine. If the driver tries to select a sleep state
that we don't define that's fine.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.12.I6f03f86546e6ce9abb1d24fd9ece663c3a5b950c@changeid
As talked about in the patch ("dt-bindings: pinctrl: qcom: tlmm should
use output-disable, not input-enable"), using "input-enable" in
pinctrl states for Qualcomm TLMM pinctrl devices was either
superfluous or there to disable a pin's output.
Looking at cheza
* ec_ap_int_l, h1_ap_int_odl: Superfluous. The pins will be configured
as inputs automatically by the Linux GPIO subsystem (presumably the
reference for other OSes using these device trees).
* bios_flash_wp_l: Superfluous. This pin is exposed to userspace
through the kernel's GPIO API and will be configured automatically.
That means that in none of the cases for cheza did we need to change
"input-enable" to "output-disable" and we can just remove these
superfluous properties.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.11.Ia439c29517b1c0625325a54387b047f099d16425@changeid
As talked about in the patch ("dt-bindings: pinctrl: qcom: tlmm should
use output-disable, not input-enable"), using "input-enable" in
pinctrl states for Qualcomm TLMM pinctrl devices was either
superfluous or there to disable a pin's output.
Looking at the sc7280-idp-ec-h1.dtsi file:
* ap_ec_int_l, h1_ap_int_odl: Superfluous. The pins will be configured
as inputs automatically by the Linux GPIO subsystem (presumably the
reference for other OSes using these device trees).
That means that in none of the cases for sc7280-idp-ec-h1.dtsi did we
need to change "input-enable" to "output-disable" and we can just
remove these superfluous properties.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.10.I1343c20f4aaac8e2c1918b756f7ed66f6ceace9c@changeid
As talked about in the patch ("dt-bindings: pinctrl: qcom: tlmm should
use output-disable, not input-enable"), using "input-enable" in
pinctrl states for Qualcomm TLMM pinctrl devices was either
superfluous or there to disable a pin's output.
Looking at trogdor:
* ap_ec_int_l, fp_to_ap_irq_l, h1_ap_int_odl, p_sensor_int_l:
Superfluous. The pins will be configured as inputs automatically by
the Linux GPIO subsystem (presumably the reference for other OSes
using these device trees).
* bios_flash_wp_l: Superfluous. This pin is exposed to userspace
through the kernel's GPIO API and will be configured automatically.
That means that in none of the cases for trogdor did we need to change
"input-enable" to "output-disable" and we can just remove these
superfluous properties.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.9.I94dbc53176e8adb0d7673b7feb2368e85418f938@changeid
The l13a rail on trogdor devices has always been intended to be
always-on on both S0 and S3. Different trogdor variants use l13a in
slightly different ways, but the overall theme is that it's a 1.8V
rail that the board uses for things that it wants powered in on S0 and
S3. On many boards this includes the boot SPI (AKA qspi).
For all intents and purposes this patch is actually a no-op since
something else in the system seems to already be keeping the rail on
all the time (confirmed via multimeter). That "something else" was
postulated to be the modem but the rail is on / stays on even without
the modem/wifi coming up so it's likely the boot config. In any case,
making the fact that this is always-on explicit seems like a good
idea.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.4.I9f47a8a53eacff6229711a827993792ceeb36971@changeid
There are 4 qspi data pins: data0, data1, data2, and data3. Currently
we have a shared pin state for data0 and data1 (2 lane config) and a
pin state for data2 and data3 (you'd enable both this and the 2 lane
state for 4 lanes). The second state is obviously misnamed. Fix it.
Fixes: e1ce853932 ("arm64: dts: qcom: sdm845: Add qspi (quad SPI) node")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.3.I88528d037b7fda4e53a40f661be5ac61628691cd@changeid
There are 4 qspi data pins: data0, data1, data2, and data3. Currently
we have a shared pin state for data0 and data1 (2 lane config) and a
pin state for data2 and data3 (you'd enable both this and the 2 lane
state for 4 lanes). The second state is obviously misnamed. Fix it.
Fixes: 7720ea001b ("arm64: dts: qcom: sc7280: Add QSPI node")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.2.I4043491bb24b1e92267c5033d76cdb0fe60934da@changeid
There are 4 qspi data pins: data0, data1, data2, and data3. Currently
we have a shared pin state for data0 and data1 (2 lane config) and a
pin state for data2 and data3 (you'd enable both this and the 2 lane
state for 4 lanes). The second state is obviously misnamed. Fix it.
Fixes: ba3fc64963 ("arm64: dts: sc7180: Add qupv3_0 and qupv3_1")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.1.Ifc1b5be04653f4ab119698a5944bfecded2080d6@changeid
There are some interop issues seen across a few DP monitors with
HBR3 and herobrine boards where the DP display stays blank with hbr3.
This is still under investigation but in preparation for supporting
higher resolutions, its better to disable HBR3 till the issues are
root-caused as there is really no guarantee which monitors will show
the issue and which would not.
This can be enabled back after successful validation across more DP
sinks.
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230329233416.27152-1-quic_abhinavk@quicinc.com
The DSA framework has got more picky about always having a phy-mode
for the CPU port. The SoC Ethernet is being configured to
10gbase-r. Set the switch phy-mode based on this. Additionally, the
SoC Ethernet is using in-band signalling to determine the link speed,
so add same parameter to the switch.
Additionally, the cpu label has never actually been used in the
binding, so remove it.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
The GL-MV1000 (Brume) is a small form-factor gateway router.
It is based on the Marvell Armada 88F3720 SOC (1GHz), has 3 gigabit ethernet ports, 1 GB RAM, 16M SPI flash, 8GB eMMC and an uSD slot, as well as an USB 2.0 type A and an USB 3.0 type C port.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
CC: Pali <pali@kernel.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Bindings expect thermal node names to end with '-thermal':
armada-8040-db.dtb: thermal-zones: 'ap-thermal-cpu0', ... do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Armada 7040 uses a rather small 15MB memory window for every PCI adapter,
however this is not sufficient for Qualcomm QCA6390 802.11ax cards that
are shipped along with the OpenWrt WLAN model of MOCHAbin as ath11k
requires at least 16MB of memory.
So, similar to what MACCHIATOBin has been doing for years, lets move
to using the second PCIe 2 memory window and expand it to 128MB to
make it future proof.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Add the Low Power Audio SubSystem (LPASS) / ADSP audio codec macros on
Qualcomm SM8550. The nodes are very similar to SM8450, except missing
NPL clock which is not exposed on SM8550 and should not be touched.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230310134925.514125-1-krzysztof.kozlowski@linaro.org
Currently, most of the Qualcomm SoCs specify both "iommus" and "iommu-map"
properties for the PCIe nodes. First one passes the SMR mask to the iommu
driver and the latter specifies the SID for each PCIe device.
But with "iommus" property, the PCIe controller will be added to the
iommu group along with the devices. This makes no sense because the
controller will not initiate any DMA transaction on its own. And moreover,
it is not strictly required to pass the SMR mask to the iommu driver. If
the "iommus" property is not present, then the default mask of "0" would be
used which should work for all PCIe devices.
On the other side, if the SMR mask specified doesn't match the one expected
by the hypervisor, then all the PCIe transactions will end up triggering
"Unidentified Stream Fault" by the SMMU.
So to get rid of these hassles and also prohibit PCIe controllers from
adding to the iommu group, let's remove the "iommus" property from PCIe
nodes.
Reported-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/linux-arm-msm/20230227195535.GA749409-robh@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230308075648.134119-1-manivannan.sadhasivam@linaro.org
The parent controller for both interrupts is GIC, so no need for
interrupts-extended.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230405060906.143058-5-krzysztof.kozlowski@linaro.org
The parent controller for the interrupt is GIC, so no need for
interrupts-extended.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230405060906.143058-4-krzysztof.kozlowski@linaro.org
The parent controller for both interrupts is GIC, so no need for
interrupts-extended.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230405060906.143058-3-krzysztof.kozlowski@linaro.org
Use labels, instead of comments, for Soundwire controllers. Naming them
is useful, because they are specialized and have also naming in
datasheet/programming guide.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230405060906.143058-2-krzysztof.kozlowski@linaro.org
Use labels, instead of comments, for Soundwire controllers. Naming them
is useful, because they are specialized and have also naming in
datasheet/programming guide.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230405060906.143058-1-krzysztof.kozlowski@linaro.org
- Ensure the guest PMU context is restored before the first KVM_RUN,
fixing an issue where EL0 event counting is broken after vCPU
save/restore
- Actually initialize ID_AA64PFR0_EL1.{CSV2,CSV3} based on the
sanitized, system-wide values for protected VMs
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCZC2ZbwAKCRCivnWIJHzd
FvovAP9aooqUBBs8w2myh8SXCv7dJOg88r6fKS5vCqMdkY7OhwD9GXA7hWU2dXdy
X1L8qq6C7R+GtIY/kDm9E2HkNKg7rQc=
=nfXd
-----END PGP SIGNATURE-----
Merge tag 'kvmarm-fixes-6.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 fixes for 6.3, part #3
- Ensure the guest PMU context is restored before the first KVM_RUN,
fixing an issue where EL0 event counting is broken after vCPU
save/restore
- Actually initialize ID_AA64PFR0_EL1.{CSV2,CSV3} based on the
sanitized, system-wide values for protected VMs
Version 2022-12 of DDI0601 has defined a number of new fields in
previously RES0 space in ID_AA64PFR1_EL1, update our definition to
include them.
No functional changes.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230308-arm64-aa64pfr1-2022-12-v1-1-f03c1ea39611@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Convert the fine grained traps read and write control registers to
automatic generation as per DDI0601 2022-12. No functional changes.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230306-arm64-fgt-reg-gen-v3-1-decba93cbaab@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
We'd like to support Enum/SignedEnum/UnsignedEnum blocks within
SysregFields blocks, so that we can define enumerations for sets of
registers. This isn't currently supported by gen-sysreg.awk due to the
way we track the active block, which can't handle more than a single
layer of nesting, which imposes an awkward requirement that when ending
a block we know what the parent block is when calling change_block()
Make this nicer by using a stack of active blocks, with block_push() to
start a block, and block_pop() to end a block. Doing so means that we
only need to check the active block at the start of parsing a line: for
the start of a block we can check the parent is valid, and for the end
of a block we check that the active block is valid.
This structure makes the block parsing simpler and makes it easy to
permit a block to live under several potential parents (e.g. by
permitting Enum to start when the active block is Sysreg or
SysregFields). It also permits further nesting, if we need that in
future.
To aid debugging, the stack of active blocks is reported for fatal
errors, and an error is raised if the file is terminated without ending
the active block. For clarity I've renamed the top-level element from
"None" to "Root".
The Fields element it intended only for use within Sysreg blocks, and
does not make sense within SysregFields blocks, and so remains forbidden
within a SysregFields block.
I've verified using sha1sum that this patch does not change the
current generated contents of <asm/sysreg-defs.h>.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230306114836.2575432-1-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Attempt VMA lock-based page fault handling first, and fall back to the
existing mmap_lock-based handling if that fails.
Link: https://lkml.kernel.org/r/20230227173632.3292573-31-surenb@google.com
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Add two new tagging-related routines arch_suppress_tag_checks_start/stop
that suppress MTE tag checking via the TCO register.
These rouines are used in the next patch.
[andreyknvl@google.com: drop __ from mte_disable/enable_tco names]
Link: https://lkml.kernel.org/r/7ad5e5a9db79e3aba08d8f43aca24350b04080f6.1680114854.git.andreyknvl@google.com
Link: https://lkml.kernel.org/r/75a362551c3c54b70ae59a3492cabb51c105fa6b.1678491668.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Weizhao Ouyang <ouyangweizhao@zeku.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The TCO related routines are used in uaccess methods and
load_unaligned_zeropad() but are unrelated to both even if the naming
suggest otherwise.
Improve the readability of the code moving the away from uaccess.h and
pre-pending them with "mte".
[andreyknvl@google.com: drop __ from mte_disable/enable_tco names]
Link: https://lkml.kernel.org/r/74d26337b2360733956114069e96ff11c296a944.1680114854.git.andreyknvl@google.com
Link: https://lkml.kernel.org/r/a48e7adce1248c0f9603a457776d59daa0ef734b.1678491668.git.andreyknvl@google.com
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Weizhao Ouyang <ouyangweizhao@zeku.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Rename arch_enable_tagging_sync/async/asymm to
arch_enable_tag_checks_sync/async/asymm, as the new name better reflects
their function.
Also rename kasan_enable_tagging to kasan_enable_hw_tags for the same
reason.
Link: https://lkml.kernel.org/r/069ef5b77715c1ac8d69b186725576c32b149491.1678491668.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Weizhao Ouyang <ouyangweizhao@zeku.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Add LCDIF scanout engine and DSIM bridge nodes for i.MX8M Plus.
This makes the DSI display pipeline available on this SoC.
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add LCDIF scanout engine and DSIM bridge nodes for i.MX8M Nano.
This makes the DSI display pipeline available on this SoC.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add LCDIF scanout engine and DSIM bridge nodes for i.MX8M Mini.
This makes the DSI display pipeline available on this SoC.
Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
There are cadence usb3.0 controller in 8qxp and 8qm.
Add usb3 node at common connect subsystem.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
'#clock-cells' is a dependency of 'clock-output-names', following
binding doc, add it.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The i.MX8MP includes the same GPT blocks as the i.MX6DL. Add all 6
instances.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
This is an NXP downstream property. And no binding doc, and no
driver use this property. So drop it
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O
Port access. In a future patch HAS_IOPORT=n will disable compilation of
the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390.
The following architectures do not select HAS_IOPORT:
* ARC
* C-SKY
* Hexagon
* Nios II
* OpenRISC
* s390
* User-Mode Linux
* Xtensa
All other architectures select HAS_IOPORT at least conditionally.
The "depends on" relations on HAS_IOPORT in drivers as well as ifdefs
for HAS_IOPORT specific sections will be added in subsequent patches on
a per subsystem basis.
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@kernel.org>
Acked-by: Johannes Berg <johannes@sipsolutions.net> # for ARCH=um
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When returning to userspace to handle a SMCCC call, we consistently
set PC to point to the instruction immediately after the HVC/SMC.
However, should userspace need to know the exact address of the
trapping instruction, it needs to know about the *size* of that
instruction. For AArch64, this is pretty easy. For AArch32, this
is a bit more funky, as Thumb has 16bit encodings for both HVC
and SMC.
Expose this to userspace with a new flag that directly derives
from ESR_EL2.IL. Also update the documentation to reflect the PC
state at the point of exit.
Finally, this fixes a small buglet where the hypercall.{args,ret}
fields would not be cleared on exit, and could contain some
random junk.
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/86pm8iv8tj.wl-maz@kernel.org
The Anbernic and Odroid Go have different panels and take differently
named supplies, so move all the supplies to DTS defining actual panel to
fix warnings like:
rk3326-odroid-go3.dtb: panel@0: 'IOVCC-supply' is a required property
rk3326-odroid-go3.dtb: panel@0: 'iovcc-supply', 'vdd-supply' do not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230326204520.80859-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Anbernic and Odroid Go have different panels and take differently
named supplies, so move all the supplies to DTS defining actual panel to
fix warnings like:
rk3326-odroid-go3.dtb: panel@0: 'IOVCC-supply' is a required property
rk3326-odroid-go3.dtb: panel@0: 'iovcc-supply', 'vdd-supply' do not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230326204520.80859-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The panel bindings expect to have only one port, thus they do not allow
to use "ports" node:
rk3399-rockpro64.dtb: panel@0: 'ports' does not match any of the regexes: 'pinctrl-[0-9]+'
There is only one endpoint, so use simpler form without "reg".
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230326204520.80859-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The panel bindings expect to have only one port, thus they do not allow
to use "ports" node:
rk3399-pinebook-pro.dtb: edp-panel: 'ports' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230326204520.80859-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the necessary DT nodes for the Rock 5B board to enable the analog
audio support provided by the Everest Semi ES8316 codec.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
Link: https://lore.kernel.org/r/20230402095054.384739-6-cristian.ciocaltea@collabora.com
[adapted to the fan addition I applied slightly earlier]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
In addition to the five I2S/PCM/TDM controllers and the two I2S/PCM
controllers shared between the RK3588 and RK3588S SoCs, RK3588 provides
another group of four I2S/PCM/TDM controllers.
Add the DT nodes corresponding to the additional controllers.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230402095054.384739-5-cristian.ciocaltea@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
There are five I2S/PCM/TDM controllers and two I2S/PCM controllers
embedded in the RK3588 and RK3588S SoCs.
Add the DT nodes corresponding to the above mentioned Rockchip
controllers.
Also note RK3588 SoC contains four additional I2S/PCM/TDM controllers,
which are handled via a separate patch.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230402095054.384739-4-cristian.ciocaltea@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The clock rate for PLL_PPLL has been wrongly initialized to 100 MHz
instead of 1.1 GHz. Fix it.
Fixes: c9211fa260 ("arm64: dts: rockchip: Add base DT for rk3588 SoC")
Reported-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230402095054.384739-3-cristian.ciocaltea@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Since commit df4fdd0db4 ("dt-bindings: firmware: arm,scmi: Restrict
protocol child node properties") the following dtbs_check warning is
shown:
rk3588-rock-5b.dtb: scmi: protocol@14: Unevaluated properties are not
allowed ('assigned-clock-rates', 'assigned-clocks' were unexpected)
Because adding the missing properties to firmware/arm,scmi.yaml binding
document was not an acceptable solution, move SCMI_CLK_CPUB01 and
SCMI_CLK_CPUB23 assigned clocks to the related CPU nodes and also add
the missing SCMI_CLK_CPUL.
Additionally, adjust frequency to 816 MHz for all the above mentioned
assigned clocks, in order to match the firmware defaults.
Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230402095054.384739-2-cristian.ciocaltea@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add thermal sensor IP, which allows monitoring temperatures at
seven different places in the SoC:
* Chip Center
* CPU Cluster 1 (Dual A76 "Big" Cores)
* CPU Cluster 2 (Dual A76 "Big" Cores)
* CPU Cluster 0 (Quad A55 "Little" Cores)
* Power Domain Center
* Graphics Processing Unit
* Neural Processing Unit
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20230404154429.51601-1-sebastian.reichel@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the necessary DT changes for the Rock 5B board to enable support for
the PWM controlled heat sink fan.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
Link: https://lore.kernel.org/r/20230404173807.490520-3-cristian.ciocaltea@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
