summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-11-21PCI/pwrctl: Remove pwrctl device without iterating over all children of ↵Manivannan Sadhasivam
pwrctl parent There is no need to iterate over all children of the pwrctl device parent to remove the pwrctl device. Since the pwrctl device associated with the PCI device can be found using of_find_device_by_node() API, use it directly instead. Any pwrctl devices lying around without getting associated with the PCI devices will be removed once their parent device gets removed. Link: https://lore.kernel.org/r/20241025-pci-pwrctl-rework-v2-5-568756156cbe@linaro.org Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Tested-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-21PCI/pwrctl: Ensure that pwrctl drivers are probed before PCI client driversManivannan Sadhasivam
As per the kernel device driver model, a pwrctl device is the supplier for the PCI device, but the device link that enforces the supplier-consumer relationship was previously created by the pwrctl driver. Therefore, the driver model didn't prevent probing PCI client drivers before probing the corresponding pwrctl drivers. This may lead to a race condition if the PCI device was already powered on by the bootloader (before the pwrctl driver). If the bootloader did not power on the PCI device, this wouldn't create any problem as the pwrctl driver will be the one powering on the device, so the PCI client driver always gets probed afterward. But if the device was already powered on, then the device will be seen by the PCI core and the PCI client driver may get probed before its pwrctl driver. This creates a race condition as the pwrctl driver may change the device power state while the device is being accessed by the client driver. One such issue was already reported on the Qcom X13s platform with the WLAN device and fixed with a hack in the WCN pwrseq driver by a9aaf1ff88a8 ("power: sequencing: request the WLAN enable GPIO as-is"). A cleaner way to fix the above mentioned race condition is to ensure that the pwrctl drivers are always probed before the client drivers. If the PCI device is associated with a pwrctl platform device with a power supply, add a device link between the PCI device and the pwrctl device before device_attach() in pci_bus_add_device(). Note that there is no need to explicitly remove the device link as that will be taken care of by the driver core when the PCI device gets removed. Fixes: 4565d2652a37 ("PCI/pwrctl: Add PCI power control core code") Fixes: 8fb18619d910 ("PCI/pwrctl: Create platform devices for child OF nodes of the port node") Link: https://lore.kernel.org/r/20241025-pci-pwrctl-rework-v2-3-568756156cbe@linaro.org Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Tested-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> [bhelgaas: squash fix from https://lore.kernel.org/r/20241120062459.6371-1-manivannan.sadhasivam@linaro.org for SPARCv9 issue reported by Jonathan Currier <dullfire@yahoo.com>] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> [kwilczynski: wrap code to 80 columns] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Cc: stable+noautosel@kernel.org # Depends on power supply check
2024-11-21PCI/pwrctl: Create pwrctl device only if at least one power supply is presentManivannan Sadhasivam
Currently, pwrctl devices are created if the corresponding PCI nodes are defined in devicetree. But this is not correct, because not all PCI nodes require pwrctl support. Pwrctl comes into the picture only when the device requires kernel to manage its power state. This can be determined using the power supply properties present in the devicetree node of the device. Add of_pci_supply_present() to check whether the devicetree contains at least one power supply property for a device. If one is present, create a pwrctl device for that PCI node. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: 8fb18619d910 ("PCI/pwrctl: Create platform devices for child OF nodes of the port node") Link: https://lore.kernel.org/r/20241025-pci-pwrctl-rework-v2-2-568756156cbe@linaro.org Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Tested-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> [bhelgaas: rename of_pci_is_supply_present() to of_pci_supply_present() for readability] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Cc: stable+noautosel@kernel.org # Depends on of_platform_device_create() rework
2024-11-21PCI/pwrctl: Use of_platform_device_create() to create pwrctl devicesManivannan Sadhasivam
The of_platform_populate() API creates platform devices by descending through the children of the parent node. But it provides no control over the child nodes, which makes it difficult to add checks for the child nodes in the future. Use of_platform_device_create() and for_each_child_of_node_scoped() to make it possible to add checks for each node before creating the platform device. Link: https://lore.kernel.org/r/20241025-pci-pwrctl-rework-v2-1-568756156cbe@linaro.org Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Tested-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-21regulator: core: Ignore unset max_uA constraints in current limit checkKory Maincent (Dent Project)
We should only consider max_uA constraints if they are explicitly defined. In cases where it is not set, we should assume the regulator has no current limit. Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20241121-feature_poe_port_prio-v3-2-83299fa6967c@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-21io_uring/nop: ensure nop->fd is always initializedJens Axboe
A previous commit added file support for nop, but it only initializes nop->fd if IORING_NOP_FIXED_FILE is set. That check should be IORING_NOP_FILE. Fix up the condition in nop preparation, and initialize it to a sane value even if we're not going to be directly using it. While in there, do the same thing for the nop->buffer field. Reported-by: syzbot+9a8500a45c2cabdf9577@syzkaller.appspotmail.com Fixes: a85f31052bce ("io_uring/nop: add support for testing registered files and buffers") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-11-21io_uring: limit local tw doneDavid Wei
Instead of eagerly running all available local tw, limit the amount of local tw done to the max of IO_LOCAL_TW_DEFAULT_MAX (20) or wait_nr. The value of 20 is chosen as a reasonable heuristic to allow enough work batching but also keep latency down. Add a retry_llist that maintains a list of local tw that couldn't be done in time. No synchronisation is needed since it is only modified within the task context. Signed-off-by: David Wei <dw@davidwei.uk> Link: https://lore.kernel.org/r/20241120221452.3762588-3-dw@davidwei.uk Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-11-21io_uring: add io_local_work_pending()David Wei
In preparation for adding a new llist of tw to retry due to hitting the tw limit, add a helper io_local_work_pending(). This function returns true if there is any local tw pending. For now it only checks ctx->work_llist. Signed-off-by: David Wei <dw@davidwei.uk> Reviewed-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/20241120221452.3762588-2-dw@davidwei.uk Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-11-21ASoC: apple: Fix the wrong format specifierliujing
In the mca_fe_hw_params(), the variable tdm_slot_width is of type unsigned int, so the output should be %u Signed-off-by: liujing <liujing@cmss.chinamobile.com> Link: https://patch.msgid.link/20241113015758.5441-1-liujing@cmss.chinamobile.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-21ASoC: imx-audmix: Add NULL check in imx_audmix_probeCharles Han
devm_kasprintf() can return a NULL pointer on failure,but this returned value in imx_audmix_probe() is not checked. Add NULL check in imx_audmix_probe(), to handle kernel NULL pointer dereference error. Fixes: 05d996e11348 ("ASoC: imx-audmix: Split capture device for audmix") Signed-off-by: Charles Han <hanchunchao@inspur.com> Link: https://patch.msgid.link/20241118084553.4195-1-hanchunchao@inspur.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-21spi-imx: prevent overflow when estimating transfer timeAntonio Quartulli
The words delay is computed by multiplying two unsigned ints and by adding up the result to a u64 variable. The multiplication, however, is performed with 32bit math thus losing data when the actual result is larger than UINT32_MAX. Fix the operation by casting the first operand to u64, thus forcing the multiplication to be performed with 64bit math. This fixes 1 OVERFLOW_BEFORE_WIDEN issue reported by Coverity Report: CID 1601859: Integer handling issues (OVERFLOW_BEFORE_WIDEN) Cc: Mark Brown <broonie@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: imx@lists.linux.dev Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Antonio Quartulli <antonio@mandelbit.com> Link: https://patch.msgid.link/20241115220202.31086-1-antonio@mandelbit.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-219p/xen: fix init sequenceAlex Zenla
Large amount of mount hangs observed during hotplugging of 9pfs devices. The 9pfs Xen driver attempts to initialize itself more than once, causing the frontend and backend to disagree: the backend listens on a channel that the frontend does not send on, resulting in stalled processing. Only allow initialization of 9p frontend once. Fixes: c15fe55d14b3b ("9p/xen: fix connection sequence") Signed-off-by: Alex Zenla <alex@edera.dev> Signed-off-by: Alexander Merritt <alexander@edera.dev> Signed-off-by: Ariadne Conill <ariadne@ariadne.space> Reviewed-by: Juergen Gross <jgross@suse.com> Message-ID: <20241119211633.38321-1-alexander@edera.dev> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2024-11-21KVM: riscv: selftests: Add Svade and Svadu Extension to get-reg-list testYong-Xuan Wang
Update the get-reg-list test to test the Svade and Svadu Extensions are available for guest OS. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20240726084931.28924-6-yongxuan.wang@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org>
2024-11-21RISC-V: KVM: Add Svade and Svadu Extensions Support for Guest/VMYong-Xuan Wang
We extend the KVM ISA extension ONE_REG interface to allow VMM tools to detect and enable Svade and Svadu extensions for Guest/VM. Since the henvcfg.ADUE is read-only zero if the menvcfg.ADUE is zero, the Svadu extension is available for Guest/VM and the Svade extension is allowed to disabledonly when arch_has_hw_pte_young() is true. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Samuel Holland <samuel.holland@sifive.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20240726084931.28924-4-yongxuan.wang@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org>
2024-11-21dt-bindings: riscv: Add Svade and Svadu EntriesYong-Xuan Wang
Add entries for the Svade and Svadu extensions to the riscv,isa-extensions property. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Samuel Holland <samuel.holland@sifive.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20240726084931.28924-3-yongxuan.wang@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org>
2024-11-21RISC-V: Add Svade and Svadu Extensions SupportYong-Xuan Wang
Svade and Svadu extensions represent two schemes for managing the PTE A/D bits. When the PTE A/D bits need to be set, Svade extension intdicates that a related page fault will be raised. In contrast, the Svadu extension supports hardware updating of PTE A/D bits. Since the Svade extension is mandatory and the Svadu extension is optional in RVA23 profile, by default the M-mode firmware will enable the Svadu extension in the menvcfg CSR when only Svadu is present in DT. This patch detects Svade and Svadu extensions from DT and adds arch_has_hw_pte_young() to enable optimization in MGLRU and __wp_page_copy_user() when we have the PTE A/D bits hardware updating support. Co-developed-by: Jinyu Tang <tjytimi@163.com> Signed-off-by: Jinyu Tang <tjytimi@163.com> Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20240726084931.28924-2-yongxuan.wang@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org>
2024-11-21s390/entry: Mark IRQ entries to fix stack depot warningsVasily Gorbik
The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot. Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved. While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific. Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like: Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 with PREEMPT and KASAN enabled. Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section. This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value. SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing. IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies. Cc: stable@vger.kernel.org # 5.15+ Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-11-21s390/cpum_sf: Simplify release of SDBs and SDBTsThomas Richter
Free_sampling_buffer() releases the Sampling Data Buffers (SDBs) and Sampling Data Buffer Table (SDBTs) allocated at event initialization. Both buffers are of PAGE_SIZE bytes. Each SDBT consists of 512 entries. The first 511 entries point to SDBs the last entry points to a successor SDBT. The last SDBT in the list points to the origin of all SDBTs. SDBTs do not contain holes, that is an entry always points to a SDB. If less than 511 SDBs have been allocation, the last entry points to the origin SDBT. Simplify the release of the SDBs and SDBTs, walk along the SDBT chain, release SDBs and SDBTs and stop when reaching the origin again. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-11-21s390/vfio-ap: Remove gmap_convert_to_secure() from vfio_ap_opsClaudio Imbrenda
If the page has been exported, do not re-import it. Imports should only be triggered by the guest. The guest will import the page automatically when it will need it again, there is no advantage in importing it manually. Moreover, vfio_pin_pages() will take an extra reference on the page and thus will cause the import to always fail. The extra reference would be dropped only after pointlessly trying to import the page. Fixes: f88fb1335733 ("s390/vfio-ap: make sure nib is shared") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Link: https://lore.kernel.org/r/20241115135611.87836-1-imbrenda@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-11-21s390/stacktrace: Use break instead of return statementHeiko Carstens
arch_stack_walk_user_common() contains a return statement instead of a break statement in case store_ip() fails while trying to store a callchain entry of a user space process. This may lead to a missing pagefault_enable() call. If this happens any subsequent page fault of the process won't be resolved by the page fault handler and this in turn will lead to the process being killed. Use a break instead of a return statement to fix this. Fixes: ebd912ff9919 ("s390/stacktrace: Merge perf_callchain_user() and arch_stack_walk_user()") Cc: stable@vger.kernel.org Reviewed-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-11-21s390/mm: Remove bogus comment in __tlb_flush_mm()Alexander Gordeev
Since commit b3e5dc45fd1e ("s390/mm: fix local TLB flushing vs. detach of an mm address space") __tlb_flush_mm() does not flush local CPU, but the comment suggests it does, which is misleading. Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-11-21s390/debug: Pass in and enforce output buffer size for format handlersNiklas Schnelle
The s390dbf format handler rely on being passed an output buffer sized such that their output will always fit and then use plain sprintf() to write to it. While only supplied data from other kernel components this still potentially allows buffer overwrite if callers are not careful. Instead just pass in the size of the output buffer and use scnprintf() instead of sprintf() and strscpy() instead of strcpy(). The latter also allows us to get rid of a separate strlen() call. Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-11-21ALSA: pcm: Add sanity NULL check for the default mmap fault handlerTakashi Iwai
A driver might allow the mmap access before initializing its runtime->dma_area properly. Add a proper NULL check before passing to virt_to_page() for avoiding a panic. Reported-by: syzbot+4bf62a7b1d0f4fdb7ae2@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20241120141104.7060-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-11-21ALSA: docs: fix dead hyperlink to Intel HD-Audio specHridesh MG
Update the hyperlink as it currently redirects to a generic site instead of the actual specification. Signed-off-by: Hridesh MG <hridesh699@gmail.com> Link: https://patch.msgid.link/20241120155553.21099-1-hridesh699@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-11-21Merge tag 'kvmarm-fixes-6.13-1' of ↵Paolo Bonzini
https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 changes for 6.13, part #2 - Constrain invalidations from GICR_INVLPIR to only affect the LPI INTID space - Set of robustness improvements to the management of vgic irqs and GIC ITS table entries - Fix compilation issue w/ CONFIG_CC_OPTIMIZE_FOR_SIZE=y where set_sysreg_masks() wasn't getting inlined, breaking check for a constant sysreg index - Correct KVM's vPMU overflow condition to match the architecture for hyp and non-hyp counters
2024-11-21statmount: fix security option retrievalChristian Brauner
Fix the inverted check for security_sb_show_options(). Link: https://lore.kernel.org/r/c8eaa647-5d67-49b6-9401-705afcb7e4d7@stanley.mountain Link: https://lore.kernel.org/r/20241120-verehren-rhabarber-83a11b297bcc@brauner Fixes: aefff51e1c29 ("statmount: retrieve security mount options") Reviewed-by: Jeff Layton <jlayton@kernel.org> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Cc: stable@vger.kernel.org # mainline only Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-21statmount: clean up unescaped option handlingMiklos Szeredi
Move common code from opt_array/opt_sec_array to helper. This helper does more than just unescape options, so rename to statmount_opt_process(). Handle corner case of just a single character in options. Rename some local variables to better describe their function. Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Link: https://lore.kernel.org/r/20241120142732.55210-1-mszeredi@redhat.com Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-21Merge patch series "iomap: zero range flush fixes"Christian Brauner
Brian Foster <bfoster@redhat.com> says: Here's v4 of the zero range flush improvements. No real major changes here, mostly minor whitespace, naming issues, etc. * patches from https://lore.kernel.org/r/20241115200155.593665-1-bfoster@redhat.com: iomap: elide flush from partial eof zero range iomap: lift zeroed mapping handling into iomap_zero_range() iomap: reset per-iter state on non-error iter advances Link: https://lore.kernel.org/r/20241115200155.593665-1-bfoster@redhat.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-21fscache: Remove duplicate included headerThorsten Blum
Remove duplicate included header file linux/uio.h Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Link: https://lore.kernel.org/r/20240628062329.321162-2-thorsten.blum@toblux.com Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-21iomap: elide flush from partial eof zero rangeBrian Foster
iomap zero range flushes pagecache in certain situations to determine which parts of the range might require zeroing if dirty data is present in pagecache. The kernel robot recently reported a regression associated with this flushing in the following stress-ng workload on XFS: stress-ng --timeout 60 --times --verify --metrics --no-rand-seed --metamix 64 This workload involves repeated small, strided, extending writes. On XFS, this produces a pattern of post-eof speculative preallocation, conversion of preallocation from delalloc to unwritten, dirtying pagecache over newly unwritten blocks, and then rinse and repeat from the new EOF. This leads to repetitive flushing of the EOF folio via the zero range call XFS uses for writes that start beyond current EOF. To mitigate this problem, special case EOF block zeroing to prefer zeroing the folio over a flush when the EOF folio is already dirty. To do this, split out and open code handling of an unaligned start offset. This brings most of the performance back by avoiding flushes on zero range calls via write and truncate extension operations. The flush doesn't occur in these situations because the entire range is post-eof and therefore the folio that overlaps EOF is the only one in the range. Signed-off-by: Brian Foster <bfoster@redhat.com> Link: https://lore.kernel.org/r/20241115200155.593665-4-bfoster@redhat.com Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-21iomap: lift zeroed mapping handling into iomap_zero_range()Brian Foster
In preparation for special handling of subranges, lift the zeroed mapping logic from the iterator into the caller. Since this puts the pagecache dirty check and flushing in the same place, streamline the comments a bit as well. Signed-off-by: Brian Foster <bfoster@redhat.com> Link: https://lore.kernel.org/r/20241115200155.593665-3-bfoster@redhat.com Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-21iomap: reset per-iter state on non-error iter advancesBrian Foster
iomap_iter_advance() zeroes the processed and mapping fields on every non-error iteration except for the last expected iteration (i.e. return 0 expected to terminate the iteration loop). This appears to be circumstantial as nothing currently relies on these fields after the final iteration. Therefore to better faciliate iomap_iter reuse in subsequent patches, update iomap_iter_advance() to always reset per-iteration state on successful completion. Signed-off-by: Brian Foster <bfoster@redhat.com> Link: https://lore.kernel.org/r/20241115200155.593665-2-bfoster@redhat.com Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-21iomap: warn on zero range of a post-eof folioBrian Foster
iomap_zero_range() uses buffered writes for manual zeroing, no longer updates i_size for such writes, but is still explicitly called for post-eof ranges. The historical use case for this is zeroing post-eof speculative preallocation on extending writes from XFS. However, XFS also recently changed to convert all post-eof delalloc mappings to unwritten in the iomap_begin() handler, which means it now never expects manual zeroing of post-eof mappings. In other words, all post-eof mappings should be reported as holes or unwritten. This is a subtle dependency that can be hard to detect if violated because associated codepaths are likely to update i_size after folio locks are dropped, but before writeback happens to occur. For example, if XFS reverts back to some form of manual zeroing of post-eof blocks on write extension, writeback of those zeroed folios will now race with the presumed i_size update from the subsequent buffered write. Since iomap_zero_range() can't correctly zero post-eof mappings beyond EOF without updating i_size, warn if this ever occurs. This serves as minimal indication that if this use case is reintroduced by a filesystem, iomap_zero_range() might need to reconsider i_size updates for write extending use cases. Signed-off-by: Brian Foster <bfoster@redhat.com> Link: https://lore.kernel.org/r/20241115145931.535207-1-bfoster@redhat.com Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-21gpio: exar: set value when external pull-up or pull-down is presentSai Kumar Cholleti
Setting GPIO direction = high, sometimes results in GPIO value = 0. If a GPIO is pulled high, the following construction results in the value being 0 when the desired value is 1: $ echo "high" > /sys/class/gpio/gpio336/direction $ cat /sys/class/gpio/gpio336/value 0 Before the GPIO direction is changed from an input to an output, exar_set_value() is called with value = 1, but since the GPIO is an input when exar_set_value() is called, _regmap_update_bits() reads a 1 due to an external pull-up. regmap_set_bits() sets force_write = false, so the value (1) is not written. When the direction is then changed, the GPIO becomes an output with the value of 0 (the hardware default). regmap_write_bits() sets force_write = true, so the value is always written by exar_set_value() and an external pull-up doesn't affect the outcome of setting direction = high. The same can happen when a GPIO is pulled low, but the scenario is a little more complicated. $ echo high > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 1 $ echo in > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 0 $ echo low > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 1 Fixes: 36fb7218e878 ("gpio: exar: switch to using regmap") Co-developed-by: Matthew McClain <mmcclain@noprivs.com> Signed-off-by: Matthew McClain <mmcclain@noprivs.com> Signed-off-by: Sai Kumar Cholleti <skmr537@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241105071523.2372032-1-skmr537@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-21gpio: altera: Add missed base and label initialisationsAndy Shevchenko
During conversion driver to modern APIs the base field initial value of the GPIO chip was moved from -1 to 0, which triggers a warning. Add missed base initialisation as it was in the original code. Initialise the GPIO chip label correctly as it was done by of_mm_gpiochip_add_data() before the below mentioned change. Fixes: 50dded8d9d62 ("gpio: altera: Drop legacy-of-mm-gpiochip.h header") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241118095402.516989-1-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-21gpio: zevio: Add missed label initialisationAndy Shevchenko
Initialise the GPIO chip label correctly as it was done by of_mm_gpiochip_add_data() before the below mentioned change. Fixes: cf8f4462e5fa ("gpio: zevio: drop of_gpio.h header") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241118092729.516736-1-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-20Merge branch '6.12/scsi-fixes' into 6.13/scsi-stagingMartin K. Petersen
Pull in the fixes branch to resolve conflict in UFS core. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2024-11-20KVM: arm64: Use MDCR_EL2.HPME to evaluate overflow of hyp countersOliver Upton
The 'global enable control' (as it is termed in the architecture) for counters reserved by EL2 is MDCR_EL2.HPME. Use that instead of PMCR_EL0.E when evaluating the overflow state for hyp counters. Change the return value to a bool while at it, which better reflects the fact that the overflow state is a shared signal and not a per-counter property. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241120005230.2335682-3-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-11-20KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow statusRaghavendra Rao Ananta
DDI0487K.a D13.3.1 describes the PMU overflow condition, which evaluates to true if any counter's global enable (PMCR_EL0.E), overflow flag (PMOVSSET_EL0[n]), and interrupt enable (PMINTENSET_EL1[n]) are all 1. Of note, this does not require a counter to be enabled (i.e. PMCNTENSET_EL0[n] = 1) to generate an overflow. Align kvm_pmu_overflow_status() with the reality of the architecture and stop using PMCNTENSET_EL0 as part of the overflow condition. The bug was discovered while running an SBSA PMU test [*], which only sets PMCR.E, PMOVSSET<0>, PMINTENSET<0>, and expects an overflow interrupt. Cc: stable@vger.kernel.org Fixes: 76d883c4e640 ("arm64: KVM: Add access handler for PMOVSSET and PMOVSCLR register") Link: https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pmu/operating_system/test_pmu001.c Signed-off-by: Raghavendra Rao Ananta <rananta@google.com> [ oliver: massaged changelog ] Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241120005230.2335682-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-11-20KVM: arm64: Mark set_sysreg_masks() as inline to avoid build failureMarc Zyngier
When compiling with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, set_sysreg_masks() fails to compile thanks to: BUILD_BUG_ON(!__builtin_constant_p(sr)); as the compiler doesn't identify sr as a constant, despite all the callers passing constants. Fix the issue by always inlining this function, which allows GCC to do the right thing. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202411201857.ZNudtGJl-lkp@intel.com/ Fixes: a0162020095e2 ("KVM: arm64: Extend masking facility to arbitrary registers") Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Joey Gouly <joey.gouly@arm.com> Link: https://lore.kernel.org/r/20241120111516.304250-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-11-20KVM: arm64: vgic-its: Add stronger type-checking to the ITS entry sizesMarc Zyngier
The ITS ABI infrastructure allows for some pretty lax code, where the size of the data doesn't have to match the size of the entry, potentially leading to a collection of interesting bugs. Commit 7fe28d7e68f9 ("KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*") added some checks, but starts by implicitly casting all writes to a 64bit value, hiding some of the issues. Instead, introduce macros that will check the data type actually used for dealing with the table entries. The macros are taking a symbolic entry type that is used to fetch the size of the entry type for the current ABI. This immediately catches a couple of low-impact gotchas (zero values that are implicitly 32bit), easy enough to fix. Given that we currently only have a single ABI, hardcode a couple of BUILD_BUG_ON()s that will fire if we use anything but a 64bit quantity, and some (currently unreachable) fallback code that may become useful one day. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241117165757.247686-5-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-11-20KVM: arm64: vgic: Kill VGIC_MAX_PRIVATE definitionMarc Zyngier
VGIC_MAX_PRIVATE is a pretty useless definition, and is better replaced with VGIC_NR_PRIVATE_IRQS. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241117165757.247686-4-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-11-20KVM: arm64: vgic: Make vgic_get_irq() more robustMarc Zyngier
vgic_get_irq() has an awkward signature, as it takes both a kvm *and* a vcpu, where the vcpu is allowed to be NULL if the INTID being looked up is a global interrupt (SPI or LPI). This leads to potentially problematic situations where the INTID passed is a private interrupt, but that there is no vcpu. In order to make things less ambiguous, let have *two* helpers instead: - vgic_get_irq(struct kvm *kvm, u32 intid), which is only concerned with *global* interrupts, as indicated by the lack of vcpu. - vgic_get_vcpu_irq(struct kvm_vcpu *vcpu, u32 intid), which can return *any* interrupt class, but must have of course a non-NULL vcpu. Most of the code nicely falls under one or the other situations, except for a couple of cases (close to the UABI or in the debug code) where we have to distinguish between the two cases. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241117165757.247686-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-11-20KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIRMarc Zyngier
Make sure we filter out non-LPI invalidation when handling writes to GICR_INVLPIR. Fixes: 4645d11f4a553 ("KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation") Reported-by: Alexander Potapenko <glider@google.com> Tested-by: Alexander Potapenko <glider@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20241117165757.247686-2-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-11-20Merge tag 'soc-arm-6.13' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC updates from Arnd Bergmann: "The SoC specific code updates for 6.13 are fairly minimal. One Broadcom SoC model gains automatic configuration for the debug uarg as we have on many other machines, the remaining changes are trivial cleanups" * tag 'soc-arm-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: imx: Switch to new sys-off handler API ARM: bcm: brcmstb: Drop custom init_irq callback ARM: bcm: Support BCMBCA debug UART ARM: zynq: Remove unused zynq_slcr_init() declaration ASoC: samsung: Remove obsoleted declaration for s3c64xx_ac97_setup_gpio ARM: samsung: Remove obsoleted declaration for s3c_hwmon_set_platdata
2024-11-20Merge tag 'soc-defconfig-6.13' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC defconfig updates from Arnd Bergmann: "As usual, a few newly added device drivers get enabled in the arm32 multi_v7_defconfig and arm64 defconfig as well as a few of the SoC specific config files. The main visible change is the inclusion of (reduced) debug info by default in the 32-bit defconfig" * tag 'soc-defconfig-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: imx_v6_v7_defconfig: Enable drivers for Kobo Clara 2E arm64: defconfig: Enable VBATTB clock and Renesas RTCA-3 arm64: defconfig: Enable PCF857X GPIO expander arm64: defconfig: Enable sc7280 clock controllers ARM: configs: at91: enable PAC1934 driver as module ARM: multi_v7_defconfig: Enable debugging symbols by default
2024-11-20Merge tag 'soc-drivers-6.13' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC driver updates from Arnd Bergmann: "Nothing particular important in the SoC driver updates, just the usual improvements to for drivers/soc and a couple of subsystems that don't fit anywhere else: - The largest set of updates is for Qualcomm SoC drivers, extending the set of supported features for additional SoCs in the QSEECOM, LLCC and socinfo drivers.a - The ti_sci firmware driver gains support for power managment - The drivers/reset subsystem sees a rework of the microchip sparx5 and amlogic reset drivers to support additional chips, plus a few minor updates on other platforms - The SCMI firmware interface driver gains support for two protocol extensions, allowing more flexible use of the shared memory area and new DT binding properties for configurability. - Mediatek SoC drivers gain support for power managment on the MT8188 SoC and a new driver for DVFS. - The AMD/Xilinx ZynqMP SoC drivers gain support for system reboot and a few bugfixes - The Hisilicon Kunpeng HCCS driver gains support for configuring lanes through sysfs Finally, there are cleanups and minor fixes for drivers/{soc, bus, memory}, including changing back the .remove_new callback to .remove, as well as a few other updates for freescale (powerpc) soc drivers, NXP i.MX soc drivers, cznic turris platform driver, memory controller drviers, TI OMAP SoC drivers, and Tegra firmware drivers" * tag 'soc-drivers-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (116 commits) soc: fsl: cpm1: qmc: Set the ret error code on platform_get_irq() failure soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting() soc: fsl: cpm1: tsa: switch to for_each_available_child_of_node_scoped() platform: cznic: turris-omnia-mcu: Rename variable holding GPIO line names platform: cznic: turris-omnia-mcu: Document the driver private data structure firmware: turris-mox-rwtm: Document the driver private data structure bus: Switch back to struct platform_driver::remove() soc: qcom: ice: Remove the device_link field in qcom_ice drm/msm/adreno: Setup SMMU aparture for per-process page table firmware: qcom: scm: Introduce CP_SMMU_APERTURE_ID firmware: arm_scpi: Check the DVFS OPP count returned by the firmware soc: qcom: socinfo: add IPQ5424/IPQ5404 SoC ID dt-bindings: arm: qcom,ids: add SoC ID for IPQ5424/IPQ5404 soc: qcom: llcc: Flip the manual slice configuration condition dt-bindings: firmware: qcom,scm: Document sm8750 SCM firmware: qcom: uefisecapp: Allow X1E Devkit devices misc: lan966x_pci: Fix dtc warn 'Missing interrupt-parent' misc: lan966x_pci: Fix dtc warns 'missing or empty reg/ranges property' soc: qcom: llcc: Add LLCC configuration for the QCS8300 platform dt-bindings: cache: qcom,llcc: Document the QCS8300 LLCC ...
2024-11-20Merge tag 'soc-dt-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds
Pull SoC devicetree updates from Arnd Bergmann: "This release adds the devicetree files for an impressive number of new SoC variants, though as expected these are all related to others we already support: - The microchip sam9x7 devicetree is now added, after the device driver and platform code has already made it in. This is likely the last ARMv5 (!) platform to ever get added, updating the 20+ year old at91/sam9 platform with DDR3 memory and gigabit ethernet. - On the Apple platform, there are now devicetree files for a number of A-series SoCs in addition to the M-series ones, these are used primarily in phones and tablets, but are closely related to the already supported chips. - Samsung Exynos 8895 and Exynos 990 are more phone SoCs used in older Samsung Galaxy phones. - Qualcomm Snapdragon 778G (SM7325) is another phone SoC, closely related to the Snapdragon 7c+ Gen 3 (SC7280) used in low-end laptops. - Rockchip RK3528 and RK3576 are new variants of their TV box and Tablet chips, still using the older ARMv8.0 cores from RK3328/RK3399 but with a newer process and other improvements from the RK35xx (otherwise ARMv8.2) chips. RK3566T and RK3399-S are also added, these are just lower-cost versions of their normal counterparts. - TI J742S2 is a feature-reduced version of the J784s4 industrial/automotive SoC, with fewer CPU cores. - Sophgo SG2002 is an embedded SoC with one RISC-V (C906) and one ARM (Cortex-A53) core, at this point support is only added for running on the RISC-V side on the LicheeRV Nano board. A total of 92 new .dts files describing individual machines is added, which must be a new record. The majority of these is for the newly added chips above, notably all the Apple phones and tablets. The other new machines include nine industrial/embedded boards with NXP i.MX6 or i.MX8 SoCs, eight for Rockchips RK35XX and one or two each for Rockchips RV1109, RK3308, Allwinner A33, Tegra 234, Qualcomm qcs9100/sc8280xp/x1e80100, TI AM625 and Starfive JH7110. As usual there are also many newly added features in existing boards as well as cleanups and minor bugfixes" * tag 'soc-dt-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (718 commits) arm64: dts: apm: Remove unused and undocumented "bus_num" property arm: dts: spear13xx: Remove unused and undocumented "pl022,slave-tx-disable" property arm64: dts: amd: Remove unused and undocumented "amd,zlib-support" property arm64: dts: lg131x: Update spi clock properties arm64: dts: seattle: Update spi clock properties arm64: dts: rockchip: use less broad pinctrl for pcie3x1 on Radxa E25 arm64: dts: rockchip: add Radxa ROCK 5C dt-bindings: arm: rockchip: add Radxa ROCK 5C arm64: dts: rockchip: orangepi-5-plus: Enable GPU arm64: dts: rockchip: enable USB3 on NanoPC-T6 arm64: dts: rockchip: adapt regulator nodenames to preferred form arm64: dts: rockchip: Enable HDMI display for rk3588 Cool Pi GenBook arm64: dts: rockchip: Enable HDMI display for rk3588 Cool Pi 4B arm64: dts: rockchip: Enable HDMI0 for rk3588 Cool Pi CM5 EVB arm64: dts: rockchip: Enable HDMI on NanoPi R6C/R6S arm64: dts: rockchip: Enable GPU on NanoPi R6C/R6S arm64: dts: rockchip: Enable HDMI on Hardkernel ODROID-M2 arm64: dts: rockchip: Remove non-removable flag from sdmmc on rk3576-sige5 arm64: dts: allwinner: a100: perf1: Add eMMC and MMC node arm64: dts: allwinner: pinephone: Add mount matrix to accelerometer ...
2024-11-20Merge tag 'asm-generic-3.13' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pull asm-generic updates from Arnd Bergmann: "These are a number of unrelated cleanups, generally simplifying the architecture specific header files: - A series from Al Viro simplifies asm/vga.h, after it turns out that most of it can be generalized. - A series from Julian Vetter adds a common version of memcpy_{to,from}io() and memset_io() and changes most architectures to use that instead of their own implementation - A series from Niklas Schnelle concludes his work to make PC style inb()/outb() optional - Nicolas Pitre contributes improvements for the generic do_div() helper - Christoph Hellwig adds a generic version of page_to_phys() and phys_to_page(), replacing the slightly different architecture specific definitions. - Uwe Kleine-Koenig has a minor cleanup for ioctl definitions" * tag 'asm-generic-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: (24 commits) empty include/asm-generic/vga.h sparc: get rid of asm/vga.h asm/vga.h: don't bother with scr_mem{cpy,move}v() unless we need to vt_buffer.h: get rid of dead code in default scr_...() instances tty: serial: export serial_8250_warn_need_ioport lib/iomem_copy: fix kerneldoc format style hexagon: simplify asm/io.h for !HAS_IOPORT loongarch: Use new fallback IO memcpy/memset csky: Use new fallback IO memcpy/memset arm64: Use new fallback IO memcpy/memset New implementation for IO memcpy and IO memset watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240 __arch_xprod64(): make __always_inline when optimizing for performance ARM: div64: improve __arch_xprod_64() asm-generic/div64: optimize/simplify __div64_const32() lib/math/test_div64: add some edge cases relevant to __div64_const32() asm-generic: add an optional pfn_valid check to page_to_phys asm-generic: provide generic page_to_phys and phys_to_page implementations asm-generic/io.h: Remove I/O port accessors for HAS_IOPORT=n tty: serial: handle HAS_IOPORT dependencies ...
2024-11-20Merge tag 'for-linus' of https://github.com/openrisc/linuxLinus Torvalds
Pull OpenRISC update from Stafford Horne: "A single fixup from me: Fix bug with earlycon being broken due to removal of early_ioremap" * tag 'for-linus' of https://github.com/openrisc/linux: openrisc: Implement fixmap to fix earlycon
generated by cgit (git 2.34.1) at 2025-09-12 23:28:10 +0000