| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
With commit 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs
tracing") common code calls arch_cpu_idle() with a lockdep state that
tells irqs are on.
This doesn't work very well for s390: psw_idle() will enable interrupts
to wait for an interrupt. As soon as an interrupt occurs the interrupt
handler will verify if the old context was psw_idle(). If that is the
case the interrupt enablement bits in the old program status word will
be cleared.
A subsequent test in both the external as well as the io interrupt
handler checks if in the old context interrupts were enabled. Due to
the above patching of the old program status word it is assumed the
old context had interrupts disabled, and therefore a call to
TRACE_IRQS_OFF (aka trace_hardirqs_off_caller) is skipped. Which in
turn makes lockdep incorrectly "think" that interrupts are enabled
within the interrupt handler.
Fix this by unconditionally calling TRACE_IRQS_OFF when entering
interrupt handlers. Also call unconditionally TRACE_IRQS_ON when
leaving interrupts handlers.
This leaves the special psw_idle() case, which now returns with
interrupts disabled, but has an "irqs on" lockdep state. So callers of
psw_idle() must adjust the state on their own, if required. This is
currently only __udelay_disabled().
Fixes: 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs tracing")
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
|
|
The directed MSIs are delivered to CPUs whose address is
written to the MSI message address. The current code assumes
that a CPU logical number (as it is seen by the kernel)
is also the CPU address.
The above assumption is not correct, as the CPU address
is rather the value returned by STAP instruction. That
value does not necessarily match the kernel logical CPU
number.
Fixes: e979ce7bced2 ("s390/pci: provide support for CPU directed interrupts")
Cc: <[email protected]> # v5.2+
Signed-off-by: Alexander Gordeev <[email protected]>
Reviewed-by: Halil Pasic <[email protected]>
Reviewed-by: Niklas Schnelle <[email protected]>
Signed-off-by: Niklas Schnelle <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
|
|
This can be hit by an HPT guest running on an HPT host and bring down
the host, so it's quite important to fix.
Fixes: 7290f3b3d3e6 ("powerpc/64s/powernv: machine check dump SLB contents")
Cc: [email protected] # v5.4+
Signed-off-by: Nicholas Piggin <[email protected]>
Acked-by: Mahesh Salgaonkar <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Fix the following kernel-doc warning:
arch/x86/include/uapi/asm/sgx.h:19: warning: expecting prototype \
for enum sgx_epage_flags. Prototype was for enum sgx_page_flags instead
[ bp: Launder the commit message. ]
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://lkml.kernel.org/r/ca11a4540d981cbd5f026b6cbc8931aa55654e00.1606897462.git.mchehab+huawei@kernel.org
|
|
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]
|
|
SYS_USER_DISPATCH will be triggered when a syscall is sent to userspace
by the Syscall User Dispatch mechanism. This adjusts eventual
BUILD_BUG_ON around the tree.
Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>
Acked-by: Kees Cook <[email protected]>
Acked-by: Christian Brauner <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Syscall user redirection requires the signal trampoline code to not be
captured, in order to support returning with a locked selector while
avoiding recursion back into the signal handler. For ia-32, which has
the trampoline in the vDSO, expose the entry points to the kernel, such
that it can avoid dispatching syscalls from that region to userspace.
Suggested-by: Andy Lutomirski <[email protected]>
Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>
Acked-by: Andy Lutomirski <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
atmel,adc-res, atmel,adc-res-names and the trigger nodes are not parsed by
the driver anymore and the information is now defined in the driver data.
Also remove the leftover #address-cells and #size-cells that were used when
the trigger nodes had a unit-address.
Finally, the default is already to use the highest resoution. Remove
atmel,adc-use-res from the SoC dtsi.
Signed-off-by: Alexandre Belloni <[email protected]>
Reviewed-by: Ludovic Desroches <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The triggers for the ADC were taken from at91sam9260 dtsi but are not
correct.
Fixes: a4c1d6c75822 ("ARM: at91/dt: sam9rl: add lcd, adc, usb gadget and pwm support")
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The ADC is different from the at91sam9x5 ADC. Not only it doesn't have the
same resolution but it even has only one and the LOWRES bit doesn't exist.
Signed-off-by: Alexandre Belloni <[email protected]>
Reviewed-by: Ludovic Desroches <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Switch to the new pwm-atmel-tcb binding that avoid wasting TCB channels.
Signed-off-by: Alexandre Belloni <[email protected]>
Cc: Antoine Aubert <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Currently, if an MCE happens in user-mode or while the kernel is copying
data from user space, 'kill_it' is used to check if execution of the
interrupted task can be recovered or not; the flag name however is not
very meaningful, hence rename it to match its goal.
[ bp: Massage commit message, rename the queue_task_work() arg too. ]
Signed-off-by: Gabriele Paoloni <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
|
|
Currently, __mc_scan_banks() in do_machine_check() does the following
callchain:
__mc_scan_banks()->mce_log()->irq_work_queue(&mce_irq_work).
Hence, the call to irq_work_queue() below after __mc_scan_banks()
seems redundant. Just remove it.
Signed-off-by: Gabriele Paoloni <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
|
|
Right now for LMCE, if no_way_out is set, mce_panic() is called
regardless of mca_cfg.tolerant. This is not correct as, if
mca_cfg.tolerant = 3, the code should never panic.
Add that check.
[ bp: use local ptr 'cfg'. ]
Signed-off-by: Gabriele Paoloni <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
|
|
Right now, for local MCEs the machine calls panic(), if needed, right
after lmce is set. For MCE broadcasting, mce_reign() takes care of
calling mce_panic().
Hence:
- improve readability by moving the conditional evaluation of
tolerant up to when kill_it is set first;
- move the mce_panic() call up into the statement where mce_end()
fails.
[ bp: Massage, remove comment in the mce_end() failure case because it
is superfluous; use local ptr 'cfg' in both tests. ]
Signed-off-by: Gabriele Paoloni <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
|
|
Merge the -rc6 tag to pick up dependent changes.
Signed-off-by: Borislav Petkov <[email protected]>
|
|
Commit
fd8d9db3559a ("x86/resctrl: Remove superfluous kernfs_get() calls to prevent refcount leak")
removed superfluous kernfs_get() calls in rdtgroup_ctrl_remove() and
rdtgroup_rmdir_ctrl(). That change resulted in an unused function
parameter to these two functions.
Clean up the unused function parameter in rdtgroup_ctrl_remove(),
rdtgroup_rmdir_mon() and their callers rdtgroup_rmdir_ctrl() and
rdtgroup_rmdir().
Signed-off-by: Xiaochen Shen <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Reinette Chatre <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
|
|
Merge -rc6 tag to pick up dependent changes.
Signed-off-by: Borislav Petkov <[email protected]>
|
|
When the AMD QoS feature CDP (code and data prioritization) is enabled
or disabled, the CDP bit in MSR 0000_0C81 is written on one of the CPUs
in an L3 domain (core complex). That is not correct - the CDP bit needs
to be updated on all the logical CPUs in the domain.
This was not spelled out clearly in the spec earlier. The specification
has been updated and the updated document, "AMD64 Technology Platform
Quality of Service Extensions Publication # 56375 Revision: 1.02 Issue
Date: October 2020" is available now. Refer the section: Code and Data
Prioritization.
Fix the issue by adding a new flag arch_has_per_cpu_cfg in rdt_cache
data structure.
The documentation can be obtained at:
https://developer.amd.com/wp-content/resources/56375.pdf
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
[ bp: Massage commit message. ]
Fixes: 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature")
Signed-off-by: Babu Moger <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Reinette Chatre <[email protected]>
Link: https://lkml.kernel.org/r/160675180380.15628.3309402017215002347.stgit@bmoger-ubuntu
|
|
Revert the following two commits:
de3accdaec88 ("x86, build: Build 16-bit code with -m16 where possible")
a9cfccee6604 ("x86, build: Change code16gcc.h from a C header to an assembly header")
Since
0bddd227f3dc ("Documentation: update for gcc 4.9 requirement")
the minimum supported version of GCC is gcc-4.9. It's now safe to remove
this code.
Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Woodhouse <[email protected]>
Link: https://lkml.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]>
|
|
e820__mapped_all() is passed as a callback to is_mmconf_reserved(),
which expects a function of type:
typedef bool (*check_reserved_t)(u64 start, u64 end, unsigned type);
However, e820__mapped_all() accepts enum e820_type as the last argument
and this type mismatch trips indirect call checking with Clang's
Control-Flow Integrity (CFI).
As is_mmconf_reserved() only passes enum e820_type values for the
type argument, change the typedef and the unused type argument in
is_acpi_reserved() to enum e820_type to fix the type mismatch.
Reported-by: Sedat Dilek <[email protected]>
Suggested-by: Borislav Petkov <[email protected]>
Signed-off-by: Sami Tolvanen <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://lkml.kernel.org/r/[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]>
|
|
Commit 062cfab7069f ("KVM: PPC: Book3S HV: XIVE: Make VP block size
configurable") updated kvmppc_xive_vcpu_id_valid() in a way that
allows userspace to trigger an assertion in skiboot and crash the host:
[ 696.186248988,3] XIVE[ IC 08 ] eq_blk != vp_blk (0 vs. 1) for target 0x4300008c/0
[ 696.186314757,0] Assert fail: hw/xive.c:2370:0
[ 696.186342458,0] Aborting!
xive-kvCPU 0043 Backtrace:
S: 0000000031e2b8f0 R: 0000000030013840 .backtrace+0x48
S: 0000000031e2b990 R: 000000003001b2d0 ._abort+0x4c
S: 0000000031e2ba10 R: 000000003001b34c .assert_fail+0x34
S: 0000000031e2ba90 R: 0000000030058984 .xive_eq_for_target.part.20+0xb0
S: 0000000031e2bb40 R: 0000000030059fdc .xive_setup_silent_gather+0x2c
S: 0000000031e2bc20 R: 000000003005a334 .opal_xive_set_vp_info+0x124
S: 0000000031e2bd20 R: 00000000300051a4 opal_entry+0x134
--- OPAL call token: 0x8a caller R1: 0xc000001f28563850 ---
XIVE maintains the interrupt context state of non-dispatched vCPUs in
an internal VP structure. We allocate a bunch of those on startup to
accommodate all possible vCPUs. Each VP has an id, that we derive from
the vCPU id for efficiency:
static inline u32 kvmppc_xive_vp(struct kvmppc_xive *xive, u32 server)
{
return xive->vp_base + kvmppc_pack_vcpu_id(xive->kvm, server);
}
The KVM XIVE device used to allocate KVM_MAX_VCPUS VPs. This was
limitting the number of concurrent VMs because the VP space is
limited on the HW. Since most of the time, VMs run with a lot less
vCPUs, commit 062cfab7069f ("KVM: PPC: Book3S HV: XIVE: Make VP
block size configurable") gave the possibility for userspace to
tune the size of the VP block through the KVM_DEV_XIVE_NR_SERVERS
attribute.
The check in kvmppc_pack_vcpu_id() was changed from
cpu < KVM_MAX_VCPUS * xive->kvm->arch.emul_smt_mode
to
cpu < xive->nr_servers * xive->kvm->arch.emul_smt_mode
The previous check was based on the fact that the VP block had
KVM_MAX_VCPUS entries and that kvmppc_pack_vcpu_id() guarantees
that packed vCPU ids are below KVM_MAX_VCPUS. We've changed the
size of the VP block, but kvmppc_pack_vcpu_id() has nothing to
do with it and it certainly doesn't ensure that the packed vCPU
ids are below xive->nr_servers. kvmppc_xive_vcpu_id_valid() might
thus return true when the VM was configured with a non-standard
VSMT mode, even if the packed vCPU id is higher than what we
expect. We end up using an unallocated VP id, which confuses
OPAL. The assert in OPAL is probably abusive and should be
converted to a regular error that the kernel can handle, but
we shouldn't really use broken VP ids in the first place.
Fix kvmppc_xive_vcpu_id_valid() so that it checks the packed
vCPU id is below xive->nr_servers, which is explicitly what we
want.
Fixes: 062cfab7069f ("KVM: PPC: Book3S HV: XIVE: Make VP block size configurable")
Cc: [email protected] # v5.5+
Signed-off-by: Greg Kurz <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[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 'eth_switch' name has been misspelled in the imx28.dtsi file,
so this change fixes it.
Signed-off-by: Lukasz Majewski <[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]>
|
|
Protonic WD3 is a proof of concept platform for tractor e-cockpit applications
Signed-off-by: Oleksij Rempel <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
Use the correct pin for the i2c scl signal else we can't access the
SoM eeprom.
Fixes: 2a51f9dae13d ("ARM: dts: imx6qdl-kontron-samx6i: Add iMX6-based Kontron SMARC-sAMX6i module")
Signed-off-by: Bernd Bauer <[email protected]>
[[email protected]: Adapt commit message]
Signed-off-by: Marco Felsch <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
Set it to max. allowed 375kHz for faster transfers. The limit is given
by the erratum [1].
[1] https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
Signed-off-by: Marco Felsch <[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]>
|
|
Since commit 8ad2d1dcce54 ("ARM: dts: imx6qdl-wandboard: Add OV5645 camera
support") the PAD_GPIO_6 is used for providing the camera sensor clock.
Remove it from the enetgrp to fix the following IOMXU conflict:
[ 9.972414] imx6q-pinctrl 20e0000.pinctrl: pin MX6Q_PAD_GPIO_6 already requested by 2188000.ethernet; cannot claim for 1-003c
[ 9.983857] imx6q-pinctrl 20e0000.pinctrl: pin-140 (1-003c) status -22
[ 9.990514] imx6q-pinctrl 20e0000.pinctrl: could not request pin 140 (MX6Q_PAD_GPIO_6) from group ov5645grp on device 20e0000.pinctrl
Fixes: 8ad2d1dcce54 ("ARM: dts: imx6qdl-wandboard: Add OV5645 camera support")
Signed-off-by: Fabio Estevam <[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]
|
|
Commit 4a4fb66119eb ("ARM: imx: Add missing of_node_put()") accidentally
forgot to rename a variable, which caused the wrong address to be used
and, in our case, the ULL getting falsely identified as ULZ.
Fixes: 4a4fb66119eb ("ARM: imx: Add missing of_node_put()")
Signed-off-by: Robert Karszniewicz <[email protected]>
Reviewed-by: Fabio Estevam <[email protected]>
Signed-off-by: Shawn Guo <[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]
|