| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Now the uaccess primitives use LDTR/STTR unconditionally, the
uao_{ldp,stp,user_alternative} asm macros are misnamed, and have a
redundant argument. Let's remove the redundant argument and rename these
to user_{ldp,stp,ldst} respectively to clean this up.
Signed-off-by: Mark Rutland <[email protected]>
Reviewed-by: Robin Murohy <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: James Morse <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
This patch separates arm64's user and kernel memory access primitives
into distinct routines, adding new __{get,put}_kernel_nofault() helpers
to access kernel memory, upon which core code builds larger copy
routines.
The kernel access routines (using LDR/STR) are not affected by PAN (when
legitimately accessing kernel memory), nor are they affected by UAO.
Switching to KERNEL_DS may set UAO, but this does not adversely affect
the kernel access routines.
The user access routines (using LDTR/STTR) are not affected by PAN (when
legitimately accessing user memory), but are affected by UAO. As these
are only legitimate to use under USER_DS with UAO clear, this should not
be problematic.
Routines performing atomics to user memory (futex and deprecated
instruction emulation) still need to transiently clear PAN, and these
are left as-is. These are never used on kernel memory.
Subsequent patches will refactor the uaccess helpers to remove redundant
code, and will also remove the redundant PAN/UAO manipulation.
Signed-off-by: Mark Rutland <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: James Morse <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
As a step towards implementing __{get,put}_kernel_nofault(), this patch
splits most user-memory specific logic out of __{get,put}_user(), with
the memory access and fault handling in new __{raw_get,put}_mem()
helpers.
For now the LDR/LDTR patching is left within the *get_mem() helpers, and
will be removed in a subsequent patch.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: James Morse <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
Currently __copy_user_flushcache() open-codes raw_copy_from_user(), and
doesn't use uaccess_mask_ptr() on the user address. Let's have it call
raw_copy_from_user(), which is both a simplification and ensures that
user pointers are masked under speculation.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <[email protected]>
Reviewed-by: Robin Murphy <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
We currently have many uaccess_*{enable,disable}*() variants, which
subsequent patches will cut down as part of removing set_fs() and
friends. Once this simplification is made, most uaccess routines will
only need to ensure that the user page tables are mapped in TTBR0, as is
currently dealt with by uaccess_ttbr0_{enable,disable}().
The existing uaccess_{enable,disable}() routines ensure that user page
tables are mapped in TTBR0, and also disable PAN protections, which is
necessary to be able to use atomics on user memory, but also permit
unrelated privileged accesses to access user memory.
As preparatory step, let's rename uaccess_{enable,disable}() to
uaccess_{enable,disable}_privileged(), highlighting this caveat and
discouraging wider misuse. Subsequent patches can reuse the
uaccess_{enable,disable}() naming for the common case of ensuring the
user page tables are mapped in TTBR0.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: James Morse <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
In preparation for removing addr_limit and set_fs() we must decouple the
SDEI PAN/UAO manipulation from the uaccess code, and explicitly
reinitialize these as required.
SDEI enters the kernel with a non-architectural exception, and prior to
the most recent revision of the specification (ARM DEN 0054B), PSTATE
bits (e.g. PAN, UAO) are not manipulated in the same way as for
architectural exceptions. Notably, older versions of the spec can be
read ambiguously as to whether PSTATE bits are inherited unchanged from
the interrupted context or whether they are generated from scratch, with
TF-A doing the latter.
We have three cases to consider:
1) The existing TF-A implementation of SDEI will clear PAN and clear UAO
(along with other bits in PSTATE) when delivering an SDEI exception.
2) In theory, implementations of SDEI prior to revision B could inherit
PAN and UAO (along with other bits in PSTATE) unchanged from the
interrupted context. However, in practice such implementations do not
exist.
3) Going forward, new implementations of SDEI must clear UAO, and
depending on SCTLR_ELx.SPAN must either inherit or set PAN.
As we can ignore (2) we can assume that upon SDEI entry, UAO is always
clear, though PAN may be clear, inherited, or set per SCTLR_ELx.SPAN.
Therefore, we must explicitly initialize PAN, but do not need to do
anything for UAO.
Considering what we need to do:
* When set_fs() is removed, force_uaccess_begin() will have no HW
side-effects. As this only clears UAO, which we can assume has already
been cleared upon entry, this is not a problem. We do not need to add
code to manipulate UAO explicitly.
* PAN may be cleared upon entry (in case 1 above), so where a kernel is
built to use PAN and this is supported by all CPUs, the kernel must
set PAN upon entry to ensure expected behaviour.
* PAN may be inherited from the interrupted context (in case 3 above),
and so where a kernel is not built to use PAN or where PAN support is
not uniform across CPUs, the kernel must clear PAN to ensure expected
behaviour.
This patch reworks the SDEI code accordingly, explicitly setting PAN to
the expected state in all cases. To cater for the cases where the kernel
does not use PAN or this is not uniformly supported by hardware we add a
new cpu_has_pan() helper which can be used regardless of whether the
kernel is built to use PAN.
The existing system_uses_ttbr0_pan() is redefined in terms of
system_uses_hw_pan() both for clarity and as a minor optimization when
HW PAN is not selected.
Signed-off-by: Mark Rutland <[email protected]>
Reviewed-by: James Morse <[email protected]>
Cc: James Morse <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
The SDEI support code is split across arch/arm64/ and drivers/firmware/,
largley this is split so that the arch-specific portions are under
arch/arm64, and the management logic is under drivers/firmware/.
However, exception entry fixups are currently under drivers/firmware.
Let's move the exception entry fixups under arch/arm64/. This
de-clutters the management logic, and puts all the arch-specific
portions in one place. Doing this also allows the fixups to be applied
earlier, so things like PAN and UAO will be in a known good state before
we run other logic. This will also make subsequent refactoring easier.
Signed-off-by: Mark Rutland <[email protected]>
Reviewed-by: James Morse <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
As with SCTLR_ELx and other control registers, some PSTATE bits are
UNKNOWN out-of-reset, and we may not be able to rely on hardware or
firmware to initialize them to our liking prior to entry to the kernel,
e.g. in the primary/secondary boot paths and return from idle/suspend.
It would be more robust (and easier to reason about) if we consistently
initialized PSTATE to a default value, as we do with control registers.
This will ensure that the kernel is not adversely affected by bits it is
not aware of, e.g. when support for a feature such as PAN/UAO is
disabled.
This patch ensures that PSTATE is consistently initialized at boot time
via an ERET. This is not intended to relax the existing requirements
(e.g. DAIF bits must still be set prior to entering the kernel). For
features detected dynamically (which may require system-wide support),
it is still necessary to subsequently modify PSTATE.
As ERET is not always a Context Synchronization Event, an ISB is placed
before each exception return to ensure updates to control registers have
taken effect. This handles the kernel being entered with SCTLR_ELx.EOS
clear (or any future control bits being in an UNKNOWN state).
Signed-off-by: Mark Rutland <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: James Morse <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
Let's make SCTLR_ELx initialization a bit clearer by using meaningful
names for the initialization values, following the same scheme for
SCTLR_EL1 and SCTLR_EL2.
These definitions will be used more widely in subsequent patches.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: James Morse <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
For a while now el2_setup has performed some basic initialization of EL1
even when the kernel is booted at EL1, so the name is a little
misleading. Further, some comments are stale as with VHE it doesn't drop
the CPU to EL1.
To clarify things, rename el2_setup to init_kernel_el, and update
comments to be clearer as to the function's purpose.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: James Morse <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
To make callsites easier to read, add trivial C wrappers for the
SET_PSTATE_*() helpers, and convert trivial uses over to these. The new
wrappers will be used further in subsequent patches.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: James Morse <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
For consistency, all tasks have a pt_regs reserved at the highest
portion of their task stack. Among other things, this ensures that a
task's SP is always pointing within its stack rather than pointing
immediately past the end.
While it is never legitimate to ERET from a kthread, we take pains to
initialize pt_regs for kthreads as if this were legitimate. As this is
never legitimate, the effects of an erroneous return are rarely tested.
Let's simplify things by initializing a kthread's pt_regs such that an
ERET is caught as an illegal exception return, and removing the explicit
initialization of other exception context. Note that as
spectre_v4_enable_task_mitigation() only manipulates the PSTATE within
the unused regs this is safe to remove.
As user tasks will have their exception context initialized via
start_thread() or start_compat_thread(), this should only impact cases
where something has gone very wrong and we'd like that to be clearly
indicated.
Signed-off-by: Mark Rutland <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: James Morse <[email protected]>
Cc: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
If we get a FSC_PERM fault, just using (logging_active && writable) to
determine calling kvm_pgtable_stage2_map(). There will be two more cases
we should consider.
(1) After logging_active is configged back to false from true. When we
get a FSC_PERM fault with write_fault and adjustment of hugepage is needed,
we should merge tables back to a block entry. This case is ignored by still
calling kvm_pgtable_stage2_relax_perms(), which will lead to an endless
loop and guest panic due to soft lockup.
(2) We use (FSC_PERM && logging_active && writable) to determine
collapsing a block entry into a table by calling kvm_pgtable_stage2_map().
But sometimes we may only need to relax permissions when trying to write
to a page other than a block.
In this condition,using kvm_pgtable_stage2_relax_perms() will be fine.
The ISS filed bit[1:0] in ESR_EL2 regesiter indicates the stage2 lookup
level at which a D-abort or I-abort occurred. By comparing granule of
the fault lookup level with vma_pagesize, we can strictly distinguish
conditions of calling kvm_pgtable_stage2_relax_perms() or
kvm_pgtable_stage2_map(), and the above two cases will be well considered.
Suggested-by: Keqian Zhu <[email protected]>
Signed-off-by: Yanan Wang <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When dirty logging is enabled, we collapse block entries into tables
as necessary. If dirty logging gets canceled, we can end-up merging
tables back into block entries.
When this happens, we must not only free the non-huge page-table
pages but also invalidate all the TLB entries that can potentially
cover the block. Otherwise, we end-up with multiple possible translations
for the same physical page, which can legitimately result in a TLB
conflict.
To address this, replease the bogus invalidation by IPA with a full
VM invalidation. Although this is pretty heavy handed, it happens
very infrequently and saves a bunch of invalidations by IPA.
Signed-off-by: Yanan Wang <[email protected]>
[maz: fixup commit message]
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When installing a new leaf PTE onto an invalid ptep, we need to
get_page(ptep) to account for the new mapping.
However, simply updating a valid PTE shouldn't result in any
additional refcounting, as there is new mapping. This otherwise
results in a page being forever wasted.
Address this by fixing-up the refcount in stage2_map_walker_try_leaf()
if the PTE was already valid, balancing out the later get_page()
in stage2_map_walk_leaf().
Signed-off-by: Yanan Wang <[email protected]>
[maz: update commit message, add comment in the code]
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Currently, '--orphan-handling=warn' is spread out across four different
architectures in their respective Makefiles, which makes it a little
unruly to deal with in case it needs to be disabled for a specific
linker version (in this case, ld.lld 10.0.1).
To make it easier to control this, hoist this warning into Kconfig and
the main Makefile so that disabling it is simpler, as the warning will
only be enabled in a couple places (main Makefile and a couple of
compressed boot folders that blow away LDFLAGS_vmlinx) and making it
conditional is easier due to Kconfig syntax. One small additional
benefit of this is saving a call to ld-option on incremental builds
because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN.
To keep the list of supported architectures the same, introduce
CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to
gain this automatically after all of the sections are specified and size
asserted. A special thanks to Kees Cook for the help text on this
config.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Acked-by: Kees Cook <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Reviewed-by: Nick Desaulniers <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Handling all combinations of the VMAP_STACK and SHADOW_CALL_STACK options
in sdei_arch_get_entry_point() makes the code difficult to read,
particularly when considering the error and cleanup paths.
Move the checking of these options into the callee functions, so that
they return early if the relevant option is not enabled.
Signed-off-by: Will Deacon <[email protected]>
|
|
Use scs_alloc() to allocate also IRQ and SDEI shadow stacks instead of
using statically allocated stacks.
Signed-off-by: Sami Tolvanen <[email protected]>
Acked-by: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[will: Move CONFIG_SHADOW_CALL_STACK check into init_irq_scs()]
Signed-off-by: Will Deacon <[email protected]>
|
|
Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
delay config") network is broken on the NanoPi Neo Plus2.
This patch changes the phy-mode to use internal delays both for RX and TX
as has been done for other boards affected by the same commit.
Fixes: bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
delay config") iSCSI booting fails on the Pine A64 LTS.
This patch changes the phy-mode to use internal delays both for RX and TX
as has been done for other boards affected by the same commit.
Fixes: bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The PMIC throws an errors because the clock isn't assigned to it.
Fix this by assigning the clocks info.
Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
On the i.MX8MM Beacon SOM, there is an RTC chip which is fed power
from the baseboard during power off. The SNVS RTC integrated into
the SoC is not fed power. Depending on the order the modules are
loaded, this can be a problem if the external RTC isn't rtc0.
Make the alias for rtc0 point to the external RTC all the time and
rtc1 point to the SVNS in order to correctly hold date/time over
a power-cycle.
Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
The i.MX8M Nano can support SPDIF which is compatible to the
IP used on the i.MX35.
Add the node.
Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
The i.MX8M Nano has supports the MICFIL digital interface.
It's a 16-bit audio signal from a PDM microphone bitstream.
The driver is already in the kernel, but the node is missing.
Add the micfil node.
Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
The i.MX8M Nano has several SAI nodes available to it.
Enable them.
Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
The driver exists for the Enhanced Asynchronous Sample Rate Converter
(EASRC) Controller, but there isn't a device tree entry for it.
On the vendor kernel, they put this on a spba-bus for SDMA support.
Add the node for the spba-bus with the easrc node inside.
Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
As the boot order in the kernel continues to change, sometimes it may
happen that the eSDHC controller mmc@2150000 (the one for eMMC) gets
probed before the one at mmc@2140000 (for external SD cards). The effect
is that the eMMC controller gets the /dev/mmcblk0 name, and the SD card
gets /dev/mmcblk1.
Since the introduction of this SoC, that has never happened in practice,
even though it was never guaranteed in theory. Setting
"root=/dev/mmcblk0p2" in /proc/cmdline has always caused the kernel to
use the second partition from the SD card as the rootfs.
The NXP development boards are typically shipped with either
- LSDK, which uses "root=UUID=", or
- OpenIL, which uses "root=/dev/mmcblkNp2"
So for OpenIL, let's preserve that old behavior by adding some aliases
which create naming consistency (for LSDK it doesn't matter):
- the SD card controller uses /dev/mmcblk0
- the eMMC controller uses /dev/mmcblk1
For the Kontron SL28 boards, Michael Walle says that they are shipped
with "root=UUID=" already, so the probing order doesn't matter, but it
is more natural to him for /dev/mmcblk0 to be the eMMC, so let's do it
the other way around there.
The aliases are parsed by mmc_alloc_host() in drivers/mmc/core/host.c.
Cc: Ashish Kumar <[email protected]>
Cc: Yangbo Lu <[email protected]>
Cc: Michael Walle <[email protected]>
Signed-off-by: Vladimir Oltean <[email protected]>
Acked-by: Michael Walle <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
This enables
- CONFIG_BATTERY_MAX17042: battery chip
- CONFIG_CHARGER_BQ25980: charge controller
- CONFIG_DRM_PANEL_MANTIX_MLAF057WE5: LCD panel
- CONFIG_GNSS/CONFIG_GNSS_MTK_SERIAL: GNSS receiver
- CONFIG_IIO_ST_LSM6DSX: IMU
- CONFIG_IMX_DCSS: 2nd display controller
- CONFIG_LEDS_LM3692X: LCD backlight
- CONFIG_REGULATOR_TPS65132: regulator for the LCD panel
- CONFIG_TOUCHSCREEN_EDT_FT5X06: touch controller
- CONFIG_TYPEC_TPS6598X: USB PD controller
- CONFIG_VCNL4000: ambient light and proximity sensor
as modules.
Signed-off-by: Guido Günther <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
The freqency 1512000000 should be 1500000000.
Signed-off-by: Dongjin Kim <[email protected]>
Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS")
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/20201130060320.GA30098@anyang-linuxfactory-or-kr
|
|
Set the IR keymap to the KHAMSIN remote shipped with the SML5442TW.
Signed-off-by: Christian Hewitt <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Update the VIM3/3L common dtsi to use the new function/color bindings.
Suggested-by: Artem Lapkin <[email protected]>
Signed-off-by: Christian Hewitt <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The max frequency for the w25q32 (VIM v1.2) and w25q128 (VIM v1.4) spifc
chip should be 104Mhz not 30MHz.
Fixes: b8b74dda3908 ("ARM64: dts: meson-gxm: Add support for Khadas VIM2")
Signed-off-by: Artem Lapkin <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Tweak the node name to make it aliasable, then add aliases for the
on-board RTC chip and meson-vrtc timer so they probe as rtc0 and
rtc1 respectively.
before:
VIM3:~ # dmesg | grep rtc
[ 3.622530] meson-vrtc ff8000a8.rtc: registered as rtc0
[ 3.622574] meson-vrtc ff8000a8.rtc: setting system clock to 1970-01-01T00:00:03 UTC (3)
[ 3.646936] rtc-hym8563 0-0051: no valid clock/calendar values available
[ 3.647125] rtc-hym8563 0-0051: registered as rtc1
[ 3.852382] rtc-hym8563 0-0051: no valid clock/calendar values available
after:
VIM3:~ # dmesg | grep rtc
[ 3.583735] meson-vrtc ff8000a8.rtc: registered as rtc1
[ 3.633888] rtc-hym8563 0-0051: no valid clock/calendar values available
[ 3.634120] rtc-hym8563 0-0051: registered as rtc0
[ 3.635250] rtc-hym8563 0-0051: no valid clock/calendar values available
[ 3.635267] rtc-hym8563 0-0051: hctosys: unable to read the hardware clock
[ 3.852632] rtc-hym8563 0-0051: no valid clock/calendar values available
Signed-off-by: Christian Hewitt <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
GXM (S912) is a big-little design with CPUs 0-3 clocked at 1.5GHz
and CPUs 4-7 at 1.0GHz. Adding capacity-dmips-mhz attributes allows
the scheduler to factor the different clock speeds into capacity
calculations and prefer the higher-clocked cluster to improve
overall performance.
This was inspired by the similar change for G12B [0] boards. The
diference here is that all cores are A53's so the same dmips-mhz
value is used.
VIM2:~ # cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
1512000
1512000
1512000
1512000
1000000
1000000
1000000
1000000
before:
VIM2:~ # cat /sys/devices/system/cpu/cpu*/cpu_capacity
1024
1024
1024
1024
1024
1024
1024
1024
after:
VIM2:~ # cat /sys/devices/system/cpu/cpu*/cpu_capacity
1024
1024
1024
1024
677
677
677
677
The after value matches my table-napkin calculation:
(1000000 / 1512000 = 0.661) * 1024 = 677
[0] https://github.com/torvalds/linux/commit/6eeaf4d2452ec8b1ece58776812140734fc2e088
Signed-off-by: Christian Hewitt <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Signed-off-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This adds the nodes for the :
- AXG PCIe PHY, using the shared analog PCIe/MIPI DSI PHY
- 2x AXG PCIe controllers
Signed-off-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This adds the nodes for :
- MIPI DSI+PCIe analog phy
- MIPI D-PHY
Signed-off-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This adds the power controller PWRC node and the corresponding ethernet power domain.
Signed-off-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Enable the rtc node on VIM1/VIM2 boards so users can simply attach a power
cell and use the on-board RTC without modifying the device-tree.
Cold boot with no cell attached is gracefully handled:
VIM2:~ # dmesg | grep rtc
[ 7.716150] rtc-hym8563 1-0051: no valid clock/calendar values available
[ 7.716957] rtc-hym8563 1-0051: registered as rtc0
[ 7.729850] rtc-hym8563 1-0051: no valid clock/calendar values available
[ 7.729877] rtc-hym8563 1-0051: hctosys: unable to read the hardware clock
[ 8.126768] rtc-hym8563 1-0051: no valid clock/calendar values available
Warm boot (and any boot with cell attached) recalls stored values resulting
in consistently faster (re)boot times:
VIM2:~ # dmesg | grep rtc
[ 7.441671] rtc-hym8563 1-0051: registered as rtc0
[ 7.442663] rtc-hym8563 1-0051: setting system clock to 2020-11-16T05:49:59 UTC (1605505799)
Suggested-by: Artem Lapkin <[email protected]>
Signed-off-by: Christian Hewitt <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
RTC HYM8563 used in the ARM64 Rockchip SoC's SDIO power
sequence enablement.
Enable it as module.
Signed-off-by: Jagan Teki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Heiko Stuebner <[email protected]>
|
|
UL in the definition of SYS_TFSR_EL1_TF1 was misspelled causing
compilation issues when trying to implement in kernel MTE async
mode.
Fix the macro correcting the typo.
Note: MTE async mode will be introduced with a future series.
Fixes: c058b1c4a5ea ("arm64: mte: system register definitions")
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Vincenzo Frascino <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
The Lenovo Yoga C630 drives the Boe NV133FHM-N61 eDP display from DSI
using a TI SN65DSI86 bridge chip on I2C 10. Define the bridge and eDP
panel and enable the display blocks.
Tested-by: Steev Klimaszewski <[email protected]>
Acked-by: Shawn Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
|
|
The "pins" property takes an array of pin _names_, not pin numbers. Fix
this.
Tested-by: Steev Klimaszewski <[email protected]>
Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
|
|
The numbering of the i2c busses differs from ACPI and a number of typos
was made in the original patch. Further more the irq flags for the
various resources was not correct and i2c3 only has one of the two
client devices active in any one device.
Also label the various devices, for easier comparison with the ACPI
tables.
Tested-by: Steev Klimaszewski <[email protected]>
Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
|
|
Add the I2S controller node to sc7180 dtsi.
Add pinmux for primary and secondary I2S.
Reviewed-by: Srinivas Kandagatla <[email protected]>
Signed-off-by: Ajit Pandey <[email protected]>
Signed-off-by: Cheng-Yi Chiang <[email protected]>
Signed-off-by: V Sujith Kumar Reddy <[email protected]>
Signed-off-by: Srinivasa Rao Mandadapu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
|
|
Add the QPIC BAM and QPIC NAND controller support and
enable the same in board DTS file.
Co-developed-by: Anusha Canchi Ramachandra Rao <[email protected]>
Signed-off-by: Anusha Canchi Ramachandra Rao <[email protected]>
Signed-off-by: Kathiravan T <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
|
|
Add the interconnects DT property to describe the ports for GENI QUPs
on the sdm845 platform.
Signed-off-by: Georgi Djakov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
|
|
The LID state can be read from GPIO 124 and the "tablet mode" from GPIO
95, expose these to the system using gpio-keys and mark the falling edge
of the LID state as a wakeup-source - to wake the system from suspend.
Tested-by: Steev Klimaszewski <[email protected]>
Acked-by: Shawn Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
|
|
Re-enable the apps_smmu now that the arm-smmu driver supports stream
mapping handoff from firmware.
Tested-by: Steev Klimaszewski <[email protected]>
Acked-by: Shawn Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
|
|
Add crypto engine (CE) and CE BAM related nodes and definitions to
"sdm845.dtsi".
Signed-off-by: Thara Gopinath <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[bjorn: Replaced RPMH_CE_CLK constant, for now]
Signed-off-by: Bjorn Andersson <[email protected]>
|