- Apr 16, 2024
-
-
The ret variable may not be initialized in rk_udphy_usb3_phy_init(), if the PHY is not using USB3 mode. Since the DisplayPort part is handled separately and the PHY does not support USB2 (which is routed to another PHY on Rockchip RK3588), the right exit code for this case is 0. Thus let's initialize the variable accordingly. Fixes: 2f70bbdd ("phy: rockchip: add usbdp combo phy driver") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404141048.qFAYDctQ-lkp@intel.com/ Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
- Apr 08, 2024
-
-
Enable full support (XHCI, EHCI, OHCI) for the lower USB3 port from Radxa Rock 5 Model B. The upper one is already supported. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Enable full support (XHCI, EHCI, OHCI) for the upper USB3 port from Radxa Rock 5 Model A. The lower one is already supported. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add support for the board's USB3 connectors. It has 1x USB Type-A and 1x USB Type-C. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add both USB3 dual-role controllers to the RK3588 devicetree. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add both USB3-DisplayPort PHYs to RK3588 SoC DT. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Reorder common DT properties alphabetically for usb2phy, according to latest DT style rules. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
usb2-phy should be named usb2phy according to the DT binding, so let's fix it up accordingly. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
The USBDP Phy is used by RK3588 to handle the Dual-Role USB3 controllers. The Phy also supports Displayport Alt-Mode, but the necessary DRM driver has not yet been merged. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
This adds a new USBDP combo PHY with Samsung IP block driver. The driver get lane mux and mapping info in 2 ways, supporting DisplayPort alternate mode or parsing from DT. When parsing from DT, the property "rockchip,dp-lane-mux" provide the DP mux and mapping info. This is needed when the PHY is not used with TypeC Alt-Mode. For example if the USB3 interface of the PHY is connected to a USB Type A connector and the DP interface is connected to a DisplayPort connector. When do DP link training, need to set lane number, link rate, swing, and pre-emphasis via PHY configure interface. Co-developed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Co-developed-by: Zhang Yubing <yubing.zhang@rock-chips.com> Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com> Co-developed-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
- Mar 25, 2024
-
-
Add device tree binding document for Rockchip USBDP Combo PHY with Samsung IP block. Co-developed-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add CI support. This will do the following: 1. Run dt_binding_check to make sure no major flaws were introduced in the DT bindings 2. Run dtbs_check, for Rock 5A, Rock 5B and EVB1. If warnings are generated the CI will report that as warning 3. Build a Kernel .deb package 4. Generate a test job for LAVA and run it Co-developed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Co-developed-by: Sjoerd Simons <sjoerd@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
-
- Mar 24, 2024
-
-
Heiko Stuebner authored
-
Heiko Stuebner authored
-
Andy Yan authored
According to the hardware design, the i2c address of audio codec es8316 on Cool Pi CM5 is 0x10. This fix the read/write error like bellow: es8316 7-0011: ASoC: error at soc_component_write_no_lock on es8316.7-0011 for register: [0x0000000c] -6 es8316 7-0011: ASoC: error at soc_component_write_no_lock on es8316.7-0011 for register: [0x00000003] -6 es8316 7-0011: ASoC: error at soc_component_read_no_lock on es8316.7-0011 for register: [0x00000016] -6 es8316 7-0011: ASoC: error at soc_component_read_no_lock on es8316.7-0011 for register: [0x00000016] -6 Fixes: 791c154c ("arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5 EVB") Signed-off-by: Andy Yan <andyshrk@163.com> Link: https://lore.kernel.org/r/20240324112833.2181961-1-andyshrk@163.com [also adapted the node name to audio-codec@10] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Quentin Schulz authored
The PCIe PHY requires two regulators and are present on the SoM directly, while the PCIe connector also exposes 3V3 and 12V power rails which are available on the baseboard. Considering that 3/4 regulators are always-on on HW level and that the last one depends on a regulator from the PMIC that is specified as always on, this commit should be purely cosmetic and no change in behavior is expected. Let's add all regulators for PCIe on RK3399 Puma Haikou. Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://lore.kernel.org/r/20240308-puma-diode-pu-v2-3-309f83da110a@theobroma-systems.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Quentin Schulz authored
The PCIE_WAKE# has a diode used as a level-shifter, and is used as an input pin. While the SoC default is to enable the pull-up, the core rk3399 pinconf for this pin opted for pull-none. So as to not disturb the behaviour of other boards which may rely on pull-none instead of pull-up, set the needed pull-up only for RK3399 Puma. Fixes: 60fd9f72 ("arm64: dts: rockchip: add Haikou baseboard with RK3399-Q7 SoM") Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://lore.kernel.org/r/20240308-puma-diode-pu-v2-2-309f83da110a@theobroma-systems.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Quentin Schulz authored
The Q7_USB_ID has a diode used as a level-shifter, and is used as an input pin. The SoC default for this pin is a pull-up, which is correct but the pinconf in the introducing commit missed that, so let's fix this oversight. Fixes: ed2c66a9 ("arm64: dts: rockchip: fix rk3399-puma-haikou USB OTG mode") Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://lore.kernel.org/r/20240308-puma-diode-pu-v2-1-309f83da110a@theobroma-systems.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Iskander Amara authored
Nodes overridden by their reference should be ordered alphabetically to make it easier to read the DTS. pinctrl node is defined in the wrong location so let's reorder it. Signed-off-by: Iskander Amara <iskander.amara@theobroma-systems.com> Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://lore.kernel.org/r/20240308085243.69903-2-iskander.amara@theobroma-systems.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Iskander Amara authored
Q7_THRM# pin is connected to a diode on the module which is used as a level shifter, and the pin have a pull-down enabled by default. We need to configure it to internal pull-up, other- wise whenever the pin is configured as INPUT and we try to control it externally the value will always remain zero. Signed-off-by: Iskander Amara <iskander.amara@theobroma-systems.com> Fixes: 2c66fc34 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240308085243.69903-1-iskander.amara@theobroma-systems.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Dragan Simic authored
Add missing cache information to the Rockchip RK356x SoC dtsi, to allow the userspace, which includes lscpu(1) that uses the virtual files provided by the kernel under the /sys/devices/system/cpu directory, to display the proper RK3566 and RK3568 cache information. Adding the cache information to the RK356x SoC dtsi also makes the following warning message in the kernel log go away: cacheinfo: Unable to detect cache hierarchy for CPU 0 The cache parameters for the RK356x dtsi were obtained and partially derived by hand from the cache size and layout specifications found in the following datasheets and technical reference manuals: - Rockchip RK3566 datasheet, version 1.1 - Rockchip RK3568 datasheet, version 1.3 - ARM Cortex-A55 revision r1p0 TRM, version 0100-00 - ARM DynamIQ Shared Unit revision r4p0 TRM, version 0400-02 For future reference, here's a rather detailed summary of the documentation, which applies to both Rockchip RK3566 and RK3568 SoCs: - All caches employ the 64-byte cache line length - Each Cortex-A55 core has 32 KB of L1 4-way, set-associative instruction cache and 32 KB of L1 4-way, set-associative data cache - There are no L2 caches, which are per-core and private in Cortex-A55, because it belongs to the ARM DynamIQ IP core lineup - The entire SoC has 512 KB of unified L3 16-way, set-associative cache, which is shared among all four Cortex-A55 CPU cores - Cortex-A55 cores can be configured without private per-core L2 caches, in which case the shared L3 cache appears to them as an L2 cache; this is the case for the RK356x SoCs, so let's use "cache-level = <2>" to prevent the "huh, no L2 caches, but an L3 cache?" confusion among the users viewing the data presented to the userspace; another option could be to have additional 0 KB L2 caches defined, which may be technically correct, but would probably be even more confusing Helped-by: Anand Moon <linux.amoon@gmail.com> Tested-By: Diederik de Haas <didi.debian@cknow.org> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/2dee6dad8460b0c5f3b5da53cf55f735840efef1.1709957777.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Dragan Simic authored
Add missing cache information to the Rockchip RK3328 SoC dtsi, to allow the userspace, which includes lscpu(1) that uses the virtual files provided by the kernel under the /sys/devices/system/cpu directory, to display the proper RK3328 cache information. While there, use a more self-descriptive label for the L2 cache node, which also makes it more consistent with other SoC dtsi files. The cache parameters for the RK3328 dtsi were obtained and partially derived by hand from the cache size and layout specifications found in the following datasheets, official vendor websites, and technical reference manuals: - Rockchip RK3328 datasheet, version 1.4 - https://opensource.rock-chips.com/wiki_RK3328 , accessed on 2024-02-28 - ARM Cortex-A53 revision r0p3 TRM, version E For future reference, here's a brief summary of the documentation: - All caches employ the 64-byte cache line length - Each Cortex-A53 core has 32 KB of L1 2-way, set-associative instruction cache and 32 KB of L1 4-way, set-associative data cache - The entire SoC has 256 KB of unified L2 16-way, set-associative cache The RK3328 SoC dtsi is also used for the single RK3318-based supported board. Unfortunately, no datasheet is available for the RK3318, but some unofficial sources state that its L2 cache size is the same as RK3328's, so it's perhaps safe to assume the same for the L1 instruction and data cache sizes. Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/a681b3c6dbf7b25b1527b11cea5ae0d6d1733714.1709958234.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Arınç ÜNAL authored
The MT7531 switch listens on PHY address 0x1f on an MDIO bus. I've got two findings that support this. There's no bootstrapping option to change the PHY address of the switch. The Linux driver hardcodes 0x1f as the PHY address of the switch. So the reg property on the device tree is currently ignored by the Linux driver. Therefore, describe the correct PHY address on Banana Pi BPI-R2 Pro that has this switch. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Fixes: c1804463 ("arm64: dts: rockchip: Add mt7531 dsa node to BPI-R2-Pro board") Link: https://lore.kernel.org/r/20240314-for-rockchip-mt7531-phy-address-v1-1-743b5873358f@arinc9.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds authored
Pull EFI fixes from Ard Biesheuvel: - Fix logic that is supposed to prevent placement of the kernel image below LOAD_PHYSICAL_ADDR - Use the firmware stack in the EFI stub when running in mixed mode - Clear BSS only once when using mixed mode - Check efi.get_variable() function pointer for NULL before trying to call it * tag 'efi-fixes-for-v6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: fix panic in kdump kernel x86/efistub: Don't clear BSS twice in mixed mode x86/efistub: Call mixed mode boot services on the firmware's stack efi/libstub: fix efi_random_alloc() to allocate memory at alloc_min or higher address
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: - Ensure that the encryption mask at boot is properly propagated on 5-level page tables, otherwise the PGD entry is incorrectly set to non-encrypted, which causes system crashes during boot. - Undo the deferred 5-level page table setup as it cannot work with memory encryption enabled. - Prevent inconsistent XFD state on CPU hotplug, where the MSR is reset to the default value but the cached variable is not, so subsequent comparisons might yield the wrong result and as a consequence the result prevents updating the MSR. - Register the local APIC address only once in the MPPARSE enumeration to prevent triggering the related WARN_ONs() in the APIC and topology code. - Handle the case where no APIC is found gracefully by registering a fake APIC in the topology code. That makes all related topology functions work correctly and does not affect the actual APIC driver code at all. - Don't evaluate logical IDs during early boot as the local APIC IDs are not yet enumerated and the invoked function returns an error code. Nothing requires the logical IDs before the final CPUID enumeration takes place, which happens after the enumeration. - Cure the fallout of the per CPU rework on UP which misplaced the copying of boot_cpu_data to per CPU data so that the final update to boot_cpu_data got lost which caused inconsistent state and boot crashes. - Use copy_from_kernel_nofault() in the kprobes setup as there is no guarantee that the address can be safely accessed. - Reorder struct members in struct saved_context to work around another kmemleak false positive - Remove the buggy code which tries to update the E820 kexec table for setup_data as that is never passed to the kexec kernel. - Update the resource control documentation to use the proper units. - Fix a Kconfig warning observed with tinyconfig * tag 'x86-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/boot/64: Move 5-level paging global variable assignments back x86/boot/64: Apply encryption mask to 5-level pagetable update x86/cpu: Add model number for another Intel Arrow Lake mobile processor x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Documentation/x86: Document that resctrl bandwidth control units are MiB x86/mpparse: Register APIC address only once x86/topology: Handle the !APIC case gracefully x86/topology: Don't evaluate logical IDs during early boot x86/cpu: Ensure that CPU info updates are propagated on UP kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address x86/pm: Work around false positive kmemleak report in msr_build_context() x86/kexec: Do not update E820 kexec table for setup_data x86/config: Fix warning for 'make ARCH=x86_64 tinyconfig'
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler doc clarification from Thomas Gleixner: "A single update for the documentation of the base_slice_ns tunable to clarify that any value which is less than the tick slice has no effect because the scheduler tick is not guaranteed to happen within the set time slice" * tag 'sched-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/doc: Update documentation for base_slice_ns and CONFIG_HZ relation
-
git://git.infradead.org/users/hch/dma-mappingLinus Torvalds authored
Pull dma-mapping fixes from Christoph Hellwig: "This has a set of swiotlb alignment fixes for sometimes very long standing bugs from Will. We've been discussion them for a while and they should be solid now" * tag 'dma-mapping-6.9-2024-03-24' of git://git.infradead.org/users/hch/dma-mapping: swiotlb: Reinstate page-alignment for mappings >= PAGE_SIZE iommu/dma: Force swiotlb_max_mapping_size on an untrusted device swiotlb: Fix alignment checks when both allocation and DMA masks are present swiotlb: Honour dma_alloc_coherent() alignment in swiotlb_alloc() swiotlb: Enforce page alignment in swiotlb_alloc() swiotlb: Fix double-allocation of slots due to broken alignment handling
-
Oleksandr Tymoshenko authored
Check if get_next_variable() is actually valid pointer before calling it. In kdump kernel this method is set to NULL that causes panic during the kexec-ed kernel boot. Tested with QEMU and OVMF firmware. Fixes: bad267f9 ("efi: verify that variable services are supported") Signed-off-by: Oleksandr Tymoshenko <ovt@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
-
Ard Biesheuvel authored
Clearing BSS should only be done once, at the very beginning. efi_pe_entry() is the entrypoint from the firmware, which may not clear BSS and so it is done explicitly. However, efi_pe_entry() is also used as an entrypoint by the mixed mode startup code, in which case BSS will already have been cleared, and doing it again at this point will corrupt global variables holding the firmware's GDT/IDT and segment selectors. So make the memset() conditional on whether the EFI stub is running in native mode. Fixes: b3810c5a ("x86/efistub: Clear decompressor BSS in native EFI entrypoint") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
-
Ard Biesheuvel authored
Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made. Cc: <stable@kernel.org> # v6.1+ Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
-
Tom Lendacky authored
Commit 63bed966 ("x86/startup_64: Defer assignment of 5-level paging global variables") moved assignment of 5-level global variables to later in the boot in order to avoid having to use RIP relative addressing in order to set them. However, when running with 5-level paging and SME active (mem_encrypt=on), the variables are needed as part of the page table setup needed to encrypt the kernel (using pgd_none(), p4d_offset(), etc.). Since the variables haven't been set, the page table manipulation is done as if 4-level paging is active, causing the system to crash on boot. While only a subset of the assignments that were moved need to be set early, move all of the assignments back into check_la57_support() so that these assignments aren't spread between two locations. Instead of just reverting the fix, this uses the new RIP_REL_REF() macro when assigning the variables. Fixes: 63bed966 ("x86/startup_64: Defer assignment of 5-level paging global variables") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/2ca419f4d0de719926fd82353f6751f717590a86.1711122067.git.thomas.lendacky@amd.com
-
Tom Lendacky authored
When running with 5-level page tables, the kernel mapping PGD entry is updated to point to the P4D table. The assignment uses _PAGE_TABLE_NOENC, which, when SME is active (mem_encrypt=on), results in a page table entry without the encryption mask set, causing the system to crash on boot. Change the assignment to use _PAGE_TABLE instead of _PAGE_TABLE_NOENC so that the encryption mask is set for the PGD entry. Fixes: 533568e0 ("x86/boot/64: Use RIP_REL_REF() to access early_top_pgt[]") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/8f20345cda7dbba2cf748b286e1bc00816fe649a.1711122067.git.thomas.lendacky@amd.com
-
Tony Luck authored
This one is the regular laptop CPU. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20240322161725.195614-1-tony.luck@intel.com
-
Adamos Ttofari authored
Commit 67236547 ("x86/fpu: Update XFD state where required") and commit 8bf26758 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD. Fixes: 67236547 ("x86/fpu: Update XFD state where required") Signed-off-by: Adamos Ttofari <attofari@amazon.de> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240322230439.456571-1-chang.seok.bae@intel.com Closes: https://lore.kernel.org/lkml/20230511152818.13839-1-attofari@amazon.de
-
Tony Luck authored
The memory bandwidth software controller uses 2^20 units rather than 10^6. See mbm_bw_count() which computes bandwidth using the "SZ_1M" Linux define for 0x00100000. Update the documentation to use MiB when describing this feature. It's too late to fix the mount option "mba_MBps" as that is now an established user interface. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20240322182016.196544-1-tony.luck@intel.com
-
- Mar 23, 2024
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Thomas Gleixner: "Two regression fixes for the timer and timer migration code: - Prevent endless timer requeuing which is caused by two CPUs racing out of idle. This happens when the last CPU goes idle and therefore has to ensure to expire the pending global timers and some other CPU come out of idle at the same time and the other CPU wins the race and expires the global queue. This causes the last CPU to chase ghost timers forever and reprogramming it's clockevent device endlessly. Cure this by re-evaluating the wakeup time unconditionally. - The split into local (pinned) and global timers in the timer wheel caused a regression for NOHZ full as it broke the idle tracking of global timers. On NOHZ full this prevents an self IPI being sent which in turn causes the timer to be not programmed and not being expired on time. Restore the idle tracking for the global timer base so that the self IPI condition for NOHZ full is working correctly again" * tag 'timers-urgent-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timers: Fix removed self-IPI on global timer's enqueue in nohz_full timers/migration: Fix endless timer requeue after idle interrupts
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull more clocksource updates from Thomas Gleixner: "A set of updates for clocksource and clockevent drivers: - A fix for the prescaler of the ARM global timer where the prescaler mask define only covered 4 bits while it is actully 8 bits wide. This obviously restricted the possible range of prescaler adjustments - A fix for the RISC-V timer which prevents a timer interrupt being raised while the timer is initialized - A set of device tree updates to support new system on chips in various drivers - Kernel-doc and other cleanups all over the place" * tag 'timers-core-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clocksource/drivers/timer-riscv: Clear timer interrupt on timer initialization dt-bindings: timer: Add support for cadence TTC PWM clocksource/drivers/arm_global_timer: Simplify prescaler register access clocksource/drivers/arm_global_timer: Guard against division by zero clocksource/drivers/arm_global_timer: Make gt_target_rate unsigned long dt-bindings: timer: add Ralink SoCs system tick counter clocksource: arm_global_timer: fix non-kernel-doc comment clocksource/drivers/arm_global_timer: Remove stray tab clocksource/drivers/arm_global_timer: Fix maximum prescaler value clocksource/drivers/imx-sysctr: Add i.MX95 support clocksource/drivers/imx-sysctr: Drop use global variables dt-bindings: timer: nxp,sysctr-timer: support i.MX95 dt-bindings: timer: renesas: ostm: Document RZ/Five SoC dt-bindings: timer: renesas,tmu: Document input capture interrupt clocksource/drivers/ti-32K: Fix misuse of "/**" comment clocksource/drivers/stm32: Fix all kernel-doc warnings dt-bindings: timer: exynos4210-mct: Add google,gs101-mct compatible clocksource/drivers/imx: Fix -Wunused-but-set-variable warning
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "A series of fixes for the Renesas RZG21 interrupt chip driver to prevent spurious and misrouted interrupts. - Ensure that posted writes are flushed in the eoi() callback - Ensure that interrupts are masked at the chip level when the trigger type is changed - Clear the interrupt status register when setting up edge type trigger modes - Ensure that the trigger type and routing information is set before the interrupt is enabled" * tag 'irq-urgent-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/renesas-rzg2l: Do not set TIEN and TINT source at the same time irqchip/renesas-rzg2l: Prevent spurious interrupts when setting trigger type irqchip/renesas-rzg2l: Rename rzg2l_irq_eoi() irqchip/renesas-rzg2l: Rename rzg2l_tint_eoi() irqchip/renesas-rzg2l: Flush posted write in irq_eoi()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull core entry fix from Thomas Gleixner: "A single fix for the generic entry code: The trace_sys_enter() tracepoint can modify the syscall number via kprobes or BPF in pt_regs, but that requires that the syscall number is re-evaluted from pt_regs after the tracepoint. A seccomp fix in that area removed the re-evaluation so the change does not take effect as the code just uses the locally cached number. Restore the original behaviour by re-evaluating the syscall number after the tracepoint" * tag 'core-entry-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: entry: Respect changes to system call number by trace_sys_enter()
-