summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-02-29cgroup/cpuset: Fix retval in update_cpumask()Kamalesh Babulal
The update_cpumask(), checks for newly requested cpumask by calling validate_change(), which returns an error on passing an invalid set of cpu(s). Independent of the error returned, update_cpumask() always returns zero, suppressing the error and returning success to the user on writing an invalid cpu range for a cpuset. Fix it by returning retval instead, which is returned by validate_change(). Fixes: 99fe36ba6fc1 ("cgroup/cpuset: Improve temporary cpumasks handling") Signed-off-by: Kamalesh Babulal <kamalesh.babulal@oracle.com> Reviewed-by: Waiman Long <longman@redhat.com> Cc: stable@vger.kernel.org # v6.6+ Signed-off-by: Tejun Heo <tj@kernel.org>
2024-02-29Merge tag 'landlock-6.8-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux Pull Landlock fix from Mickaël Salaün: "Fix a potential issue when handling inodes with inconsistent properties" * tag 'landlock-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux: landlock: Fix asymmetric private inodes referring
2024-02-29cgroup/cpuset: Mark memory_spread_slab as obsoleteXiongwei Song
We've removed the SLAB allocator, cpuset_do_slab_mem_spread() and SLAB_MEM_SPREAD, memory_spread_slab is a no-op now. We can mark memory_spread_slab as obsolete in case someone still wants to use it after cpuset_do_slab_mem_spread() removed. For more details, please check [1]. [1] https://lore.kernel.org/lkml/32bc1403-49da-445a-8c00-9686a3b0d6a3@redhat.com/T/#m8e292e21b00f95a4bb8086371fa7387fa4ea8f60 tj: Description and cosmetic updates. Signed-off-by: Xiongwei Song <xiongwei.song@windriver.com> Acked-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-02-29cgroup/cpuset: Remove cpuset_do_slab_mem_spread()Xiongwei Song
The SLAB allocator has been removed sine 6.8-rc1 [1], so there is no user with SLAB_MEM_SPREAD and cpuset_do_slab_mem_spread(). Then SLAB_MEM_SPREAD is marked as unused by [2]. Here we can remove cpuset_do_slab_mem_spread(). For more details, please check [3]. [1] https://lore.kernel.org/linux-mm/20231120-slab-remove-slab-v2-0-9c9c70177183@suse.cz/ [2] https://lore.kernel.org/linux-kernel/20240223-slab-cleanup-flags-v2-0-02f1753e8303@suse.cz/T/ [3] https://lore.kernel.org/lkml/32bc1403-49da-445a-8c00-9686a3b0d6a3@redhat.com/T/#mf14b838c5e0e77f4756d436bac3d8c0447ea4350 Signed-off-by: Xiongwei Song <xiongwei.song@windriver.com> Reviewed-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-02-29riscv: Sparse-Memory/vmemmap out-of-bounds fixDimitris Vlachos
Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments Suggested-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Dimitris Vlachos <dvlachos@ics.forth.gr> Reported-by: Dimitris Vlachos <dvlachos@ics.forth.gr> Closes: https://lore.kernel.org/linux-riscv/20240202135030.42265-1-csd4492@csd.uoc.gr Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem") Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20240229191723.32779-1-dvlachos@ics.forth.gr Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29dpll: fix build failure due to rcu_dereference_check() on unknown typeEric Dumazet
Tasmiya reports that their compiler complains that we deref a pointer to unknown type with rcu_dereference_rtnl(): include/linux/rcupdate.h:439:9: error: dereferencing pointer to incomplete type ‘struct dpll_pin’ Unclear what compiler it is, at the moment, and we can't report but since DPLL can't be a module - move the code from the header into the source file. Fixes: 0d60d8df6f49 ("dpll: rely on rcu for netdev_dpll_pin()") Reported-by: Tasmiya Nalatwad <tasmiya@linux.vnet.ibm.com> Link: https://lore.kernel.org/all/3fcf3a2c-1c1b-42c1-bacb-78fdcd700389@linux.vnet.ibm.com/ Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20240229190515.2740221-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-29PM: suspend: Set mem_sleep_current during kernel command line setupMaulik Shah
psci_init_system_suspend() invokes suspend_set_ops() very early during bootup even before kernel command line for mem_sleep_default is setup. This leads to kernel command line mem_sleep_default=s2idle not working as mem_sleep_current gets changed to deep via suspend_set_ops() and never changes back to s2idle. Set mem_sleep_current along with mem_sleep_default during kernel command line setup as default suspend mode. Fixes: faf7ec4a92c0 ("drivers: firmware: psci: add system suspend support") CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-02-29Revert "ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default"Daniel Drake
This reverts commit d52848620de00cde4a3a5df908e231b8c8868250, which was originally put in place to work around a s2idle failure on this platform where the NVMe device was inaccessible upon resume. After extended testing, we found that the firmware's implementation of S3 is buggy and intermittently fails to wake up the system. We need to revert to s2idle mode. The NVMe issue has now been solved more precisely in the commit titled "PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge" Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742 Link: https://lore.kernel.org/r/20240228075316.7404-2-drake@endlessos.org Signed-off-by: Daniel Drake <drake@endlessos.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jian-Hong Pan <jhp@endlessos.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org>
2024-02-29PCI: Disable D3cold on Asus B1400 PCI-NVMe bridgeDaniel Drake
The Asus B1400 with original shipped firmware versions and VMD disabled cannot resume from suspend: the NVMe device becomes unresponsive and inaccessible. This appears to be an untested D3cold transition by the vendor; Intel socwatch shows that Windows leaves the NVMe device and parent bridge in D0 during suspend, even though these firmware versions have StorageD3Enable=1. The NVMe device and parent PCI bridge both share the same "PXP" ACPI power resource, which gets turned off as both devices are put into D3cold during suspend. The _OFF() method calls DL23() which sets a L23E bit at offset 0xe2 into the PCI configuration space for this root port. This is the specific write that the _ON() routine is unable to recover from. This register is not documented in the public chipset datasheet. Disallow D3cold on the PCI bridge to enable successful suspend/resume. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742 Link: https://lore.kernel.org/r/20240228075316.7404-1-drake@endlessos.org Signed-off-by: Daniel Drake <drake@endlessos.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jian-Hong Pan <jhp@endlessos.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org>
2024-02-29cpufreq: Honour transition_latency over transition_delay_usQais Yousef
Some platforms like Arm's Juno can have a high transition latency that can be larger than the 2ms cap introduced. If a driver reports a transition_latency that is higher than the cap, then use it as-is. Update comment s/10/2/ to reflect the new cap of 2ms. Reported-by: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Qais Yousef <qyousef@layalina.io> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-02-29cpufreq: Limit resolving a frequency to policy min/maxShivnandan Kumar
Resolving a frequency to an efficient one should not transgress policy->max (which can be set for thermal reason) and policy->min. Currently, there is possibility where scaling_cur_freq can exceed scaling_max_freq when scaling_max_freq is an inefficient frequency. Add a check to ensure that resolving a frequency will respect policy->min/max. Cc: All applicable <stable@vger.kernel.org> Fixes: 1f39fa0dccff ("cpufreq: Introducing CPUFREQ_RELATION_E") Signed-off-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> [ rjw: Whitespace adjustment, changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-02-29Documentation: PM: Fix runtime_pm.rst markdown syntaxYiwei Lin
The '7. Generic subsystem callbacks' should be a section title, but the markdown syntax is not adequate now. Fix it so the chapter can be linked at docs.kernel.org correctly. Signed-off-by: Yiwei Lin <s921975628@gmail.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-02-29cpufreq: amd-pstate: adjust min/max limit perfMeng Li
The min/max limit perf values calculated based on frequency may exceed the reasonable range of perf(highest perf, lowest perf). Signed-off-by: Meng Li <li.meng@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-02-29Merge patch series "NAPOT Fixes"Palmer Dabbelt
Alexandre Ghiti <alexghiti@rivosinc.com> says: This contains 2 fixes for NAPOT: patch 1 disables the use of NAPOT mapping for vmalloc/vmap and patch 2 implements pte_leaf_size() to report NAPOT size. * b4-shazam-merge: riscv: Fix pte_leaf_size() for NAPOT Revert "riscv: mm: support Svnapot in huge vmap" Link: https://lore.kernel.org/r/20240227205016.121901-1-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29riscv: Fix pte_leaf_size() for NAPOTAlexandre Ghiti
pte_leaf_size() must be reimplemented to add support for NAPOT mappings. Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20240227205016.121901-3-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29Revert "riscv: mm: support Svnapot in huge vmap"Alexandre Ghiti
This reverts commit ce173474cf19fe7fbe8f0fc74e3c81ec9c3d9807. We cannot correctly deal with NAPOT mappings in vmalloc/vmap because if some part of a NAPOT mapping is unmapped, the remaining mapping is not updated accordingly. For example: ptr = vmalloc_huge(64 * 1024, GFP_KERNEL); vunmap_range((unsigned long)(ptr + PAGE_SIZE), (unsigned long)(ptr + 64 * 1024)); leads to the following kernel page table dump: 0xffff8f8000ef0000-0xffff8f8000ef1000 0x00000001033c0000 4K PTE N .. .. D A G . . W R V Meaning the first entry which was not unmapped still has the N bit set, which, if accessed first and cached in the TLB, could allow access to the unmapped range. That's because the logic to break the NAPOT mapping does not exist and likely won't. Indeed, to break a NAPOT mapping, we first have to clear the whole mapping, flush the TLB and then set the new mapping ("break- before-make" equivalent). That works fine in userspace since we can handle any pagefault occurring on the remaining mapping but we can't handle a kernel pagefault on such mapping. So fix this by reverting the commit that introduced the vmap/vmalloc support. Fixes: ce173474cf19 ("riscv: mm: support Svnapot in huge vmap") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20240227205016.121901-2-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29Merge patch series "riscv: cbo.zero fixes"Palmer Dabbelt
Samuel Holland <samuel.holland@sifive.com> says: This series fixes a couple of issues related to using the cbo.zero instruction in userspace. The first patch fixes a bug where the wrong enable bit gets set if the kernel is running in M-mode. The remaining patches fix a bug where the enable bit gets reset to its default value after a nonretentive idle state. I have hardware which reproduces this: Before this series: $ tools/testing/selftests/riscv/hwprobe/cbo TAP version 13 1..3 ok 1 Zicboz block size # Zicboz block size: 64 Illegal instruction After applying this series: $ tools/testing/selftests/riscv/hwprobe/cbo TAP version 13 1..3 ok 1 Zicboz block size # Zicboz block size: 64 ok 2 cbo.zero ok 3 cbo.zero check # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0 * b4-shazam-merge: riscv: Save/restore envcfg CSR during CPU suspend riscv: Add a custom ISA extension for the [ms]envcfg CSR riscv: Fix enabling cbo.zero when running in M-mode Link: https://lore.kernel.org/r/20240228065559.3434837-1-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29riscv: Save/restore envcfg CSR during CPU suspendSamuel Holland
The value of the [ms]envcfg CSR is lost when entering a nonretentive idle state, so the CSR must be rewritten when resuming the CPU. Cc: <stable@vger.kernel.org> # v6.7+ Fixes: 43c16d51a19b ("RISC-V: Enable cbo.zero in usermode") Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20240228065559.3434837-4-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29riscv: Add a custom ISA extension for the [ms]envcfg CSRSamuel Holland
The [ms]envcfg CSR was added in version 1.12 of the RISC-V privileged ISA (aka S[ms]1p12). However, bits in this CSR are defined by several other extensions which may be implemented separately from any particular version of the privileged ISA (for example, some unrelated errata may prevent an implementation from claiming conformance with Ss1p12). As a result, Linux cannot simply use the privileged ISA version to determine if the CSR is present. It must also check if any of these other extensions are implemented. It also cannot probe the existence of the CSR at runtime, because Linux does not require Sstrict, so (in the absence of additional information) it cannot know if a CSR at that address is [ms]envcfg or part of some non-conforming vendor extension. Since there are several standard extensions that imply the existence of the [ms]envcfg CSR, it becomes unwieldy to check for all of them wherever the CSR is accessed. Instead, define a custom Xlinuxenvcfg ISA extension bit that is implied by the other extensions and denotes that the CSR exists as defined in the privileged ISA, containing at least one of the fields common between menvcfg and senvcfg. This extension does not need to be parsed from the devicetree or ISA string because it can only be implemented as a subset of some other standard extension. Cc: <stable@vger.kernel.org> # v6.7+ Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20240228065559.3434837-3-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29riscv: Fix enabling cbo.zero when running in M-modeSamuel Holland
When the kernel is running in M-mode, the CBZE bit must be set in the menvcfg CSR, not in senvcfg. Cc: <stable@vger.kernel.org> Fixes: 43c16d51a19b ("RISC-V: Enable cbo.zero in usermode") Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240228065559.3434837-2-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29perf: RISCV: Fix panic on pmu overflow handlerFei Wu
(1 << idx) of int is not desired when setting bits in unsigned long overflowed_ctrs, use BIT() instead. This panic happens when running 'perf record -e branches' on sophgo sg2042. [ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [ 273.320851] Oops [#1] [ 273.323179] Modules linked in: [ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9 [ 273.332521] Hardware name: Sophgo Mango (DT) [ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e [ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0 [ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978 [ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70 [ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000 [ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015 [ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a [ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0 [ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210 [ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098 [ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca [ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8 [ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d [ 273.434512] [<ffffffff80aecd98>] riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.441169] [<ffffffff80076bd8>] handle_percpu_devid_irq+0x98/0x1ee [ 273.447562] [<ffffffff80071158>] generic_handle_domain_irq+0x28/0x36 [ 273.454151] [<ffffffff8047a99a>] riscv_intc_irq+0x36/0x4e [ 273.459659] [<ffffffff80c944de>] handle_riscv_irq+0x4a/0x74 [ 273.465442] [<ffffffff80c94c48>] do_irq+0x62/0x92 [ 273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783 [ 273.477921] ---[ end trace 0000000000000000 ]--- [ 273.482630] Kernel panic - not syncing: Fatal exception in interrupt Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Signed-off-by: Fei Wu <fei2.wu@intel.com> Link: https://lore.kernel.org/r/20240228115425.2613856-1-fei2.wu@intel.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29MAINTAINERS: Update SiFive driver maintainersSamuel Holland
Add myself as a maintainer for the various SiFive drivers, since I have been performing cleanup activity on these drivers and reviewing patches to them for a while now. Remove Palmer as a maintainer, as he is focused on overall RISC-V architecture support. Collapse some duplicate entries into the main SiFive drivers entry: - Conor is already maintainer of standalone cache drivers as a whole, and these files are also covered by the "sifive" file name regex. - Paul's git tree has not been updated since 2018, and all file names matching the "fu540" pattern also match the "sifive" pattern. - Green has not been active on the LKML for a couple of years. Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Acked-by: Paul Walmsley <paul.walmsley@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20240215234941.1663791-1-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-29mfd: cs42l43: Fix wrong register defaultsMaciej Strozek
A few regs have unnecessary values in defaults, change them to match the datasheet Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver") Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240229155616.118457-1-mstrozek@opensource.cirrus.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-02-29mfd: mt6397-core: Register mt6357 sound codecFabien Parent
Add MT6357 codec entry in the MFD driver. Signed-off-by: Fabien Parent <fparent@baylibre.com> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240226-audio-i350-v1-13-4fa1cea1667f@baylibre.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-02-29ACPI: APEI: Skip initialization of GHES_ASSIST structures for Machine Check ↵Avadhut Naik
Architecture To support GHES_ASSIST on Machine Check Architecture (MCA) error sources, a set of GHES structures is provided by the system firmware for each MCA error source. Each of these sets consists of a GHES structure for each MCA bank on each logical CPU, with all structures of a set sharing a common Related Source ID, equal to the Source ID of one of the MCA error source structures.[1] On SOCs with large core counts, this typically equates to tens of thousands of GHES_ASSIST structures for MCA under "/sys/bus/platform/drivers/GHES". Support for GHES_ASSIST however, hasn't been implemented in the kernel. As such, the information provided through these structures is not consumed by Linux. Moreover, these GHES_ASSIST structures for MCA, which are supposed to provide supplemental information in context of an error reported by hardware, are setup as independent error sources by the kernel during HEST initialization. Additionally, if the Type field of the Notification structure, associated with these GHES_ASSIST structures for MCA, is set to Polled, the kernel sets up a timer for each individual structure. The duration of the timer is derived from the Poll Interval field of the Notification structure. On SOCs with high core counts, this will result in tens of thousands of timers expiring periodically causing unnecessary preemptions and wastage of CPU cycles. The problem will particularly intensify if Poll Interval duration is not sufficiently high. Since GHES_ASSIST support is not present in kernel, skip initialization of GHES_ASSIST structures for MCA to eliminate their performance impact. [1] ACPI specification 6.5, section 18.7 Signed-off-by: Avadhut Naik <avadhut.naik@amd.com> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-02-29dt-bindings: mfd: syscon: Add ti,am62-usb-phy-ctrl compatibleRoger Quadros
Add the compatible for TI AM62 USB PHY Control register. This register is found in the TI AM62 WKUP_CTRL_MMR0 space [1]. It is used to indicate the USB PHY PLL reference clock rate and core voltage level to the USB controller. [1] - https://www.ti.com/lit/pdf/spruiv7 Signed-off-by: Roger Quadros <rogerq@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240226-b4-for-v6-5-am62-usb-typec-dt-v6-1-acf77fff4344@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-02-29kunit: Fix again checksum tests on big endian CPUsChristophe Leroy
Commit b38460bc463c ("kunit: Fix checksum tests on big endian CPUs") fixed endianness issues with kunit checksum tests, but then commit 6f4c45cbcb00 ("kunit: Add tests for csum_ipv6_magic and ip_fast_csum") introduced new issues on big endian CPUs. Those issues are once again reflected by the warnings reported by sparse. So, fix them with the same approach, perform proper conversion in order to support both little and big endian CPUs. Once the conversions are properly done and the right types used, the sparse warnings are cleared as well. Reported-by: Erhard Furtner <erhard_f@mailbox.org> Fixes: 6f4c45cbcb00 ("kunit: Add tests for csum_ipv6_magic and ip_fast_csum") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/73df3a9e95c2179119398ad1b4c84cdacbd8dfb6.1708684443.git.christophe.leroy@csgroup.eu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-29dt-bindings: mfd: dlg,da9063: Make #interrupt-cells requiredGeert Uytterhoeven
'#interrupt-cells' is a required provided for interrupt providers, hence make it required. While at it, move '#interrupt-cells' in the example to match common sort order. Fixes: 361104b05684 ("dt-bindings: mfd: Convert da9063 to yaml") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/f512045738d2102c771a171a514ed7cf612c6d6f.1708944455.git.geert+renesas@glider.be Signed-off-by: Lee Jones <lee@kernel.org>
2024-02-29Merge tag 'for-net-2024-02-28' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - mgmt: Fix limited discoverable off timeout - hci_qca: Set BDA quirk bit if fwnode exists in DT - hci_bcm4377: do not mark valid bd_addr as invalid - hci_sync: Check the correct flag before starting a scan - Enforce validation on max value of connection interval - hci_sync: Fix accept_list when attempting to suspend - hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST - Avoid potential use-after-free in hci_error_reset - rfcomm: Fix null-ptr-deref in rfcomm_check_security - hci_event: Fix wrongly recorded wakeup BD_ADDR - qca: Fix wrong event type for patch config command - qca: Fix triggering coredump implementation * tag 'for-net-2024-02-28' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: qca: Fix triggering coredump implementation Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DT Bluetooth: qca: Fix wrong event type for patch config command Bluetooth: Enforce validation on max value of connection interval Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST Bluetooth: mgmt: Fix limited discoverable off timeout Bluetooth: hci_event: Fix wrongly recorded wakeup BD_ADDR Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security Bluetooth: hci_sync: Fix accept_list when attempting to suspend Bluetooth: Avoid potential use-after-free in hci_error_reset Bluetooth: hci_sync: Check the correct flag before starting a scan Bluetooth: hci_bcm4377: do not mark valid bd_addr as invalid ==================== Link: https://lore.kernel.org/r/20240228145644.2269088-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-29Merge branch 'tls-a-few-more-fixes-for-async-decrypt'Jakub Kicinski
Sabrina Dubroca says: ==================== tls: a few more fixes for async decrypt The previous patchset [1] took care of "full async". This adds a few fixes for cases where only part of the crypto operations go the async route, found by extending my previous debug patch [2] to do N synchronous operations followed by M asynchronous ops (with N and M configurable). [1] https://patchwork.kernel.org/project/netdevbpf/list/?series=823784&state=* [2] https://lore.kernel.org/all/9d664093b1bf7f47497b2c40b3a085b45f3274a2.1694021240.git.sd@queasysnail.net/ ==================== Link: https://lore.kernel.org/r/cover.1709132643.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-29tls: fix use-after-free on failed backlog decryptionSabrina Dubroca
When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new ->async_done flag) that the memory has already been released. Fixes: 859054147318 ("net: tls: handle backlogging of crypto requests") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/4755dd8d9bebdefaa19ce1439b833d6199d4364c.1709132643.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-29tls: separate no-async decryption request handling from asyncSabrina Dubroca
If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result. We should preferably also use a separate crypto_wait. I'm not seeing a UAF as I did in the past, I think aec7961916f3 ("tls: fix race between async notify and socket close") took care of it. This will make the next fix easier. Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/47bde5f649707610eaef9f0d679519966fc31061.1709132643.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-29tls: fix peeking with sync+async decryptionSabrina Dubroca
If we peek from 2 records with a currently empty rx_list, and the first record is decrypted synchronously but the second record is decrypted async, the following happens: 1. decrypt record 1 (sync) 2. copy from record 1 to the userspace's msg 3. queue the decrypted record to rx_list for future read(!PEEK) 4. decrypt record 2 (async) 5. queue record 2 to rx_list 6. call process_rx_list to copy data from the 2nd record We currently pass copied=0 as skip offset to process_rx_list, so we end up copying once again from the first record. We should skip over the data we've already copied. Seen with selftest tls.12_aes_gcm.recv_peek_large_buf_mult_recs Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/1b132d2b2b99296bfde54e8a67672d90d6d16e71.1709132643.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-29tls: decrement decrypt_pending if no async completion will be calledSabrina Dubroca
With mixed sync/async decryption, or failures of crypto_aead_decrypt, we increment decrypt_pending but we never do the corresponding decrement since tls_decrypt_done will not be called. In this case, we should decrement decrypt_pending immediately to avoid getting stuck. For example, the prequeue prequeue test gets stuck with mixed modes (one async decrypt + one sync decrypt). Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls records") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/c56d5fc35543891d5319f834f25622360e1bfbec.1709132643.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-29Merge tag 'tegra-for-6.9-arm64-dt' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt arm64: tegra: Device tree changes for v6.9-rc1 This set of changes refactors the audio-related device tree nodes on Tegra234 and improves USB support for Jetson AGX Xavier. Furthermore this consolidates SD/MMC aliases on Tegra234 and provides correct configuration data for the MGBE Ethernet devices found on Tegra234 so that they can operate at full speed. * tag 'tegra-for-6.9-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: arm64: tegra: Remove Jetson Orin NX and Jetson Orin Nano DTSI arm64: tegra: Add audio support for Jetson Orin NX and Jetson Orin Nano arm64: tegra: Define missing IO ports arm64: tegra: Move AHUB ports to SoC DTSI arm64: tegra: Add USB Type-C controller for Jetson AGX Xavier arm64: tegra: Add USB device support for Jetson AGX Xavier arm64: tegra: Add current monitors for Jetson Xavier arm64: tegra: Add AXI configuration for Tegra234 MGBE arm64: tegra: Use consistent SD/MMC aliases on Tegra234 arm64: tegra: Enable cros-ec-spi as wake source Link: https://lore.kernel.org/r/20240223174849.1509465-5-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-29Merge tag 'tegra-for-6.9-arm-dt' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt ARM: tegra: Device tree changes for v6.9-rc1 Add support for the LG Optimus 4X HD and LG Optimus VU devices and clean up some minor issues. * tag 'tegra-for-6.9-arm-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: ARM: tegra: Add device-tree for LG Optimus 4X HD (P880) ARM: tegra: Add device-tree for LG Optimus Vu (P895) ARM: tegra: nexus7: Add missing clock binding into sound node ARM: tegra: Enable cros-ec-spi as wake source Link: https://lore.kernel.org/r/20240223174849.1509465-4-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-29Merge tag 'tegra-for-6.9-dt-bindings' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt dt-bindings: Changes for v6.9-rc1 This contains device tree bindings additions for LG Optimus devices as well as cleanups for the PMC hardware block. * tag 'tegra-for-6.9-dt-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: dt-bindings: arm: tegra: Add LG Optimus Vu P895 and Optimus 4X P880 dt-bindings: tegra: pmc: Update scratch as an optional aperture Link: https://lore.kernel.org/r/20240223174849.1509465-3-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-29Merge tag 'renesas-dts-for-v6.9-tag2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt Renesas DTS updates for v6.9 (take two) - Add pin control, I2C, GPIO, CA76 cluster, Ethernet, SD/MMC, DMA, and HyperFLASH/QSPI (RPC) support for the R-Car V4M SoC, - Add I2C EEPROM, Ethernet, eMMC, and QSPI FLASH support for the Gray Hawk Single development board, - Fix PCIe power on ULCB development boards equipped with the Shimafuji Kingfisher extension, - Add PSCI support for the RZ/G3S SoC, - Add camera support for the RZ/G2UL SMARC EVK development board, - Add display support for the RZ/G2L{,C} and RZ/V2L SoCs and SMARC EVK development boards, - Miscellaneous fixes and improvements, * tag 'renesas-dts-for-v6.9-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (31 commits) arm64: dts: renesas: rzg2l-smarc: Enable DU and link with DSI arm64: dts: renesas: r9a07g054: Add DU node arm64: dts: renesas: r9a07g044: Add DU node arm64: dts: renesas: gray-hawk-single: Add QSPI FLASH support arm64: dts: renesas: r8a779h0: Add RPC node arm64: dts: renesas: r8a779h0: Add DMA support arm64: dts: renesas: gray-hawk-single: Add eMMC support arm64: dts: renesas: r8a779h0: Add SD/MMC node ARM: dts: renesas: r8a7778: Add missing reg-names to sound node arm64: dts: renesas: rzg2ul-smarc: Enable CRU, CSI support arm64: dts: renesas: gray-hawk-single: Add Ethernet support arm64: dts: renesas: r8a779h0: Add Ethernet-AVB support arm64: dts: renesas: r8a779g0: Correct avb[01] reg sizes arm64: dts: renesas: r8a779a0: Correct avb[01] reg sizes arm64: dts: renesas: r9a08g045: Add PSCI support arm64: dts: renesas: rzg3s-smarc-som: Guard Ethernet IRQ GPIO hogs arm64: dts: renesas: r9a08g045: Add missing interrupts to IRQC node arm64: dts: renesas: rzg2l: Add missing interrupts to IRQC nodes arm64: dts: renesas: r8a779h0: Add CA76 operating points arm64: dts: renesas: r8a779h0: Add CPU core clocks ... Link: https://lore.kernel.org/r/cover.1708687134.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-29Merge tag 'renesas-dt-bindings-for-v6.9-tag2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt Renesas DT binding updates for v6.9 (take two) - Restore sort order, - Document preferred compatible naming, * tag 'renesas-dt-bindings-for-v6.9-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: dt-bindings: renesas: Document preferred compatible naming dt-bindings: soc: renesas: Preserve the order of SoCs based on their part numbers Link: https://lore.kernel.org/r/cover.1708687132.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-29Merge tag 'v6.9-rockchip-dts32-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt Display output for rk3128 and some adaptions to binding clarifications for hdmi nodes on some older socs. * tag 'v6.9-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: ARM: dts: rockchip: fix rk322x hdmi ports node ARM: dts: rockchip: fix rk3288 hdmi ports node ARM: dts: rockchip: Enable HDMI output for XPI-3128 ARM: dts: rockchip: Add HDMI node for RK3128 ARM: dts: rockchip: Add display subsystem for RK3128 Link: https://lore.kernel.org/r/37970455.XM6RcZxFsP@diego Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-29tick/sched: Fix build failure for CONFIG_NO_HZ_COMMON=nArnd Bergmann
In configurations with CONFIG_TICK_ONESHOT but no CONFIG_NO_HZ or CONFIG_HIGH_RES_TIMERS, tick_sched_timer_dying() is stubbed out, but still defined as a global function as well: kernel/time/tick-sched.c:1599:6: error: redefinition of 'tick_sched_timer_dying' 1599 | void tick_sched_timer_dying(int cpu) | ^ kernel/time/tick-sched.h:111:20: note: previous definition is here 111 | static inline void tick_sched_timer_dying(int cpu) { } | ^ This configuration only appears with ARM CONFIG_ARCH_BCM_MOBILE, which should not actually select CONFIG_TICK_ONESHOT. Adjust the #ifdef for the stub to match the condition for building the tick-sched.c file for consistency with the definition and to avoid the build regression. Fixes: 3aedb7fcd88a ("tick/sched: Remove useless oneshot ifdeffery") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240228123850.3499024-1-arnd@kernel.org
2024-02-29drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flipHsin-Yi Wang
It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240223212404.3709690-1-hsinyi@chromium.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2024-02-29rxrpc: Move rxrpc_send_ACK() to output.c with rxrpc_send_ack_packet()David Howells
Move rxrpc_send_ACK() to output.c to so that it is with rxrpc_send_ack_packet() prior to merging the two. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
2024-02-29rxrpc: Don't pick values out of the wire header when setting up securityDavid Howells
Don't pick values out of the wire header in rxkad when setting up DATA packet security, but rather use other sources. This makes it easier to get rid of txb->wire. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
2024-02-29rxrpc: Split up the DATA packet transmission functionDavid Howells
Split (sub)packet preparation and timestamping out of the DATA packet transmission function to make it easier to glue multiple txbufs together into a jumbo DATA packet. This will require preparation and timestamping of all the subpackets in a txbuf, and these functions provide convenient points to place the required iteration. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
2024-02-29rxrpc: Add a kvec[] to the rxrpc_txbuf structDavid Howells
Add a kvec[] to the rxrpc_txbuf struct to point to the contributory buffers for a packet. Start with just a single element for now, but this will be expanded later. Make the ACK sending function use it, which means that rxrpc_fill_out_ack() doesn't need to return the size of the sack table, padding and trailer. Make the data sending code use it, both in where sendmsg() packages code up into txbufs and where those txbufs are transmitted. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
2024-02-29rxrpc: Merge together DF/non-DF branches of data Tx functionDavid Howells
Merge together the DF and non-DF branches of the transmission function and always set the flag to the right thing before transmitting. If we see -EMSGSIZE from udp_sendmsg(), turn off DF and retry. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
2024-02-29rxrpc: Do lazy DF flag resettingDavid Howells
Don't reset the DF flag after transmission, but rather set it when needed since it should be a fast op now that we call IP directly. This includes turning it off for RESPONSE packets and, for the moment, ACK packets. In future, we will need to turn it on for ACK packets used to do path MTU discovery. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
2024-02-29rxrpc: Remove atomic handling on some fields only used in I/O threadDavid Howells
call->tx_transmitted and call->acks_prev_seq don't need to be managed with cmpxchg() and barriers as it's only used within the singular I/O thread. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
2024-02-29rxrpc: Strip barriers and atomics off of timer trackingDavid Howells
Strip the atomic ops and barriering off of the call timer tracking as this is handled solely within the I/O thread, except for expect_term_by which is set by sendmsg(). Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
generated by cgit (git 2.34.1) at 2025-09-22 08:03:25 +0000