summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-04-24KVM: x86: Do not use kvm_rip_read() unconditionally for KVM_PROFILINGAdrian Hunter
Not all VMs allow access to RIP. Check guest_state_protected before calling kvm_rip_read(). This avoids, for example, hitting WARN_ON_ONCE in vt_cache_reg() for TDX VMs. Fixes: 81bf912b2c15 ("KVM: TDX: Implement TDX vcpu enter/exit path") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Message-ID: <20250415104821.247234-3-adrian.hunter@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24KVM: x86: Do not use kvm_rip_read() unconditionally in KVM tracepointsAdrian Hunter
Not all VMs allow access to RIP. Check guest_state_protected before calling kvm_rip_read(). This avoids, for example, hitting WARN_ON_ONCE in vt_cache_reg() for TDX VMs. Fixes: 81bf912b2c15 ("KVM: TDX: Implement TDX vcpu enter/exit path") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Message-ID: <20250415104821.247234-2-adrian.hunter@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24KVM: SVM: WARN if an invalid posted interrupt IRTE entry is addedSean Christopherson
Now that the AMD IOMMU doesn't signal success incorrectly, WARN if KVM attempts to track an AMD IRTE entry without metadata. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20250404193923.1413163-8-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24iommu/amd: WARN if KVM attempts to set vCPU affinity without posted intrruptsSean Christopherson
WARN if KVM attempts to set vCPU affinity when posted interrupts aren't enabled, as KVM shouldn't try to enable posting when they're unsupported, and the IOMMU driver darn well should only advertise posting support when AMD_IOMMU_GUEST_IR_VAPIC() is true. Note, KVM consumes is_guest_mode only on success. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20250404193923.1413163-7-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24iommu/amd: Return an error if vCPU affinity is set for non-vCPU IRTESean Christopherson
Return -EINVAL instead of success if amd_ir_set_vcpu_affinity() is invoked without use_vapic; lying to KVM about whether or not the IRTE was configured to post IRQs is all kinds of bad. Fixes: d98de49a53e4 ("iommu/amd: Enable vAPIC interrupt remapping mode by default") Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20250404193923.1413163-6-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24KVM: x86: Take irqfds.lock when adding/deleting IRQ bypass producerSean Christopherson
Take irqfds.lock when adding/deleting an IRQ bypass producer to ensure irqfd->producer isn't modified while kvm_irq_routing_update() is running. The only lock held when a producer is added/removed is irqbypass's mutex. Fixes: 872768800652 ("KVM: x86: select IRQ_BYPASS_MANAGER") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20250404193923.1413163-5-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24KVM: x86: Explicitly treat routing entry type changes as changesSean Christopherson
Explicitly treat type differences as GSI routing changes, as comparing MSI data between two entries could get a false negative, e.g. if userspace changed the type but left the type-specific data as-is. Fixes: 515a0c79e796 ("kvm: irqfd: avoid update unmodified entries of the routing") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20250404193923.1413163-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24KVM: x86: Reset IRTE to host control if *new* route isn't postableSean Christopherson
Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed. Fixes: efc644048ecd ("KVM: x86: Update IRTE for posted-interrupts") Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted interrupt") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20250404193923.1413163-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24KVM: SVM: Allocate IR data using atomic allocationSean Christopherson
Allocate SVM's interrupt remapping metadata using GFP_ATOMIC as svm_ir_list_add() is called with IRQs are disabled and irqfs.lock held when kvm_irq_routing_update() reacts to GSI routing changes. Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted interrupt") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20250404193923.1413163-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24KVM: SVM: Don't update IRTEs if APICv/AVIC is disabledSean Christopherson
Skip IRTE updates if AVIC is disabled/unsupported, as forcing the IRTE into remapped mode (kvm_vcpu_apicv_active() will never be true) is unnecessary and wasteful. The IOMMU driver is responsible for putting IRTEs into remapped mode when an IRQ is allocated by a device, long before that device is assigned to a VM. I.e. the kernel as a whole has major issues if the IRTE isn't already in remapped mode. Opportunsitically kvm_arch_has_irq_bypass() to query for APICv/AVIC, so so that all checks in KVM x86 incorporate the same information. Cc: Yosry Ahmed <yosry.ahmed@linux.dev> Cc: Jim Mattson <jmattson@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20250401161804.842968-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24KVM: arm64, x86: make kvm_arch_has_irq_bypass() inlinePaolo Bonzini
kvm_arch_has_irq_bypass() is a small function and even though it does not appear in any *really* hot paths, it's also not entirely rare. Make it inline---it also works out nicely in preparation for using it in kvm-intel.ko and kvm-amd.ko, since the function is not currently exported. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-04-24block: don't autoload drivers on blk-cgroup configurationChristoph Hellwig
Loading a driver just to configure blk-cgroup doesn't make sense, as that assumes and already existing device. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Christian Brauner <brauner@kernel.org> Acked-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/20250423053810.1683309-5-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-24block: don't autoload drivers on statChristoph Hellwig
blkdev_get_no_open can trigger the legacy autoload of block drivers. A simple stat of a block device has not historically done that, so disable this behavior again. Fixes: 9abcfbd235f5 ("block: Add atomic write support for statx") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Christian Brauner <brauner@kernel.org> Acked-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/20250423053810.1683309-4-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-24block: remove the backing_inode variable in bdev_statxChristoph Hellwig
backing_inode is only used once, so remove it and update the comment describing the bdev lookup to be a bit more clear. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Christian Brauner <brauner@kernel.org> Acked-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/20250423053810.1683309-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-24block: move blkdev_{get,put} _no_open prototypes out of blkdev.hChristoph Hellwig
These are only to be used by block internal code. Remove the comment as we grew more users due to reworking block device node opening. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Christian Brauner <brauner@kernel.org> Acked-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/20250423053810.1683309-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-24block: never reduce ra_pages in blk_apply_bdi_limitsChristoph Hellwig
When the user increased the read-ahead size through sysfs this value currently get lost if the device is reprobe, including on a resume from suspend. As there is no hardware limitation for the read-ahead size there is no real need to reset it or track a separate hardware limitation like for max_sectors. This restores the pre-atomic queue limit behavior in the sd driver as sd did not use blk_queue_io_opt and thus never updated the read ahead size to the value based of the optimal I/O, but changes behavior for all other drivers. As the new behavior seems useful and sd is the driver for which the readahead size tweaks are most useful that seems like a worthwhile trade off. Fixes: 804e498e0496 ("sd: convert to the atomic queue limits API") Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20250424082521.1967286-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-24selftests: ublk: common: fix _get_disk_dev_t for pre-9.0 coreutilsUday Shankar
Some distributions, such as centos stream 9, still have a version of coreutils which does not yet support the %Hr and %Lr formats for stat(1) [1, 2]. Running ublk selftests on these distributions results in the following error in tests that use the _get_disk_dev_t helper: line 23: ?r: syntax error: operand expected (error token is "?r") To better accommodate older distributions, rewrite _get_disk_dev_t to use the much older %t and %T formats for stat instead. [1] https://github.com/coreutils/coreutils/blob/v9.0/NEWS#L114 [2] https://pkgs.org/download/coreutils Signed-off-by: Uday Shankar <ushankar@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250423-ublk_selftests-v1-2-7d060e260e76@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-24io_uring: don't duplicate flushing in io_req_post_cqePavel Begunkov
io_req_post_cqe() sets submit_state.cq_flush so that *flush_completions() can take care of batch commiting CQEs. Don't commit it twice by using __io_cq_unlock_post(). Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/41c416660c509cee676b6cad96081274bcb459f3.1745493861.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-24Merge tag 'nvme-6.15-2025-04-24' of git://git.infradead.org/nvme into block-6.15Jens Axboe
Pull NVMe fix from Christoph: "nvme fixes for Linux 6.15 - fix an out-of-bounds access in nvmet_enable_port (Richard Weinberger)" * tag 'nvme-6.15-2025-04-24' of git://git.infradead.org/nvme: nvmet: fix out-of-bounds access in nvmet_enable_port
2025-04-24rust: drm: file: Add File abstractionAsahi Lina
A DRM File is the DRM counterpart to a kernel file structure, representing an open DRM file descriptor. Add a Rust abstraction to allow drivers to implement their own File types that implement the DriverFile trait. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-7-dakr@kernel.org [ Rework of drm::File * switch to the Opaque<T> type * fix (mutable) references to struct drm_file (which in this context is UB) * restructure and rename functions to align with common kernel schemes * write and fix safety and invariant comments * remove necessity for and convert 'as' casts * original source archive: https://archive.is/GH8oy - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24rust: drm: add DRM driver registrationAsahi Lina
Implement the DRM driver `Registration`. The `Registration` structure is responsible to register and unregister a DRM driver. It makes use of the `Devres` container in order to allow the `Registration` to be owned by devres, such that it is automatically dropped (and the DRM driver unregistered) once the parent device is unbound. Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-6-dakr@kernel.org [ Rework of drm::Registration * move VTABLE to drm::Device to prevent use-after-free bugs; VTABLE needs to be bound to the lifetime of drm::Device, not the drm::Registration * combine new() and register() to get rid of the registered boolean * remove file_operations * move struct drm_device creation to drm::Device * introduce Devres * original source archive: https://archive.is/Pl9ys - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24rust: drm: add device abstractionAsahi Lina
Implement the abstraction for a `struct drm_device`. A `drm::Device` creates a static const `struct drm_driver` filled with the data from the `drm::Driver` trait implementation of the actual driver creating the `drm::Device`. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-5-dakr@kernel.org [ Rewrite of drm::Device * full rewrite of the drm::Device abstraction using the subclassing pattern * original source archive: http://archive.today/5NxBo - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24spi: spi-qpic-snand: propagate errors from qcom_spi_block_erase()Gabor Juhos
The qcom_spi_block_erase() function returns with error in case of failure. Change the qcom_spi_send_cmdaddr() function to propagate these errors to the callers instead of returning with success. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://patch.msgid.link/20250423-qpic-snand-propagate-error-v1-1-4b26ed45fdb5@gmail.com Reviewed-by: Md Sadre Alam <quic_mdalam@quicinc.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-04-24ASoC: renesas: rz-ssi: Use NOIRQ_SYSTEM_SLEEP_PM_OPS()Claudiu Beznea
In the latest kernel versions system crashes were noticed occasionally during suspend/resume. This occurs because the RZ SSI suspend trigger (called from snd_soc_suspend()) is executed after rz_ssi_pm_ops->suspend() and it accesses IP registers. After the rz_ssi_pm_ops->suspend() is executed the IP clocks are disabled and its reset line is asserted. Since snd_soc_suspend() is invoked through snd_soc_pm_ops->suspend(), snd_soc_pm_ops is associated with soc_driver (defined in sound/soc/soc-core.c), and there is no parent-child relationship between soc_driver and rz_ssi_driver the power management subsystem does not enforce a specific suspend/resume order between the RZ SSI platform driver and soc_driver. To ensure that the suspend/resume function of rz-ssi is executed after snd_soc_suspend(), use NOIRQ_SYSTEM_SLEEP_PM_OPS(). Fixes: 1fc778f7c833 ("ASoC: renesas: rz-ssi: Add suspend to RAM support") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20250410141525.4126502-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-04-24rust: drm: add driver abstractionsAsahi Lina
Implement the DRM driver abstractions. The `Driver` trait provides the interface to the actual driver to fill in the driver specific data, such as the `DriverInfo`, driver features and IOCTLs. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-4-dakr@kernel.org [ MISC changes * remove unnecessary DRM features; make remaining ones crate private * add #[expect(unused)] to avoid warnings * add sealed trait * remove shmem::Object references * original source archive: https://archive.is/Pl9ys - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24rust: drm: ioctl: Add DRM ioctl abstractionAsahi Lina
DRM drivers need to be able to declare which driver-specific ioctls they support. Add an abstraction implementing the required types and a helper macro to generate the ioctl definition inside the DRM driver. Note that this macro is not usable until further bits of the abstraction are in place (but it will not fail to compile on its own, if not called). Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-3-dakr@kernel.org [ MISC fixes * wrap raw_data in Opaque to avoid UB when creating a reference * fix IOCTL sample declaration * fix safety comment of IOCTL argument * original source archive: https://archive.is/LqHDQ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24drm: drv: implement __drm_dev_alloc()Danilo Krummrich
In the Rust DRM device abstraction we need to allocate a struct drm_device. Currently, there are two options, the deprecated drm_dev_alloc() (which does not support subclassing) and devm_drm_dev_alloc(). The latter supports subclassing, but also manages the initial reference through devres for the parent device. In Rust we want to conform with the subclassing pattern, but do not want to get the initial reference managed for us, since Rust has its own, idiomatic ways to properly deal with it. There are two options to achieve this. 1) Allocate the memory ourselves with a KBox. 2) Implement __drm_dev_alloc(), which supports subclassing, but is unmanged. While (1) would be possible, it would be cumbersome, since it would require exporting drm_dev_init() and drmm_add_final_kfree(). Hence, go with option (2) and implement __drm_dev_alloc(). Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250410235546.43736-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-04-24Merge drm/drm-next into drm-xe-nextThomas Hellström
Backmerge to bring in linux 6.15-rc. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-04-24drm/imagination: Add reset controller support for GPU initializationMichal Wilczynski
All IMG Rogue GPUs include a reset line that participates in the power-up sequence. On some SoCs (e.g., T-Head TH1520 and Banana Pi BPI-F3), this reset line is exposed and must be driven explicitly to ensure proper initialization. On others, such as the currently supported TI SoC, the reset logic is handled in hardware or firmware without exposing the line directly. In platforms where the reset line is externally accessible, if it is not driven correctly, the GPU may remain in an undefined state, leading to instability or performance issues. This commit adds a dedicated reset controller to the drm/imagination driver. By managing the reset line (where applicable) as part of normal GPU bring-up, the driver ensures reliable initialization across platforms regardless of whether the reset is controlled externally or handled internally. Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://lore.kernel.org/r/20250418-apr_18_reset_img-v6-2-85a06757b698@samsung.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-24dt-bindings: gpu: Add 'resets' property for GPU initializationMichal Wilczynski
All IMG Rogue GPUs include a reset line that participates in the power-up sequence. On some SoCs (e.g., T-Head TH1520 and Banana Pi BPI-F3), this reset line is exposed and must be driven explicitly to ensure proper initialization. To support this, add a 'resets' property to the GPU device tree bindings. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://lore.kernel.org/r/20250418-apr_18_reset_img-v6-1-85a06757b698@samsung.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-24drm/imagination: avoid unused-const-variable warningArnd Bergmann
When CONFIG_DEBUG_FS is disabled, the stid_fmts[] array is not referenced anywhere, causing a W=1 warning with gcc: In file included from drivers/gpu/drm/imagination/pvr_fw_trace.c:7: drivers/gpu/drm/imagination/pvr_rogue_fwif_sf.h:75:39: error: 'stid_fmts' defined but not used [-Werror=unused-const-variable=] 75 | static const struct rogue_km_stid_fmt stid_fmts[] = { | ^~~~~~~~~ Rather than adding more #ifdef blocks, address this by changing the existing #ifdef into equivalent IS_ENABLED() checks so gcc can see where the symbol is used but still eliminate it from the object file. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://lore.kernel.org/r/20250409122314.2848028-1-arnd@kernel.org Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-24Merge branch 'net-stmmac-fix-timestamp-snapshots-on-dwmac1000'Paolo Abeni
Alexis Lothore says: ==================== net: stmmac: fix timestamp snapshots on dwmac1000 this is the v2 of a small series containing two small fixes for the timestamp snapshot feature on stmmac, especially on dwmac1000 version. Those issues have been detected on a socfpga (Cyclone V) platform. They kind of follow the big rework sent by Maxime at the end of last year to properly split this feature support between different versions of the DWMAC IP. v1: https://lore.kernel.org/r/20250422-stmmac_ts-v1-0-b59c9f406041@bootlin.com Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> ==================== Link: https://patch.msgid.link/20250423-stmmac_ts-v2-0-e2cf2bbd61b1@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-24net: stmmac: fix multiplication overflow when reading timestampAlexis Lothoré
The current way of reading a timestamp snapshot in stmmac can lead to integer overflow, as the computation is done on 32 bits. The issue has been observed on a dwmac-socfpga platform returning chaotic timestamp values due to this overflow. The corresponding multiplication is done with a MUL instruction, which returns 32 bit values. Explicitly casting the value to 64 bits replaced the MUL with a UMLAL, which computes and returns the result on 64 bits, and so returns correctly the timestamps. Prevent this overflow by explicitly casting the intermediate value to u64 to make sure that the whole computation is made on u64. While at it, apply the same cast on the other dwmac variant (GMAC4) method for snapshot retrieval. Fixes: 477c3e1f6363 ("net: stmmac: Introduce dwmac1000 timestamping operations") Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20250423-stmmac_ts-v2-2-e2cf2bbd61b1@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-24net: stmmac: fix dwmac1000 ptp timestamp status offsetAlexis Lothore
When a PTP interrupt occurs, the driver accesses the wrong offset to learn about the number of available snapshots in the FIFO for dwmac1000: it should be accessing bits 29..25, while it is currently reading bits 19..16 (those are bits about the auxiliary triggers which have generated the timestamps). As a consequence, it does not compute correctly the number of available snapshots, and so possibly do not generate the corresponding clock events if the bogus value ends up being 0. Fix clock events generation by reading the correct bits in the timestamp register for dwmac1000. Fixes: 477c3e1f6363 ("net: stmmac: Introduce dwmac1000 timestamping operations") Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20250423-stmmac_ts-v2-1-e2cf2bbd61b1@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-24net: dp83822: Fix OF_MDIO config checkJohannes Schneider
When CONFIG_OF_MDIO is set to be a module the code block is not compiled. Use the IS_ENABLED macro that checks for both built in as well as module. Fixes: 5dc39fd5ef35 ("net: phy: DP83822: Add ability to advertise Fiber connection") Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20250423044724.1284492-1-johannes.schneider@leica-geosystems.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-24selftests/fs/mount-notify: test also remove/flush of mntns marksAmir Goldstein
Regression test for FAN_MARK_MNTFS | FAN_MARK_FLUSH bug. Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20250418193903.2607617-3-amir73il@gmail.com
2025-04-24fanotify: fix flush of mntns marksAmir Goldstein
fanotify_mark(fd, FAN_MARK_FLUSH | FAN_MARK_MNTNS, ...) incorrectly ends up causing removal inode marks. Fixes: 0f46d81f2bce ("fanotify: notify on mount attach and detach") Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20250418193903.2607617-2-amir73il@gmail.com
2025-04-24drm/i915/display: Disintegrate sink alpm enable from psr with lobfAnimesh Manna
Make a generic alpm enable function for sink which can be used for PSR2/PR/Lobf. v1: Initial version. v2: Move code comment to intel_psr_needs_alpm(). [Jouni] Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-12-animesh.manna@intel.com
2025-04-24drm/i915/alpm: Add intel_psr_need_alpm() to simplify alpm checkAnimesh Manna
Simplify the alpm check which will be used multiple places like source configuration, sink enablement etc. Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-11-animesh.manna@intel.com
2025-04-24drm/i915/lobf: Check for sink error and disable LOBFAnimesh Manna
Disable LOBF/ALPM for any erroneous condition from sink side. v1: Initial version. v2: Add centralized alpm error handling. [Jouni] v3: Improve debug print. [Jouni] v4: Disable alpm permanently for sink error. [Jouni] Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-10-animesh.manna@intel.com
2025-04-24drm/i915/lobf: Add mutex for alpm updateAnimesh Manna
The ALPM_CTL can be updated from different context, so add mutex to sychonize the update. Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-9-animesh.manna@intel.com
2025-04-24drm/i915/lobf: Add debug interface for lobfAnimesh Manna
Add an interface in debugfs which will help in debugging LOBF feature. v1: Initial version. v2: - Remove FORCE_EN flag. [Jouni] - Change prefix from I915 to INTEL. [Jani] - Use u8 instead of bool for lobf-debug flag. [Jani] v3: - Use intel_connector instead of display. [Jani] - Remove edp connector check as it was already present in caller function. [Jani] - Remove loop of searching edp encoder which is directly accessible from intel_connector. [Jani] v4: - Simplify alpm debug to bool instead of bit-mask. [Jani] v5: - Remove READ_ONCE(). [Jani] - Modify variable name to *_disable_*. [Jouni] v6: Improved debug print. [Jouni] Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-8-animesh.manna@intel.com
2025-04-24drm/i915/lobf: Update lobf if any change in dependent parametersAnimesh Manna
For every commit the dependent condition for LOBF is checked and accordingly update has_lobf flag which will be used to update the ALPM_CTL register during commit. v1: Initial version. v2: Avoid reading h/w register without has_lobf check. [Jani] v3: Update LOBF in post plane update instead of separate function. [Jouni] v4: - Add lobf disable print. [Jouni] - Simplify condition check for enabling/disabling lobf. [Jouni] v5: Disable LOBF in pre_plane_update(). [Jouni] v6: use lobf flag of old_crtc_state and write 0 into ALPM_CTL. [Jouni] Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-7-animesh.manna@intel.com
2025-04-24drm/i915/lobf: Add fixed refresh rate check in compute_config()Animesh Manna
LOBF can be enabled with vrr fixed rate mode, so add check if vmin = vmax = flipline in compute_config(). Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-6-animesh.manna@intel.com
2025-04-24drm/i915/lobf: Disintegrate alpm_disable from psr_disableAnimesh Manna
Currently clearing of alpm registers is done through psr_disable() which is always not correct, without psr also alpm can exist. So dis-integrate alpm_disable() from psr_disable(). v1: Initial version. v2: - Remove h/w register read from alpm_disable(). [Jani] Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-5-animesh.manna@intel.com
2025-04-24drm/i915/lobf: Add debug print for LOBFAnimesh Manna
Lobf is enabled part of ALPM configuration and if has_lobf is set to true respective bit for LOBF will be set. Add debug print while setting the bitfield of LOBF. Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-4-animesh.manna@intel.com
2025-04-24drm/i915/lobf: Add lobf enablement in post plane updateAnimesh Manna
Enablement of LOBF is added in post plane update whenever has_lobf flag is set. As LOBF can be enabled in non-psr case as well so adding in post plane update. There is no change of configuring alpm with psr path. v1: Initial version. v2: Use encoder-mask to find the associated encoder from crtc-state. [Jani] v3: Remove alpm_configure from intel_psr.c. [Jouni] Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-3-animesh.manna@intel.com
2025-04-24drm/i915/alpm: use variable from intel_crtc_state instead of intel_psrJouni Högander
Currently code is making assumption that PSR is enabled when intel_alpm_configure is called. This doesn't work if alpm is configured before PSR is enabled. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://lore.kernel.org/r/20250423092334.2294483-2-animesh.manna@intel.com
2025-04-24drm/panel: himax-hx8279: Always initialize goa_{even,odd}_valid in ↵Nathan Chancellor
hx8279_check_goa_config() Clang warns (or errors with CONFIG_WERROR=y): drivers/gpu/drm/panel/panel-himax-hx8279.c:838:6: error: variable 'goa_even_valid' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] 838 | if (num_zero == ARRAY_SIZE(desc->goa_even_timing)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/panel/panel-himax-hx8279.c:842:23: note: uninitialized use occurs here 842 | if (goa_odd_valid != goa_even_valid) | ^~~~~~~~~~~~~~ drivers/gpu/drm/panel/panel-himax-hx8279.c:838:2: note: remove the 'if' if its condition is always true 838 | if (num_zero == ARRAY_SIZE(desc->goa_even_timing)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 839 | goa_even_valid = false; drivers/gpu/drm/panel/panel-himax-hx8279.c:818:36: note: initialize the variable 'goa_even_valid' to silence this warning 818 | bool goa_odd_valid, goa_even_valid; | ^ | = 0 Even though only the even valid variable gets flagged, both valid variables appear to have the same issue of possibly being used uninitialized if the if statement initializing them to false is not taken. Turn the if statement then variable assignment into a single variable assignment, which states that the configuration is valid when there are not all zeros, clearing up the warning since the variable will always be initialized. Fixes: 38d42c261389 ("drm: panel: Add driver for Himax HX8279 DDIC panels") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250423-panel-himax-hx8279-fix-sometimes-uninitialized-v2-1-fc501c6558d9@kernel.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250423-panel-himax-hx8279-fix-sometimes-uninitialized-v2-1-fc501c6558d9@kernel.org
2025-04-24drm/i915/reg: Add/remove some extra blank linesJani Nikula
Add/remove some blank lines to/from i915_reg.h primarily to help the scripted refactoring coming up, separating unrelated registers and keeping the comments together. v2: Also add some extra blank lines Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> # v1 Link: https://lore.kernel.org/r/20250423100213.720585-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit (git 2.34.1) at 2025-09-11 21:29:55 +0000