| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The kbuild robot reports that we're relying on an implicit inclusion to
get a definition of task_stack_page() in the Spectre-v4 mitigation code,
which is not always in place for some configurations:
| arch/arm64/kernel/proton-pack.c:329:2: error: implicit declaration of function 'task_stack_page' [-Werror,-Wimplicit-function-declaration]
| task_pt_regs(task)->pstate |= val;
| ^
| arch/arm64/include/asm/processor.h:268:36: note: expanded from macro 'task_pt_regs'
| ((struct pt_regs *)(THREAD_SIZE + task_stack_page(p)) - 1)
| ^
| arch/arm64/kernel/proton-pack.c:329:2: note: did you mean 'task_spread_page'?
Add the missing include to fix the build error.
Fixes: a44acf477220 ("arm64: Move SSBD prctl() handler alongside other spectre mitigation code")
Reported-by: Anthony Steinhauser <[email protected]>
Reported-by: kernel test robot <[email protected]>
Link: https://lore.kernel.org/r/202009260013.Ul7AD29w%[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
Patching the EL2 exception vectors is integral to the Spectre-v2
workaround, where it can be necessary to execute CPU-specific sequences
to nobble the branch predictor before running the hypervisor text proper.
Remove the dependency on CONFIG_RANDOMIZE_BASE and allow the EL2 vectors
to be patched even when KASLR is not enabled.
Fixes: 7a132017e7a5 ("KVM: arm64: Replace CONFIG_KVM_INDIRECT_VECTORS with CONFIG_RANDOMIZE_BASE")
Reported-by: kernel test robot <[email protected]>
Link: https://lore.kernel.org/r/202009221053.Jv1XsQUZ%[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
Out with the old ghost, in with the new...
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
Convert the KVM WA2 code to using the Spectre infrastructure,
making the code much more readable. It also allows us to
take SSBS into account for the mitigation.
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
kvm_arm_have_ssbd() is now completely unused, get rid of it.
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
Owing to the fact that the host kernel is always mitigated, we can
drastically simplify the WA2 handling by keeping the mitigation
state ON when entering the guest. This means the guest is either
unaffected or not mitigated.
This results in a nice simplification of the mitigation space,
and the removal of a lot of code that was never really used anyway.
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
Rewrite the Spectre-v4 mitigation handling code to follow the same
approach as that taken by Spectre-v2.
For now, report to KVM that the system is vulnerable (by forcing
'ssbd_state' to ARM64_SSBD_UNKNOWN), as this will be cleared up in
subsequent steps.
Signed-off-by: Will Deacon <[email protected]>
|
|
As part of the spectre consolidation effort to shift all of the ghosts
into their own proton pack, move all of the horrible SSBD prctl() code
out of its own 'ssbd.c' file.
Signed-off-by: Will Deacon <[email protected]>
|
|
In a similar manner to the renaming of ARM64_HARDEN_BRANCH_PREDICTOR
to ARM64_SPECTRE_V2, rename ARM64_SSBD to ARM64_SPECTRE_V4. This isn't
_entirely_ accurate, as we also need to take into account the interaction
with SSBS, but that will be taken care of in subsequent patches.
Signed-off-by: Will Deacon <[email protected]>
|
|
If all CPUs discovered during boot have SSBS, then spectre-v4 will be
considered to be "mitigated". However, we still allow late CPUs without
SSBS to be onlined, albeit with a "SANITY CHECK" warning. This is
problematic for userspace because it means that the system can quietly
transition to "Vulnerable" at runtime.
Avoid this by treating SSBS as a non-strict system feature: if all of
the CPUs discovered during boot have SSBS, then late arriving secondaries
better have it as well.
Signed-off-by: Will Deacon <[email protected]>
|
|
The is_ttbrX_addr() functions have somehow ended up in the middle of
the start_thread() functions, so move them out of the way to keep the
code readable.
Signed-off-by: Will Deacon <[email protected]>
|
|
If the system is not affected by Spectre-v2, then advertise to the KVM
guest that it is not affected, without the need for a safelist in the
guest.
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
The Spectre-v2 mitigation code is pretty unwieldy and hard to maintain.
This is largely due to it being written hastily, without much clue as to
how things would pan out, and also because it ends up mixing policy and
state in such a way that it is very difficult to figure out what's going
on.
Rewrite the Spectre-v2 mitigation so that it clearly separates state from
policy and follows a more structured approach to handling the mitigation.
Signed-off-by: Will Deacon <[email protected]>
|
|
The spectre mitigation code is spread over a few different files, which
makes it both hard to follow, but also hard to remove it should we want
to do that in future.
Introduce a new file for housing the spectre mitigations, and populate
it with the spectre-v1 reporting code to start with.
Signed-off-by: Will Deacon <[email protected]>
|
|
For better or worse, the world knows about "Spectre" and not about
"Branch predictor hardening". Rename ARM64_HARDEN_BRANCH_PREDICTOR to
ARM64_SPECTRE_V2 as part of moving all of the Spectre mitigations into
their own little corner.
Signed-off-by: Will Deacon <[email protected]>
|
|
Use is_hyp_mode_available() to detect whether or not we need to patch
the KVM vectors for branch hardening, which avoids the need to take the
vector pointers as parameters.
Signed-off-by: Will Deacon <[email protected]>
|
|
The removal of CONFIG_HARDEN_BRANCH_PREDICTOR means that
CONFIG_KVM_INDIRECT_VECTORS is synonymous with CONFIG_RANDOMIZE_BASE,
so replace it.
Signed-off-by: Will Deacon <[email protected]>
|
|
The spectre mitigations are too configurable for their own good, leading
to confusing logic trying to figure out when we should mitigate and when
we shouldn't. Although the plethora of command-line options need to stick
around for backwards compatibility, the default-on CONFIG options that
depend on EXPERT can be dropped, as the mitigations only do anything if
the system is vulnerable, a mitigation is available and the command-line
hasn't disabled it.
Remove CONFIG_HARDEN_BRANCH_PREDICTOR and CONFIG_ARM64_SSBD in favour of
enabling this code unconditionally.
Signed-off-by: Will Deacon <[email protected]>
|
|
Commit 606f8e7b27bf ("arm64: capabilities: Use linear array for
detection and verification") changed the way we deal with per-CPU errata
by only calling the .matches() callback until one CPU is found to be
affected. At this point, .matches() stop being called, and .cpu_enable()
will be called on all CPUs.
This breaks the ARCH_WORKAROUND_2 handling, as only a single CPU will be
mitigated.
In order to address this, forcefully call the .matches() callback from a
.cpu_enable() callback, which brings us back to the original behaviour.
Fixes: 606f8e7b27bf ("arm64: capabilities: Use linear array for detection and verification")
Cc: <[email protected]>
Reviewed-by: Suzuki K Poulose <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
Signed-off-by: Marc Zyngier <[email protected]>
|
|
As we can now hide events from the guest, let's also adjust its view of
PCMEID{0,1}_EL1 so that it can figure out why some common events are not
counting as they should.
The astute user can still look into the TRM for their CPU and find out
they've been cheated, though. Nobody's perfect.
Signed-off-by: Marc Zyngier <[email protected]>
|
|
It can be desirable to expose a PMU to a guest, and yet not want the
guest to be able to count some of the implemented events (because this
would give information on shared resources, for example.
For this, let's extend the PMUv3 device API, and offer a way to setup a
bitmap of the allowed events (the default being no bitmap, and thus no
filtering).
Userspace can thus allow/deny ranges of event. The default policy
depends on the "polarity" of the first filter setup (default deny if the
filter allows events, and default allow if the filter denies events).
This allows to setup exactly what is allowed for a given guest.
Note that although the ioctl is per-vcpu, the map of allowed events is
global to the VM (it can be setup from any vcpu until the vcpu PMU is
initialized).
Reviewed-by: Andrew Jones <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
|
|
The PMU code suffers from a small defect where we assume that the event
number provided by the guest is always 16 bit wide, even if the CPU only
implements the ARMv8.0 architecture. This isn't really problematic in
the sense that the event number ends up in a system register, cropping
it to the right width, but still this needs fixing.
In order to make it work, let's probe the version of the PMU that the
guest is going to use. This is done by temporarily creating a kernel
event and looking at the PMUVer field that has been saved at probe time
in the associated arm_pmu structure. This in turn gets saved in the kvm
structure, and subsequently used to compute the event mask that gets
used throughout the PMU code.
Signed-off-by: Marc Zyngier <[email protected]>
|
|
The PMU emulation error handling is pretty messy when dealing with
attributes. Let's refactor it so that we have less duplication,
and that it is easy to extend later on.
A functional change is that kvm_arm_pmu_v3_init() used to return
-ENXIO when the PMU feature wasn't set. The error is now reported
as -ENODEV, matching the documentation. -ENXIO is still returned
when the interrupt isn't properly configured.
Signed-off-by: Marc Zyngier <[email protected]>
|
|
Fix the leds subnode names to match (^led-[0-9a-f]$|led).
Similar change has been also done by commit 08dc0e5dd9aa ("arm64: dts:
meson: fix leds subnodes name").
The patch is fixing this warning:
avnet-ultra96-rev1.dt.yaml: leds: 'ds2', 'ds3', 'ds4', 'ds5' do not match
any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/1a69c3fa0291f991ffcf113ea222c713ba4d4ff0.1598264917.git.michal.simek@xilinx.com
|
|
u-boot, DT properties are not documented anywhere in Linux DT binding
that's why remove them.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/8ba339425b9c9f319bdedce7741367055a30713c.1598257720.git.michal.simek@xilinx.com
Reviewed-by: Krzysztof Kozlowski <[email protected]>
|
|
DT binding permits only one compatible string which was decribed in past by
commit 63cab195bf49 ("i2c: removed work arounds in i2c driver for Zynq
Ultrascale+ MPSoC").
The commit aea37006e183 ("dt-bindings: i2c: cadence: Migrate i2c-cadence
documentation to YAML") has converted binding to yaml and the following
issues is reported:
...: i2c@ff030000: compatible: Additional items are not allowed
('cdns,i2c-r1p10' was unexpected)
From schema:
.../Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml fds
...: i2c@ff030000: compatible: ['cdns,i2c-r1p14', 'cdns,i2c-r1p10'] is too
long
The commit c415f9e8304a ("ARM64: zynqmp: Fix i2c node's compatible string")
has added the second compatible string but without removing origin one.
The patch is only keeping one compatible string "cdns,i2c-r1p14".
Fixes: c415f9e8304a ("ARM64: zynqmp: Fix i2c node's compatible string")
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/cc294ae1a79ef845af6809ddb4049f0c0f5bb87a.1598259551.git.michal.simek@xilinx.com
Reviewed-by: Krzysztof Kozlowski <[email protected]>
|
|
Rename amba-apu and amba to AXI. Based on Xilinx ZynqMP TRM (Chapter 15)
chip is "using the advanced eXtensible interface (AXI) point-to-point
channels for communicating addresses, data, and response transactions
between master and slave clients."
Issues are reported as:
...: amba: $nodename:0: 'amba' does not match
'^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
From schema: .../dt-schema/dtschema/schemas/simple-bus.yaml
...: amba-apu@0: $nodename:0: 'amba-apu@0' does not match
'^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
From schema: .../dt-schema/dtschema/schemas/simple-bus.yaml
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/68f20a2b2bb0feee80bc3348619c2ee98aa69963.1598263539.git.michal.simek@xilinx.com
Reviewed-by: Krzysztof Kozlowski <[email protected]>
|
|
The convention for node names is to use hyphens, not underscores.
dtschema for pca95xx expects GPIO hogs to end with 'hog' prefix.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux into for-joerg/arm-smmu/updates
Pull in core arm64 changes required to enable Shared Virtual Memory
(SVM) using SMMUv3. This brings us increasingly closer to being able to
share page-tables directly between user-space tasks running on the CPU
and their corresponding contexts on coherent devices performing DMA
through the SMMU.
Signed-off-by: Will Deacon <[email protected]>
|
|
Reading the 'prod' MMIO register in order to determine whether or not
there is valid data beyond 'cons' for a given queue does not provide
sufficient dependency ordering, as the resulting access is address
dependent only on 'cons' and can therefore be speculated ahead of time,
potentially allowing stale data to be read by the CPU.
Use readl() instead of readl_relaxed() when updating the shadow copy of
the 'prod' pointer, so that all speculated memory reads from the
corresponding queue can occur only from valid slots.
Signed-off-by: Zhou Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[will: Use readl() instead of explicit barrier. Update 'cons' side to match.]
Signed-off-by: Will Deacon <[email protected]>
|
|
The SMMUv3 driver would like to read the MMFR0 PARANGE field in order to
share CPU page tables with devices. Allow the driver to be built as
module by exporting the read_sanitized_ftr_reg() cpufeature symbol.
Signed-off-by: Jean-Philippe Brucker <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Acked-by: Suzuki K Poulose <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
To enable address space sharing with the IOMMU, introduce
arm64_mm_context_get() and arm64_mm_context_put(), that pin down a
context and ensure that it will keep its ASID after a rollover. Export
the symbols to let the modular SMMUv3 driver use them.
Pinning is necessary because a device constantly needs a valid ASID,
unlike tasks that only require one when running. Without pinning, we would
need to notify the IOMMU when we're about to use a new ASID for a task,
and it would get complicated when a new task is assigned a shared ASID.
Consider the following scenario with no ASID pinned:
1. Task t1 is running on CPUx with shared ASID (gen=1, asid=1)
2. Task t2 is scheduled on CPUx, gets ASID (1, 2)
3. Task tn is scheduled on CPUy, a rollover occurs, tn gets ASID (2, 1)
We would now have to immediately generate a new ASID for t1, notify
the IOMMU, and finally enable task tn. We are holding the lock during
all that time, since we can't afford having another CPU trigger a
rollover. The IOMMU issues invalidation commands that can take tens of
milliseconds.
It gets needlessly complicated. All we wanted to do was schedule task tn,
that has no business with the IOMMU. By letting the IOMMU pin tasks when
needed, we avoid stalling the slow path, and let the pinning fail when
we're out of shareable ASIDs.
After a rollover, the allocator expects at least one ASID to be available
in addition to the reserved ones (one per CPU). So (NR_ASIDS - NR_CPUS -
1) is the maximum number of ASIDs that can be shared with the IOMMU.
Signed-off-by: Jean-Philippe Brucker <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
kvm_vcpu_kick() is not NMI safe. When the overflow handler is called from
NMI context, defer waking the vcpu to an irq_work queue.
A vcpu can be freed while it's not running by kvm_destroy_vm(). Prevent
running the irq_work for a non-existent vcpu by calling irq_work_sync() on
the PMU destroy path.
[Alexandru E.: Added irq_work_sync()]
Signed-off-by: Julien Thierry <[email protected]>
Signed-off-by: Alexandru Elisei <[email protected]>
Tested-by: Sumit Garg <[email protected]> (Developerbox)
Cc: Julien Thierry <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: James Morse <[email protected]>
Cc: Suzuki K Pouloze <[email protected]>
Cc: [email protected]
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
When handling events, armv8pmu_handle_irq() calls perf_event_overflow(),
and subsequently calls irq_work_run() to handle any work queued by
perf_event_overflow(). As perf_event_overflow() raises IPI_IRQ_WORK when
queuing the work, this isn't strictly necessary and the work could be
handled as part of the IPI_IRQ_WORK handler.
In the common case the IPI handler will run immediately after the PMU IRQ
handler, and where the PE is heavily loaded with interrupts other handlers
may run first, widening the window where some counters are disabled.
In practice this window is unlikely to be a significant issue, and removing
the call to irq_work_run() would make the PMU IRQ handler NMI safe in
addition to making it simpler, so let's do that.
[Alexandru E.: Reworded commit message]
Signed-off-by: Julien Thierry <[email protected]>
Signed-off-by: Alexandru Elisei <[email protected]>
Cc: Julien Thierry <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Catalin Marinas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
The PMU is disabled and enabled, and the counters are programmed from
contexts where interrupts or preemption is disabled.
The functions to toggle the PMU and to program the PMU counters access the
registers directly and don't access data modified by the interrupt handler.
That, and the fact that they're always called from non-preemptible
contexts, means that we don't need to disable interrupts or use a spinlock.
[Alexandru E.: Explained why locking is not needed, removed WARN_ONs]
Signed-off-by: Julien Thierry <[email protected]>
Signed-off-by: Alexandru Elisei <[email protected]>
Tested-by: Sumit Garg <[email protected]> (Developerbox)
Cc: Will Deacon <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Catalin Marinas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
Currently we access the counter registers and their respective type
registers indirectly. This requires us to write to PMSELR, issue an ISB,
then access the relevant PMXEV* registers.
This is unfortunate, because:
* Under virtualization, accessing one register requires two traps to
the hypervisor, even though we could access the register directly with
a single trap.
* We have to issue an ISB which we could otherwise avoid the cost of.
* When we use NMIs, the NMI handler will have to save/restore the select
register in case the code it preempted was attempting to access a
counter or its type register.
We can avoid these issues by directly accessing the relevant registers.
This patch adds helpers to do so.
In armv8pmu_enable_event() we still need the ISB to prevent the PE from
reordering the write to PMINTENSET_EL1 register. If the interrupt is
enabled before we disable the counter and the new event is configured,
we might get an interrupt triggered by the previously programmed event
overflowing, but which we wrongly attribute to the event that we are
enabling. Execute an ISB after we disable the counter.
In the process, remove the comment that refers to the ARMv7 PMU.
[Julien T.: Don't inline read/write functions to avoid big code-size
increase, remove unused read_pmevtypern function,
fix counter index issue.]
[Alexandru E.: Removed comment, removed trailing semicolons in macros,
added ISB]
Signed-off-by: Mark Rutland <[email protected]>
Signed-off-by: Julien Thierry <[email protected]>
Signed-off-by: Alexandru Elisei <[email protected]>
Tested-by: Sumit Garg <[email protected]> (Developerbox)
Cc: Julien Thierry <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Catalin Marinas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
Writes to the PMXEVTYPER_EL0 register are not self-synchronising. In
armv8pmu_enable_event(), the PE can reorder configuring the event type
after we have enabled the counter and the interrupt. This can lead to an
interrupt being asserted because of the previous event type that we were
counting using the same counter, not the one that we've just configured.
The same rationale applies to writes to the PMINTENSET_EL1 register. The PE
can reorder enabling the interrupt at any point in the future after we have
enabled the event.
Prevent both situations from happening by adding an ISB just before we
enable the event counter.
Fixes: 030896885ade ("arm64: Performance counters support")
Reported-by: Julien Thierry <[email protected]>
Signed-off-by: Alexandru Elisei <[email protected]>
Tested-by: Sumit Garg <[email protected]> (Developerbox)
Cc: Julien Thierry <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Catalin Marinas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
ARMv8.4-PMU introduces the PMMIR_EL1 registers and some new PMU events,
like STALL_SLOT etc, are related to it. Let's add a caps directory to
/sys/bus/event_source/devices/armv8_pmuv3_0/ and support slots from
PMMIR_EL1 registers in this entry. The user programs can get the slots
from sysfs directly.
/sys/bus/event_source/devices/armv8_pmuv3_0/caps/slots is exposed
under sysfs. Both ARMv8.4-PMU and STALL_SLOT event are implemented,
it returns the slots from PMMIR_EL1, otherwise it will return 0.
Signed-off-by: Shaokun Zhang <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Mark Rutland <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
'origin/irq/owl' into irq/irqchip-next
Signed-off-by: Marc Zyngier <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/defconfig
Samsung defconfig changes for v5.10
1. Re-enable platform media drivers as new dependency on
MEDIA_PLATFORM_SUPPORT appeared.
2. Enable ROHM BD718x7 PMIC present on some of boards with i.MX 8 SoCs.
3. Enable Samsung S3FWRN5 NFC driver present on TM2/TM2E boards.
* tag 'samsung-defconfig-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
arm64: defconfig: Enable Samsung S3FWRN5 NFC driver
arm64: defconfig: Enable clock driver for ROHM BD718x7 PMIC
ARM: exynos_defconfig: enable platform media drivers
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Olof Johansson <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/defconfig
arm64: tegra: Default configuration updates for v5.10-rc1
This pair of patches enable the ADMA, ACONNECT and AHUB drivers that
are required for audio support on Tegra210 and later.
* tag 'tegra-for-5.10-arm64-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: defconfig: Build ADMA and ACONNECT driver
arm64: defconfig: Build AHUB component drivers
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Olof Johansson <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into arm/dt
mt8173:
- make nor flash work
- fix da9211 regulator modes
mt8183:
- add support for system companion processor
mt8516:
- set reset gpio for gpio expander in pumpkin board
* tag 'v5.9-next-dts64' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
arm64: dts: mt8183: update watchdog device node
arm64: dts: mt8173: elm: Fix nor_flash node property
arm64: dts: mediatek: fix tca6416 reset GPIOs in pumpkin
arm64: dts: mt8183: add scp node
arm64: dts: mt8173-elm: fix supported values for regulator-allowed-modes of da9211
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Olof Johansson <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/dt
arm64: dtc: amlogic updates for v5.10
- new boards: libretch s905x cc v2, Hardkernel ODROID-N2+
- vim3: sound updates
* tag 'amlogic-dt64' of https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic:
arm64: dts: meson: initial support for aml-s905x-cc v2
dt-bindings: arm: amlogic: add support for libretch s905x cc v2
arm64: dts: meson: add support for the ODROID-N2+
dt-bindings: arm: amlogic: add support for the ODROID-N2+
arm64: dts: meson: convert ODROID-N2 to dtsi
arm64: dts: meson: vim3l: remove sound card definition
arm64: dts: meson: vim3: make sound card common to all variants
arm64: dts: meson: vim3: correct led polarity
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Olof Johansson <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
Qualcomm ARM64 DT updates for v5.10
Cleanup, refactor and modernize MSM8916 by sorting nodes, moving device
and platform specific parts to their respective files, add and use
labels for reference nodes and use IRQ defines. Migrate TCSR mutex off
the depricated binding, add resin node for PM8916.
Add LPASS clock controller for SC7180. Fix the LLCC reg, increase
interconnect-cells, drop flags on MDSS irqs. Add interconnects for
display, eMMC and SD-card, specify 'sustainable_power' for CPU thermal
zones, improve pinconf states related to UART and Bluetooth. Add new DT
for Lazor and Trogdor.
Increase #interconnect-cells for SDM845 to allow tags, add OPP tables
and power-domains for Venus and interconnects for display. Fix the ports
on the HDMI nodes for DB845c and add DT for the Xiaomi Poco F1.
Add interconnect providers, fix up primary USB's clock and use
dt-binding defines for GPU clocks on SM8150.
Add interconnect providers, CPUfreq, thermal configuration and missing
uarts for SM8250. Fix up naming of debug uart, add always-on supply
clock to gcc, fix up the sleep clock rate and define OPP tables for all
QUP devices. Then add a new DeviceTree for the QRB5165 RB5 board.
Enable watchdog on IPQ8074 and use the appropriate compatible for the
PMU node. Enable DVFS support for IPQ6018.
Finally correct the spelling of "interrupts" in MSM8992 uart node, fix
missing # in PM660 #interrupt-cells, add second VFE power-domain to
camss in MSM8996 and sort the Makefile.
* tag 'qcom-arm64-for-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (75 commits)
arm64: dts: qcom: sm8250: Add thermal zones and throttling support
arm64: dts: qcom: sm8250: Add cpufreq hw node
arm64: dts: qcom: sdm845: Add interconnects property for display
arm64: dts: qcom: sm8250: Add EPSS L3 interconnect provider
arm64: dts: qcom: sm8150: Add OSM L3 interconnect provider
arm64: dts: qcom: sm8250: add interconnect nodes
arm64: dts: qcom: sm8150: add interconnect nodes
arm64: dts: qcom: sc7180: Increase the number of interconnect cells
arm64: dts: qcom: sdm845: Increase the number of interconnect cells
arm64: dts: qcom: Makefile: Sort lines
arm64: dts: qcom: pm8916: Sort nodes
arm64: dts: qcom: msm8916: Sort nodes
arm64: dts: qcom: msm8916: Pad addresses
arm64: dts: qcom: msm8916: Rename "x-smp2p" to "smp2p-x"
arm64: dts: qcom: msm8916: Use more generic node names
arm64: dts: qcom: msm8916: Add MSM8916-specific compatibles to SCM/MSS
arm64: dts: qcom: msm8916: Minor style fixes
arm64: dts: qcom: msm8916: Drop qcom,tcsr-mutex syscon
arm64: dts: qcom: msm8916: Use IRQ defines, add IRQ types
arm64: dts: qcom: msm8916: Fix MDP/DSI interrupts
...
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Olof Johansson <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
New boards NanoPi R2S, A95X-Z2 and more Rock-Pi4 variants.
Khadas-edge additions and a some fixes.
* tag 'v5.10-rockchip-dts64-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: add ir-receiver node to rk3399-khadas-edge
arm64: dts: rockchip: add spiflash node to rk3399-khadas-edge
arm64: dts: rockchip: Add support for FriendlyARM NanoPi R2S
dt-bindings: Add doc for FriendlyARM NanoPi R2S
arm64: dts: rockchip: replace status value "ok" by "okay"
arm64: dts: rockchip: fix cpu-supply for rk3328-evb
arm64: dts: rockchip: add rk3318 A95X Z2 board
dt-bindings: arm: rockchip: add Zkmagic A95X Z2 description
dt-bindings: Add vendor prefix for Shenzhen Zkmagic Technology Co., Ltd.
arm64: dts: rockchip: Add Radxa ROCK Pi 4C support
arm64: dts: rockchip: Add Radxa ROCK Pi 4B support
arm64: dts: rockchip: Mark rock-pi-4 as rock-pi-4a dts
dt-bindings: arm: rockchip: Update ROCKPi 4 binding
arm64: dts: rockchip: change spdif fallback compatible on rk3308
arm64: dts: rockchip: Fix power routing to support POE on rk3399-roc-pc
Link: https://lore.kernel.org/r/16010805.MhVyP8KKtY@diego
Signed-off-by: Olof Johansson <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/dt
i.MX arm64 device tree change for 5.10:
- New board/device support: Librem 5 phone, i.MX8MM DDR4 EVK, Variscite
VAR-SOM-MX8MN SoM and Symphony board.
- Add NWL MIPI DSI controller support for i.MX8MQ.
- Several series from Krzysztof Kozlowski to clean and fix up i.MX8
based device trees according to DT schema.
- A series from Michael Walle to add sl28cpld support for Kontron sl28
device based on LS1028A.
- Add two parameters for Samsung picophy tuning on imx8mm-evk and
imx8mn-evk boards.
- Add more thermal zones for Layerscape SoCs.
- Various random update and minor fix-ups.
* tag 'imx-dt64-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: (71 commits)
arm64: dts: imx8mq-librem5: correct GPIO hog property
arm64: dts: imx8mm-var-som-symphony: Drop wake-up source from RTC
arm64: dts: imx8mq: correct interrupt flags
arm64: dts: imx8mn: correct interrupt flags
arm64: dts: imx8mm: correct interrupt flags
arm64: dts: imx8mm-var-som-symphony: fix ptn5150 interrupts
arm64: dts: layerscape: correct watchdog clocks for LS1088A
arm64: dts: freescale: sl28: enable fan support
arm64: dts: freescale: sl28: enable LED support
arm64: dts: freescale: sl28: map GPIOs to input events
arm64: dts: freescale: sl28: enable sl28cpld
arm64: dts: imx8mq-evk: Add MIPI DSI support
arm64: dts: layerscape: Add label to pcie nodes
arm64: dts: imx8mn-var-som-symphony: Add Variscite Symphony board with VAR-SOM-MX8MN
arm64: dts: imx8mn-var-som: Add Variscite VAR-SOM-MX8MN System on Module
arm64: dts: imx8mn-ddr4-evk: Remove unneeded PMIC pin configuration
arm64: dts: imx8mm-var-som-symphony: Adjust ethernet pin configuration
arm64: dts: imx8mm-var-som-symphony: Remove unneeded i2c3 properties
arm64: dts: imx8mm-var-som-symphony: Drop unused gpioledgrp
arm64: dts: imx8mq-librem5: Add interrupt-names to ti,tps6598x
...
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Olof Johansson <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux into arm/dt
Device tree updates towards 5.10-rc1 for TI K3 platform.
* tag 'ti-k3-dt-for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux: (23 commits)
arm64: dts: ti: k3-j721e-common-proc-board: Configure the PCIe instances
arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes
arm64: dts: ti: k3-*: Fix up node_name_chars_strict warnings
arm64: dts: ti: k3-am65-wakeup: Use generic temperature-sensor for node name
arm64: dts: ti: k3-am65-base-board Use generic camera for node name instead of ov5640
arm64: dts: ti: k3-*: Use generic pinctrl for node names
arm64: dts: ti: k3-am65*: Use generic clock for syscon clock names
arm64: dts: ti: k3-am65*: Use generic gpio for node names
arm64: dts: ti: k3-am65-main: Use lower case hexadecimal
arm64: dts: ti: k3-j721e: Use lower case hexadecimal
arm64: dts: ti: k3-am65: restrict PCIe to Gen2 speed
arm64: dts: ti: k3-j721e-som-p0: Reserve memory for IPC between RTOS cores
arm64: dts: ti: k3-j721e-som-p0: Add DDR carveout memory nodes for C71x DSP
arm64: dts: ti: k3-j721e-som-p0: Add mailboxes to C71x DSP
arm64: dts: ti: k3-j721e-main: Add C71x DSP node
arm64: dts: ti: k3-j721e-som-p0: Add DDR carveout memory nodes for C66 DSPs
arm64: dts: ti: k3-j721e-som-p0: Add mailboxes to C66x DSPs
arm64: dts: ti: k3-j721e-main: Add C66x DSP nodes
arm64: dts: ti: k3-j721e-som-p0: Move mailbox nodes from board dts file
arm64: dts: ti: k3-j721e-main: Add crypto accelerator node
...
Link: https://lore.kernel.org/r/20200922134722.2y5kqxu4lghbwp5u@akan
Signed-off-by: Olof Johansson <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm ARM64 DT fixes for v5.9
This fixes the OPP table for SDM845 QUP devices to bring back
Bluetooth support, disables SMMU on SDM630 to make the devices boot
again, disables the eMMC controller on Kitakami to prevent permanent
damage and fixes a typo in the pm660.
* tag 'qcom-arm64-fixes-for-5.9' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: pm660: Fix missing pound sign in interrupt-cells
arm64: dts: qcom: kitakami: Temporarily disable SDHCI1
arm64: dts: sdm630: Temporarily disable SMMUs by default
arm64: dts: sdm845: Fixup OPP table for all qup devices
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Olof Johansson <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes
Two fixes for the Allwinner SoCs, one for the H5 GPU support and one for
a misconfigured regulator on the Bananapi M2 Ultra.
* tag 'sunxi-fixes-for-5.9-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
arm64: dts: allwinner: h5: remove Mali GPU PMU module
ARM: dts: sun8i: r40: bananapi-m2-ultra: Fix dcdc1 regulator
Link: https://lore.kernel.org/r/8a436328-b844-4599-8695-ab2088a00ade.lettre@localhost
Signed-off-by: Olof Johansson <[email protected]>
|