| Age | Commit message (Collapse) | Author |
|---|
|
Three different OV5640 modules are supported using the FFC connector on
BeaglePlay:
- Digilent PCam 5C
- ALINX AN5641
- TEVI-OV5640-*-RPI
The Digilent and ALINX modules supply a 12Mhz XCLK to the sensor, while
the TEVI module supplies a 24Mhz XCLK, thus requiring a separate
overlay.
Reviewed-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20231201-csi_dts-v3-4-9f06f31080fe@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add nodes for Cadence DPHY, CSI2RX and TI's pixel-grabbing wrapper.
AM62A uses a dedicated BCDMA instance for CSI-RX traffic, so enable
that as well.
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20231201-csi_dts-v3-3-9f06f31080fe@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The CSI2RX subsystem can be used to capture video frames from CSI-2
cameras. Add nodes for the CSI core, SHIM layer, and the DPHY.
Tested-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20231201-csi_dts-v3-2-9f06f31080fe@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
AM62 and other K3 based SoCs use Cadence DPHY and CSI-RX bridge
drivers, along with a DMA wrapper CSI IP for the camera pipeline.
Enable the same to get camera functionality on AM62x-SK, BeaglePlay and
AM62Ax SK among other platforms.
Tested-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20231201-csi_dts-v3-1-9f06f31080fe@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The AM652 is basically a AM654 but with 2 cores instead of 4. Add a
DTSI file for AM652 matching AM654 except this core difference.
This removes the need to remove the extra cores from AM654 manually
in DT files for boards that use the AM652 variant. Do that for the
IOT2050 boards here.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20231205162358.23904-1-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
io_uring sets up the io worker kernel thread via a syscall out of an
user space prrocess. This process might have used FPU and since
copy_thread() didn't clear FPU states for kernel threads a BUG()
is triggered for using FPU inside kernel. Move code around
to always clear FPU state for user and kernel threads.
Cc: stable@vger.kernel.org
Reported-by: Aurelien Jarno <aurel32@debian.org>
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055021
Suggested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
|
There are many types of revsered memory passed from firmware
that should be reserved in memblock, and UMA memory passed
from firmware that should be added to system memory for system
to use.
Also for memblock there is no need to align those space into page,
which actually cause problems.
Handle them properly to prevent memory corruption on some systems.
Cc: stable@vger.kernel.org
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
|
There are some Loongson64 systems come with broken coherent DMA
support, firmware will set a bit in boot_param and pass nocoherentio
in cmdline.
However nonconherent support was missed out when spin off Loongson-2EF
form Loongson64, and that boot_param change never made itself into
upstream.
Support DMA noncoherent properly to get those systems working.
Cc: stable@vger.kernel.org
Fixes: 71e2f4dd5a65 ("MIPS: Fork loongson2ef from loongson64")
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
|
vgabios is passed from firmware to kernel on Loongson64 systems.
Sane firmware will keep this pointer in reserved memory space
passed from the firmware but insane firmware keeps it in low
memory before kernel entry that is not reserved.
Previously kernel won't try to allocate memory from low memory
before kernel entry on boot, but after converting to memblock
it will do that.
Fix by resversing those memory on early boot.
Cc: stable@vger.kernel.org
Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
|
rcutree_report_cpu_starting() must be called before
clockevents_register_device() to avoid the following lockdep splat triggered by
calling list_add() when CONFIG_PROVE_RCU_LIST=y:
WARNING: suspicious RCU usage
...
-----------------------------
kernel/locking/lockdep.c:3680 RCU-list traversed in non-reader section!!
other info that might help us debug this:
RCU used illegally from offline CPU!
rcu_scheduler_active = 1, debug_locks = 1
no locks held by swapper/1/0.
...
Call Trace:
[<ffffffff8012a434>] show_stack+0x64/0x158
[<ffffffff80a93d98>] dump_stack_lvl+0x90/0xc4
[<ffffffff801c9e9c>] __lock_acquire+0x1404/0x2940
[<ffffffff801cbf3c>] lock_acquire+0x14c/0x448
[<ffffffff80aa4260>] _raw_spin_lock_irqsave+0x50/0x88
[<ffffffff8021e0c8>] clockevents_register_device+0x60/0x1e8
[<ffffffff80130ff0>] r4k_clockevent_init+0x220/0x3a0
[<ffffffff801339d0>] start_secondary+0x50/0x3b8
raw_smp_processor_id() is required in order to avoid calling into lockdep
before RCU has declared the CPU to be watched for readers.
See also commit 29368e093921 ("x86/smpboot: Move rcu_cpu_starting() earlier"),
commit de5d9dae150c ("s390/smp: move rcu_cpu_starting() earlier") and commit
99f070b62322 ("powerpc/smp: Call rcu_cpu_starting() earlier").
Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
|
The typical style is to define functions before calling them. Move
pci_mmcfg_arch_map() and pci_mmcfg_arch_unmap() earlier so they're defined
before they're called. No functional change intended.
Link: https://lore.kernel.org/r/20231121183643.249006-10-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
If pci_mmconfig_alloc() fails, return the failure early so it's obvious
that the failure is the exception, and the success is the normal case. No
functional change intended.
Link: https://lore.kernel.org/r/20231121183643.249006-9-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
In pci_mmconfig_insert(), there's no reference to "addr" between locking
pci_mmcfg_lock and testing "addr", so it *looks* like we should move the
test before the lock.
But 07f9b61c3915 ("x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at
address zero") did that, which broke things by returning -EINVAL when
"addr" is zero instead of -EEXIST.
So 07f9b61c3915 was reverted by 67d470e0e171 ("Revert "x86/PCI: MMCONFIG:
Check earlier for MMCONFIG region at address zero"").
Add a comment about this issue to prevent it from happening again.
Link: https://lore.kernel.org/r/20231121183643.249006-8-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
"pci_mmcfg_check_reserved()" doesn't give a hint about what the boolean
return value means. Rename it to pci_mmcfg_reserved() so testing
"if (pci_mmcfg_reserved())" makes sense.
Update callers to treat the return value as boolean instead of comparing
with 0.
Link: https://lore.kernel.org/r/20231121183643.249006-7-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
"acpi_mcfg_check_entry()" doesn't give a hint about what the return value
means. Rename it to "acpi_mcfg_valid_entry()", convert the return value to
bool, and update the return values and callers to match so testing
"if (acpi_mcfg_valid_entry())" makes sense.
Link: https://lore.kernel.org/r/20231121183643.249006-6-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The "MMCONFIG" term is not used in PCI/PCIe specs. Replace it with "ECAM",
the term used in PCIe r6.0, sec 7.2.2.
Define pr_fmt() instead of repeating PREFIX in every log message.
Link: https://lore.kernel.org/r/20231121183643.249006-5-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
MCFG handling is a frequent source of problems. Add more logging to aid in
debugging.
Enable the logging with CONFIG_DYNAMIC_DEBUG=y and the kernel boot
parameter 'dyndbg="file arch/x86/pci +p"'.
Link: https://lore.kernel.org/r/20231121183643.249006-4-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
fd3a8cff4d4a ("x86/pci: Treat EfiMemoryMappedIO as reservation of ECAM
space") added the concept of using the EFI memory map to help decide
whether ECAM space mentioned in the MCFG table is valid.
Unfortunately it described that EfiMemoryMappedIO space as "reserved", but
it is actually not *reserved* by the EFI memory map. EfiMemoryMappedIO
only means the firmware requested that the OS map this space for use by
firmware runtime services.
Change the dmesg logging to describe it as simply "EfiMemoryMappedIO", not
as "reserved as EfiMemoryMappedIO". A previous commit actually *does*
reserve the space if ACPI PNP0C01/02 devices haven't done so:
- PCI: ECAM at [mem 0xe0000000-0xefffffff] reserved as EfiMemoryMappedIO
+ PCI: ECAM at [mem 0xe0000000-0xefffffff] is EfiMemoryMappedIO; assuming valid
PCI: ECAM [mem 0xe0000000-0xefffffff] reserved to work around lack of ACPI motherboard _CRS
Link: https://lore.kernel.org/r/20231121183643.249006-3-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Tomasz, Sebastian, and some Proxmox users reported problems initializing
ixgbe NICs.
I think the problem is that ECAM space described in the ACPI MCFG table is
not reserved via a PNP0C02 _CRS method as required by the PCI Firmware spec
(r3.3, sec 4.1.2), but it *is* included in the PNP0A03 host bridge _CRS as
part of the MMIO aperture.
If we allocate space for a PCI BAR, we're likely to allocate it from that
ECAM space, which obviously cannot work.
This could happen for any device, but in the ixgbe case it happens because
it's an SR-IOV device and the BIOS didn't allocate space for the VF BARs,
so Linux reallocated the bridge window leading to ixgbe and put it on top
of the ECAM space. From Tomasz' system:
PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000)
PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] not reserved in ACPI motherboard resources
pci_bus 0000:00: root bus resource [mem 0x80000000-0xfbffffff window]
pci 0000:00:01.1: PCI bridge to [bus 02-03]
pci 0000:00:01.1: bridge window [mem 0xfb900000-0xfbbfffff]
pci 0000:02:00.0: [8086:10fb] type 00 class 0x020000 # ixgbe
pci 0000:02:00.0: reg 0x10: [mem 0xfba80000-0xfbafffff 64bit]
pci 0000:02:00.0: VF(n) BAR0 space: [mem 0x00000000-0x000fffff 64bit] (contains BAR0 for 64 VFs)
pci 0000:02:00.0: BAR 7: no space for [mem size 0x00100000 64bit] # VF BAR 0
pci_bus 0000:00: No. 2 try to assign unassigned res
pci 0000:00:01.1: resource 14 [mem 0xfb900000-0xfbbfffff] released
pci 0000:00:01.1: BAR 14: assigned [mem 0x80000000-0x806fffff]
pci 0000:02:00.0: BAR 0: assigned [mem 0x80000000-0x8007ffff 64bit]
pci 0000:02:00.0: BAR 7: assigned [mem 0x80204000-0x80303fff 64bit] # VF BAR 0
Fixes: 07eab0901ede ("efi/x86: Remove EfiMemoryMappedIO from E820 map")
Fixes: fd3a8cff4d4a ("x86/pci: Treat EfiMemoryMappedIO as reservation of ECAM space")
Reported-by: Tomasz Pala <gotar@polanet.pl>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218050
Reported-by: Sebastian Manciulea <manciuleas@protonmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218107
Link: https://forum.proxmox.com/threads/proxmox-8-kernel-6-2-16-4-pve-ixgbe-driver-fails-to-load-due-to-pci-device-probing-failure.131203/
Link: https://lore.kernel.org/r/20231121183643.249006-2-helgaas@kernel.org
Tested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v6.2+
|
|
In current code, init_irq_stacks() will call cpu_to_node().
The cpu_to_node() depends on percpu "numa_node" which is initialized in:
arch_call_rest_init() --> rest_init() -- kernel_init()
--> kernel_init_freeable() --> smp_prepare_cpus()
But init_irq_stacks() is called in init_IRQ() which is before
arch_call_rest_init().
So in init_irq_stacks(), the cpu_to_node() does not work, it
always return 0. In NUMA, it makes the node 1 cpu accesses the IRQ stack which
is in the node 0.
This patch fixes it by:
1.) export the early_cpu_to_node(), and use it in the init_irq_stacks().
2.) change init_irq_stacks() to __init function.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
Link: https://lore.kernel.org/r/20231124031513.81548-1-shijie@os.amperecomputing.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Commit ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
deprecated <asm-generic/export.h>, which is now a wrapper of
<linux/export.h>.
Replace #include <asm-generic/export.h> with #include <linux/export.h>.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20231126151045.1556686-1-masahiroy@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Currently the 32-bit arm PMU drivers use the pmu_hw_events::lock spinlock in
their arm_pmu::{start,stop,enable,disable}() callbacks to protect hardware
state and event data.
This locking is not necessary as the perf core code already provides mutual
exclusion, disabling interrupts to serialize against the IRQ handler, and
using perf_event_context::lock to protect against concurrent modifications of
events cross-cpu.
The locking was removed from the arm64 (now PMUv3) PMU driver in commit:
2a0e2a02e4b7 ("arm64: perf: Remove PMU locking")
... and the same reasoning applies to all the 32-bit PMU drivers.
Remove the locking from the 32-bit PMU drivers.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-perf-users@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20231115092805.737822-2-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Since commit c7e73b5051d6 ("ARM: imx: mach-imx6ul: remove 14x14 EVK
specific PHY fixup")thet Ethernet PHY is no longer configured via code
in board file.
This caused Ethernet to stop working.
Fix this problem by describing the clocks and clock-names to the
Ethernet PHY node so that the KSZ8081 chip can be clocked correctly.
Fixes: c7e73b5051d6 ("ARM: imx: mach-imx6ul: remove 14x14 EVK specific PHY fixup")
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
TQMa7x (revision 01xxx) uses a LM75A temperature sensor.
The two sensors use different I2C addresses, so we can set both sensors
simultaneously.
Signed-off-by: João Rodrigues <jrodrigues@ubimet.com>
Reviewed-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long) as arguments
without warnings.
For symmetry do the same with pfn_to_virt().
For compiletime resolution of __pa() we need PAGE_OFFSET which
was not available to __pa() and resolved by the preprocessor
wherever __pa() was used. Fix this by explicitly including
<asm/mem-layout.h> where required, following the pattern of the
architectures page.h file.
Acked-by: Brian Cain <bcain@quicinc.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long) as arguments
without warnings.
In order to do this we move the virt_to_phys() and
below the definition of the __pa() and __va() macros so it
compiles. The macro version was also able to do recursive
symbol resolution.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
When this file is included before defining readq(), it misses the
declarations for a couple of functions that now become unusable:
lib/iomap.c:156:5: warning: no previous prototype for 'ioread64_lo_hi' [-Wmissing-prototypes]
lib/iomap.c:163:5: warning: no previous prototype for 'ioread64_hi_lo' [-Wmissing-prototypes]
lib/iomap.c:170:5: warning: no previous prototype for 'ioread64be_lo_hi' [-Wmissing-prototypes]
lib/iomap.c:178:5: warning: no previous prototype for 'ioread64be_hi_lo' [-Wmissing-prototypes]
lib/iomap.c:264:6: warning: no previous prototype for 'iowrite64_lo_hi' [-Wmissing-prototypes]
lib/iomap.c:272:6: warning: no previous prototype for 'iowrite64_hi_lo' [-Wmissing-prototypes]
lib/iomap.c:280:6: warning: no previous prototype for 'iowrite64be_lo_hi' [-Wmissing-prototypes]
lib/iomap.c:288:6: warning: no previous prototype for 'iowrite64be_hi_lo' [-Wmissing-prototypes]
The file is included again later from asm-generic/io.h, so dropping the initial
include statement makes it do the right thing, both for avoiding the warning
and for actually providing these functions.
Link: https://lkml.kernel.org/r/20231204115710.2247097-17-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Rothwell <sfr@rothwell.id.au>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
|
Back in 2016, it was argued that implementations lacking a HW
prefetcher could be helped by sprinkling a number of PRFM
instructions in strategic locations.
In 2023, the one platform that presumably needed this hack is no
longer in active use (let alone maintained), and an quick
experiment shows dropping this hack only leads to a 0.4% drop
on a full kernel compilation (tested on a MT30-GS0 48 CPU system).
Given that this is pretty much in the noise department and that
it may give odd ideas to other implementers, drop the hack for
good.
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20231122133754.1240687-1-maz@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
|
|
'make vdso_install' renames arch/arm64/kernel/vdso32/vdso.so.dbg to
vdso32.so during installation, which allows 64-bit and 32-bit vdso
files to be installed in the same directory.
However, arm64 is the only architecture that requires this renaming.
To simplify the vdso_install logic, rename the in-tree vdso file so
its base name matches the installed file name.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20231117125620.1058300-1-masahiroy@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
|
|
kasan_pte_populate fill KASAN_SHADOW_INIT in the newly
allocated shadow page, so it's unnecessary to
use memblock_alloc_try_nid, which always zero the
new allocated memory.
Use memblock_alloc_try_nid_raw instead of
memblock_alloc_try_nid like arm64 does which
can make kasan init faster.
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
|
|
Attempt VMA lock-based page fault handling first, and fall back to the
existing mmap_lock-based handling if that fails, the ebizzy benchmark
shows 25% improvement on qemu with 2 cpus.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
|
|
kconfig warns when PINCTRL_SINGLE is selected but PINCTRL is not
set, so also set PINCTRL for ARCH_DAVINCI. This prevents a
kconfig/build warning:
WARNING: unmet direct dependencies detected for PINCTRL_SINGLE
Depends on [n]: PINCTRL [=n] && OF [=y] && HAS_IOMEM [=y]
Selected by [y]:
- ARCH_DAVINCI [=y] && ARCH_MULTI_V5 [=y]
Closes: lore.kernel.org/r/202311070548.0f6XfBrh-lkp@intel.com
Fixes: f962396ce292 ("ARM: davinci: support multiplatform build for ARM v5")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: patches@armlinux.org.uk
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
|
|
Add the missing "Unconditional Advanced SIMD and floating-point
instructions" in [1] to the VFP undef hook.
This commit addresses the issue reported in [2], where
executing the vudot instruction on a platform with FEAT_DotProd
support resulted in an undefined instruction error.
Link: https://developer.arm.com/documentation/ddi0597/2023-06/?lang=en [1]
Link: https://lore.kernel.org/lkml/20230920083907.30479-1-mark-pk.tsai@mediatek.com/ [2]
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Tested-by: Xuewen Yan <xuewen.yan@unisoc.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
|
|
We now have *two* values for CTR_EL0.L1Ip that are reserved.
Which makes things a bit awkward. In order to lift the ambiguity,
rename RESERVED (0b01) to RESERVED_AIVIVT, and VPIPT (0b00) to
RESERVED_VPIPT.
This makes it clear which of these meant what, and I'm sure
archeologists will find it useful...
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20231204143606.1806432-4-maz@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Since the kernel will never run on a system with the VPIPT i-cache
policy, drop the detection code altogether.
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20231204143606.1806432-3-maz@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
|
|
We have some special handling for VPIPT I-cache in critical parts
of the cache and TLB maintenance. Remove it.
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20231204143606.1806432-2-maz@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Remove CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_SLAB_DEPRECATED and
everything in Kconfig files and mm/Makefile that depends on those. Since
SLUB is the only remaining allocator, remove the allocator choice, make
CONFIG_SLUB a "def_bool y" for now and remove all explicit dependencies
on SLUB or SLAB as it's now always enabled. Make every option's verbose
name and description refer to "the slab allocator" without refering to
the specific implementation. Do not rename the CONFIG_ option names yet.
Everything under #ifdef CONFIG_SLAB, and mm/slab.c is now dead code, all
code under #ifdef CONFIG_SLUB is now always compiled.
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Tested-by: David Rientjes <rientjes@google.com>
Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
|
|
The i.MX8MP and i.MX8MQ devices both use the same DWC3 controller and
are both affected by a known issue with the controller due to specific
behaviour when park mode is enabled in SuperSpeed host mode operation.
Under heavy USB traffic from multiple endpoints the controller will
sometimes incorrectly process transactions such that some transactions
are lost, or the controller may hang when processing transactions. When
the controller hangs it does not recover.
This issue is documented partially within the linux-imx vendor kernel
which references a Synopsys STAR number 9001415732 in commits [1] and
additional details in [2]. Those commits provide some additional
controller internal implementation specifics around the incorrect
behaviour of the SuperSpeed host controller operation when park mode is
enabled.
The summary of this issue is that the host controller can incorrectly
enter/exit park mode such that part of the controller is in a state
which behaves as if in park mode even though it is not. In this state
the controller incorrectly calculates the number of TRBs available which
results in incorrect access of the internal caches causing the overwrite
of pending requests in the cache which should have been processed but
are ignored. This can cause the controller to drop the requests or hang
waiting for the pending state of the dropped requests.
The workaround for this issue is to disable park mode for SuperSpeed
operation of the controller through the GUCTL1[17] bit. This is already
available as a quirk for the DWC3 controller and can be enabled via the
'snps,parkmode-disable-ss-quirk' device tree property.
It is possible to replicate this failure on an i.MX8MP EVK with a USB
Hub connecting 4 SuperSpeed USB flash drives. Performing continuous
small read operations (dd if=/dev/sd... of=/dev/null bs=16) on the block
devices will result in device errors initially and will eventually
result in the controller hanging.
[13240.896936] xhci-hcd xhci-hcd.0.auto: WARN Event TRB for slot 4 ep 2 with no TDs queued?
[13240.990708] usb 2-1.3: reset SuperSpeed USB device number 5 using xhci-hcd
[13241.015582] sd 2:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
[13241.025198] sd 2:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
[13241.032949] I/O error, dev sdc, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 25 prio class 2
[13272.150710] usb 2-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[13272.175469] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=DRIVER_OK cmd_age=31s
[13272.185365] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
[13272.193385] I/O error, dev sdb, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 2
[13434.846556] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command
[13434.854592] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
[13434.862553] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
[1] https://github.com/nxp-imx/linux-imx/commit/97a5349d936b08cf301730b59e4e8855283f815c
[2] https://github.com/nxp-imx/linux-imx/commit/b4b5cbc5a12d7c3b920d1d7cba0ada3379e4e42b
Fixes: fb8587a2c165 ("arm64: dtsi: imx8mp: add usb nodes")
Fixes: ad37549cb5dc ("arm64: dts: imx8mq: add USB nodes")
Signed-off-by: Nathan Rossi <nathan.rossi@digi.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
SoC TRM, SoC datasheet and board schematics always refer to the
same uart numbers - even if not all are used for a specific board.
In order to not have to re-define them for every board move the
aliases to SoC dtsi for RK3128 like it's being done for all other
Rockchip ARM SoCs.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20231202130506.66738-5-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
SoC TRM, SoC datasheet and board schematics always refer to the
same i2c numbers - even if not all are used for a specific board.
In order to not have to re-define them for every board move the
aliases to SoC dtsi for RK3128 like it's being done for all other
Rockchip ARM SoCs.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20231202130506.66738-4-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
SoC TRM, SoC datasheet and board schematics always refer to the
same gpio numbers - even if not all are used for a specific board.
In order to not have to re-define them for every board move the
aliases to SoC dtsi for RK3128 like it's being done for most other
Rockchip ARM SoCs.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20231202130506.66738-3-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Sonoff iHost is gateway device designed to provide a Smart Home Hub,
it is based on Rockchip RV1126. There is also a version with 2GB RAM
based off the RV1109 dual core SoC.
Features:
- Rockchip RV1126
- 4GB DDR4
- 8GB eMMC
- microSD slot
- RMII Ethernet PHY
- 1x USB 2.0 Host
- 1x USB 2.0 OTG
- Realtek RTL8723DS WiFi/BT
- EFR32MG21 Silabs Zigbee radio
- Speaker/Microphone
This patch adds the initial device tree for this device, it is largely
based off the device trees for mainline Edgeble Neu2 and downstream
Rockchip rv1126-evb-v13 configs. It has been adapted with relevant
peripheral and GPIO pins for the iHost.
Signed-off-by: Tim Lunn <tim@feathertop.org>
Link: https://lore.kernel.org/r/20231203124004.2676174-8-tim@feathertop.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The Rockchip rv1109 SoC is a dual core version of the rv1126. It is
otherwise identical and shares the same device tree config.
This patch introduces a dtsi file to drop the additional cpu nodes.
Taken from Rockchip BSP kernel.
Signed-off-by: Tim Lunn <tim@feathertop.org>
Link: https://lore.kernel.org/r/20231203124004.2676174-7-tim@feathertop.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Split up the pinctrl definitions for rgmii1 so it can be shared
with devices using an RMII PHY.
Signed-off-by: Tim Lunn <tim@feathertop.org>
Link: https://lore.kernel.org/r/20231203124004.2676174-6-tim@feathertop.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add i2c2 node and i2c2_xfer pinctrl for Rockchip RV1126
Signed-off-by: Tim Lunn <tim@feathertop.org>
Link: https://lore.kernel.org/r/20231203124004.2676174-5-tim@feathertop.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add serial aliases for uart nodes so that serial devices are created
Signed-off-by: Tim Lunn <tim@feathertop.org>
Link: https://lore.kernel.org/r/20231203124004.2676174-3-tim@feathertop.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add uart3m2_xfer and uart4m2_xfer pins for Rockchip RV1126. These are
used as serial ports for the indicator and Zigbee radio on the iHost.
Signed-off-by: Tim Lunn <tim@feathertop.org>
Link: https://lore.kernel.org/r/20231203124004.2676174-2-tim@feathertop.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add the supply and enable gpu node for XPI-3128 board.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20231204153547.97877-4-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
RK3128 SoCs have Mali400 MP2 GPU.
Add the respective device tree node and the correspondending opp-table.
The frequencies and voltages of the opp-table have been taken from
downstream kernel.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20231204153547.97877-3-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add power controller and qos nodes for RK3128 in order to use
them as powerdomains.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20231204153547.97877-2-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
